Free CAS-005 Practice Test Questions 2026

A. Incorrectly typed password

Explanation:
If the user is occasionally mistyping their password, this could cause intermittent authentication failures. However, the scenario emphasizes that an analyst is reviewing logs, which suggests a deeper investigation beyond simple user error. Logs typically show authentication attempts, including whether the credentials were incorrect, but repeated password errors would likely be consistent rather than intermittent unless the user is inconsistently mistyping. This option is plausible but less likely in a technical investigation context unless the logs explicitly show "invalid credentials" errors sporadically.

Likelihood:
Moderate, but not the strongest fit without log evidence of repeated incorrect password entries.

B. Time-based access restrictions

Explanation:
Time-based access restrictions limit user access to specific time windows (e.g., business hours only). If the user attempts to authenticate outside these allowed times, access would be denied, and this could appear as intermittent if the user’s attempts vary across allowed and restricted times. Authentication logs would likely show a pattern of denials corresponding to specific times, with error messages like “access denied due to time restrictions.” This is a common enterprise security control and aligns well with intermittent issues, especially if the user is unaware of the policy.

Likelihood:
High, as time-based restrictions are a standard access control mechanism and could explain sporadic denials.

C. Account compromis:

Explanation:
Account compromise implies unauthorized access or changes to the account (e.g., password changed by an attacker, triggering lockouts, or multi-factor authentication (MFA) failures). Intermittent issues could arise if the attacker’s actions (e.g., failed login attempts from different locations) cause temporary lockouts or if MFA prompts are not reaching the user. Logs might show unusual login attempts (e.g., from unrecognized IPs or devices). However, without specific log evidence of suspicious activity, this option is less certain and assumes a more severe issue than the scenario suggests.

Likelihood:
Moderate, but requires log evidence of compromise (e.g., unusual IPs, excessive failed attempts).

D. Invalid user-to-device bindings

Explanation:
User-to-device bindings restrict authentication to specific devices (e.g., via device certificates or MAC address whitelisting). If the user switches devices or uses an unrecognized device, authentication could fail intermittently, depending on the device used. Logs might show errors like “unrecognized device” or “device not authorized.” This is plausible in environments with strict device-based access controls, but it’s less common than time-based restrictions and would require specific log entries to confirm.

Likelihood:
Moderate, but less likely unless the scenario involves multiple devices or strict device policies.

Reasoning Process

Intermittent nature:
The key clue is that authentication fails "sometimes," suggesting a conditional restriction rather than a consistent issue like a permanently incorrect password or fully compromised account.

Log analysis:
The analyst’s review of logs implies the answer lies in a pattern detectable in authentication logs, such as time-based denials, device-specific issues, or compromise indicators.

Enterprise context:
CASP+ focuses on advanced security controls in enterprise environments, where time-based access restrictions (option B) and device bindings (option D) are common. ime-based restrictions are more frequently implemented and easier to verify in logs via timestamps and policy-related error codes.

Elimination:
A: Incorrect passwords are user-driven and less likely to be intermittent unless the user is inconsistent, which logs would confirm but isn’t strongly implied.

C: Account compromise is a serious issue but requires evidence like unusual login patterns, which isn’t mentioned.

D:Invalid device bindings are plausible but less common than time-based restrictions and would depend on device-specific log errors.

B: Time-based restrictions align best with intermittent failures, as they depend on when the user attempts to log in, and logs would show a clear pattern of denials outside allowed times.

Correct Answer

B. Time-based access restrictions

Explanation
The most likely reason for the user’s intermittent authentication failures is time-based access restrictions. In enterprise environments, access control policies often restrict logins to specific time windows (e.g., 9 AM–5 PM). If the user attempts to authenticate outside these hours, the system denies access, resulting in intermittent failures. Authentication logs would show denials with error messages tied to time-based policies, which an analyst could easily identify. This aligns with CASP+ objectives around identity and access management (IAM) and is a common cause of such issues in secure environments.

References
CompTIA CASP+ Study Guide (CAS-005): Covers identity and access management, including time-based access controls as part of role-based and attribute-based access control (ABAC) policies.

NIST SP 800-53 (Security and Privacy Controls): Discusses access control policies (AC-3), including time-based restrictions as a mechanism to enforce least privilege.

General Knowledge: Authentication logs in systems like Active Directory or IAM platforms (e.g., Okta, Azure AD) often include error codes for time-based denials, such as “access denied due to policy” or “outside permitted hours.”

Explanation:
The scenario describes a likely MFA fatigue attack (also called push bombing or prompt spamming). In this attack, an attacker who has obtained a user's password repeatedly sends MFA push notifications to the user's device in the hope that the user will eventually accidentally approve one or get frustrated and approve it to stop the notifications.

FIDO2/WebAuthn:
FIDO2 security keys (e.g., YubiKey, Google Titan) use public key cryptography to perform authentication. The user must physically possess the key and perform an action (e.g., touch a sensor) to complete login.

Why it's the Best Solution:
FIDO2 is fundamentally resistant to MFA fatigue attacks. An attacker cannot spam push notifications to a FIDO2 key. The authentication process only begins after the user has inserted their key and entered their PIN. It requires explicit, physical user interaction on the local device for every login attempt, making remote bombing impossible. This completely eliminates the nuisance and the security risk described.

Analysis of Incorrect Options:

B. Deploying a text message based on MFA (SMS):
This is a terrible solution. SMS-based MFA is considered insecure due to its vulnerability to SIM swapping attacks and interception. Switching from push notifications to SMS does not stop the attack; the user would instead be spammed with text messages at night. It exchanges one type of spam for another while potentially lowering security.

C. Enabling OTP via email:
This is also a poor choice. If an attacker is spamming login attempts, the user would be spammed with emails containing one-time passwords. Furthermore, if the user's email account is compromised, the attacker could intercept these OTPs. This method is not considered secure for high-value accounts.

D. Configuring prompt-driven MFA:
This is the problem, not the solution. "Prompt-driven MFA" is exactly what is being abused in the attack—a prompt (push notification) is sent to the user's device for approval. Reconfiguring settings within the same system (e.g., changing the number of prompts) might slightly inconvenience the attacker but does not address the fundamental vulnerability of the method.

Reference:

This scenario addresses Domain 3.5:
Identity and Access Management of the CAS-005 exam, focusing on implementing strong authentication mechanisms. Key concepts include:

Understanding MFA Strengths and Weaknesses:
Knowing that push notifications are susceptible to social engineering and fatigue attacks.

Implementing Phishing-Resistant MFA:
FIDO2 is currently the gold standard for phishing-resistant MFA, as defined by frameworks from CISA and NIST. It is explicitly recommended to mitigate these exact types of attacks.

The best way to restrict the notifications is to eliminate the attack vector entirely by replacing the vulnerable method (push notifications) with a phishing-resistant and fatigue-proof method (FIDO2).

A. Spear-phishing campaign

Explanation:
Spear-phishing is a targeted form of phishing where an attacker tailors messages to specific individuals or groups, often impersonating a trusted entity (e.g., a recruiter) to trick victims into revealing sensitive information or performing actions. If multiple employees received similar messages from the same individual impersonating a recruiter, this indicates a coordinated, targeted attack. Correlating these incidents in reports would point to a spear-phishing campaign, as the pattern shows deliberate targeting of specific employees with a common pretext.

Likelihood:
High, as the scenario describes a single impersonator targeting multiple employees, which aligns with the definition of a spear-phishing campaign.

B. Threat modeling

Explanation:
Threat modeling is a proactive process used to identify, assess, and prioritize potential threats to a system or organization, often during system design or risk assessment. It involves creating models of threats (e.g., STRIDE or MITRE ATT&CK) to understand attack vectors. While useful for preparing against phishing, threat modeling is not a correlation activity and doesn’t describe the act of identifying a pattern in reports about employee contacts.

Likelihood:
Low, as threat modeling is a planning activity, not a reactive analysis of incidents.

C. Red team assessmen:

Explanation:
A red team assessment involves authorized security professionals simulating attacks to test an organization’s defenses. While a red team might simulate phishing, the scenario describes an external individual (implying a real attacker) and a security officer analyzing reports, not a controlled test. Correlating incidents in reports doesn’t align with a red team’s activities, which focus on attack simulation rather than log analysis.

Likelihood:
Low, as the scenario suggests a real attack, not a simulated one.

D. Attack pattern analysis

Explanation:
Attack pattern analysis involves identifying and categorizing patterns in attack methods, often using frameworks like MITRE ATT&CK to understand tactics, techniques, and procedures (TTPs). While the security officer’s correlation of incidents could contribute to attack pattern analysis, the specific scenario of multiple employees being targeted by an impersonator points more directly to a spear-phishing campaign. Attack pattern analysis is broader and might occur after identifying the campaign to study its TTPs, but it’s not the best description of the initial correlation.

Likelihood:
Moderate, as it’s related to correlation but less specific than spear-phishing.

Reasoning Process

Key clues:
The scenario highlights “several employees” contacted by the “same individual” impersonating a recruiter, with the correlation found in reports. This suggests a targeted, coordinated effort by an attacker, which aligns with spear-phishing.

Correlation focus:
The act of correlation involves recognizing that multiple incidents (contacts) share a common actor and method (impersonation of a recruiter), pointing to a specific attack type.

CASP+ context:
The CAS-005 exam emphasizes threat detection, incident response, and social engineering attacks. Spear-phishing (option A) is a specific type of social engineering attack, while attack pattern analysis (option D) is a broader analytical process. The scenario’s specificity about impersonation and targeting makes spear-phishing the best fit.

Elimination:
B: Threat modeling is proactive and not about correlating incidents in reports.

C: Red team assessments are simulated, not real attacks, and don’t involve report correlation.

D: Attack pattern analysis is too broad and less specific than identifying a spear-phishing campaign.

A: Spear-phishing directly describes the attack type indicated by the correlated incidents.

Correct Answer

A. Spear-phishing campaign

Explanation:
The correlation described in the scenario best aligns with identifying a spear-phishing campaign. Spear-phishing involves targeted attacks where an individual (here, impersonating a recruiter) sends tailored messages to specific victims (employees) to deceive them. The security officer’s discovery that multiple employees were contacted by the same impersonator, as found in reports, indicates a pattern consistent with a spear-phishing campaign. This type of correlation involves recognizing the common attacker and method across incidents, a key skill in security operations and incident response.

References:
CompTIA CASP+ Study Guide (CAS-005): Covers social engineering attacks, including spear-phishing, as part of threat identification and incident response (Domain 2: Security Operations).

NIST SP 800-61 (Incident Handling Guide): Discusses correlation of incident data to identify attack patterns, such as phishing campaigns, in the detection and analysis phase.

MITRE ATT&CK Framework:Lists spear-phishing (T1566) as a technique under Initial Access, describing targeted emails or messages impersonating trusted entities.

Explanation:
The core problem is a dynamic environment where the inventory of assets (devices/IPs) is constantly changing. This leads to vulnerability scans that are out of date the moment they are finished, missing new assets and wasting time scanning decommissioned ones.

Discovery Scanning:
Modern vulnerability management tools include a discovery scan function. This is a lightweight scan that rapidly identifies live hosts on a network, their IP addresses, and basic information (like OS type). It does not perform deep vulnerability checks.

Improving the Process:
By performing frequent, automated discovery scans (e.g., daily), the vulnerability management system can maintain an accurate and current asset inventory. This updated inventory then serves as the target list for the more intensive, in-depth vulnerability assessment scans. This ensures that the vulnerability reports are consistent and reflect the actual, current state of the network, as they are based on the most recent asset data.

Analysis of Incorrect Options:

A. Request a weekly report with all new assets deployed and decommissioned.
This is a manual, administrative process that is prone to error and delay. It relies on humans to remember to report changes and for the security team to manually update the scanner. In a fast-paced environment where changes happen "regularly," a weekly report is too infrequent and will not keep the scanner's target list current. Automation is always superior to manual processes for this task.

B. Extend the DHCP lease time to allow the devices to remain with the same address for a longer period.
This might slightly reduce IP churn for some devices but is not a solution to the vulnerability management problem. Many critical assets (servers, network devices) use static IPs, and this does nothing for devices that are physically added or removed from the network. The problem is asset inventory management, not just IP stability. A vulnerability scanner must find all assets, regardless of how they get their IP.

C. Implement a shadow IT detection process to avoid rogue devices on the network.
While detecting unauthorized devices is an important security practice, it is not the direct solution to this problem. The issue is the scanner's lack of awareness of authorized devices that are being added and dropped regularly. The goal is to have a complete picture of all assets, not just to find rogue ones. A shadow IT process might use similar discovery techniques, but option D is the more direct and comprehensive answer.

Reference:
This solution is a best practice in Domain 4.4: Vulnerability Management of the CAS-005 exam. The process is often described as:

Discover:
Identify all assets across the network.

Prioritize:
Classify assets based on criticality.

Assess:
Scan prioritized assets for vulnerabilities.

Report:
Define and communicate vulnerabilities.

Remediate:
Fix vulnerabilities.

Verify:
Confirm that vulnerabilities are resolved.

The problem occurs at the very first step (Discover). Without an automated and frequent discovery process, the entire vulnerability management program is built on an inaccurate foundation. Therefore, performing regular discovery scanning is the most direct and effective way to improve the process.

Explanation:
This scenario involves providing access from a less secure network (the business/enterprise network) to a highly sensitive network (the SCADA/Operational Technology (OT) environment). The core security principle here is to provide access without compromising the security integrity of the SCADA network.

Screened Subnet (Demilitarized Zone - DMZ):
This is a classic and recommended architecture for this purpose. A screened subnet is a perimeter network segmented off from both the internal IT network and the critical SCADA network.

How it Works:
The historian server, or a replica of it, would be placed in this DMZ. The SCADA network can push data to the server in the DMZ through a firewall with restrictive rules. The business users can then pull the metrics they need from the server in the DMZ. This creates a "buffer zone."

Security Benefit:
This architecture prevents a direct network path from the enterprise network to the SCADA network. If the historian server in the DMZ is compromised, the attacker still cannot directly access the critical control systems, as the firewall between the DMZ and the SCADA network will block unauthorized traffic.

Analysis of Incorrect Options:

A. Isolating the historian server for connections only from the SCADA environment.
This is the default, most secure posture for a SCADA system. However, it directly contradicts the business requirement which is to provide access to business users who are not on the SCADA network. This action would deny the required access.

B. Publishing the C$ share from SCADA to the enterprise.
This is an extremely dangerous and insecure action. The C$ share is a default administrative share for the entire C: drive. Publishing this from a critical SCADA system to the enterprise network would provide widespread, privileged access to the most sensitive systems, making them incredibly vulnerable to attack, data theft, and ransomware. It completely violates the principle of least privilege.

D. Adding the business workstations to the SCADA domain.
This deeply integrates the business workstations into the most sensitive security domain. It creates a direct trust path from the enterprise network to the SCADA domain, significantly increasing the attack surface. If a business workstation is compromised (a common event), the attacker could easily move laterally into the SCADA domain and disrupt critical operations.

Reference:
This solution is a foundational principle in Domain 3.0: Security Architecture of the CAS-005 exam, specifically:

Secure Network Architecture:
Designing segmented networks (e.g., using the Purdue Model for ICS security) is essential for protecting critical environments like SCADA/ICS.

The Purdue Model:
This model explicitly defines a "Demilitarized Zone (DMZ)" level (Level 3.5) for precisely this purpose—to host historians and other data brokers that facilitate communication between the Industrial Control System (ICS) levels (Levels 0-3) and the Enterprise IT levels (Levels 4-5).

Using a screened subnet (DMZ) is the industry-standard way to securely facilitate data flow from an OT environment to business users without jeopardizing the safety and reliability of the industrial control processes.

Explanation:
The question specifies the goal is to secure remote access connections to Linux systems. The primary method for remote administrative access to Linux systems is SSH (Secure Shell).

Cipher-Block Chaining (CBC):
CBC is an older mode of operation for block ciphers. Vulnerabilities (e.g., the Lucky Thirteen attack) have made CBC-based ciphers in SSH weak and undesirable for secure communications.

SSH Server Configuration:
The configuration file for the SSH daemon (the service that accepts incoming SSH connections) is typically located at /etc/ssh/sshd_config.

Modifying Ciphers:
This file contains a directive called Ciphers. To disable weak CBC ciphers, the security engineer would edit this file and specify a list of strong, modern ciphers (e.g., AES in GCM or CTR mode, ChaCha20-Poly1305), explicitly omitting any ciphers that use CBC mode (e.g., aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc).

Analysis of Incorrect Options:

A. The /etc/openssl.conf file, updating the virtual site parameter:
The openssl.conf file is used to configure the OpenSSL library, which provides cryptographic functions for many applications. It is not the primary configuration file for the SSH service. While OpenSSL is used by SSH, the specific configuration for SSH's ciphers is handled within its own sshd_config file.

B. The /etc/nsswitch.conf file, updating the name server:
The nsswitch.conf (Name Service Switch configuration) file controls how the system resolves sources for different databases, such as passwords (passwd) and hostnames (hosts). It has nothing to do with configuring encryption algorithms or remote access protocols.

C. The /etc/hosts file, updating the IP parameter:
The hosts file is a static table for mapping hostnames to IP addresses. It is a simple form of local name resolution and is completely unrelated to the encryption protocols used for network connections.

Reference:
This task falls under Domain 3.0: Security Engineering of the CAS-005 exam, specifically:

Cryptography (3.6): Implementing cryptographic protocols and understanding weak ciphers.

Secure Network Protocols (3.4): Securing administration channels like SSH by hardening their configuration.

The action of disabling weak CBC ciphers in SSH is a standard system hardening step found in benchmarks from the CIS (Center for Internet Security) and other security guides. The correct file to modify to control SSH server behavior is unequivocally /etc/ssh/sshd_config.

Explanation:
The scenario involves a legacy system (COBOL) that is critical but likely has known, unpatched vulnerabilities due to its age and lack of modern support. The goal is to keep it running securely until it can be replaced. The most effective security strategy for protecting such a system is network segmentation to minimize its attack surface.

Isolation and Firewall Rules:
This approach follows the principle of least privilege at the network level. By placing the system in an isolated network segment and configuring firewall rules to only permit traffic from specific, authorized endpoints (e.g., other systems it must communicate with), you drastically reduce the ways an attacker can reach it.

Reducing Attack Vectors:
Even if the COBOL system has vulnerabilities, they cannot be exploited if malicious traffic is never allowed to reach it. This control is external and does not rely on the legacy system's inherent security capabilities, which are assumed to be weak.

Analysis of Incorrect Options:

B. Enforcing strong credentials and improving monitoring:
While important, this is insufficient for a legacy system. If the system itself has vulnerabilities, an attacker might bypass authentication entirely (e.g., through a remote code execution flaw). Monitoring can only detect attacks after they have been attempted or have succeeded; it does not prevent them. This approach relies on the system's internal security, which is the weakest link.

C. Restricting system access to perform necessary maintenance by the IT team:
This applies the principle of least privilege to user access, which is good. However, it does nothing to protect the system from network-based attacks. An attacker exploiting a vulnerability would not need valid user credentials. This measure protects against unauthorized use but not against exploitation of software flaws.

D. Placing the system in a screened subnet and blocking access from internal resources:
A screened subnet (DMZ) is traditionally used to host services accessible from the internet. This is the opposite of what is needed for an internal legacy system. Blocking access from internal resources might break its functionality, as it likely needs to communicate with other internal systems (databases, clients). This would harm operational requirements without necessarily improving security in the right way.

Reference:
This strategy is a core component of Domain 3.0: Security Engineering in the CAS-005 exam, focusing on:

Secure Network Segmentation: Isolating critical or vulnerable assets to protect them from broader network threats.

Zero Trust Concepts: The principle of "never trust, always verify" applies here—the system is not trusted, so its communication is restricted to only explicitly allowed pathways.

For a legacy system that cannot be patched, compensating controls like strict network segmentation and firewall rules are the most effective and secure way to mitigate risk while maintaining operations. Option A provides this isolation while still allowing necessary business communication.

Explanation:
The root cause of the failed patch deployments is identified: system owners are making ad hoc (unplanned, unauthorized, and unrecorded) modifications to systems and applications. These unexpected changes create an environment that the patch deployment process is not expecting, leading to conflicts and failures.

Change Management:
This is a formal process designed to prevent exactly this problem. It ensures that all changes to the IT environment are:

Requested:
Proposed in a standardized way.

Reviewed:
Evaluated for potential impact, risk, and compatibility with other systems.

Approved:
Formally authorized before implementation.

Documented:
Recorded in a change log.

Tested:
Verified to work correctly in a test environment.

How it Reduces Failures:
By implementing a change management process, the systems administrator ensures that the state of every system is known and controlled. The patch deployment team will be aware of all modifications that have been made and can plan their patches accordingly, drastically reducing unexpected conflicts.

Analysis of Incorrect Options:

A. Compliance tracking:
This involves monitoring systems to ensure they adhere to security policies and standards (e.g., checking if patches are installed). While it can identify that a system is non-compliant (e.g., a patch failed), it does not address the process issue that caused the failure—the ad hoc changes. It is a reactive measure, not a proactive fix for the root cause.

B. Situational awareness:
This refers to having knowledge and understanding of the current state of the IT environment and potential threats. While good situational awareness might help the administrator discover the ad hoc changes, it is not a process or control that will prevent them from happening in the first place. Change management is the process that creates and enforces situational awareness.

D. Quality assurance (QA):
QA is a process focused on verifying that a product or change meets specified requirements and is free of defects. It is typically applied to testing software before it is released or testing a patch before it is deployed. QA would not prevent a system owner from making an unauthorized change to a production system; that is the function of change control, which is a part of the larger change management process.

Reference:
This solution falls under Domain 1.0: Governance, Risk, and Compliance and Domain 4.0: Security Operations of the CAS-005 exam. Key concepts include: Change Management (4.4): Implementing and managing the change control process is a fundamental part of security operations and IT service management (e.g., ITIL frameworks).

Governance: Establishing formal processes to manage IT operations and reduce risk.

The best way to reduce failures caused by uncontrolled modifications is to implement the formal process designed to control those modifications: Change Management.

Explanation:
A central bank is a high-value target for nation-states and sophisticated threat actors. The specific mitigation mentioned—an allow list for specific countries of origin—is a geopolitical control aimed at minimizing risk from hostile or untrusted nations.

Physical Implants and Tampering:
The primary cyberthreat this control addresses is the risk of hardware sabotage. A nation-state actor could compromise hardware at the point of manufacture by: Installing malicious hardware implants (e.g., microchips) that create backdoors.

Tampering with firmware to introduce vulnerabilities.

Modifying devices to leak encryption keys or sensitive data.

Why Country of Origin Matters:
Hardware sourced from a country with a hostile intelligence agency or a history of state-sponsored hacking presents a much higher risk of such tampering. By creating an allow list of trusted countries, the bank is attempting to mitigate this threat by sourcing hardware from nations with which it has stronger diplomatic ties and greater trust in their manufacturing integrity.

Analysis of Incorrect Options:

A. Ability to obtain components during wartime:
This describes a supply chain disruption risk. While a valid concern, it is a logistical and availability issue, not primarily a cyberthreat. The mitigation (allow listing countries) is not about ensuring supply during conflict but about ensuring the integrity and trustworthiness of the components themselves.

B. Fragility and other availability attacks:
This refers to hardware that is intentionally designed to be fragile or to fail under certain conditions, causing a denial of service. While a potential threat, it is not the most classic or high-impact threat associated with nation-state level hardware supply chain attacks against a critical financial institution. The focus is more on stealthy implants for espionage and persistence rather than obvious destruction.

D. Non-conformance to accepted manufacturing standards:
This is a quality control issue. Hardware that doesn't meet standards might fail prematurely or perform poorly, but it is not typically the result of a malicious cyber threat. It is often due to cost-cutting, errors, or poor oversight. The bank's mitigation is focused on intentional, malicious action by a geopolitical adversary, not accidental non-conformance.

Reference:
This threat is a key concern in Domain 1.0: Governance, Risk, and Compliance and Domain 3.0: Security Engineering of the CAS-005 exam. It specifically relates to:

Supply Chain Risk Management (SCRM): Understanding and mitigating risks associated with purchasing technology from third-party vendors and specific geographic regions.

Hardware Security: Protecting against threats that target the physical integrity of computing hardware.

This scenario is inspired by real-world concerns, such as those reported in investigations into hardware manufactured by certain companies (e.g., Huawei, ZTE) where foreign governments have raised concerns about potential for state-mandated backdoors. The allow list is a direct mitigation for the threat of physical implants and tampering.

Explanation:
The requirement is to prevent application-focused attacks. These are attacks that target vulnerabilities within the web application itself, such as: SQL Injection (SQLi)

Cross-Site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Remote Code Execution

Web Application Firewall (WAF):
A WAF is a security control specifically designed to protect web applications by filtering, monitoring, and blocking malicious HTTP/S traffic. It operates at Layer 7 (the application layer) of the OSI model.

Policies for Programming Languages:
Modern WAFs can be tuned with policies that understand the specific context of different programming languages (e.g., Java, .NET, PHP, Python) and frameworks. This allows them to more accurately detect and block attacks that are attempting to exploit common vulnerabilities in those technologies. This control most directly addresses the goal of preventing attacks aimed at the application's logic and code.

Analysis of Incorrect Options:

A. Improving security dashboard visualization on SIEM:
A SIEM (Security Information and Event Manager) is a detective and reporting tool. It aggregates logs and provides alerts after a potential security event has occurred. While crucial for awareness and investigation, it does not prevent an attack from reaching and compromising the application. It helps you see what happened, but it doesn't stop it from happening.

B. Rotating API access and authorization keys every two months:
Key rotation is a important security practice for limiting the blast radius of a key compromise. If a key is stolen, rotating it revokes the attacker's access. However, this is an access control measure. It does not prevent the initial application-focused attack (like an injection flaw) that might be used to steal those keys in the first place. It is a response to a breach, not a prevention of the attack vector.

C. Implementing application load balancing and cross-region availability:
This is an availability and performance solution. Load balancers distribute traffic to ensure no single server is overwhelmed, and cross-region availability protects against outages in a single geographic location. These are excellent for ensuring uptime and resilience but provide no inherent security against application-layer attacks like SQL injection or XSS. They are not security controls.

Reference:
This solution falls under Domain 3.0: Security Engineering of the CAS-005 exam, specifically:

3.4: Implement secure network architecture concepts. This includes deploying perimeter security controls like WAFs to protect web applications.

3.2: Implement security design principles. The WAF acts as a specialized control to protect the application, following the principle of defense-in-depth.

A WAF is the industry-standard, first-line defense for mitigating the OWASP Top 10 web application security risks. Creating tailored policies for the specific programming languages in use is the most direct and effective way to prevent application-focused attacks.

Explanation:
The scenario describes a new application triggering anti-malware alerts on multiple customer test workstations. The key detail is that the application is built from an internal code repository.

Bundled Libraries:
Modern software development heavily relies on third-party open-source libraries and dependencies to add functionality without writing code from scratch. These libraries are often "bundled" into the final application package.

The Cause:
If these third-party libraries contain known vulnerabilities or, more critically, if they have been compromised (e.g., through a software supply chain attack where a malicious version is published to a public repository), anti-malware software and endpoint protection platforms will detect them as malicious. The company's internal developers might have unknowingly integrated a vulnerable or malicious library into their codebase, which is now being flagged upon execution on the customers' systems.

This is a very common issue in software development and a primary focus of Software Composition Analysis (SCA) tools.

Analysis of Incorrect Options:

A. Misconfigured code commit:
A misconfigured code commit typically relates to issues within a version control system (e.g., accidentally committing passwords or API keys). While a serious security concern, it would not typically cause the compiled application binary to be flagged as malware by anti-virus software on an end-user's machine. It's a data exposure problem, not a malware execution problem.

C. Invalid code signing certificate:
An invalid or expired code signing certificate might cause the operating system to display a warning that the publisher could not be verified (e.g., "Unknown Publisher"). However, standard anti-malware software does not typically trigger alerts solely based on a missing or invalid signature. It triggers based on the behavior or signatures of malicious code. An invalid certificate is a trust issue, not a direct malware detection.

D. Data leakage:
Data leakage refers to the unauthorized transmission of sensitive data from within the company to an external destination. This is a completely different problem. The issue described is that the application itself is being flagged as malicious upon execution, not that it is secretly sending out data. Data leakage might be a result of the malware, but it is not the cause of the anti-malware alerts.

Reference:
This scenario is a classic example of a software supply chain attack and falls under Domain 1.0: Governance, Risk, and Compliance and Domain 4.0: Security Operations of the CAS-005 exam. Key concepts include:

Software Composition Analysis (SCA): The process of managing and securing open-source dependencies to prevent the use of vulnerable or malicious libraries.

Supply Chain Security: Understanding how threats can be introduced into software through third-party components.

The most likely cause is that the application contains compromised or known-malicious open-source libraries (unsecure bundled libraries) that are being detected by the customers' endpoint protection software.

Explanation:
The question specifies that the SSDs are encrypted. This is a crucial detail. Modern SSDs often use hardware-based encryption (e.g., Opal, SED - Self-Encrypting Drive) where all data written to the drive is encrypted in real-time by a dedicated controller using a unique, internal encryption key.

How it Works:
The user's password (or key) does not decrypt the data itself; it decrypts and provides access to this internal media encryption key. The data on the physical NAND chips is always ciphertext.

Secure Erasure:
The most efficient and secure way to render all data on an encrypted SSD irrecoverable is to cryptographically erase it. This is done by instructing the drive's controller to delete the internal media encryption key. Once this key is destroyed, all data on the drive becomes permanently and instantly unreadable, as there is no way to decrypt it. The process takes milliseconds and is 100% effective.

NIST Standard:
This method, known as Crypto Erase or Sanitize, is recommended by NIST SP 800-88 (Guidelines for Media Sanitization) for sanitizing encrypted storage devices.

Analysis of Incorrect Options:

A. Executing a script that deletes and overwrites all data on the SSD three times.
This is a traditional method for magnetic hard drives (HDDs) known as the DoD wipe. However, due to wear leveling and over-provisioning on SSDs, the operating system and scripts cannot directly address all physical memory cells. The SSD controller may remap writes, meaning the script cannot guarantee that every single physical block has been overwritten. Some original data may remain in retired or reserved blocks and could be recovered with specialized tools.

B. Wiping the SSD through degaussing.
Degaussing uses a powerful magnetic field to erase data on magnetic media like traditional HDDs or tapes. SSDs use flash memory (NAND cells), which is not magnetic. Degaussing has no effect on SSDs and will not erase any data.

D. Writing non-zero, random data to all cells of the SSD.
Similar to option A, this is ineffective on SSDs due to their architecture. The user/OS cannot directly access "all cells" because the flash translation layer (FTL) and wear-leveling algorithms abstract the physical layout. The drive's controller will not allow a full overwrite of every physical block, including spare and over-provisioned areas, through standard write commands.

Reference:
This process is defined in Domain 3.6: Cryptography and Domain 4.4: Security Operations of the CAS-005 exam. It relates to:

Media Sanitization: Understanding the proper methods for sanitizing different types of storage media as per NIST SP 800-88.

Cryptographic Erasure: Leveraging the built-in encryption capabilities of modern storage devices for instant and secure data destruction.

For encrypted SSDs, the most secure, fast, and reliable method is C. Securely deleting the encryption keys used by the SSD. This cryptographic erase is the industry best practice.