Free CAS-005 Practice Questions – 2026 Updated

The requirements to hash, version control, keep updated, and scan container images are all security and quality gates that should be enforced before deployment. Integrating these checks into a Continuous Integration/Continuous Deployment (CI/CD) pipeline automates this enforcement. During the CI phase, the pipeline can build the image, assign a version tag, generate a cryptographic hash (digest), and run a vulnerability scanner against it. The pipeline can be configured to fail the build if vulnerabilities are found or other quality checks are not met, preventing insecure images from ever reaching the container registry or production environment. This approach aligns with modern DevSecOps principles of "shifting security left."

A. Service meshes and Access Control Lists (ACLs) are runtime controls that manage network traffic between running containers, not security controls for the static container images themselves.

C. Auditing is a detective control that identifies non-compliance after an image has been built or deployed, rather than a preventative control that ensures requirements are met beforehand.

D. Pulling images directly from a public vendor repository and deploying them without internal validation and scanning is a highly insecure practice that bypasses essential security checks.

1. National Institute of Standards and Technology. (2017). SP 800-190

Application Container Security Guide. Section 3.2.2

"Vulnerability Scanning

" states

"Organizations should integrate vulnerability scanning tools into their CI/CD pipelines to ensure that images that have known vulnerabilities are not pushed to the registry." Section 3.2.1

"Image Signing

" discusses using cryptographic methods to ensure image integrity

a process also managed within the pipeline. (https://doi.org/10.6028/NIST.SP.800-190)

2. Pape

F. (2021). Lecture 10: DevSecOps. CS 161: Computer Security

University of California

Berkeley. Course materials emphasize integrating security tools like static analysis and vulnerability scanners directly into the CI/CD pipeline to automate security checks early in the development lifecycle.

3. Red Hat. (n.d.). Securing the build pipeline. Red Hat OpenShift Documentation. This official vendor documentation details the best practice of incorporating security checks

such as static code analysis and vulnerability scanning of dependencies and container images

within the CI/CD pipeline to secure the software supply chain.

The most appropriate and robust solution to ensure logs are properly retained in an enterprise environment is to use a Security Information and Event Management (SIEM) system. A SIEM is specifically designed to collect, aggregate, normalize, and securely store logs from disparate sources, including legacy platforms. By forwarding the logs from the legacy system to the SIEM, the organization centralizes log management, overcomes the local storage limitations of the legacy platform, and ensures compliance with long-term retention policies mandated by the audit. This approach provides a scalable, secure, and searchable archive for forensic analysis and compliance reporting.

A. A scheduled task is a brittle, localized solution that lacks the centralized management, security, and analytical capabilities inherent in a proper log management infrastructure.

B. Event-based triggers are designed for alerting on specific conditions, not for comprehensive log collection, and would result in incomplete data retention for audit purposes.

D. Building a custom script and database is inefficient, costly to maintain, and less secure than using a dedicated, industry-standard SIEM platform designed for this purpose.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-92

Guide to Computer Security Log Management.

Section 3.1.3

"Log Storage and Retention

" states: "Organizations should also consider using a dedicated log server for centralized log storage... Centralized log storage facilitates long-term log retention and reduces the risk of logs on individual hosts being lost..." A SIEM is a primary example of a system providing this centralized function.

2. Carnegie Mellon University

Software Engineering Institute

"Common Sense Guide to Mitigating Insider Threats

5th Edition."

Practice 17: Deploy a Log Management System

Page 111

recommends organizations to "Aggregate and centrally store logs from all relevant sources (e.g.

network devices

servers

databases

applications)." This directly supports using a central system like a SIEM to solve the problem described.

3. Al-Abassi

A.

Karim

A.

& Al-Ogaili

A. (2017). A Survey of SIEM Tools. In Proceedings of the International Conference on Big Data and Internet of Things (BDIoT’17). ACM

New York

NY

USA

Article 29

pp. 1–6.

Section 2

"SIEM Architecture

" describes the fundamental components of a SIEM

highlighting the "Log collection" and "Log storage" functions. The text explains that a core purpose of a SIEM is to gather logs from various sources (agents or collectors) and store them in a central repository (database or file system) for analysis and retention.

DOI: https://doi.org/10.1145/3175828.3175857

The core issue is a functional defect (a memory leak) introduced by a "small change" to existing code. Regression testing is the specific process of re-running functional and non-functional tests to ensure that previously developed and tested software still performs correctly after a change. An effective regression test suite for a critical resource allocation module would include performance and memory profiling tests. Executing this suite after the change would have detected the memory leak before deployment, thus preventing the production failure. This makes it the most efficient and direct technique to prevent this specific problem from reoccurring.

A. Load: While a load test would have exposed this specific memory leak, regression testing is the overarching process that ensures any bug introduced by a change is caught.

B. Smoke: Smoke testing is a preliminary, high-level check to ensure basic functionality works; it is not deep enough to detect subtle resource management bugs like a memory leak.

D. Canary: Canary testing is a deployment strategy that exposes new code to a small subset of users. It mitigates production impact but does not prevent the bug from being deployed.

---

1. Ammann

P.

& Offutt

J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press. In Chapter 1

Section 1.2

"A Fault

Error

Failure Terminology

" the text defines regression testing as "the process of retesting a modified program to ensure that no new faults have been introduced as a result of the changes." This directly aligns with the scenario where a change introduced a fault.

2. Bertolino

A. (2007). Software Testing Research: Achievements

Challenges

Dreams. In 2007 Future of Software Engineering (pp. 85-103). IEEE. https://doi.org/10.1109/FOSE.2007.27. On page 91

the paper discusses regression testing as essential for software evolution

stating its goal is to "provide confidence that the changes did not break any previously working functionality."

3. National Institute of Standards and Technology (NIST). (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (NIST Special Publication 800-218). Section 4

Practice PW.8

"Test Executable Code

" emphasizes the need to "review test plans and test results to confirm that the tests adequately address all security requirements." A comprehensive test plan

subject to regression

would include tests for resource exhaustion vulnerabilities like memory leaks.

The primary business requirement for a healthcare provider encrypting patient data at rest is to comply with regulations like the Health Insurance Portability and Accountability Act (HIPAA). HIPAA's Security Rule mandates the protection of electronic Protected Health Information (ePHI) confidentiality. Encryption is a key technical safeguard that achieves this. This control is crucial for supporting data portability—the ability to store and move data on laptops, backup media, or cloud services—without compromising patient privacy. If a device containing encrypted data is lost or stolen, the information remains secure, thus fulfilling the dual business requirement of protecting privacy while enabling necessary data mobility for healthcare operations.

A. Securing data transfer between hospitals addresses data in transit, which is protected by different controls (e.g., TLS), not encryption at rest.

B. Providing for non-repudiation data is about ensuring the integrity and origin of data, typically using digital signatures or secure audit logs, not encryption at rest.

C. Reducing liability from identity theft is a beneficial outcome of encryption, but the fundamental business requirement is the proactive protection of patient privacy as mandated by law.

1. U.S. Department of Health & Human Services (HHS). "Summary of the HIPAA Security Rule." The rule's purpose is to "protect the privacy of individuals’ health information" while allowing "the flow of health information needed to provide and promote high quality health care." This directly aligns with protecting privacy while supporting portability. The Technical Safeguards section (§ 164.312(a)(2)(iv)) identifies encryption as a key addressable implementation specification for protecting ePHI. (Source: HHS.gov)

2. National Institute of Standards and Technology (NIST). Special Publication 800-66 Revision 2: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. Section 3.3.1

"Access Control Standard

" discusses how encryption can be used to protect ePHI on various media

stating

"Encryption can be an effective tool in protecting the confidentiality of ePHI on a variety of media

including when it is being transmitted over a network or stored on a portable device." This highlights the link between encryption at rest and secure portability.

3. Johns Hopkins University. Information Security Policies and Standards

Policy: Encryption. Section 4.1 requires the encryption of all portable devices and media that store sensitive or confidential information

including PHI. This university policy reflects the industry-standard interpretation of the business and regulatory requirement to protect portable data through encryption. (Source: it.jhu.edu/policies)

The primary way to shrink a container’s privilege-escalation attack surface is to ensure the containerized process does NOT run as root. Option A builds the image so it contains only a non-root account (UID 1000) that has /dev/null as its shell; subsequent Dockerfile instructions would then use USER 1000. By removing root inside the container, any compromise is confined to an unprivileged context, blocking escalation to host or kernel privileges. This aligns with the least-privilege guidance in NIST SP 800-190 and the CIS Docker Benchmark.

B. EDR + SIEM improves detection but does not change the privileges the container holds; attack surface remains.

C. Auto-replacing compromised containers improves resiliency, not initial privilege-escalation surface within each container.

D. Network isolation and ACLs mitigate exposure paths, not internal privilege levels; root in the container is still available to attackers.

1. NIST SP 800-190 “Application Container Security Guide

” §5.1 Principle of Least Privilege

pp. 13-14.

2. Center for Internet Security (CIS) Docker Benchmark v1.4.0

Control 1.2 “Ensure that containers do not run as root

” pp. 27-28.

3. Kubernetes Documentation

“SecurityContext—runAsNonRoot

” v1.29

para. 1-2 (mirrors container least-privilege best practice).

4. Red Hat Container Security Guide

Ch. 3 “Running as Non-root

” pp. 31-33.

A Business Impact Analysis (BIA) is a systematic process to determine and evaluate the potential effects of an interruption to critical business operations. The two most fundamental data types required from business unit leaders are the identification of critical processes (F) and the quantification of the costs associated with downtime (C) for those processes. Identifying critical processes is the foundational step, establishing what the BIA will analyze. Quantifying the financial and operational costs of a disruption (e.g., lost revenue, penalties, reputational damage) is the core of the "impact" analysis, which is essential for prioritizing recovery efforts and defining Recovery Time Objectives (RTOs).

A. Inventory details: This is a component of asset management or a technical risk assessment, not a primary input from business leaders for a BIA, which focuses on processes and impact.

B. Applicable contract obligations: While important, these obligations (like SLAs) are a component of the overall impact, which is more comprehensively captured by the total costs associated with downtime.

D. Network diagrams: These are technical artifacts used in the subsequent disaster recovery planning phase to design solutions, not a primary business-level input for the BIA itself.

E. Contingency plans: These are an output of the business continuity process. They are created after the BIA has been completed to address the identified risks and impacts.

1. NIST Special Publication 800-34 Rev. 1

Contingency Planning Guide for Federal Information Systems.

Section 3.2

Business Impact Analysis (BIA)

Step 1 (Page 16): "The first BIA step is to identify the organization’s mission/business processes and determine their recovery criticality." This directly supports the selection of F. Critical processes.

Section 3.2

Business Impact Analysis (BIA)

Step 2 (Page 17): This step involves identifying outage impacts. The guide states

"Impacts may include... financial

loss of revenue..." This directly supports the collection of data on C. Costs associated with downtime.

2. Herbane

B. (2010). The evolution of business continuity management: A historical review of practices and drivers. Business History

52(6)

978-1002.

Page 985: The article describes the BIA process as involving the identification of "the critical processes which are essential for survival" and assessing "the business impact of a failure of these processes

which is usually measured in financial terms." This supports both F. Critical processes and C. Costs associated with downtime as central to the BIA. DOI: https://doi.org/10.1080/00076791.2010.511185

3. University of Illinois at Urbana-Champaign

CS 461/ECE 422: Computer Security I

Lecture 23: Business Continuity.

Slide 6

"Business Impact Analysis": The lecture material defines the BIA as the process to "Identify critical business functions" and "Determine tangible and intangible impact of the loss of that function." Tangible impacts are explicitly listed as financial losses

directly corresponding to F. Critical processes and C. Costs associated with downtime.

The log snippet indicates a successful DNS zone transfer (qrytype: AXFR) was executed from an external IP address (19.27.214.22). This type of query allows an attacker to download the entire DNS zone file, revealing the internal network topology, hostnames, and IP addresses of sensitive servers (e.g., directoryserver1, msn-crit-apcs). This information is invaluable for reconnaissance and subsequent lateral movement. The most direct and effective mitigation is to configure the DNS server to disable or strictly control zone transfers, permitting them only from the IP addresses of authorized secondary DNS servers and denying all others.

B. Restricting DNS traffic to UDP/53: This is incorrect because while most standard queries use UDP, zone transfers and large responses legitimately require TCP. Blocking TCP/53 entirely would break necessary DNS functions.

C. Implementing DNS masking on internal servers: This is incorrect because while split-horizon DNS is a good practice, it does not prevent the zone transfer itself. A misconfigured server could still allow the transfer of the internal zone view.

D. Permitting only clients from internal networks to query DNS: This is incorrect as it would block all legitimate external queries for public resources (e.g., the company website), rendering public-facing services inaccessible to the internet.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-81-2

Secure Domain Name System (DNS) Deployment Guide. Section 3.3.1

"Restrict Zone Transfers

" states

"Zone transfers should be restricted to prevent unauthorized users from obtaining a copy of a zone’s contents... DNS servers should be configured to allow zone transfers only to explicitly authorized servers." This directly supports disabling open zone transfers. (Page 16).

2. Internet Systems Consortium (ISC)

BIND 9.18.24 Administrator Reference Manual. The documentation for the allow-transfer option specifies its use for creating an access control list (ACL) of hosts permitted to receive zone transfers. The default is to allow transfers to all hosts

which is insecure. The manual guides administrators to restrict this to only known

trusted secondary servers. (Section: "The allow-transfer option").

3. University of California

Berkeley. CS 161: Computer Security

Lecture 18: Network Security II. Course materials discuss DNS security vulnerabilities

explicitly identifying zone transfers (AXFR) as a method for attackers to map an entire internal network. The recommended countermeasure is to configure DNS servers to restrict zone transfers to only authorized secondary name servers.

The scenario describes a false positive where a vulnerability scanner incorrectly reported a missing hotfix. This type of error commonly occurs during unauthenticated (network-based) scans, which infer system state from network banners and service responses without logging into the host. An authenticated scan uses credentials to log into the target system, allowing it to directly inspect the registry, file versions, and installed software lists. This provides a highly accurate assessment of the system's patch level, significantly reducing or eliminating false positives related to missing patches.

A. Getting an up-to-date list of assets from the CMDB: This improves scan coverage by ensuring all assets are targeted, but it does not improve the accuracy of the scan results on an individual asset.

C. Configuring the sensor with an advanced policy for fingerprinting servers: While advanced fingerprinting can better identify an OS, it is still an unauthenticated inference method and is less accurate for patch verification than a direct, authenticated check.

D. Coordinating the scan execution with the remediation team early in the process: This is a process improvement for managing remediation efforts but does not change the technical accuracy of the scan itself, which is the root cause of the false positive.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-115

Technical Guide to Information Security Testing and Assessment.

Section 5.3.1

"Authenticated Scans": This section explicitly states

"Authenticated scans are much less likely to produce false positives because they do not have to rely on inference to determine the security posture of a host... For example

an authenticated scan can read the registry of a Windows host to determine which patches have been installed." This directly supports the choice of authenticated scanning to avoid false positives for missing patches.

2. Carnegie Mellon University

Software Engineering Institute (SEI)

Defining a Strategy for Vulnerability Disclosure.

Section: "Vulnerability Scanning": Courseware and technical reports from institutions like the SEI often differentiate between scanning methods. They explain that credentialed (authenticated) scans provide "ground truth" by accessing the host's configuration directly

whereas uncredentialed scans are prone to errors from inferential analysis

leading to false positives. This aligns with the reasoning that authenticated scans are the solution. (Reference: General principle taught in advanced cybersecurity coursework).

3. SANS Institute

Penetration Testing and Vulnerability Analysis.

Reading Room Whitepaper

"Credentialed versus Non-Credentialed Vulnerability Scanning": SANS publications consistently highlight the superior accuracy of credentialed scans. They detail how these scans can access detailed version information and configuration files

which is impossible for non-credentialed scans

thereby preventing incorrect findings like the one described in the question.

Big Data refers to the technologies and strategies used to manage and analyze extremely large and complex datasets that cannot be handled by traditional data-processing tools. The process described—collecting a "large pool of behavioral observations"—directly corresponds to the core characteristics of Big Data, often defined by Volume (large pool), Variety (behavioral observations), and Velocity. The ultimate goal of Big Data analytics is to extract valuable insights from this data to "inform decision-making," making it the most fitting answer for the described process.

A. Linear regression: This is a specific statistical algorithm used for predictive modeling. It is a tool for analysis, not the overarching process of collecting and managing massive datasets.

B. Distributed consensus: This is a fault-tolerance protocol used in distributed systems (e.g., blockchain) to ensure all nodes agree on a single data value, which is unrelated to behavioral data collection.

D. Machine learning: This is a field of AI that involves algorithms that learn from data. While machine learning is used to analyze Big Data, the term "Big Data" itself describes the paradigm of collecting and managing the large data pool.

---

1. National Institute of Standards and Technology (NIST). (2022). NIST Big Data Interoperability Framework: Volume 1

Definitions (NIST Special Publication 1500-1r2). Section 2.2

"Big Data Definition

" states

"Big Data is a term used to describe the large amount of data in the networked

digitized

sensor-laden

information-driven world... The value of Big Data is the potential to analyze it to make better decisions." This directly aligns with the question's premise.

2. Gandomi

A.

& Haider

M. (2015). Beyond the hype: Big data concepts

methods

and analytics. International Journal of Information Management

35(2)

137-144. https://doi.org/10.1016/j.ijinfomgt.2014.10.007. The paper defines Big Data analytics as "the process of collecting

organizing and analyzing large sets of data... to discover patterns and other useful information" (p. 137)

distinguishing the data collection/management (Big Data) from the analysis techniques (e.g.

machine learning).

3. Massachusetts Institute of Technology (MIT) OpenCourseWare. (2016). Course 15.071 The Analytics Edge

Lecture 1: Introduction to Analytics. The lecture materials differentiate between the data itself (Big Data) and the methods used to analyze it

such as regression and machine learning

positioning Big Data as the foundational resource for these analytical processes.

The practice described—creating a registry of software dependencies and hashing vetted packages—is a direct countermeasure against supply chain attacks. A software supply chain attack involves compromising a third-party component, such as a library or package, which is then incorporated into the target organization's systems. By maintaining a registry (a form of Software Bill of Materials or SBOM) and using hashes for integrity checking, the organization can verify that the software components they use are the authentic, vetted versions. This helps detect unauthorized modifications and facilitates rapid incident response by quickly identifying all systems that use a compromised or vulnerable package.

B. Cipher substitution attack: This is a cryptographic attack targeting weaknesses in ciphers, which is unrelated to managing the integrity of software dependencies.

C. Side-channel analysis: This attack exploits information leaked from a system's physical implementation (e.g., power consumption), not vulnerabilities within its software components.

D. On-path attack: This attack intercepts network traffic. While it could be a vector to deliver a malicious package, the registry addresses the package's integrity, which is a supply chain concern.

E. Pass-the-hash attack: This is an authentication attack that uses a stolen credential hash to access network resources and is unrelated to software package management.

---

1. National Telecommunications and Information Administration (NTIA). (2021). The Minimum Elements For a Software Bill of Materials (SBOM).

Section: "What is an SBOM?" (Page 4): "A Software Bill of Materials (SBOM) is a nested inventory

a list of ingredients that make up software components... SBOMs are particularly useful in vulnerability management. When a vulnerability in a particular component is discovered

an SBOM allows an organization to easily determine if they are impacted and take action." This directly supports the scenario's use of a dependency registry for incident response.

2. National Institute of Standards and Technology (NIST). (2022). SP 800-161 Rev. 1

Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

Section 2.3.2

"Threats" (Page 13): This section details threats to the supply chain

including the "installation of malicious or counterfeit hardware or software." The use of hashes to verify vetted packages

as described in the question

is a direct control against this threat.

3. Parno

B.

& Jackson

C. (2022). 6.858 Computer Systems Security

Fall 2022 Lecture 15: Web Security. MIT OpenCourseWare.

Slide 47

"Software supply chain attacks": This lecture material defines supply chain attacks as compromising upstream dependencies (e.g.

libraries) that are then used by downstream developers. The scenario's focus on a "commonly used package" aligns perfectly with this definition.

4. National Institute of Standards and Technology (NIST). (n.d.). Glossary: Pass the hash. Computer Security Resource Center.

The glossary defines pass-the-hash as a technique where an "adversary steals a hashed user credential and

without cracking it

reuses it to trick an authentication system into creating a new authenticated session on the same network." This confirms its irrelevance to the scenario.

A staging environment is a replica of the production environment used for final testing before deployment. Its primary purpose is to validate new features, code changes, and updates in a setting that mirrors the live system's hardware, software, and network configuration. Testing a "newly released feature" here allows the administrator to identify any issues related to integration, performance, or deployment in a controlled, production-like setting without impacting actual users. This environment is the final gate before a feature goes live, making it the best choice for this scenario.

B. Testing environment: This environment is for general quality assurance (QA) testing and often precedes staging. It may not be an exact replica of the production environment.

C. CI/CD pipeline: This is an automated process for building, testing, and deploying code through various stages; it is not a test location itself.

D. Development environment: This is where developers write and perform initial unit tests on their code, a phase that a "newly released feature" has already passed.

---

1. Google Cloud Architecture Center. (2023). Application development and delivery: Environments. "A staging environment is the last step before a production environment. The staging environment should be as identical to the production environment as possible... This environment is used to test the code and to check for any production-specific deployment issues."

2. AWS Well-Architected Framework. (July 2023). Operational Excellence Pillar (Whitepaper)

p. 31. In the section "Implement changes

" the framework advises

"Test deployment procedures in an environment that is a replica of your production environment. This is often called a staging or pre-production environment."

3. Saltzer

J. H.

& Kaashoek

M. F. (2009). Principles of Computer System Design: An Introduction. MIT OCW

Course 6.033 Computer System Engineering

Spring 2009

Chapter 8

p. 218. The text discusses the principle of a "staging system" as a crucial step for testing changes in a realistic environment before they are deployed to the primary

operational system to minimize risk.

The Security Content Automation Protocol (SCAP) is a suite of specifications standardized by NIST for automating vulnerability management and policy compliance evaluation. It is designed specifically for tasks like performing a gap assessment against a security benchmark, checking for required configurations such as firewall status, password policies, and application lists.

Secure Access Service Edge (SASE) is a cloud-native architecture that converges network and security services. A core tenet of SASE is Zero Trust Network Access (ZTNA), which directly addresses the "Zero Trust application access" requirement. SASE solutions enforce access policies by continuously assessing the security posture of endpoints, verifying compliance with requirements like full disk encryption and host-based firewalls before granting access to resources.

A. CASB: A Cloud Access Security Broker (CASB) primarily secures traffic between users and cloud applications; it does not perform comprehensive OS-level configuration assessments.

B. SBoM: A Software Bill of Materials (SBoM) is an inventory of software components, used for vulnerability management and supply chain security, not for enforcing endpoint configuration policies.

E. HIDS: A Host-based Intrusion Detection System (HIDS) is a monitoring tool that detects malicious activity or policy violations, but it is not a framework for configuration assessment or Zero Trust access control.

1. NIST Special Publication 800-126 Revision 3

The Security Content Automation Protocol (SCAP) Version 1.3. Section 2

"Introduction

" states

"SCAP is a suite of specifications for exchanging security automation content... It is used for purposes such as automating vulnerability checking

compliance checking

and security measurement."

2. NIST Special Publication 800-207

Zero Trust Architecture. Section 3.2.2

"Device

" discusses the importance of the system's security posture in a Zero Trust Architecture. It states

"The enterprise monitors and manages the security posture of devices... This includes patch levels

OS versions

and integrity of security components." SASE is an implementation of this principle.

3. Yousef

W.

& Shosha

A. F. (2023). A Survey on Secure Access Service Edge (SASE). IEEE Access

11

51119-51143. https://doi.org/10.1109/ACCESS.2023.3279111. The paper defines SASE as a framework that "integrates networking and security functions into a unified

cloud-native service

" with Zero Trust Network Access (ZTNA) as a core component for enforcing granular

identity- and context-aware access policies.

A Threat Intelligence Platform (TIP) is the most suitable option as it is specifically designed to manage the threat intelligence lifecycle. A TIP aggregates raw data from various sources (including dark web monitoring and honeypots), enriches and analyzes it to produce contextualized, actionable intelligence. This output can then be directly operationalized by integrating with other security tools like SIEMs, SOAR platforms, and firewalls to automate defensive actions, thus fulfilling the company's goal of investing in research and making its output useful for security operations.

A. Dark web monitoring: This is a specific source of threat data, not a comprehensive platform for aggregating, analyzing, and operationalizing intelligence from multiple research efforts.

C. Honeypots: These are decoy systems used to gather specific intelligence on attacker tactics, techniques, and procedures (TTPs). The data from a honeypot is a research input, not the platform for operationalization.

D. Continuous adversary emulation: This is a validation technique used to test the effectiveness of existing security controls against known threats, rather than a platform for collecting and operationalizing new research.

---

1. European Union Agency for Cybersecurity (ENISA). (2021). Threat Intelligence Platforms.

Page 11

Section 3.1

"What is a TIP?": The document states

"A Threat Intelligence Platform (TIP) is a technology solution that collects

aggregates

and organises threat data from multiple sources... The primary goal of a TIP is to help organisations manage the overwhelming amount of threat data... and provide actionable intelligence to their security teams." This directly supports the choice of a TIP for operationalizing research.

2. Tounsi

W.

& Rais

H. (2018). A Survey on Technical Threat Intelligence in the Age of Big Data. IEEE Communications Surveys & Tutorials

20(3)

2123-2146.

Page 2133

Section V-A

"Threat Intelligence Platforms": The paper describes TIPs as solutions that "allow the operationalization of threat intelligence" by integrating with security controls like firewalls and IDS. It contrasts TIPs with simple data feeds

highlighting their role in analysis and action.

DOI: https://doi.org/10.1109/COMST.2018.2808252

3. Martin

R. A. (2016). A Framework for Classifying and Comparing Threat Intelligence Platforms. Carnegie Mellon University

Software Engineering Institute.

Page 3

Section 2

"Threat Intelligence Platform (TIP) Defined": This technical note defines a TIP as a platform that "facilitates the collection

analysis

and dissemination of threat intelligence." It emphasizes the function of dissemination

which is key to operationalizing the research output by feeding it to other security systems.

Regression testing is specifically designed to detect the re-emergence of previously fixed defects after code changes, upgrades, or component reintegration. By executing a maintained suite of regression tests every time earlier versions or modules are merged into the current code base, the team verifies that earlier fixes (such as the RBAC segmentation control) still hold, preventing the reintroduction of old bugs in a multitenant SaaS environment.

B. Code signing – Verifies publisher authenticity and integrity of delivered binaries; it does not test for functional defects.

C. Automated test and retest – Generic phrase; without a focused regression test suite it may miss previously resolved issues.

D. User acceptance testing – Confirms user requirements in production-like conditions, not systematic detection of resurrected internal bugs.

E. Software composition analysis – Scans third-party libraries for known vulnerabilities/licensing issues, not logic flaws introduced by integrating earlier in-house code.

1. SWEBOK v3.0

Ch. 4 “Software Testing”

§4.1.4 Regression Testing

p. 43-44: describes purpose of regression testing to detect re-introduced faults after changes.

2. IEEE Std 29119-1:2013

§7.2.7 Regression Testing: mandates executing regression suites whenever existing software components are modified or integrated.

3. MIT OpenCourseWare 6.005 “Software Construction”

Lecture notes 12 “Regression Testing”

slides 3-5: explains preventing old bugs from resurfacing via automated regression tests.

4. NIST Special Publication 500-291 (Software Assurance Metrics)

§5.3.2: highlights regression tests in continuous integration pipelines to ensure fixes remain effective after updates.

Attack surface reduction is the security design principle of minimizing the number of potential entry points for an adversary. This is achieved by removing all non-essential software, disabling unnecessary services, closing unused network ports, and restricting protocols. This process directly addresses the architect's requirement to expose the least number of services possible, thereby limiting an adversary's ability to access and exploit the systems. It is the foundational strategy that encompasses other more specific hardening actions.

A. Enforce Secure Boot.

This protects the pre-boot and boot process from rootkits and bootkits, ensuring system integrity at startup, but it does not reduce the number of services running once the OS is loaded.

C. Disable third-party integrations.

This is a specific tactic within the broader strategy of attack surface reduction. While a valid step, it is not the comprehensive first action to take, which is the overall analysis and reduction process.

D. Limit access to the systems.

This involves access control measures (e.g., firewalls, ACLs) that restrict who can reach the services. It does not reduce the number of services themselves, which remain running and potentially vulnerable.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-53

Revision 5

Security and Privacy Controls for Information Systems and Organizations. Control CM-7 (Least Functionality)

Page 138. The control states

"The organization: a. Configures the system to provide only essential capabilities; and b. Prohibits or restricts the use of... functions

ports

protocols

and/or services..." This directly describes the core activity of attack surface reduction.

2. National Institute of Standards and Technology (NIST) Special Publication 800-160

Volume 1

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. Section 3.3.3.2 (Attack Surface Reduction)

Page 68. This section defines the principle: "Attack surface reduction is a means of reducing risk by giving attackers less opportunity to exploit a potential weakness or vulnerability. This can be achieved by running only essential services

removing unnecessary software

disabling unnecessary user accounts

and eliminating unused or unnecessary system capabilities or functions."

3. Purdue University

Center for Education and Research in Information Assurance and Security (CERIAS)

Introduction to Systems and Network Security. This courseware emphasizes attack surface minimization as a primary defense strategy. It defines the attack surface as the "set of ways in which an adversary can enter a system and potentially cause damage

" and its reduction as the first step in hardening a system by removing all but the necessary services. (Reference to general principles taught in foundational cybersecurity courses at institutions like Purdue).

.

Explanation:

Code Snippet 1

Vulnerability 1: SQL injection

SQL injection is a type of attack that exploits a vulnerability in the code that interacts with a

database. An attacker can inject malicious SQL commands into the input fields, such as username or

password, and execute them on the database server. This can result in data theft, data corruption, or

unauthorized access.

Fix 1: Perform input sanitization of the userid field.

Input sanitization is a technique that prevents SQL injection byvalidating and filtering the user input

values before passing them to the database. The input sanitization should remove any special

characters, such as quotes, semicolons, or dashes, that can alter the intended SQL query.

Alternatively, the input sanitization can use a whitelist of allowed values and reject any other values.

Code Snippet 2

Vulnerability 2: Cross-site request forgery

Cross-site request forgery (CSRF) is a type of attack that exploits a vulnerability in the code that

handles web requests. An attacker can trick a user into sending a malicious web request to a server

that performs an action on behalf of the user, such as changing their password, transferring funds, or

deleting dat

a. This can result in unauthorized actions, data loss, or account compromise.

Fix 2: Implement anti-forgery tokens.

Anti-forgery tokens are techniques that prevent CSRF by adding a unique and secret value to each

web request that is generated by the server and verified by the server before performing the action.

The anti-forgery token should be different for each user and each session, and should not be

predictable or reusable by an attacker. This way, only legitimate web requests from the user’s

browser can be accepted by the server.

Analysis and Remediation Options for Each IoC:

IoC 1:

Evidence:

Source: Apache_httpd

Type: DNSQ

Dest: @10.1.1.1:53,@10.1.2.5

Data: update.s.domain, CNAME 3a129sk219r9slmfkzzz000.s.domain, 108.158.253.253

Analysis:

Analysis: The service is attempting to resolve a malicious domain.

Reason: The DNS queries and the nature of the CNAME resolution indicate that the service is trying

to resolve potentially harmful domains, which is a common tactic used by malware to connect to

command-and-control servers.

Remediation:

Remediation: Implement a blocklist for known malicious ports.

Reason: Blocking known malicious domains at the DNS level prevents the resolution of harmful

domains, thereby protecting the network from potential connections to malicious servers.

IoC 2:

Evidence:

Src: 10.0.5.5

Dst: 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.2.4, 10.1.2.5

Proto: IP_ICMP

Data: ECHO

Action: Drop

Analysis:

Analysis: Someone is footprinting a network subnet.

Reason: The repeated ICMP ECHO requests to different addresses within a subnet indicate that

someone is scanning the network to discover active hosts, a common reconnaissance technique used

by attackers.

Remediation:

Remediation: Block ping requests across the WAN interface.

Reason: Blocking ICMP ECHO requests on the WAN interface can prevent attackers from using ping

sweeps to gather information about the network topology and active devices.

IoC 3:

Evidence:

Proxylog:

GET

/announce?info_hash=%01dff%27f%21%10%c5%wp%4e%1d%6f%63%3c%49%6d&peer_id%3dxJFS

Uploaded=0&downloaded=0&left=3767869&compact=1&ip=10.5.1.26&event=started

User-Agent: RAZA 2.1.0.0

Host: localhost

Connection: Keep-Alive

HTTP200 OK

Analysis:

Analysis: An employee is using P2P services to download files.

Reason: The HTTP GET request with parameters related to a BitTorrent client indicates that the

employee is using peer-to-peer (P2P) services, which can lead to unauthorized data transfer and

potential security risks.

Remediation:

Remediation: Enforce endpoint controls on third-party software installations.

Reason: By enforcing strict endpoint controls, you can prevent the installation and use of

unauthorized software, such as P2P clients, thereby mitigating the risk of data leaks and other

security threats associated with such applications.

Reference:

CompTIA Security+ Study Guide: This guide offers detailed explanations on identifying and mitigating

various types of Indicators of Compromise (IoCs) and the corresponding analysis and remediation

strategies.

CompTIA Security+ Exam Objectives: These objectives cover key concepts in network security

monitoring and incident response, providing guidelines on how to handle different types of security

events.

Security Operations Center (SOC) Best Practices: This resource outlines effective strategies for

analyzing and responding to anomalous events within a SOC, including the use of blocklists, endpoint

controls, and network configuration changes.

By accurately analyzing the nature of each IoC and applying the appropriate remediation measures,

the organization can effectively mitigate potential security threats and maintain a robust security

posture.

below.

Explanation:

10.1.45.65 SFTP ServerDisable 8080

10.1.45.66 Email Server Disable 415 and 443

10.1.45.67 Web Server Disable 21, 80

10.1.45.68 UTM Appliance Disable 21

below

for the solution.

Explanation:

WAP A: No issue found. The WAP A is configured correctly and meets therequirements.

PC A = Enable host-based firewall to block all traffic

This option will turn off the host-based firewall and allow all traffic to pass through. This will comply

with the requirement and also improve the connectivity of PC A to other devices on the network.

However, this option will also reduce the security of PC A and make it more vulnerable to attacks.

Therefore, it is recommended to use other security measures, such as antivirus, encryption, and

password complexity, to protect PC A from potential threats.

Laptop A: Patch management

This option will install the updates that are available for Laptop A and ensure that it has the most

recent security patches and bug fixes. This will comply with the requirement and also improve the

performance and stability of Laptop A. However, this option may also require a reboot of Laptop A

and some downtime during the update process. Therefore, it is recommended to backup any

important data and close any open applications before applying the updates.

Switch A: No issue found. The Switch A is configured correctly and meets the requirements.

Switch B: No issue found. The Switch B is configured correctly and meets the requirements.

Laptop B: Disable unneeded services

This option will stop and disable the telnet service that is using port 23 on Laptop B. Telnet is a

cleartext service that transmits data in plain text over the network, which exposes it to

eavesdropping, interception, and modification by attackers. By disabling the telnet service, you will

comply with the requirement and also improve the security of Laptop B. However, this option may

also affect the functionality of Laptop B if it needs to use telnet for remote administration or other

purposes. Therefore,it is recommended to use a secure alternative to telnet, such as SSH or HTTPS,

that encrypts the data in transit.

PC B: Enable disk encryption

This option will encrypt the HDD of PC B using a tool such as BitLocker or VeraCrypt. Disk encryption

is a technique that protects data at rest by converting it into an unreadable format that can only be

decrypted with a valid key or password. By enabling disk encryption, you will comply with the

requirement and also improve the confidentiality and integrity of PC B’s data. However, this option

may also affect the performance and usability of PC B, as it requires additional processing time and

user authentication to access the encrypted data. Therefore, it is recommended to backup any

important data and choose a strong key or password before encrypting the disk.

PC C: Disable unneeded services

This option will stop and disable the SSH daemon that is using port 22 on PC C. SSH is a secure

service that allows remote access and command execution over an encrypted channel. However,

port 22 is thedefault and well-known port for SSH, which makes it a common target for brute-force

attacks and port scanning. By disabling the SSH daemon on port 22, you will comply with the

requirement and also improve the security of PC C. However, this option may also affect the

functionality of PC C if it needs to use SSH for remote administration or other purposes. Therefore, it

is recommended to enable the SSH daemon on a different port, such as 4022, by editing the

configuration file using the following command:

sudo nano /etc/ssh/sshd_config

Server A. Need to select the following:

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Security_X_CASP+_CAS-005/page_108_img_1.jpg

A black and white screen with white text Description automatically generated

Matching Relevant Findings to the Affected Hosts: Finding 1: Affected Host: DNS Reason: Users are unable to log into the domain from their workstations after relocating to Site B, which implies a failure in domain name services that are critical for user authentication and domain login. Finding 2: Affected Host: Pumps Reason: Thepump room at Site B becoming inoperable directly points to the critical infrastructure components associated with pumping operations. Finding 3: Affected Host: VPN Concentrator Reason: Unreliable internet connectivity at Site B due to route flapping indicates issues with network routing, which is often managed by VPN concentrators that handle site-to-site connectivity. Corrective Actions for Finding 3: Finding 3 Corrective Action: Action: Modify the BGP configuration Reason: Route flapping is often related to issues with Border Gateway Protocol (BGP) configurations. Adjusting BGP settings can stabilize routes and improve internet connectivity reliability. Replication to Site B for Finding 1: Affected Host: DNS Domain Name System (DNS) services are essential for translating domain names into IP addresses, allowing users to log into the network. Replicating DNS services ensures that even if Site A is disrupted, users at Site B can still authenticate and access necessary resources. Replication to Site B for Finding 2: Affected Host: Pumps The operation of the pump room is crucial for maintaining various functions within the infrastructure. Replicating the control systems and configurations for the pumps at Site B ensures that operations can continue smoothly even if Site A is affected. Configuration Changes for Finding 3: Affected Host: VPN Concentrator Route flapping is a situation where routes become unstable, causing frequent changes in the best path for data to travel. This instability can be mitigated by modifying BGP configurations to ensure more stable routing. VPN concentrators, which manage connections between sites, are typically configured with BGP for optimal routing. Reference: CompTIA Security+ Study Guide: This guide provides detailed information on disaster recovery and continuity of operations, emphasizing the importance of replicating critical services and making necessary configuration changes to ensure seamless operation during disruptions. CompTIA Security+ Exam Objectives: These objectives highlight key areas in disaster recovery planning, including the replication of critical services and network configuration adjustments. Disaster Recovery and Business Continuity Planning (DRBCP): This resource outlines best practices for ensuring that operations can continue at an alternate site during a disaster, including the replication of essential services and network stability measures. By ensuring that critical services like DNS and control systems for pumps are replicated at the alternate site, and by addressing network routing issues through proper BGP configuration, the organization can maintain operational continuity and minimize the impact of natural disasters on their operations.

.

Explanation:

VPN Concentrator:

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Security_X_CASP+_CAS-005/page_111_img_1.jpg

A screenshot of a computer Description automatically generated

AAA Server:

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Security_X_CASP+_CAS-005/page_111_img_2.jpg

A screenshot of a computer Description automatically generated

Select the Action Items for the Appropriate Locations:

Authorization Server:

Action Item: Grant access

The authorization server's role is to authenticate the user and then issue an authorization code or

token that the client application can use to access resources. Granting access involves the server

authenticating the resource owner and providing the necessary tokens for the client application.

Resource Server:

Action Item: Access issued tokens

The resource server is responsible for serving the resources requested by the client application. It

must verify the issued tokens from the authorization server to ensure the client has the right

permissions to access the requested data.

B2B Client Application:

Action Item: Authorize access to other applications

The B2B client application must handle the OAuth flow to authorize access on behalf of the user

without requiring direct knowledge of the user's credentials. This includes obtaining authorization

tokens from the authorization server and using them to request access to the resource server.

Detailed

OAuth 2.0 is designed to provide specific authorization flows for web applications,

desktopapplications, mobile phones, and living room devices. The integration involves multiple steps

and components, including:

Resource Owner (User):

The user owns the data and resources that are being accessed.

Client Application (B2B Client Application):

Requests access to the resources controlled by the resource owner but does not directly handle the

user's credentials. Instead, it uses tokens obtained through the OAuth flow.

Authorization Server:

Handles the authentication of the resource owner and issues the access tokens to the client

application upon successful authentication.

Resource Server:

Hosts the resources that the client application wants to access. It verifies the access tokens issued by

the authorization server before granting access to the resources.

OAuth Workflow:

The resource owner accesses the client application.

The client application redirects the resource owner to the authorization server for authentication.

The authorization server authenticates the resource owner and asks for consent to grant access to

the client application.

Upon consent, the authorization server issues an authorization code or token to the client

application.

The client application uses the authorization code or token to request access to the resources from

the resource server.

The resource server verifies the token with the authorization server and, if valid, grants access to the

requested resources.

Reference:

CompTIA Security+ Study Guide: Provides comprehensive information on various authentication and

authorization protocols, including OAuth.

OAuth 2.0 Authorization Framework (RFC 6749): The official documentation detailing the OAuth 2.0

framework, its flows, and components.

OAuth 2.0 Simplified: A book by Aaron Parecki that provides a detailed yet easy-to-understand

explanation of the OAuth 2.0 protocol.

By ensuring that each component in the OAuth workflow performs its designated role, the B2B client

application can securely access the necessary resources without compromising user credentials,

adhering to the principle of least privilege.

Implementing microsegmentation is the best solution for hardening a three-tier architecture. This approach allows for the creation of granular security policies that isolate each tier (web, application, database) and control traffic flow between them at the individual workload level. By defining rules that only permit necessary communication—for example, allowing the web tier to communicate with the application tier on specific ports, but preventing it from directly accessing the database tier—microsegmentation enforces the principle of least privilege. This significantly reduces the attack surface and prevents lateral movement by an attacker who might compromise one tier, which is the core goal of hardening this specific environment.

A. A VPN secures remote access into the network (north-south traffic) but does not harden the internal communication between servers within the VLANs (east-west traffic).

B. A SASE solution primarily focuses on securing access for users and devices to applications and the internet, not on securing inter-server communication within a data center.

D. Making a firewall the network core is a poor architectural design that would create a significant performance bottleneck, as firewalls are not designed for core switching speeds.

1. National Institute of Standards and Technology (NIST). (2020). Special Publication (SP) 800-207

Zero Trust Architecture.

Page 13

Section 3.2.3

Micro-segmentation: "This is the process of breaking up a network into isolated zones... Enterprises can use micro-segmentation to create very small zones

often on a per-workload basis. This allows the enterprise to create policies that prevent lateral movement between workloads in the data center." This directly supports using microsegmentation to secure the distinct tiers.

2. VMware. (2021). Micro-segmentation for Dummies

VMware Special Edition. John Wiley & Sons

Inc.

Page 10

Chapter 2

"Understanding the Power of Micro-segmentation": The document explicitly uses a three-tier application as a primary example for microsegmentation

stating

"With micro-segmentation

you can create policies that allow only the web tier to talk to the app tier

and only the app tier to talk to the database tier."

3. Sharma

S.

& Trivedi

M. C. (2022). A Comprehensive Review on Micro-segmentation in Software-Defined Networking. In Proceedings of First International Conference on Information and Communication Technology for Intelligent Systems (ICTIS 2021) (Vol. 2

pp. 719-727). Springer

Singapore.

DOI: https://doi.org/10.1007/978-981-16-5392-869

Section 3

"Micro-segmentation": This academic paper discusses how microsegmentation provides "fine-grained security policies to be assigned to individual workloads" and is a key technique for implementing a Zero Trust model within a data center

which is precisely what is needed to harden a multi-tier application environment.

User and Entity Behavior Analytics (UEBA) is the most appropriate solution. The core challenge is that existing security tools, which often rely on signatures and known patterns, cannot categorize the suspicious activity. UEBA systems are specifically designed to address this gap by establishing a baseline of normal behavior for users and network entities using machine learning and statistical analysis. When an activity deviates significantly from this established baseline, UEBA flags it as anomalous, even if it does not match any known threat signature. This directly helps in identifying and providing context to previously uncategorizable or zero-day threats.

A. Implement an Interactive honeypot: An interactive honeypot is a deception tool used to lure attackers and study their methods in a controlled environment. It is for threat research, not a primary network-wide detection mechanism for ongoing, uncategorized activity.

B. Map network traffic to known IoCs: The question explicitly states that existing tools cannot categorize the activity, which implies that mapping to known Indicators of Compromise (IoCs) has already failed. This option describes the problem, not the solution.

C. Monitor the dark web: Dark web monitoring is a proactive threat intelligence gathering technique. It helps identify potential future threats or data leaks but does not directly assist in analyzing or categorizing suspicious traffic already active on the network.

---

1. National Institute of Standards and Technology (NIST)

NISTIR 8323. (2021). Foundational PNT Profile: Applying the Cybersecurity Framework for the Responsible Use of PNT Services. In Section 3.2

Table 3

under the control ID DE.AE-2

it lists "User and Entity Behavior Analytics (UEBA) solutions that can be used to detect anomalous behavior by users

devices

and other entities" as an example implementation. This supports UEBA as a primary tool for detecting anomalous (i.e.

uncategorized) activity.

2. National Institute of Standards and Technology (NIST)

Special Publication 800-94. (2007). Guide to Intrusion Detection and Prevention Systems (IDPS). Section 3.3.2

"Anomaly-Based Detection

" describes the methodology used by UEBA: "the process of comparing definitions of what is considered normal activity against observed events to identify significant deviations." This method is ideal for threats that signature-based systems cannot identify.

3. Graves

H. (2017). Honeypots for Active Defence. SANS Institute InfoSec Reading Room. Page 4 states that honeypots are tools to "gather intelligence on the attack vectors

tools and motives of our adversaries." This frames the honeypot as a specialized intelligence-gathering tool rather than a broad detection solution for an existing problem on the live network.

4. Brown

C.

& Tomlin

A. (2013). An introduction to the challenges of user behaviour analytics for cyber security. In 2013 IEEE International Conference on Intelligence and Security Informatics (pp. 206-208). DOI: 10.1109/ISI.2013.6578806. This academic paper discusses how User Behavior Analytics (UBA)

a precursor to UEBA

is used to detect "anomalous behaviour which may be indicative of a security threat" that signature-based systems miss.

The most effective security architecture to meet both requirements is network segmentation. Operating the IoT thermostats on a separate, isolated network (e.g., a dedicated VLAN or physical network) directly addresses the need to limit their access to other internal corporate devices. This containment strategy prevents a potential compromise of an IoT device from spreading to the trusted internal network. This isolated network can then be configured with specific firewall rules to allow outbound-only internet access to the vendor's update servers, satisfying the requirement for security updates while adhering to the principle of least privilege.

A. Only allowing Internet access to a set of specific domains: This is an incomplete solution. While it controls external access, it does not prevent a compromised IoT device from attacking other assets on the same internal network.

C. Only allowing operation for IoT devices during a specified time window: This is impractical for thermostats that require continuous operation and does not address the core requirement of limiting access to internal devices.

D. Configuring IoT devices to always allow automatic updates: This addresses the update requirement but completely fails to address the critical need to limit the device's access to the internal network, leaving internal assets vulnerable.

---

1. National Institute of Standards and Technology (NIST). (2019). NISTIR 8228: Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks.

Section 3.3.2

Network-Related Capabilities

Page 15: This section explicitly recommends network segmentation as a primary control. It states

"Organizations can also use network segmentation to help prevent IoT devices from being used to attack other parts of the organization’s enterprise network if the devices are compromised." This directly supports isolating IoT devices on a separate network.

DOI: https://doi.org/10.6028/NIST.IR.8228

2. National Institute of Standards and Technology (NIST). (2021). SP 800-213A: IoT Device Cybersecurity Guidance for the Federal Government.

Section 4.2

Device Security

Page 13: This document advises organizations to "Isolate IoT devices on a separate network to reduce the impact of a compromise." This reinforces the answer by highlighting network isolation as a key security measure for government and enterprise IoT deployments.

DOI: https://doi.org/10.6028/NIST.SP.800-213A

3. Al-Garadi

M. A.

Mohamed

A.

Al-Ali

A. K.

Du

X.

& Guizani

M. (2020). A Survey of IoT Platforms. IEEE Access

8

222914-222967.

Section V.A

Security

Page 222941: The paper discusses IoT security challenges and solutions

noting that "Network segmentation can be used to isolate IoT devices from critical systems... This can be achieved by placing IoT devices on a separate VLAN or subnet with strict access control lists (ACLs) to limit their communication with other parts of the network." This academic source validates network segmentation as a best practice.

DOI: https://doi.org/10.1109/ACCESS.2020.3003116

An organization’s attack surface is defined by all reachable system interfaces, components, and external dependencies that an attacker could exploit.

1. Documenting Company B’s third-party connections (A) inventories every external interface and trust relationship, revealing new exposure points that the merged enterprise will inherit.

2. Performing an architectural review of Company B’s network (E) maps internal segments, hosts, data flows, and security controls, allowing Company A to compare them with its own architecture and identify additional vectors, overlaps, or gaps.

Together, these two activities provide a complete enumeration of new assets and interfaces— the prerequisite for calculating any change in overall attack surface.

B. Privacy policies concern legal data-handling practices; they do not enumerate technical interfaces or exploitable paths.

C. Sensitivity labels/DLP mitigate data exfiltration but do not reveal where new attack vectors exist.

D. Forcing stronger passwords is a control enhancement, not a discovery activity that measures the inherited attack surface.

1. NIST SP 800-160 v1

Sec 3.4 “Attack Surface Analysis” – identifies need to catalog system interfaces and external dependencies (pp. 56-57).

2. NIST SP 800-115

Sec 2.3 “Information Gathering” – stresses architectural review and external connection mapping as first steps of security assessment (pp. 2-6).

3. ISO/IEC 27005:2018

Annex B.2 “Identifying Assets and Interfaces” – requires listing third-party links and system architecture for risk determination.

4. MIT OpenCourseWare 6.858

Lecture 5 “Threat Modeling & Attack Surface” – highlights network architecture diagrams and external trust relationships as core inputs.

5. J. Jacobs & A. Rosenthal

“Security Posture Assessment in M&A

” IEEE IT Prof.

vol. 22

no. 4

2020

pp. 57-59 – recommends architectural mapping and third-party enumeration to gauge post-acquisition attack surface.

Privilege creep occurs when users accumulate access rights beyond what is required for their current duties, often after changing roles. The most effective mitigation strategy combines proactive and detective controls.

Implementing a Role-Based Access Control (RBAC) policy (A) is a proactive measure. It ties permissions directly to job roles rather than individual users. When an employee changes roles, their old permissions are revoked, and the permissions for the new role are assigned, preventing the accumulation of unnecessary access.

Performing periodic access reviews (D) is a crucial detective and corrective control. Managers and system owners regularly verify that users' access rights are still appropriate for their current job functions. This process identifies and rectifies any excessive permissions that were missed during role transitions, thus remediating privilege creep.

B. Designing a least-needed privilege policy: This is a foundational principle, not a direct solution. RBAC (A) and access reviews (D) are specific mechanisms used to enforce this policy.

C. Establishing a mandatory vacation policy: This control is primarily for fraud detection by having another person perform the user's duties, not for managing or reducing excessive permissions.

E. Requiring periodic job rotation: Without proper access control management, job rotation can exacerbate privilege creep as employees may accumulate permissions from multiple roles over time.

F. Setting different access controls defined by business area: This is too broad. Privilege creep can still occur when employees change roles within the same business area. RBAC provides more granular, role-specific control.

1. National Institute of Standards and Technology (NIST) Special Publication 800-53

Revision 5

"Security and Privacy Controls for Information Systems and Organizations."

Control AC-2 (Account Management): Specifically

enhancement AC-2(3) states

"Review and remove/disable inactive accounts" and AC-2(4) "Review accounts for compliance with account management requirements." This directly supports periodic access reviews (D).

Control AC-3 (Access Enforcement): This control discusses the enforcement of access control policies. RBAC is a primary model for implementing this

ensuring access is based on "assigned duties of individuals." This supports implementing a role-based policy (A).

2. Ferraiolo

D. F.

& Kuhn

D. R. (1992). Role-Based Access Control. 15th National Computer Security Conference.

Section 3

"The RBAC Framework": This foundational paper describes how RBAC simplifies permission management by associating permissions with roles. It states

"When a user is removed from a role

the permissions associated with that role are revoked

" directly addressing the mitigation of privilege creep during job changes.

3. University of California

Berkeley

Security Policy

"Access Control Policy."

Section III.B

"Principle of Least Privilege": The policy states

"Access is to be granted based on the principles of least privilege and separation of duties." It further specifies that "Periodic reviews of access rights must be performed

" reinforcing the necessity of access reviews (D) to maintain this principle.

The diagram illustrates a Zero Trust security model. This architecture is defined by the principle of "never trust, always verify," where no implicit trust is granted to assets or user accounts based on their physical or network location. The diagram shows a Policy Enforcement Point (PEP) mediating all access to the data repository. Access decisions are not static; they are made by a Policy Decision Point (PDP) which dynamically evaluates multiple context sources: user identity, device health, threat intelligence, and data classification. This dynamic, granular, and context-aware policy enforcement for every access request is the fundamental characteristic of a Zero Trust Architecture.

A. Identity and access management model: This is only one component of the illustrated architecture; the model also critically includes device health, data classification, and threat intelligence for access decisions.

B. Agent based security model: This describes a potential implementation method (e.g., for checking device health) rather than the overarching architectural strategy of dynamic trust evaluation.

C. Perimeter protection security model: This model establishes a trusted internal network protected by a strong border, which is the opposite of the Zero Trust principle of scrutinizing every request regardless of origin.

1. National Institute of Standards and Technology (NIST). (2020). Special Publication (SP) 800-207: Zero Trust Architecture.

Section 4

"Logical Components of a Zero Trust Architecture

" describes the core components shown in the diagram. The Policy Decision Point (PDP) is analogous to NIST's Policy Engine (PE)/Policy Administrator (PA)

and the Policy Enforcement Point (PEP) is explicitly named.

Figure 3

"Abstract Zero Trust Architecture

" provides a logical diagram that mirrors the question's illustration

showing a PEP controlling access between a subject and a resource

with decisions informed by a PE/PA.

2. Wood

B.

& Gralike

M. (2021). A Brief Introduction to Zero Trust. Carnegie Mellon University Software Engineering Institute.

Page 2

"What is Zero Trust?

" states

"In a zero trust environment

no user or device is trusted by default... Access is granted based on the authentication and authorization of the user and device." This aligns with the diagram's use of an IdP and MDM as inputs to the policy decision.

3. Microsoft Corporation. (2023). The Microsoft Zero Trust security model. Microsoft Learn Documentation.

Under the section "Zero Trust principles

" it details the core principle of "Verify explicitly

" which involves continuously authenticating and authorizing based on all available data points

including user identity

device health

and data classification

exactly as depicted in the diagram's PDP inputs.

NIST SP 800-40 r3 and Microsoft’s patch-management guidance both state that Internet-facing hosts that offer the vulnerable service must be remediated before any internal systems because they are directly exposed to untrusted networks and can be exploited immediately.

Host 1 is the only publicly reachable IIS server shown in the DMZ; therefore, it presents the highest business and security risk for the newly announced IIS zero-day. Patching it first satisfies the company’s policy (“any publicly available server must be patched within 12 hours”) and best-practice risk-based prioritisation.

B. 2 – Internal mail/relay; not Internet-reachable, lower exploit likelihood, so patched after DMZ host.

C. 3 – Internal database; no direct IIS exposure to the Internet.

D. 4 – File/application server on internal LAN; indirect risk only.

E. 5 – Domain controller; critical but non-public, protected by internal network layers.

F. 6 – Workstation or test server; internal, non-public, least immediate risk from IIS zero-day.

1. NIST SP 800-40 Revision 3

“Guide to Enterprise Patch Management

” §2.3 Prioritizing Patch Deployment

pp. 11-13.

2. Microsoft Security Response Center

“Prioritizing Security Updates on Internet-Facing Windows Servers

” 2021

para 2-3.

3. CIS Critical Security Controls v8

Control 7.2

“Establish and Maintain a Patch Management Process

” emphasis on externally accessible systems.

4. MIT OpenCourseWare

6.857 “Computer and Network Security” (Fall 2020)

Lecture 9 slides

p. 7: “Patch Internet-visible services first.”

5. IEEE Security & Privacy

Vol. 17

No. 2 (2019)

“Risk-Based Patch Management

” pp. 45-46 – empirical data showing highest ROI when patching externally exposed services first.

The scenario describes an MFA fatigue or "MFA bombing" attack, where an adversary who has already compromised user credentials repeatedly triggers MFA push notifications, hoping the user will eventually approve one by mistake or out of frustration. The most effective way to restrict the success of this attack is to enhance the existing push notification system.

Configuring prompt-driven MFA, specifically through a method like number matching (also known as a number challenge), directly mitigates this threat. Instead of a simple "Approve/Deny" prompt, the user is shown a number on the login screen and must enter that same number into their authenticator app. This forces the user to be actively engaged in the login attempt and ensures they are approving a session they initiated, effectively preventing accidental approvals from malicious, unsolicited prompts.

A. Provisioning FIDO2 devices: While FIDO2 is a highly secure, phishing-resistant MFA method, deploying it is a long-term strategic project, not an immediate way to restrict the current malicious notifications.

B. Deploying a text message based on MFA: Switching to SMS-based MFA is a downgrade in security, as it is vulnerable to SIM-swapping attacks, and it does not solve the problem of notification spam.

C. Enabling OTP via email: This is also a less secure MFA method and, like SMS, does not address the core issue of excessive, malicious authentication attempts; it only changes the notification channel.

1. Microsoft Documentation: In its official documentation on authentication methods

Microsoft identifies MFA fatigue attacks and explicitly recommends number matching as the primary defense. "Number matching is a key security upgrade to traditional second factor notifications in Authenticator... This feature is critical for protecting against MFA fatigue attacks."

Source: Microsoft Entra documentation

"How to use number matching in multifactor authentication (MFA) notifications - Authentication methods policy". (Refer to the sections on "MFA fatigue attacks" and the benefits of number matching).

2. Cybersecurity and Infrastructure Security Agency (CISA): CISA has issued guidance on mitigating MFA-based attacks. Their recommendations include implementing number matching to prevent users from accidentally approving malicious MFA prompts.

Source: CISA

"Alert (AA22-279A): Lapsus$ and Related Threat Groups Observed Using Social Engineering to Steal Credentials and Bypass MFA

" October 6

2022. (Refer to the "Mitigations" section

which recommends using number matching or FIDO-based authenticators).

3. NIST Special Publication 800-63B: This publication on Digital Identity Guidelines discusses requirements for authenticators. For out-of-band authenticators (like push notifications)

it emphasizes the need for the authentication system to provide context to the user to help them identify fraudulent requests. Number matching is a direct implementation of this principle.

Source: NIST SP 800-63B

Digital Identity Guidelines: Authentication and Lifecycle Management

Section 5.1.3.2

"Out-of-Band Authenticators". (The principle of providing transaction-specific information to the user to approve is foundational to why number matching is effective).