Free CS0-003 Practice Questions – 2026 Updated

A discovery scan is a type of reconnaissance activity performed to map the structure and components of a target system or application. Its primary goal is to identify assets, enumerate directories, and understand the overall layout—precisely what the analyst is tasked with. This initial mapping allows the analyst to define the scope for a more focused vulnerability scan and to explicitly exclude sensitive URIs or directories from further, potentially disruptive, testing. This activity is a prerequisite to in-depth scanning, not the in-depth scan itself.

A. Uncredentialed scan: This describes the authentication context (scanning without login credentials), not the specific objective of mapping the application's structure.

C. Vulnerability scan: This is a more intensive scan that actively probes for known weaknesses, which the scenario states will occur after this initial mapping phase.

D. Credentialed scan: This describes scanning with authenticated user privileges to assess the internal attack surface, which is not the stated goal of the initial reconnaissance.

1. National Institute of Standards and Technology (NIST). (2008). Technical Guide to Information Security Testing and Assessment (Special Publication 800-115).

Section 3.2

"Discovery

" describes this phase as the start of testing

used to "identify systems and the information on them" and to "develop a map of the network." This directly supports the concept of scanning to understand where the scan will go.

2. CompTIA. (2022). CompTIA Cybersecurity Analyst (CySA+) Certification Exam Objectives CS0-003.

Exam Objective 2.1

"Explain the importance of vulnerability management

" lists "Discovery" as a specific type of scan. This confirms its relevance and distinction from other scan types within the official exam curriculum.

3. Kruegel

C.

& Vigna

G. (2003). Anomalous Payload-Based Network Intrusion Detection. In Proceedings of the 5th International Symposium on Recent Advances in Intrusion Detection (RAID '02).

The paper

in its discussion of web application analysis

implicitly supports the concept of a discovery/crawling phase. Section 3

"Web Application Analysis

" describes the initial step as crawling the web application to "build a model of the application

" which is synonymous with a discovery scan's purpose of mapping URIs before deeper analysis. (Available via Springer or university libraries).

A formal incident declaration process is a critical component of an Incident Response Plan (IRP). Its most important function is to establish a clear, unambiguous line of authority. This ensures that only designated and qualified personnel can officially classify a security event as an incident, thereby triggering the allocation of significant organizational resources and initiating the formal response protocol. Without this documented authority, organizations risk delayed responses, confusion, premature or unnecessary escalations, and a general lack of control over the incident management lifecycle. This formal designation of authority is the cornerstone of an orderly and effective response.

A. To require that an incident be reported through the proper channels

This is incorrect because reporting channels are part of the initial detection and analysis phase, which precedes the formal declaration. The declaration process is what happens after an event has been reported.

C. To allow for public disclosure of a security event impacting the organization

This is incorrect because public disclosure is a communication task that occurs much later in the incident response process, if at all. The initial declaration is an internal trigger for the response team.

D. To establish the department that is responsible for responding to an incident

This is incorrect because the responsible department (e.g., CSIRT) and its roles are defined in the overarching Incident Response Plan, not within the specific procedure for declaration.

---

1. NIST Special Publication 800-61 Rev. 2

Computer Security Incident Handling Guide.

Section 2.3.2

"Policy

Plan

and Procedure Creation": This section emphasizes the need for a formal incident response policy that defines roles

responsibilities

and levels of authority. It states

"The incident response policy should also state which individuals have the authority to... declare an incident." This directly supports that identifying authority is a primary goal of formalizing the process.

2. Carnegie Mellon University

Software Engineering Institute (SEI)

Defining Incident Management Processes

CERT/CC

October 2018.

Section 3.2

"Declare an Incident": This document outlines the incident management process and states

"The goal of this step is to make a decision about whether the event should be declared an incident... This decision is usually made by an incident response team leader or manager." This highlights that the declaration is a formal decision point made by an authorized individual.

3. ISO/IEC 27035-1:2023

Information technology — Information security incident management — Part 1: Principles and process.

Section 7.3

"Decision and declaration": This international standard specifies that the incident management process must include a formal decision step. It states that criteria for declaring an incident should be established and that "the decision to declare an information security incident should be taken by a competent and authorized person or team." This reinforces the centrality of designated authority in the declaration process.

:

The primary differentiator for prioritization among the given options is the Attack Vector (AV) metric within the CVSSv3 string. The AV:N (Network) vector indicates that the vulnerability is exploitable remotely from the internet. This represents the broadest attack surface and the highest immediate risk, as an attacker requires no prior access to the local or adjacent network. When other metrics like Attack Complexity (AC:L), Privileges Required (PR:L), and Impact (C:H/I:H/A:H) are identical, the vulnerability that can be exploited from anywhere on the network should always be remediated first.

A. AV:P (Physical) requires physical access to the target system, representing the lowest level of risk and therefore the lowest priority for remediation.

B. AV:A (Adjacent) requires the attacker to be on the same local network, which is a more limited attack surface than a network-exploitable vulnerability.

D. AV:L (Local) requires the attacker to have existing access to the system, making it a lower priority than a remotely exploitable vulnerability.

1. FIRST.org

Inc. (2019). Common Vulnerability Scoring System v3.1: Specification Document. Section 2.1.1

Attack Vector (AV). The document states

"The Base Score is highest for a vulnerability that can be exploited remotely (AV:N)... This is because the attacker does not require any local or physical access to the vulnerable component." This directly supports prioritizing AV:N.

2. Mell

P.

& Scarfone

K. (2005). The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems (NISTIR 7435). National Institute of Standards and Technology. Section 3.1

"Base Metrics

" discusses how the Attack Vector metric captures the context by which vulnerability exploitation is possible

with Network being the most critical.

3. Purdue University. CS 42600: Computer Security

Lecture 18 - Vulnerabilities. Course materials discuss vulnerability analysis and CVSS. The lectures emphasize that the Attack Vector is a critical component for prioritization

with network-based vectors (AV:N) posing a significantly higher risk than local

adjacent

or physical vectors due to the vast number of potential remote attackers.

The primary objective is to implement compensating controls to contain an active adversary on a live system while maintaining critical functionality. Deploying an Endpoint Detection and Response (EDR) solution provides deep visibility into system activities and allows responders to actively block or disrupt malicious processes, thereby reducing the adversary's capabilities without taking the server offline. Concurrently, using microsegmentation allows for the creation of granular, stateful firewall policies that restrict network connectivity to only what is explicitly required—in this case, the connection from the web server to the database server on a specific port. This network-level control effectively contains the adversary, preventing lateral movement to other parts of the network while preserving the necessary service connections.

A. Dropping the tables on the database server is a destructive action that violates the requirement to keep the service functional and results in data loss.

C. Stopping the httpd service would make the web application inaccessible, directly contradicting the requirement to keep the web service running and accessible.

E. Commenting out the HTTP account in /etc/passwd would disable the service account, causing the web server process to fail and violating the accessibility requirement.

F. Moving the database to the already compromised web server would be a major architectural change that increases risk by consolidating assets on a compromised host.

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

Computer Security Incident Handling Guide.

Section 3.3.3

Containment

p. 27: This section outlines containment strategies

which include isolating affected hosts or network segments. Microsegmentation is a modern implementation of network segmentation that creates "secure zones in data centers and cloud deployments that allow companies to isolate workloads from one another and secure them individually." This directly supports option D as a containment strategy.

2. Souppaya

M.

& Scarfone

K. (2013). NIST Special Publication 800-128

Guide for Security-Focused Configuration Management of Information Systems.

Section 4.3

Isolate

p. 21: Discusses isolation as a security technique. "Isolation may be implemented through physical or logical separation... Logical separation can be accomplished through a variety of mechanisms

such as access control lists (ACLs) on routers and firewalls..." Microsegmentation is an advanced form of logical separation

aligning with this principle for containment (Option D).

3. Al-Shaer

E.

& Wei

J. (2021). Modeling and Verification of Micro-segmentation for Zero-Trust Security. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (pp. 3215–3217).

Abstract & Section 1: The paper describes microsegmentation as a key enabler for a Zero-Trust security model

which "enforces strict access control and network segmentation to prevent lateral movement." This directly supports the use of microsegmentation (Option D) to contain an adversary.

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

4. Boicea

A.

et al. (2018). EDR

EPP

and NGAV: The new triple-threat in endpoint security. 2018 10th International Conference on Electronics

Computers and Artificial Intelligence (ECAI).

Section II.A

Endpoint Detection and Response (EDR): This section describes EDR as a solution that "records system activities and events taking place on endpoints... and provides forensic analysis and remediation capabilities to identify and stop attacks." This capability to actively reduce an adversary's actions supports Option B.

DOI: https://doi.org/10.1109/ECAI.2018.8679018

The most effective method for safeguarding Personally Identifiable Information (PII) during an incident investigation is to combine technical controls with administrative controls. Encrypting the data (a technical control) protects it from unauthorized access if the storage medium is compromised. Simultaneously, limiting permissions within the investigation team (an administrative control) adheres to the principle of least privilege, ensuring that only authorized personnel with a direct need-to-know can access the sensitive data. This dual approach minimizes the risk of accidental exposure or insider threats while still enabling the investigation to proceed.

A. "Close the data so only the company has access" is overly broad and insecure, as it does not implement the principle of least privilege within the organization.

C. Creating a data deletion procedure is a crucial part of data lifecycle management but is not the most immediate or primary action for safeguarding data during an active incident.

D. "Permissions are open only to the company" is not a security control; it implies a lack of internal access controls and violates the principle of least privilege.

---

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

Guide to Protecting the Confidentiality of Personally Identifiable Information (PII).

Section 4.4

"Restrict PII Access

" states

"Organizations should restrict access to PII to only those individuals who have a need to know... This is often referred to as the principle of least privilege." (Page 29).

Section 4.5

"Protect PII at Rest and in Transit

" recommends

"Organizations should consider using encryption to protect the confidentiality of PII... PII should be encrypted when it is stored (at rest)..." (Page 30). This directly supports combining limited permissions and encryption.

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

Computer Security Incident Handling Guide.

Section 3.2.5

"Handling

" discusses the importance of protecting evidence and sensitive data during an investigation. It states

"Handling of data should be performed according to the policies and procedures that were established in the preparation phase... This includes... protecting sensitive information." (Page 31). This implies that pre-defined controls like access limitation and encryption should be applied.

3. MIT OpenCourseWare

6.858 Computer Systems Security

Fall 2014.

Lecture 1

"Introduction; Threat models

" introduces the core security principles of confidentiality

integrity

and availability. The lecture materials emphasize that confidentiality is often enforced through a combination of access control mechanisms and encryption

which aligns directly with the correct answer. (Available at ocw.mit.edu).

The threat actor's actions of compiling, testing, and modifying a malicious downloader to evade specific security controls fall directly into the Weaponization stage of the Cyber Kill Chain. This stage is defined by the creation or modification of a malicious payload (the "weapon") that is tailored to the target environment. The actor is using intelligence gathered during reconnaissance to build an effective tool for the subsequent stages of the attack. The primary activity described is the creation of the malicious artifact, not its delivery or execution.

A. Delivery: This stage involves transmitting the weapon to the target (e.g., via a phishing email or a malicious website), which has not yet occurred in the scenario.

B. Reconnaissance: This stage focuses on gathering information about the target. While the actor used intelligence, the core action described is building the tool, not gathering the data.

C. Exploitation: This stage involves triggering the malicious code on the victim's system to gain access. The actor is still in the preparation phase on their own systems.

1. Hutchins

E. M.

Cloppert

M. J.

& Amin

R. M. (2011). Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Lockheed Martin Corporation. In Section 3

"Stage 2: Weaponization

" the authors state

"Weaponization...couples a remote access trojan with an exploit into a deliverable payload." This directly aligns with creating a malicious downloader.

2. NIST. (2016). NIST Special Publication 800-150: Guide to Cyber Threat Information Sharing. National Institute of Standards and Technology. Section 2.3.1 describes the Cyber Kill Chain

where Weaponization is the stage for creating the malicious payload before the Delivery stage.

3. SANS Institute. (2015). The Sliding Scale of Cyber Security. SANS Technology Institute. Page 5 describes the kill chain stages

defining Weaponization as the point where an attacker "chooses a weapon...and packages it for delivery." The act of compiling and testing fits this definition.

Risk transfer is a risk management strategy that involves shifting the financial consequences of a potential loss to a third party. Purchasing cyber insurance is a classic example of this principle. The organization pays a premium to an insurance company, which in turn agrees to cover the financial damages resulting from a specified cyber incident (e.g., data breach, ransomware attack). This action does not eliminate or reduce the likelihood of the risk itself but transfers the associated financial burden from the organization to the insurer.

A. Accept: Risk acceptance involves acknowledging a risk and making a deliberate decision to take no action, bearing any potential losses. Purchasing insurance is an active response, not acceptance.

B. Avoid: Risk avoidance means eliminating the risk by ceasing the activity that creates it (e.g., disconnecting a system from the internet). Insurance manages the consequences, it does not avoid the activity.

C. Mitigate: Mitigation involves implementing controls (e.g., firewalls, encryption, training) to reduce the likelihood or impact of a risk. Insurance is a financial tool, not a technical or procedural control.

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

Managing Information Security Risk: Organization

Mission

and Information System View.

Section 2.3

Page 10: This document outlines the four fundamental risk response strategies. It explicitly defines risk sharing/transfer as a method "to shift risk from one group or individual to another (e.g.

by using insurance)."

2. National Institute of Standards and Technology (NIST). (2020). NISTIR 8286

Integrating Cybersecurity and Enterprise Risk Management (ERM).

Section 2.3.2

Page 13: In the discussion on Risk Response

this publication lists "Transferring (or sharing) risk to another party

such as through insurance" as a primary risk response option.

3. Peyton

E. (2006). Lecture 15: Risk Management. 1.040/1.401 Project Management

Fall 2006. Massachusetts Institute of Technology: MIT OpenCourseWare.

Slide 14

"Risk Response Planning": This university course material identifies four strategies for negative risks. It defines "Transfer" as shifting the risk and its consequences to a third party and lists "Insurance" as the prime example of this strategy.

The foundational step in a risk-based approach to cybersecurity is asset management, which begins with identifying and valuing assets. To categorize and prioritize systems for protection based on the sensitivity of their content (confidentiality, integrity, and availability), a security analyst must first determine the value of each asset. This valuation dictates the level of security controls required and guides all subsequent risk management activities, such as vulnerability scanning and control implementation. Without understanding the asset's value, it is impossible to appropriately prioritize security efforts or justify the cost of protective measures.

A. Interviewing users is a useful data-gathering step, but it does not establish the authoritative business value or impact, which is necessary for formal categorization.

B. Scanning for vulnerabilities is a subsequent step in risk assessment. The criticality of a vulnerability is determined by its potential impact on a valued asset.

C. Configuring alerts is a proactive security control. This action is typically performed after systems have been categorized and appropriate security baselines have been established.

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

Revision 1

Guide for Conducting Risk Assessments. Section 2.2

"Conduct Assessment

" outlines the process which begins with identifying assets and their value to determine the impact of a loss of confidentiality

integrity

or availability. Specifically

Task 2-3

"Determine impact

" relies on the value of the system and data.

2. Federal Information Processing Standards (FIPS) Publication 199

Standards for Security Categorization of Federal Information and Information Systems. Section 3

"Security Categorization

" states

"The first step in the security categorization process is to identify the information types processed

stored

or transmitted by the information system." This process is directly tied to determining the value and sensitivity of the information asset to establish a security category.

3. Purdue University

Information Security Risk Management (CS 52600) Courseware. The risk management lifecycle taught in this program begins with "Asset Identification and Valuation

" establishing it as the prerequisite step before threat analysis or vulnerability assessment. This is a standard model in academic cybersecurity curricula.

Security Orchestration, Automation, and Response (SOAR) platforms are designed to integrate disparate security tools and automate workflows. The primary mechanism for enabling a SOAR platform to communicate with, command, and control tools from different vendors is through Application Programming Interfaces (APIs). APIs provide a standardized programmatic interface that allows the SOAR solution to send instructions (e.g., "block this IP on the firewall," "isolate this endpoint with the EDR") and retrieve data from various security products, thereby orchestrating actions across the entire security stack.

A. STIX/TAXII: These are standards for formatting and transporting threat intelligence data, not for executing commands or actions on security platforms.

C. Data enrichment: This is a process where a SOAR platform augments initial alert data with more context; it is a function, not the technology used for cross-platform control.

D. Threat feed: A threat feed is a source of threat intelligence data that a SOAR platform consumes. It does not provide the mechanism to automate actions on other tools.

1. National Institute of Standards and Technology (NIST). (2022). Security Orchestration

Automation

and Response (SOAR) and the Security Operations Center (SOC) (NISTIR 8362). In Section 2.2

"SOAR Capabilities

" the document states

"SOAR platforms integrate with other security tools and systems through APIs... This integration allows the SOAR platform to collect data from and send commands to the other tools."

2. Carnegie Mellon University Software Engineering Institute (SEI). (2019). A Look at SOAR (Security Orchestration

Automation

and Response). The publication notes that a key feature of SOAR is its ability to "integrate with other security tools through application programming interfaces (APIs)." This integration is what enables the orchestration and automation of security tasks.

3. SANS Institute. (2019). SOAR: A Practitioner's Guide to Security Orchestration

Automation

and Response. This guide explains that the core of SOAR's integration capability relies on APIs

referring to them as the "connective tissue" that allows the SOAR platform to interact with and control a diverse set of security tools for automated response actions. (p. 5).

When communicating an incident to the general public, an incident manager must collaborate with specialized teams to ensure the message is both legally sound and effectively managed. The Legal department is critical for reviewing all external communications to ensure compliance with data breach notification laws and to mitigate legal liability. The Public Relations department is responsible for crafting the message, managing media inquiries, and preserving the organization's reputation. This dual-pronged approach ensures that public statements are accurate, compliant, and strategically delivered to maintain public trust.

A. Law enforcement: Law enforcement is an external agency to be notified if a crime has occurred, not an internal entity that approves the organization's public communication process.

B. Governance: Governance provides the high-level framework and policies, but the specific, operational task of crafting and approving public statements falls to legal and PR teams.

D. Manager: This option is too vague. The incident manager is a manager who coordinates with other specific functional leads, such as the heads of legal and public relations.

F. Human resources: Human resources primarily handles internal communications and personnel-related matters, not external communications with the general public regarding a security incident.

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

Computer Security Incident Handling Guide.

Section 2.4.3

"Relationships with Other Groups

" states

"The CSIRT should also have a close relationship with the organization’s general counsel and public affairs offices. The general counsel can provide advice on legal issues... Public affairs can handle the media

which is particularly important during a high-profile incident." This directly supports the involvement of Legal (general counsel) and Public Relations (public affairs).

2. University of Washington. (2023). UW-IT Information Security and Privacy: Incident Response Plan.

Section "Incident Response Team

" under the subsection for "External Communications

" explicitly lists "University Marketing & Communications" (the public relations function) and the "Office of the Attorney General" (the legal function) as the primary entities responsible for coordinating and approving communications with the media and the public.

3. Solove

D. J.

& Citron

D. K. (2017). Risk and Anxiety: A Theory of Data-Breach Harms. The George Washington University Law School Public Law and Legal Theory Paper No. 2017-10.

Section IV.B

"The Response to a Data Breach

" discusses the institutional response

emphasizing that "companies often hire public relations firms to help them manage the crisis" and that legal counsel is central to navigating the complex web of state and federal notification laws. This academic source underscores the essential roles of both PR and legal teams. (Available via SSRN and university repositories).

The security audit's purpose is to identify unsecured network services. Based on the provided list, FTP (File Transfer Protocol) on port 21 and Telnet on port 23 are inherently insecure. Both of these legacy protocols transmit all data, including usernames and passwords, in cleartext across the network. This allows any attacker with the ability to monitor network traffic (e.g., via a man-in-the-middle attack) to easily capture and read sensitive information. Therefore, their presence represents a significant security vulnerability that requires immediate investigation and remediation, typically by replacing them with secure alternatives like SFTP and SSH, respectively.

B. 22: SSH (Secure Shell) is a secure protocol that provides strong encryption for all transmitted data, including credentials, making it the secure replacement for Telnet.

D. 636: LDAPS (Lightweight Directory Access Protocol Secure) is the secure version of LDAP, using SSL/TLS to encrypt communications. The unsecured version runs on port 389.

E. 1723: While PPTP (Point-to-Point Tunneling Protocol) is considered insecure due to known cryptographic vulnerabilities, FTP and Telnet are more fundamentally unsecured as they lack any encryption whatsoever.

F. 3389: Modern RDP (Remote Desktop Protocol) is a secure protocol that encrypts remote administration sessions, especially when Network Level Authentication (NLA) is enabled.

---

1. National Institute of Standards and Technology (NIST)

Special Publication 800-53 Revision 5

Security and Privacy Controls for Information Systems and Organizations

September 2020. In control family SC (System and Communications Protection)

control SC-8(1) "Cryptographic Protection" mandates the use of validated cryptography for data in transit. Protocols like Telnet and FTP do not meet this requirement as they transmit data in cleartext. (See control SC-8

Page 229).

2. Internet Engineering Task Force (IETF)

RFC 4217

Securing FTP with TLS

October 2005. The introduction (Section 1

Page 2) explicitly states

"The File Transfer Protocol [FTP] ... is weak with respect to security as it sends all passwords and data in the clear." This highlights the inherent insecurity of the standard FTP protocol.

3. Purdue University

CS 42600: Computer Security Courseware

"Lecture 18: Network Security". This and similar university course materials consistently identify Telnet and FTP as canonical examples of insecure protocols that operate in cleartext and should be replaced by secure alternatives like SSH and SFTP. (Specific lecture notes often detail the packet structure showing cleartext credentials).

The observed pattern of regular, periodic, outgoing HTTPS connections from a server to a single public IP address is a classic indicator of Command and Control (C2) beaconing. Malware on the compromised server establishes these connections to "call home" to its controller, receive instructions, or signal its operational status. Using a common protocol like HTTPS on port 443 is a technique used by adversaries to blend malicious traffic with legitimate network activity, making it harder to detect. The "around the clock" nature of the connections reinforces the automated, persistent nature of a C2 beacon.

B. Data exfiltration: This typically involves large or sustained data transfers, not the regular, repeating "heartbeat" pattern described in the scenario.

C. Anomalous activity on unexpected ports: The activity uses HTTPS (port 443), which is a very common and expected port for network traffic, not an unexpected one.

D. Network host IP address scanning: Scanning involves sending probes to many different IP addresses, whereas this activity is directed toward a single, specific public IP.

E. A rogue network device: The traffic originates from a known data-center server, which is a managed asset, not an unauthorized or unknown device on the network.

1. MITRE ATT&CK® Framework. (2023). Technique T1071: Application Layer Protocol. MITRE. Retrieved from https://attack.mitre.org/techniques/T1071/

Reference Detail: Sub-technique T1071.001 (Web Protocols) states

"Adversaries may communicate using HTTP and HTTPS to command and control victim systems... C2 traffic is often camouflaged as normal web traffic to avoid detection." This directly supports the use of HTTPS for C2 communications.

2. NIST Special Publication 800-61 Rev. 2. (2012). Computer Security Incident Handling Guide. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r2

Reference Detail: Section 2.3.3

"Sources of Precursors and Indicators

" discusses how network traffic analysis can reveal indicators of compromise. An unexpected outbound connection from a server

especially one with a regular pattern

is a strong indicator of a compromised host

consistent with C2 activity.

3. SANS Institute Reading Room. (2016). Beats on the Wire: A Security Analysis of Command and Control. SANS Technology Institute.

Reference Detail: Page 6 discusses C2 beaconing

stating

"A beacon is a periodic outbound connection attempt from a compromised host to a command and control server... The beaconing interval can be configured to be anything from seconds to days." This describes the exact behavior observed.

The MITRE ATT&CK® framework is best described as a globally accessible, curated knowledge base of adversary tactics, techniques, and procedures (TTPs) based on real-world observations. Its primary purpose is to serve as a foundation for threat modeling and methodology, enabling organizations to track and better understand adversary behaviors. It is an open-source project that is continuously updated and evolves with contributions from the global cybersecurity community, ensuring it remains relevant against emerging threats. This dynamic nature is a defining characteristic of the framework.

A. This describes application security testing (AST) methodologies like SAST or DAST. While ATT&CK can inform such tests, it is not a testing method itself.

B. This is a better description of an Information Sharing and Analysis Center (ISAC) or a threat intelligence platform (TIP), which focus on the sharing and dissemination of intelligence.

C. This describes a primary use case or outcome of applying the ATT&CK framework, rather than describing the fundamental nature of the framework itself, which is a knowledge base.

E. This accurately describes the Lockheed Martin Cyber Kill Chain®, which models an intrusion as a linear sequence of phases, unlike the ATT&CK matrix, which is non-sequential.

1. The MITRE Corporation. (2023). About ATT&CK. MITRE ATT&CK®. Retrieved from https://attack.mitre.org/resources/getting-started/. In the "What is ATT&CK?" section

it is defined as "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations." This supports the "tracks and understands threats" aspect. The community-driven and evolving nature is also a central theme.

2. NIST. (2021). Special Publication 800-160

Volume 2

Revision 1: Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-160v2r1. In Appendix F

Section F.3

ATT&CK is described as a "curated knowledge base and model for cyber adversary behavior" used to "characterize and describe adversary behaviors." This aligns with the concept of a tool to track and understand threats.

3. Applebaum

A. (2020). A Survey of the MITRE ATT&CK Framework. SANS Institute Reading Room. Retrieved from https://www.sans.org/white-papers/39390/. On page 4

the paper states

"The ATT&CK framework is a knowledge base of adversary behavior and a model for describing the actions an adversary may take... It is a living

community-driven knowledge base that is continuously updated..." This directly supports the description of an evolving

open project for understanding threats.

The primary purpose of implementing a Secure Software Development Life Cycle (SSDLC) is to integrate security practices into every phase of software development, from requirements gathering to deployment and maintenance. This proactive "shift-left" approach systematically reduces the number of vulnerabilities in the final product, thereby decreasing the operational and business risks associated with its usage. Furthermore, many industries are subject to stringent regulatory and compliance frameworks (e.g., PCI DSS, HIPAA, GDPR) that mandate secure software development practices. Adhering to an SSDLC is a critical mechanism for demonstrating and achieving compliance with these legal and industry requirements.

A. The primary goal of an SSDLC is risk reduction and security assurance, not to serve as a marketing tool to justify price increases.

C. An SSDLC integrates with agile processes but typically increases the scope and frequency of security testing throughout the lifecycle, rather than decreasing it.

D. An SSDLC fosters a culture of shared responsibility for security (DevSecOps), embedding it within the development team, not transferring it to another team.

1. National Institute of Standards and Technology (NIST). (2022). Special Publication (SP) 800-218 V1.1

Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities.

Section 1

Introduction

Paragraph 2: "The SSDF’s goal is to reduce the number of vulnerabilities in released software

mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities

and address the root causes of vulnerabilities to prevent recurrences." This directly supports the risk reduction aspect of the correct answer.

2. OWASP Foundation. (n.d.). OWASP Software Assurance Maturity Model (SAMM) v2.0.

Section

Business Functions

Governance (G)

Paragraph 1: "The Governance function is responsible for managing the organization’s software development life cycle. It includes activities related to strategy

metrics

policy

compliance

and education." This highlights the role of an SSDLC in meeting compliance requirements.

3. Mead

N. R. (2005). Security Quality Requirements Engineering (SQUARE) Methodology. Carnegie Mellon University

Software Engineering Institute. CMU/SEI-2005-TR-009.

Page 1

Abstract: "Building secure software is a difficult problem... Failure to do so can result in serious vulnerabilities

leading to loss of money

life

and national security... This report describes the Security Quality Requirements Engineering (SQUARE) methodology... for eliciting

categorizing

and prioritizing security requirements for information technology systems and applications." This academic source establishes the direct link between secure development processes and mitigating risks from vulnerabilities.

The installation of a new EDR solution has led to a significant increase in alerts, causing alert fatigue and overwhelming the security team. To manage this, the organization needs to centralize the aggregation of these alerts and automate the response process.

A SIEM (Security Information and Event Management) system is the primary tool for centralizing security data. It aggregates logs and alerts from various sources, including the new EDR, into a single platform. This allows analysts to correlate events, reduce false positives, and prioritize threats from a unified viewpoint.

A SOAR (Security Orchestration, Automation, and Response) platform complements the SIEM by automating the remediation workload. It uses predefined "playbooks" to execute response actions automatically, such as isolating an endpoint or blocking an IP address, which directly reduces the manual effort required by analysts.

C. MSP: A Managed Service Provider is an external service that would outsource the workload, not provide a tool to help the internal team centralize it.

D. NGFW: A Next-Generation Firewall is a network security device that is a source of security alerts, not a tool for centralizing and managing alerts from other systems.

E. XDR: While Extended Detection and Response centralizes data, it is typically a more integrated, often single-vendor, evolution of EDR. A SIEM is the classic, vendor-agnostic solution for centralizing data from disparate sources, which is the immediate need.

F. DLP: Data Loss Prevention is a specific security control designed to prevent data exfiltration; it would add to the alert volume rather than help manage it.

1. NIST (National Institute of Standards and Technology). (2021). NISTIR 8334 (Draft) - A Response to the Challenge of Finding and Fixing Vulnerabilities. Section 2.2

"Security Orchestration

Automation

and Response (SOAR)

" describes SOAR as a solution to "reduce the burden on security practitioners" by automating "time-consuming

manual

and repetitive tasks." This directly addresses the increased workload.

2. NIST. (2006). SP 800-92 - Guide to Computer Security Log Management. Section 4.3

"Log Management Infrastructures

" discusses the centralization of logs for analysis. It states

"Centralized logging permits the correlation of events among several systems

" which is the core function of a SIEM in addressing a high volume of alerts from sources like an EDR.

3. Carnegie Mellon University. (2017). The 2017 SEI Cyber Intelligence Research Agenda. Section 3.2.2

"Security Orchestration

" discusses the need for tools that "integrate information from a variety of sources (e.g.

SIEMs

threat intelligence platforms...)" and "automate and assist with the response

" highlighting the synergistic roles of SIEM and SOAR. (Document CMU/SEI-2017-SR-001).

4. Suh

B.

& Lee

H. (2021). A Study on the Method of Building an Intelligent Security Control System Using SOAR. Journal of The Korea Institute of Information Security & Cryptology

31(1)

139-150. This academic paper explains that SOAR platforms are introduced to handle the "increasing security threats and alerts" by integrating with SIEMs to automate response procedures

which is the exact scenario described. (DOI: https://doi.org/10.13089/JKIISC.2021.31.1.139).

Dynamic Application Security Testing (DAST) exercises a running application with crafted inputs and analyzes the responses to uncover runtime‐layer flaws such as SQL injection, file-path inclusion (FRI), and cross-site scripting (XSS). Because it is performed throughout development and before production release, it supports the “security-by-design” objective of identifying and remediating vulnerabilities early in the software development life cycle.

A. Reverse engineering – Focuses on dissecting compiled binaries (often third-party or malicious code) rather than proactively finding vulnerabilities in software the organization is developing.

B. Known environment testing – Not an established security-testing methodology; offers no systematic process for detecting web-application vulnerabilities like injection or XSS.

D. Code debugging – Aims to correct logic or syntax errors; it lacks the automated attack simulation and vulnerability signatures required to expose security flaws such as SQLi or XSS.

1. NIST SP 800-115

“Technical Guide to Information Security Testing and Assessment

” §4.6.1 Dynamic Testing

pp. 4-7–4-9 – describes using dynamic analysis to detect SQLi

XSS

and file-inclusion flaws.

2. NIST SP 800-218 Rev.1

“Secure Software Development Framework

” Practice PO.3.3 & PO.4.2 – mandates dynamic analysis during development to identify injection and scripting vulnerabilities.

3. MIT OpenCourseWare 6.858 (Computer Systems Security)

Lecture 4 slides 34-36 – presents DAST tools (e.g.

Burp

ZAP) for finding runtime web-application flaws such as SQLi and XSS.

The scenario describes adversaries using "Living-off-the-Land" (LotL) techniques, where they leverage legitimate, native system tools (e.g., PowerShell, WMI) for malicious activities like privilege escalation. The most direct and effective control against this is application control. By implementing policies to block the execution of untrusted applications or, more granularly, restricting how trusted applications can be run (e.g., preventing Office applications from spawning PowerShell), an organization can directly disrupt the adversary's ability to use these native tools for malicious purposes. This approach, often implemented via application allowlisting, specifically targets the execution of unauthorized code, which is the core of the described threat.

A. Disabling administrative accounts is operationally infeasible, as these accounts are required for legitimate system administration and maintenance tasks.

B. MFA is an authentication control that is most effective at preventing unauthorized access, not at stopping post-compromise activities like local privilege escalation.

C. While system hardening is a valuable practice, adversaries are using core, necessary tools, which typically cannot be disabled or removed without impacting system functionality.

1. MITRE ATT&CK® Framework: The technique T1548

"Abuse Elevation Control Mechanism

" describes adversaries using system features to elevate privileges. The primary listed mitigation is M1048

"Application Control

" which states: "Use application control to prevent the execution of malicious commands and scripts that may be used to abuse elevation control mechanisms." This directly aligns with blocking the execution of untrusted applications. (Source: MITRE ATT&CK

Technique T1548

Mitigation M1048).

2. NIST Special Publication 800-53 Rev. 5

Security and Privacy Controls for Information Systems and Organizations: Control CM-7

"Least Functionality

" advocates for configuring systems to provide only essential capabilities. A key implementation of this principle is "the use of application allowlists... to ensure that only authorized software is allowed to execute." This control directly mitigates the threat of legitimate tools being used for unintended

malicious purposes. (Source: NIST SP 800-53 Rev. 5

Control: CM-7

Page 133).

3. Cybersecurity and Infrastructure Security Agency (CISA): In guidance on protecting against malicious activity

CISA consistently recommends application control as a high-priority defense. For example

in the "Joint Cybersecurity Advisory on Russian State-Sponsored Cyber Actors

" CISA recommends organizations "Implement application allowlisting" as a mitigation against actors who leverage legitimate remote access tools and other LOLbins. (Source: CISA Alert AA22-110A

Mitigations Section).

The output in Tab 1 displays a list of files and their corresponding MD5 hash values. In Windows PowerShell, the Get-ChildItem cmdlet gets the items in a specified location (in this case, the current directory), and the pipe | sends that output to the Get-Filehash cmdlet. The -Algorithm MD5 parameter specifies that the MD5 hashing algorithm should be used. The resulting output format perfectly matches what is shown in Tab 1.

The output in Tab 2 shows active TCP connections, including local and foreign addresses, state, and the process ID (PID). Critically, it also lists the executable file name (e.g., [sftp.exe]) below each relevant connection. The netstat command is used to display network connections. The -b switch displays the executable involved in creating each connection, and the -o switch displays the owning process ID. The combination netstat -bo produces the exact format seen in Tab 2.

To identify the malicious file, we must correlate information from all tabs.

File Integrity Check: First, compare the current file hashes from Tab 1 with the known-good baseline hashes from Tab 4. The MD5 hash for cmd.exe in Tab 1 (372ab...) does not match the baseline hash in Tab 4 (a2cde...). This indicates the cmd.exe file has been modified or replaced.

Network Activity Analysis: Next, examine the network connections in Tab 2. The modified cmd.exe file is shown to have an established outbound connection to 192.168.10.37:http. The Windows Command Prompt (cmd.exe) should not be making persistent outbound network connections, making this behavior highly suspicious and indicative of data exfiltration or command-and-control (C2) communication.

The combination of a failed integrity check (mismatched hash) and suspicious network activity makes cmd.exe the file responsible for the malicious behavior.

Microsoft. (2023). Get-FileHash. Microsoft Docs. Retrieved from docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash. (This official documentation describes the cmdlet used to generate the output in Tab 1.)

Microsoft. (2021). Netstat. Microsoft Docs. Retrieved from docs.microsoft.com/en-us/windows-server/administration/windows-commands/netstat. (This document details the netstat command and its parameters, such as -b and -o, which produce the output seen in Tab 2.)

Hogben, G., & Plohmann, D. (2016). Threat Landscape and Good Practice Guide for Smart Home and Converged Media. European Union Agency for Network and Information Security (ENISA). p. 28. (This report discusses how attackers replace legitimate system files, like cmd.exe, with malicious versions to establish persistence and create backdoors, aligning with the observed hash mismatch.)

Tanenbaum, A. S., & Wetherall, D. J. (2011). Computer Networks (5th ed.). Pearson Education. p. 657. (This textbook explains the TCP/IP protocol suite and connection states, providing the foundational knowledge to interpret netstat output and identify unusual established connections like an HTTP connection from cmd.exe.)

A thorough analysis of the provided logs reveals a clear sequence of a security incident.

1. Suspicious Activity: The SFTP log shows the external IP address 41.21.18.102 successfully logging in using the sjames account at 23:01:50. Immediately after, at 23:02:25, this IP writes to the index.html file, which directly corresponds to the website being "maliciously altered." The netstat log corroborates this by showing an ESTABLISHED connection from 41.21.18.102 to the local machine on port 22 (the standard port for SFTP/SSH).
2. Indicator of Compromise (IoC): The most direct evidence of the website defacement is the log entry showing the unauthorized modification of the primary web page. Therefore, the modified index.html file is the key IoC. The 404 errors from other IPs are less critical than a confirmed malicious file write.
3. Corrective Actions: The incident response must focus on containment and eradication.

• Changing the password for the sjames account is the immediate containment action to revoke the attacker's access.
• Deleting the sjames account is a necessary eradication step, ensuring this specific compromised asset can no longer be exploited. This action follows the initial password change to ensure the account is fully removed.

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer Security Incident Handling Guide (NIST Special Publication 800-61 Rev. 2). National Institute of Standards and Technology.

Page 20, Section 3.3.2 (Containment): Recommends actions such as "changing passwords" for compromised accounts as a primary containment strategy.

Page 23, Section 3.3.3 (Eradication and Recovery): Discusses eradication, which includes "deleting user accounts" that were used in the attack.

Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson.

Chapter 3, Section 3.5.2: Explains the TCP connection states, including ESTABLISHED, confirming that the netstat output shows an active, two-way connection between the server and the attacker's IP address (41.21.18.102).

Al-Harbi, M. (2020). A Framework for Detecting and Analyzing Web Defacement Attacks. IEEE Access, 8, 185672-185689. https://doi.org/10.1109/ACCESS.2020.3029981

Section III-B, Table II: Lists "Unauthorized file modification" as a primary Indicator of Compromise (IoC) for web defacement attacks, validating the selection of the "Modified index.html file" as the key indicator.

The firewall log contains an alert message at 14:03:19 on Dec 1 identifying the file invoice.exe originating from the IP address 81.161.63.253. The file integrity monitoring report confirms that invoice.exe was added to a user's downloads folder at 14:03:55. Furthermore, the malware domain list explicitly lists 81.161.63.253 as a known malicious host. The firewall alert is the earliest record of the malware entering the organization's network.

This incident follows a standard cyber-attack kill chain. The most effective control at each stage would be:

1. Phishing email: Email filtering is the primary control to detect and block malicious emails before they reach the user.
2. Active links: Converting emails to plain text email format removes clickable hyperlinks, forcing the user to manually copy and paste the URL, which reduces the risk of accidental clicks.
3. Malicious website access: An IP blocklist on the firewall would prevent any connection to known malicious IP addresses, such as the one identified in the malware domain list.
4. Malware download: A firewall file type filter can be configured to block the download of potentially malicious file types, like executables (.exe), from untrusted sources.
5. Malware install: The vulnerability scan noted that users had excessive privileges. Enforcing restricted local user permissions would prevent a standard user from installing unauthorized software.
6. Malware execution: If the malware is installed, an updated antivirus solution is the last line of defense to detect and quarantine the malicious process upon execution.
7. File encryption: In a worst-case scenario where the malware successfully encrypts files, having reliable backups is the only way to restore the data and recover from the attack.

Stallings, W., & Brown, L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson. (Discusses email security gateways (filtering), access control based on user permissions, and the role of antivirus software in Ch. 9 and Ch. 21).

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in Computing (5th ed.). Prentice Hall. (Covers principle of least privilege, corresponding to restricted permissions, and describes firewall filtering policies in Ch. 8).

Kim, D., & Solomon, M. G. (2016). Fundamentals of Information Systems Security (3rd ed.). Jones & Bartlett Learning. (Details layered security and defense-in-depth, illustrating how controls like IP blocking, file filtering, and backups function at different stages of an attack).

The analysis of scan data against the hardening guidelines reveals non-compliance in AppServ2 and AppServ3.

• AppServ2 is running Apache version 2.3.48, which is below the required version 2.4.18 or greater. Additionally, its Nmap scan shows only port 80 (HTTP) is open, meaning it is not using the default port 443 for a secure service (HTTPS).
• AppServ3 has an open HTTPS port (443), but the ssl-enum-ciphers scan fails to report that TLS 1.2 is enabled, which violates the guideline requiring TLS 1.2 as the only active version.
• AppServ1 and AppServ4 are considered compliant as the provided data does not indicate any violations of the specified hardening guidelines.

National Institute of Standards and Technology (NIST). (2019). Special Publication 800-52r2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. Section 3.1 recommends that "servers that support government-only applications and clients shall be configured to use TLS 1.2 and should be configured to use TLS 1.3." The absence of a confirmed TLS 1.2 configuration on AppServ3 makes it non-compliant. https://doi.org/10.6028/NIST.SP.800-52r2

The Apache Software Foundation. Apache HTTP Server 2.4 documentation. The official Apache documentation outlines features and security fixes introduced in new versions. Using an outdated version like 2.3.48 (as seen on AppServ2) means missing critical security patches and features available in the required 2.4.18 and later versions.

Nmap.org. Nmap Scripting Engine (NSE) Documentation: ssl-enum-ciphers. The official Nmap documentation explains that this script queries a server to enumerate its supported SSL/TLS protocol versions and ciphers. The lack of output for AppServ3 indicates a configuration issue, while the specific output for AppServ4 confirms its use of TLS 1.2.

Internet Engineering Task Force (IETF). (2008). RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Section F.1.1 describes version negotiation. If a server cannot negotiate a compliant version (TLS 1.2), it violates protocols designed to ensure secure communication.

Analyze the Timeframe: The request is to identify a server that must be patched within 14 calendar days. According to the "Vulnerability remediation timeframes" policy, this specific timeframe applies to vulnerabilities with a CVSS score between 7.9 and 9.0 that affect the Production (PROD) environment.

Eliminate Incorrect Options:

• The "Output" tab shows two fully detailed vulnerabilities on servers 192.168.76.5 (CVSS 9.2) and 192.168.76.6 (CVSS 7.4).
• Based on the "Environment" tab, both of these servers are in the 192.168.76.0/24 subnet, which belongs to the Development (DEV) environment.
• The remediation policy explicitly states that these timeframes do not apply to the DEV environment. Furthermore, their CVSS scores (9.2 and 7.4) do not fall within the 14-day remediation window (7.9-9.0). Therefore, neither of these servers is the correct choice.

Identify the Correct Server and Vulnerability:

• The list of selectable servers includes 192.168.60.5 and 192.168.60.6. The "Environment" tab confirms these IPs are part of the PROD environment (192.168.60.0/24).
• This implies that a third, partially-visible vulnerability in the "Output" tab—"Untrusted SSL/TLS Server X.509 certificate"—affects one of these PROD servers and has a CVSS score that falls within the 7.9-9.0 range, mandating a 14-day fix.
• The most appropriate mitigation for an untrusted SSL/TLS certificate is to replace it with a valid certificate issued by a reputable Certificate Authority (CA).

Select the Correct Mitigation: The option "Patch; upload signed certificate from trusted third-party provider" directly addresses the "Untrusted SSL/TLS Server X.509 certificate" vulnerability.

National Institute of Standards and Technology (NIST). (2013). Guide to Enterprise Patch Management Technologies (Special Publication 800-40r3). Section 2.2, "Patch Management Policy," discusses the importance of creating policies that specify remediation timeframes based on vulnerability severity.

Mell, P., & Scarfone, K. (2011). The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems (NISTIR 7435). This document details how CVSS scores are used to assess and prioritize vulnerabilities, forming the basis for remediation policies like the one shown.

The Open Web Application Security Project (OWASP). Transport Layer Protection Cheat Sheet. This resource explains the risks associated with improper TLS configuration, including the use of untrusted certificates, and recommends using valid certificates from trusted CAs as a primary control. (Available at owasp.org).

The solution is derived by applying the company's system hardening guidelines to the discovered services on each device.

1. Primary Role Identification: Each device's role is determined by identifying its most significant service, aligning with the "one primary service per device" rule. For instance, a device running HTTP/HTTPS is a Web Server, and one running SMTP/IMAP is a Mail Server.
2. Disabling Non-Secure Protocols: The guidelines require disabling non-secure protocols. The analysis identifies services like Telnet, FTP, HTTP, and IMAP because they transmit data, including credentials, in cleartext. Protocols like NetBIOS and RPC are also identified as non-compliant due to well-known vulnerabilities. Their secure alternatives (e.g., SSH, SFTP, HTTPS, IMAPS) are compliant.
3. DMZ Placement: The device LunchTimeMike.Local is correctly placed in the DMZ, satisfying the requirement for protecting the corporate internet presence.

National Institute of Standards and Technology (NIST) Special Publication 800-123, Guide to General Server Security. Section 4.4, "Services," advises to "disable services that are not required." It emphasizes minimizing the attack surface by removing or disabling all unnecessary functions and services.

Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Chapter 8, "Security in Computer Networks," details the vulnerabilities of protocols like Telnet and FTP, which transmit passwords and data in the clear, contrasting them with secure protocols like SSH and SSL/TLS.

Internet Engineering Task Force (IETF) RFC 854, Telnet Protocol Specification. The specification for Telnet does not include provisions for encryption, making it fundamentally insecure for transmitting sensitive information over untrusted networks.

Internet Engineering Task Force (IETF) RFC 959, File Transfer Protocol. Section 4.1 describes the unencrypted transmission of commands and data, which is the basis for its classification as a non-secure protocol. Secure alternatives like FTPS (RFC 4217) or SFTP are recommended.

A thorough analysis of the provided logs confirms the scope of the phishing incident.

1. Users Who Clicked the Link (19): The "File Server Logs" show network traffic from internal workstations to various suspicious external URLs (e.g., funweb.cn, slopthebotnet.com, chzbwebtilapia.com). Counting the unique "Source IP" addresses making these requests reveals that 19 different users clicked the phishing link.
2. Malware Executable and Infected Workstations (mailclient.exe, 1): The "SIEM Logs" provide host-level details. A "Process Creation" event for an executable named mailclient.exe is recorded for the IP address 192.168.0.188. This event occurred at 4:14:34 PM, just 30 seconds after the same IP was seen in the file server logs accessing a suspicious URL. A non-standard, generic name like mailclient.exe is a common malware tactic. As this is the only host showing this suspicious process creation, we can conclude that only 1 workstation was successfully infected.

NIST Special Publication 800-61 Rev. 2, Computer Security Incident Handling Guide. Section 3.2.3, "Sources of Precursors and Indicators," discusses how network traffic logs (like the file server/proxy logs) and host-based security software logs (like the SIEM logs) are primary sources for detecting and analyzing security incidents. Correlating data between these sources is fundamental to identifying compromised hosts. (p. 25).

Carnegie Mellon University, Software Engineering Institute. The CERT Guide to Insider Threats: How to Prevent, Detect, and Respond to Information Risk. Addison-Wesley, 2012. Chapter 14, "Analyzing System Logs," explains the importance of correlating different log types (e.g., network proxy and host process logs) to build a timeline of an attack and confirm a system compromise.

Russinovich, M. E., Solomon, D. A., & Ionescu, A. Windows Internals, Part 1 (7th ed.). Microsoft Press, 2017. Chapter 5, "Processes, Threads, and Jobs," details the legitimate system processes in Windows. An executable like mailclient.exe, which is not a standard Windows or common application process, would warrant investigation as potentially malicious during a forensic analysis.

The analysis requires mapping the vulnerabilities from the scan report to the correct servers in the network diagram and selecting the appropriate validation and remediation actions.

1. WEB_SERVER01: The vulnerability report shows a high-severity finding, "Cleartext Transmission of Sensitive Information," for the affected asset 172.30.0.15. This IP address is likely a typo for 172.30.0.150, which corresponds to WEB_SERVER01. This is a valid finding, making it a True Positive. The direct remediation for transmitting sensitive data in cleartext is to enforce encryption for the entire communication channel, hence Encrypt Entire Session.
2. WEB_SERVER02: The vulnerability scan report does not list any findings for the IP address 172.30.0.151, which is assigned to WEB_SERVER02. Therefore, any flagged vulnerability for this server is a False Positive. The standard procedure for a false positive in a compliance scan is to formally dispute the finding, which is best represented by the action Submit as Non-Issue.
3. WEB_SERVER03: The report explicitly lists a medium-severity finding, "Sensitive Cookie in HTTPS session without 'Secure' Attribute," for the IP address 172.30.0.152 (WEB_SERVER03). This is a True Positive vulnerability. The 'Secure' attribute ensures a cookie is only transmitted over an encrypted HTTPS connection. The most precise remediation is to enforce this attribute, which is accomplished by selecting Encrypt All Session Cookies.

OWASP Foundation. (n.d.). A02:2021-Cryptographic Failures. OWASP Top Ten. Retrieved from https://owasp.org/Top10/A02_2021-Cryptographic_Failures/. This reference details risks associated with transmitting data in cleartext (relevant to WEB_SERVER01).

OWASP Foundation. (n.d.). Secure Flag. OWASP Cheat Sheet Series. Retrieved from https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#secure-flag. This document explains the purpose of the 'Secure' cookie attribute and its role in preventing session sidejacking (relevant to WEB_SERVER03).

PCI Security Standards Council. (2022). Payment Card Industry Data Security Standard (PCI DSS) v4.0. Section 6.3.1. This standard requires that all system components and software have vulnerabilities corrected. For false positives, PCI DSS allows for them to be disputed with evidence. The process of submitting a finding as a "non-issue" aligns with this requirement (relevant to WEB_SERVER02).

The prioritization, categorization, and control selection are based on a standard risk management framework where risk is a function of impact and likelihood.

1. Prioritization & Categorization:

• Priority 1 (High): An internet-facing server with no authentication protecting its data represents the most critical and immediate threat, with the highest potential impact and likelihood of a breach.
• Priority 2 (High): A confirmed data breach of patient prescription information has a severe, realized impact due to regulatory (e.g., HIPAA) and reputational damages.
• Priority 3 (High): Malicious emails are a primary attack vector for ransomware and widespread compromise, posing a high risk to the entire organization.
• Priority 4 (High): Storing real Protected Health Information (PHI) in less-secure development environments creates a significant and unnecessary attack surface.
• Priorities 5-8 are ranked lower based on a decreasing scale of potential impact and immediacy, from active network scanning (High), to internal policy violations (Medium), down to a limited physical security lapse (Low).

1. Control Selection:

• The chosen controls directly mitigate the identified risks. For instance, Data Loss Prevention (DLP) is specifically designed to prevent the unauthorized exfiltration of sensitive data, such as PHI being emailed incorrectly.
• Implementing an Identity and Access Management (IAM) program is the foundational control to fix a server that lacks authentication.
• Data deidentification is the correct procedure for safely using data in non-production environments.
• Physical security issues (fax machine) require physical controls (Relocate devices), and technical controls like application whitelisting (Implement approved software listing) address unauthorized software installations.

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in Computing (5th ed.). Prentice Hall.

Chapter 1 discusses risk analysis, including assessing impact and likelihood (pp. 29-35).

Chapter 7 covers controls against network attacks, including filtering ICMP traffic (pp. 410-412).

Chapter 9 discusses data protection controls like DLP and encryption (pp. 530-535).

National Institute of Standards and Technology. (2018). Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1.

The "Protect" function (PR) outlines categories for access control (PR.AC), data security (PR.DS), and protective technology (PR.PT), which align with implementing IAM, DLP, encryption, and mail filters. The framework emphasizes prioritizing actions based on business drivers and risk assessment. (Section 2.2, pp. 11-14). https://doi.org/10.6028/NIST.CSWP.04162018

Owen, G., & Philpott, M. S. (2015). Practical Considerations for Data De-identification. MIT Computer Science and Artificial Intelligence Laboratory.

This technical report details the importance and methods of data de-identification to protect privacy when using data for secondary purposes, such as in development and testing environments. (Section 2, p. 2).

The objective is to differentiate between scan types based on the depth of information provided. A credentialed (authenticated) scan acts like an insider, using login credentials to access and report on the host's internal state, such as installed software, patch levels, and configurations. In contrast, a non-credentialed (unauthenticated) scan assesses the host from an external attacker's perspective, identifying open ports, services, and vulnerabilities visible across the network. A compliance scan specifically measures a system's configuration against a predefined security policy or benchmark. Identifying server roles depends on recognizing the standard network ports and services associated with functions like web hosting, file sharing, or directory services.

National Institute of Standards and Technology (NIST). (2008). Special Publication 800-115, Technical Guide to Information Security Testing and Assessment.

Section 5.3 ("Vulnerability Scanning") distinguishes between unauthenticated and authenticated (credentialed) scanning, noting that authenticated scans provide a "more complete and accurate picture of the vulnerabilities" by examining patch levels and system configurations directly.

Section 5.3.3 ("Analysis") discusses the process of validating findings to eliminate false positives.

Scarfone, K., & Souppaya, M. (2010). NIST Special Publication 800-128, Guide for Security-Focused Configuration Management of Information Systems.

Section 4.2.2 ("Security Configuration Checking Tools") describes how automated tools are used to verify compliance with security configurations, which is the functional basis of compliance scanning.

Anand, P., & Ryoo, J. (2018). Vulnerability Assessment and Penetration Testing. In J. Ryoo & N. E. Spaulding (Eds.), Cybersecurity Education for the Real World (pp. 119–137). CRC Press.

Chapter Section "Types of Vulnerability Assessment" (p. 122) explains the difference between unauthenticated and authenticated scans, highlighting that authenticated scans can access low-level data like specific configuration files and registry keys, thus providing more accurate results and reducing false positives compared to unauthenticated scans.

Tanenbaum, A. S., & Wetherall, D. J. (2011). Computer Networks (5th ed.). Pearson Education.

Chapter 8 ("Network Security") provides context on common network services and their associated port numbers (e.g., HTTP on port 80, HTTPS on 443, LDAP on 389), which is foundational knowledge for identifying server roles from scan results.

Fuzzing, also known as fuzz testing, is a dynamic application security testing (DAST) methodology. It involves providing a program with invalid, malformed, unexpected, or random data as inputs to identify security vulnerabilities and defects. The primary goal is to trigger crashes, memory leaks, unhandled exceptions, or other anomalous behaviors that could indicate a potential security flaw. This process automates the discovery of bugs that might be missed by manual code inspection or other testing methods, effectively "stressing" the application's input validation and error-handling routines. The description provided in the question is the textbook definition of fuzzing.

A. Reverse engineering: This is the process of deconstructing a compiled program to understand its functionality and design; it does not involve testing the application with live data inputs.

B. Static: This refers to Static Application Security Testing (SAST), which analyzes an application's source code or binaries for vulnerabilities without executing the program.

D. Debugging: This is the process of identifying, analyzing, and removing defects (bugs) from software. While fuzzing helps find bugs, debugging is the subsequent act of fixing them.

1. Manès

V. J. M.

Han

H. S.

Han

C.

Cha

S. K.

Egele

M.

Schwartz

E. J.

& Woo

M. (2019). The Art

Science

and Engineering of Fuzzing: A Survey. IEEE Transactions on Software Engineering

47(11)

2312-2331. In Section I (Introduction)

the paper defines fuzzing as a technique that "works by sending a large number of inputs to a target program in the hope of triggering a crash." https://doi.org/10.1109/TSE.2019.2946529

2. Godefroid

P.

Levin

M. Y.

& Molnar

D. (2012). SAGE: whitebox fuzzing for security testing. Queue

10(1)

20-27. The article's introduction defines fuzz testing as "a software testing technique that consists of finding implementation bugs using malformed/semi-malformed data injection in an automated fashion." https://doi.org/10.1145/2090147.2094081

3. MIT OpenCourseWare. (2014). 6.858 Computer Systems Security

Fall 2014. Lecture 7: Software security: fuzzing

bug-finding

and program analysis. The lecture notes define the core idea of fuzzing as: "throw lots of random inputs at a program

see if it crashes." This aligns with the question's description of using random data to detect crashes.

4. Zalewski

M. (2007). Cross-Site Scripting - The new fuzzer in town. In Black Hat Briefings. This presentation

from a leading security researcher and often cited in academic contexts

describes fuzzing as a method of identifying bugs by "feeding a program with semi-random

deliberately mangled data." (Slide 4).

CVSS v3.1 exploitability is driven chiefly by the four base exploitability metrics:

• Attack Vector (AV) – Network (N) is the easiest to reach when Internet-facing.

• Attack Complexity (AC) – Low (L) requires no unusual circumstances.

• Privileges Required (PR) – None (N) means the attacker is unauthenticated.

• User Interaction (UI) – None (N) means no victim action is needed.

Of the listed hosts, “blane” is the only one whose vulnerability is scored AV:N, AC:L, PR:N, UI:N, giving the highest possible Exploitability Sub-Score (3.9). When the systems become publicly reachable, that combination makes “blane” the most readily exploitable and therefore the first system that should be patched.

A. brown – AV is Adjacent (A); the attacker must be on the same subnet, so exposure after Internet publishing is lower than “blane.”

B. grey – Requires User Interaction (UI:R); phishing or social engineering is still needed, lowering exploitability.

D. sullivan – Privileges Required is High (PR:H); an attacker must already possess elevated credentials, greatly reducing likelihood of compromise.

1. FIRST.org

“Common Vulnerability Scoring System v3.1: Specification Document

” §§2.1

2.1.1-2.1.4

pp. 3-7.

2. FIRST.org

“CVSS v3.1: User Guide

” §3.1

p. 10 (exploitability sub-score formula & max of 3.9).

3. MIT OpenCourseWare

6.858 “Computer Systems Security

” Lecture 13 notes

p. 2 (discussion on remote

unauthenticated

no-interaction exploits).

4. NIST SP 800-30 Rev.1

§2.3.1

pp. 9-10 (likelihood of threat exploitation increases with low complexity and no required privileges).

An API (Application Programming Interface) endpoint is the standard, most effective method for integrating two distinct SaaS-based applications. APIs provide a structured, programmatic way for services to communicate, exchange data, and trigger actions in each other. In this scenario, the detecting tool would make a call to the receiving tool's API endpoint, sending structured data about the threat (e.g., in JSON format). This allows for reliable, real-time, and automated communication, which is fundamental for modern security orchestration and response workflows. This method is far more robust and scalable than alternative notification systems like email or file sharing.

A. SMB share: This is a network file-sharing protocol. Using it for application integration is inefficient, insecure, and not designed for real-time, event-driven communication between SaaS platforms.

C. SMTP notification: This uses email for alerts. While functional for human notification, it is a poor method for machine-to-machine integration as it requires parsing unstructured data and lacks reliability.

D. SNMP trap: This is a protocol for monitoring network devices and infrastructure components. It is not designed for the complex, high-level data exchange required between SaaS security applications.

1. Vendor Documentation: Palo Alto Networks. (2023). Cortex XSOAR Administrator's Guide. In the "Integrations" section

the guide details how the platform "interacts with third-party applications... through APIs" to orchestrate security actions

demonstrating this as the industry-standard practice for tool integration.

2. Academic Publication: Tounsi

W.

& Frikha

M. (2018). A survey on security orchestration

automation and response (SOAR). 2018 International Conference on Smart Communications in Network Technologies (SaCoNeT)

(pp. 1-6). The paper explicitly states that SOAR platforms "rely on APIs and connectors to integrate with a wide range of security tools" (Section III.A

"Integration and Interoperability"). This highlights the critical role of APIs in connecting security tools. https://doi.org/10.1109/SaCoNeT.2018.8585556

3. University Courseware: Saltzer

J. H.

& Kaashoek

M. F. (2018). 6.033 Computer System Engineering

Lecture 20: Distributed Systems Part 3: Remote Procedure Call. MIT OpenCourseWare. This lecture covers the foundational principles of Remote Procedure Calls (RPCs)

the conceptual predecessor to modern web APIs

explaining how they are designed to allow different programs on different machines to communicate as if they were local

which is the core goal of the integration described in the question.

The activity described is the Lessons Learned phase of the incident management life cycle. This phase occurs after an incident has been resolved and focuses on reviewing the event and the response effort. Creating a summary for leadership that includes the "who-what-when" (a synopsis of the incident) and evaluates the effectiveness of plans is the primary purpose of this phase. The goal is to identify strengths and weaknesses in the response to improve security posture and refine the incident response plan for future events.

A. Business continuity plan: This is a proactive plan to ensure essential business functions can continue during a disruption, not a reactive review of a past security incident.

C. Forensic analysis: This is the in-depth technical investigation to gather and preserve evidence. The summary is a high-level report that uses findings from forensics, but it is not the analysis itself.

D. Incident response plan: This is the documented set of procedures to be followed during an incident. The activity described is an evaluation of that plan's performance after the fact.

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

Computer Security Incident Handling Guide. Section 3.4

"Post-Incident Activity

" and Section 3.4.2

"Lessons Learned

" pp. 43-44. This section explicitly states that this phase involves "learning and improving" and holding a "lessons learned meeting" to discuss what happened and how to improve. The creation of a final report for management is a key output.

2. Wilson

M.

& Hash

J. (2003). CSIRT Development

Establishing a Computer Security Incident Response Team. Carnegie Mellon University

Software Engineering Institute. CMU/SEI-2003-TN-001. Section 4.3

"Post-Incident Analysis

" p. 19. This document describes the post-incident phase as the time to "review all available information... to determine exactly what happened

why it happened

and what can be done to prevent it from happening again."

3. University of Washington. (n.d.). T INFO 442: Information Assurance and Cybersecurity - Incident Response. Courseware. The curriculum outlines the incident response process based on the NIST framework

identifying "Post-Incident Activity (Lessons Learned)" as the final

critical phase for review and reporting.

The core issue is a "flat" network architecture, which lacks internal controls to isolate resources. This design allows for broad, uncontrolled access, making it easy for sensitive storage to be inadvertently exposed. Implementing network segmentation divides the flat network into smaller, isolated zones (e.g., VLANs or subnets). Access Control Lists (ACLs) are then applied to the boundaries of these segments to enforce granular traffic rules. This approach directly remedies the architectural flaw by creating a defensible space around the sensitive file storage, allowing the company to explicitly deny public access while permitting legitimate internal traffic.

B. Configure logging and monitoring to the SIEM.

This is a detective control that alerts on unauthorized access after it occurs, rather than a preventative measure that stops it from happening.

C. Deploy MFA to cloud storage locations.

MFA strengthens user authentication but is ineffective if the storage is misconfigured for public, unauthenticated access, which bypasses the authentication process entirely.

D. Roll out an IDS.

An Intrusion Detection System (IDS) is a detective control. It monitors and alerts on suspicious activity but does not actively block the traffic or fix the underlying network vulnerability.

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

Security and Privacy Controls for Information Systems and Organizations.

Control SC-7

Boundary Protection: This control explicitly discusses the need to "monitor and control communications at the external boundary of the system and at key internal boundaries within the system." The discussion section further clarifies

"This control also addresses the segmentation of systems and system components." This directly supports using segmentation and access controls (like ACLs) to secure internal resources.

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

Secure Virtual Network Configuration for Virtual Machine (VM) Protection.

Section 4.2

Network Segmentation: "Network segmentation is the separation of a network into smaller

isolated networks... Segmentation can be used to isolate VMs from one another and from other resources

which can help to contain the impact of a security breach." This highlights segmentation as a primary security solution in cloud/virtual environments.

3. Purdue University

"Information Security Policy (VII.B.2)"

Network Segmentation and Segregation.

Section 1

Standard: "Network segmentation and segregation will be used to control access to Sensitive and Restricted Data... Access Control Lists (ACLs) or other appropriate controls will be used to enforce the separation of network segments." This university policy document demonstrates the direct link between segmentation and ACLs as the standard solution for protecting sensitive data.

The Common Vulnerabilities and Exposures (CVE) list is a public repository managed by the MITRE Corporation with funding from the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Its specific mission is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. Each vulnerability is assigned a unique CVE ID. A vulnerability analyst tasked with documenting the newest and most critical vulnerabilities would use the CVE database as the authoritative source for this information, as it is the industry standard for cataloging such issues.

A. Cyber Threat Intelligence: This is a broad field of study and a product of analysis, not a specific repository for cataloging vulnerabilities.

C. Cyber Analytics Repository: The MITRE Cyber Analytics Repository (CAR) is a knowledge base of detection methods (analytics), not a list of vulnerabilities.

D. ATT&CK: The MITRE ATT&CK framework is a knowledge base of adversary tactics, techniques, and procedures (TTPs), describing how attackers operate, not the specific vulnerabilities they exploit.

1. The MITRE Corporation. (2023). About the CVE Program. CVE. Retrieved from https://www.cve.org/About/Overview.

Reference Point: The "What is CVE?" section states

"The mission of the CVE® Program is to identify

define

and catalog publicly disclosed cybersecurity vulnerabilities." This directly supports CVE as the correct repository for the analyst's task.

2. The MITRE Corporation. (2023). MITRE ATT&CK®. Retrieved from https://attack.mitre.org/

Reference Point: The main page describes ATT&CK as "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations." This distinguishes its purpose from that of a vulnerability catalog.

3. The MITRE Corporation. (2023). Cyber Analytics Repository. Retrieved from https://car.mitre.org/

Reference Point: The "Overview" section states

"The Cyber Analytics Repository (CAR) is a knowledge base of analytics developed by MITRE based on the MITRE ATT&CK® adversary model." This confirms its focus is on detection analytics

not vulnerabilities.

4. Cybersecurity and Infrastructure Security Agency (CISA). (n.d.). Common Vulnerabilities and Exposures (CVE). Retrieved from https://www.cisa.gov/resources-tools/resources/common-vulnerabilities-and-exposures-cve.

Reference Point: The page states

"CVE is a list of entries—each containing an identification number

a description

and at least one public reference—for publicly known cybersecurity vulnerabilities." This government source validates CVE's role as the primary list for this purpose.

The Open Web Application Security Project (OWASP) Zed Attack Proxy (ZAP) is a specialized, open-source tool designed specifically for finding vulnerabilities in web applications. It functions as an intercepting proxy and an automated scanner, making it highly effective for identifying common web-based security flaws. The question explicitly lists SQL injection, path traversal, and cross-site scripting, which are core vulnerabilities that OWASP ZAP is built to detect. Given the context of testing a beta web application, ZAP is the most appropriate and recommended tool for the development team to use for a quick and targeted assessment.

A. Hashcat: This is a password recovery and cracking tool used to discover passwords from their hash values; it does not scan for web application vulnerabilities.

B. OpenVAS: This is a comprehensive network vulnerability scanner that primarily identifies issues at the operating system and service level, not deep application-layer flaws.

D. Nmap: This is a network exploration tool and port scanner used for network discovery and security auditing, not for detailed web application vulnerability analysis.

1. OWASP Foundation. (n.d.). The OWASP Zed Attack Proxy Project. OWASP. Retrieved from https://owasp.org/www-project-zed-attack-proxy/. The official project page states

"It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications." This directly aligns with the scenario.

2. CompTIA. (2022). CompTIA Analyst+ (CS0-003) Exam Objectives. Version 3.0

Section 2.2. The objectives list various vulnerability scanners

implicitly categorizing tools like ZAP as web application scanners

distinct from network scanners like Nmap

which is listed under "Network enumeration."

3. Pound

J.

& Ali

S. (2018). Web Application Security. In Proceedings of the 2018 ACM SIGCSE Technical Symposium on Computer Science Education (p. 1096). Association for Computing Machinery. DOI: https://doi.org/10.1145/3159450.3162258. This academic publication discusses tools for teaching web application security

noting that "OWASP ZAP is a popular open source tool for finding vulnerabilities in web applications" and is used to demonstrate attacks like XSS and SQL injection.