Free CAS-005 Practice Test Questions 2026

Explanation:
The requirements are centered around collecting and analyzing endpoint data for centralized security monitoring.

CDR (Cloud Detection and Response) / EDR (Endpoint Detection and Response):
While the acronym "CDR" is less common and might be a distractor, in this context, it is likely intended to represent EDR (Endpoint Detection and Response). An EDR/XDR agent is a small software program installed on endpoints (laptops, servers) that continuously collects data (telemetry) on system activities, process execution, network connections, and more. This directly fulfills the first two requirements:

It establishes rich telemetry with a SIEM by sending security events.

It is the fundamental component that allows endpoints to be integrated into an XDR platform. XDR (Extended Detection and Response) often builds upon EDR data, correlating it with data from other sources (network, cloud).

Central Logging:
This is the practice of aggregating logs from all systems (including endpoints via their EDR/EDR agents) into a central repository, such as a SIEM. This is a prerequisite for the third requirement: it allows the SOC to monitor the XDR platform and the entire environment from a single pane of glass. The SIEM is the central tool the SOC uses to monitor alerts and data from the XDR platform and other sources.

Analysis of Incorrect Options:

B. HIDS and vTPM:
HIDS (Host-Based Intrusion Detection System):
A HIDS monitors a single host for malicious activity. While it can send alerts, it provides much narrower and less rich telemetry than a modern EDR agent. It is not the primary technology for XDR integration.

vTPM (Virtual Trusted Platform Module):
A vTPM provides hardware-based security for virtual machines (e.g., for measured boot or disk encryption). It is unrelated to generating the kind of behavioral telemetry needed for SIEM and XDR.

C. WAF and syslog:

WAF (Web Application Firewall):
A WAF protects web applications from attacks. It is a network security control, not an endpoint technology. It does not help endpoints establish telemetry.

Syslog:
This is a standard for message logging. While endpoints can use syslog to send logs, it is a protocol, not a solution. The richness of the data sent via syslog depends on the agent installed. EDR is a specific type of agent that uses protocols like syslog to send its rich telemetry to a SIEM. This option is incomplete without specifying the agent (like EDR) that generates the logs.

D. HIPS and host-based firewall:

HIPS (Host-Based Intrusion Prevention System):
A HIPS is designed to block malicious activity on a host. It is a prevention control, not primarily a telemetry generation tool. Its logging capabilities are typically limited to its own block events.

Host-Based Firewall:
This controls network traffic to and from a single host. Like a HIPS, its primary function is prevention, and its logging is limited to network allow/deny decisions. Neither HIPS nor a host-based firewall provides the deep, behavioral telemetry (process trees, file modifications, etc.) that EDR does, which is required for modern SIEM and XDR integration.

Reference:
This solution aligns with Domain 4.0: Security Operations of the CAS-005 exam, specifically:

4.3: Automation of Security Operations: Implementing tools like EDR and central logging (SIEM) to automate monitoring and response.

4.4: Incident Management: Using XDR and SIEM platforms to improve detection and response capabilities.

The combination of EDR (often called CDR in some contexts) agents on endpoints to collect data and central logging to aggregate and analyze it is the foundational architecture for meeting all three stated requirements.

Explanation:
The goal is to quickly evaluate vulnerabilities across all container images with minimal effort. This requires a centralized, easily queryable inventory of all software components.

SBoM (Software Bill of Materials):
An SBoM is a nested inventory, a list of ingredients that make up software components. For containers, it is a formal, machine-readable record that details all the open-source and third-party packages, libraries, and their versions contained within a container image.

How it Achieves the Objective with Least Effort:

Identification:
When a new vulnerability (e.g., CVE-2023-XXXX) is publicly disclosed, the security team can simply query the centralized SBoM database.

Evaluation:
The query instantly reveals every container image in the private repository that contains the vulnerable component. This allows the team to immediately understand the scope and impact, answering: "Do we use this? Where? How critically?"

Prioritization & Response:
With this precise information, the team can instantly prioritize a response based on which images are in production, their criticality, and whether an exploit exists. This eliminates the need to manually scan each image after every new CVE is published.

This is a proactive, automated approach that provides immediate answers, representing the "least effort" for ongoing evaluation.

Analysis of Incorrect Options:

A. SAST scan reports:
Static Application Security Testing (SAST) analyzes an application's source code for flaws (e.g., logic errors, code vulnerabilities). It is not designed to identify vulnerabilities in third-party libraries and packages within a built container image. That is the job of SCA (Software Composition Analysis) or, more broadly, an SBoM.

C. CIS benchmark compliance reports:
CIS benchmarks provide configuration baselines for securing systems (e.g., how to lock down a Docker daemon or a Linux OS). A compliance report would show how well a container's configuration aligns with these best practices. It does not provide a list of vulnerable software packages inside the container, which is the requirement here.

D. Credentialed vulnerability scan:
A credentialed vulnerability scan (often done by tools like Trivy, Clair, Grype) is absolutely necessary to find the vulnerabilities in the first place. However, the question is about what allows the team to "quickly evaluate whether to respond" after those vulnerabilities are known. Running a new scan on every image for every new CVE is reactive and labor-intensive (high effort). An SBoM provides the same answer instantly without rescanning.

Reference:
This strategy is part of Domain 4.4: Vulnerability Management and Software Supply Chain Security within the CAS-005 exam. Key concepts include:

Proactive Vulnerability Management: Using an SBoM shifts vulnerability management from a reactive scanning model to a proactive, intelligence-driven model.

NIST SP 800-161 (Software Supply Chain Security): Highlights the importance of SBoMs for providing software transparency and enabling rapid response to newly discovered vulnerabilities.

A Centralized SBoM (B) acts as a single source of truth for all software components in use. When a new vulnerability is announced, it is the most efficient tool (least effort) for quickly determining exposure and prioritizing a response.

Explanation:
The key phrase is "operationalize the research output." This means the company doesn't just want to gather theoretical information; it wants to directly use the findings to actively improve its defensive security posture.

Continuous Adversary Emulation:
This is a proactive security practice where a dedicated "red team" or automated tool continuously mimics the Tactics, Techniques, and Procedures (TTPs) of real-world threat actors that are relevant to the organization's industry.

How it Operationalizes Research:

Research Input:
The process begins with research—studying threat reports, MITRE ATT&CK, and intelligence to understand how specific adversaries operate.

Emulation Output:
This research is directly "operationalized" by designing and executing emulation campaigns that test these specific TTPs against the company's own defenses.

Actionable Results:
The output is a direct, empirical assessment of the company's defensive capabilities. It answers: "Can we detect and stop this specific real-world attack?" The findings are used to tune SIEM alerts, improve EDR rules, update firewall policies, and patch security gaps. This closes the loop from research to actionable defensive improvements.

Analysis of Incorrect Options:

A. Dark web monitoring:
This is a reconnaissance and intelligence-gathering activity. It involves scanning underground forums and marketplaces for mentions of the company's data, leaked credentials, or planned attacks. While extremely valuable, its output is raw intelligence. It requires significant analysis and processing to become operational. It is a source of information for research but is not itself an operationalized output.

B. Threat intelligence platform (TIP):
A TIP is a tool for aggregating, correlating, and managing threat intelligence data from various sources (including dark web monitoring, threat feeds, etc.). It is a force multiplier for analysts but is still primarily a data management and analysis tool. It helps organize research but does not automatically operationalize it into defensive actions. The "operationalization" often requires a separate process, like feeding IOCs into a SIEM or guiding adversary emulation.

C. Honeypots:
Honeypots are decoy systems designed to attract and study attacker behavior. They are a fantastic research tool for gathering data on the tools and methods attackers are using in the wild. However, like dark web monitoring, the data they produce is raw. It requires extensive analysis to be useful. Their primary value is in research and early warning, not in the direct, continuous operationalization of that research into defensive controls.

Reference:
This recommendation falls under Domain 4.0: Security Operations of the CAS-005 exam, specifically:

4.4: Incident Management: Using proactive techniques like adversary emulation to improve incident detection and response capabilities.

Threat Informed Defense: This is a modern security strategy where understanding adversary behavior (research) directly informs defensive testing and engineering (operationalization). Continuous adversary emulation is a core practice of this strategy.

While all the options involve research, Continuous adversary emulation (D) is the only one that is inherently designed to directly translate research findings into actionable security improvements by actively testing and validating defenses against known adversary behaviors.

Explanation:
The core challenge is creating vendor-agnostic detection logic (use cases) that can be deployed across a heterogeneous environment with different security tools (SIEMs, EDRs, etc.) from various vendors.

Sigma Rules:
Sigma is a generic, open-source signature format for describing log events and detection rules in a vendor-neutral way.

How it Achieves the Goal:

Create Use Cases:
A security analyst writes a detection rule once using the Sigma format. This rule describes the logic for detecting a specific threat (e.g., "detect a process making a network connection to a known malicious domain").

Centralized Library:
These Sigma rules can be stored in a central repository (e.g., a GitHub repo), creating the desired "centralized library."

Use Across All Companies:
Each acquired company can use a Sigma converter to translate the generic Sigma rule into the native query language of their specific SIEM or security tool (e.g., Splunk SPL, Elasticsearch Query DSL, Microsoft Sentinel KQL, IBM QRadar AQL). This allows the same detection logic to be deployed everywhere, ensuring consistent threat detection despite the different vendors in use.

Analysis of Incorrect Options:

B. Ariel Query Language (AQL):
This is the proprietary query language used specifically by IBM QRadar. It is not vendor-agnostic. Writing use cases in AQL would only work for the subsidiaries that use QRadar and would be useless for companies using Splunk, Elastic, or other platforms. It does not support the goal of a centralized, cross-vendor library.

C. UBA rules and use cases:
User and Entity Behavior Analytics (UBA) rules are typically highly specialized and proprietary to the specific UBA or SIEM platform that generates them (e.g., Exabeam, Splunk UBA). They are not easily portable between different vendors' systems. The output of a UBA system is often an alert or risk score, not a shareable, vendor-neutral detection rule.

D. TAXII/STIX library:
STIX is a language for describing cyber threat intelligence (e.g., threat actors, campaigns, indicators). TAXII is a protocol for sharing that intelligence. While a TAXII/STIX feed can inform detection (e.g., by providing a list of malicious IPs to block), it does not contain the actual detection logic or use cases themselves. A SIEM would still need its own native rules to act on the intelligence from a STIX feed. It is a source of data for detection, not the detection rule format.

Reference:
This solution is a best practice in Domain 4.0: Security Operations of the CAS-005 exam, specifically:

4.3: Automation of Security Operations: Using standardized, automated methods for deploying detection content.

Vendor Agnosticism: Understanding how to achieve security goals in a multi-vendor environment, which is common after mergers and acquisitions.

Sigma rules (A) are specifically designed to solve the exact problem presented: creating a centralized library of detection use cases that can be seamlessly deployed across a diverse set of security monitoring tools.

Explanation:
The artifacts described—binary files that masquerade as legitimate software ("same name") but are actually malicious ("different hashes")—are a classic indicator of a binary spoofing or supply chain attack. The malicious actor is exploiting the software update process to distribute trojanized versions of legitimate programs.

Digital Signature Verification:
This is a cryptographic process that allows a system to verify that a piece of software (a binary file) is genuinely from a trusted publisher and has not been altered since it was signed.

How it Prevents Reoccurrence:
By implementing and enforcing digital signature verification (e.g., through application allow-listing policies like Windows Defender Application Control), the system will block any binary that does not have a valid, trusted signature. Even if the malicious file has the same name as a valid binary, the system will check its digital signature, see that it is invalid or untrusted, and prevent it from executing. This directly stops the attack vector being exploited.

Analysis of Incorrect Options:

A. Improving patching processes:
While important, this is too vague. The problem isn't necessarily that the patching process is slow; it's that the update mechanism itself was compromised to deliver malicious files. A better patching process might not prevent an attacker from hijacking the update channel. Digital signature verification is a more specific and technical control that directly validates the integrity of each file.

C. Performing manual updates via USB ports:
This is a highly insecure and impractical recommendation. It introduces a significant physical security risk (USB-borne malware, loss/theft of drives) and is not scalable for an enterprise. It also does not inherently verify the integrity of the files on the USB drive; they could still be malicious.

D. Allowing only files from internal sources:
This is a good principle (network segmentation/air-gapping for critical systems), but it is often impractical for software that requires updates from the internet. More importantly, it is not foolproof. If an internal source (like a local update server) itself becomes compromised, it would distribute the malicious binaries to all workstations. Digital signature verification provides a stronger guarantee of file integrity, regardless of the source.

Reference:

This defense is a core component of Domain 3.6:
Cryptography and Domain 3.1: Identity and Access Management (specifically application control) in the CAS-005 exam. The principle is:

Code Integrity:
Ensuring that only authorized code from trusted publishers can execute on a system. Digital signatures are the primary mechanism for enforcing code integrity.

The most direct and effective way to prevent the execution of trojanized binaries, regardless of their source or name, is to implement and enforce digital signature verification (B) on all endpoints.

Explanation:
The organization has a policy against BYOD but lacks the technical controls to enforce it. The goal is to technically prevent unauthorized BYOD devices from accessing corporate resources. The solutions must act as gatekeepers.

B. Conditional Access (to enforce user-to-device binding):
Modern Cloud Identity and Access Management (IAM) platforms (like Azure AD) include Conditional Access policies. These policies can require that a device be marked as compliant (e.g., by Intune) or domain-joined before it is allowed to access applications. This effectively enforces "user-to-device binding," ensuring that access is only granted from company-managed and approved devices, thus blocking BYOD devices that do not meet this criteria.

C. NAC (Network Access Control, to enforce device configuration requirements):
NAC solutions act as a network gatekeeper. They can check devices attempting to connect to the corporate network (wired or wireless) for specific attributes:

Is the device a corporate asset? (e.g., does it have a specific certificate installed?)

Does it meet security requirements? (e.g., is the OS patched, is an antivirus running?)

Devices that fail these checks (including unauthorized BYOD devices) can be placed in a quarantine VLAN or denied access entirely, preventing them from reaching any internal resources.

Together, these solutions provide a layered defense: Conditional Access protects cloud applications, and NAC protects the internal network.

Analysis of Incorrect Options:

A. Cloud IAM to enforce the use of token based MFA:
MFA is a critical security control, but it authenticates the user, not the device. A user could simply authenticate from their personal BYOD phone or laptop using a token. This does nothing to enforce the policy against BYOD usage; it just adds a layer of user authentication.

D. PAM (Privileged Access Management, to enforce local password policies):
PAM solutions manage and secure privileged accounts and credentials. They are not designed to control which devices can access the network or resources. Enforcing local password policies on endpoints does not prevent a BYOD device from connecting.

E. SD-WAN (Software-Defined Wide Area Network, to enforce web content filtering through external proxies):
SD-WAN optimizes and manages network traffic between branch offices and data centers. While it can include security features like content filtering, it operates at the network perimeter and is not designed to identify and block specific BYOD devices attempting to access the network. It lacks the device-level visibility and control of NAC.

F. DLP (Data Loss Prevention, to enforce data protection capabilities):
DLP is designed to protect data from being exfiltrated or misused. It is a data-centric control, not a device-centric one. It might prevent data from being copied to a BYOD device after access has been granted, but it does nothing to prevent the BYOD device from accessing the resources in the first place, which is the core requirement.

Reference:
This solution aligns with Domain 3.5: Identity and Access Management and Domain 3.4: Secure Network Architecture of the CAS-005 exam. The key concepts are:

Zero Trust / Device Compliance: Using Conditional Access policies to enforce that only compliant, managed devices can access resources.

Network Enforcement: Using NAC as a technical control to physically block unauthorized devices from connecting to the network.

To technically enforce a no-BYOD policy, the organization must implement controls that explicitly identify and block unauthorized devices. Conditional Access (B) and NAC (C) are the two primary technical controls designed for this exact purpose.

Explanation:
The requirements listed are the core, defining functions of a Mobile Device Management (MDM) system. While the term "mobile" is in the name, modern MDM solutions (often called Unified Endpoint Management or UEM) extend these capabilities to a wide range of "specialized endpoints," including:

Mobile phones and tablets (iOS, Android)

Laptops (Windows, macOS, ChromeOS)

IoT devices

Other specialized endpoints

Let's map the requirements to MDM capabilities:

Centrally manage configurations:
MDM provides a central console to create and manage configuration profiles (e.g., Wi-Fi settings, VPN settings, security baselines).

Push policies:
MDM automatically deploys these configurations and compliance policies to enrolled devices over-the-air.

Remotely wipe devices:
This is a fundamental security feature of any MDM solution, allowing an admin to remotely erase a device if it is lost or stolen.

Maintain asset inventory:
MDM automatically maintains a detailed inventory of all enrolled devices, including hardware specs, OS versions, and installed applications.

Analysis of Incorrect Options:

A. Use a configuration management database (CMDB):
A CMDB is a repository that stores information about IT assets and their relationships. It is used for IT Service Management (ITSM) and provides visibility into what assets exist. However, a CMDB is a passive inventory tool. It cannot actively push configurations, enforce policies, or remotely wipe devices. It is for tracking, not for management.

C. Configure contextual policy management:
This is a feature or capability, not a product or solution. "Contextual policy management" refers to making access decisions based on context (user, device, location). This functionality is often a part of a larger solution like an MDM or Identity and Access Management (IAM) platform. This option does not describe a solution that can perform all the required tasks, especially remote wipe and centralized configuration.

D. Deploy a software asset manager:
Software Asset Management (SAM) tools are focused on managing software licenses, ensuring compliance, and optimizing software spend. They help track software installations but are not designed to manage device configurations, push security policies, or perform remote wipes. Their focus is financial and legal compliance, not endpoint security management.

Reference:
This solution falls under Domain 4.3: Automation of Security Operations and Domain 3.5: Identity and Access Management of the CAS-005 exam. MDM/UEM is the standard tool for automating the management and security of endpoints at scale.

An MDM solution (B) is purpose-built to meet all the listed requirements for managing specialized endpoints effectively and securely.

Explanation:
The core concept of implementing "guardrails" in an AI system is to create boundaries and constraints that prevent the AI from causing harm, making mistakes, or being misused.

Principle of Least Functionality:
This answer embodies a fundamental security principle: only allow the minimum level of access and capability necessary for a system to perform its intended function. By restricting the AI digital worker to only non-sensitive functions, the organization creates a powerful guardrail.

How it Secures the Environment:
This limitation directly mitigates a wide range of risks:

Data Exfiltration/Loss:
Prevents the AI from processing, storing, or transmitting sensitive personal data (PII), intellectual property, or financial information.

Harmful Actions:
Prevents the AI from taking autonomous actions that could have serious consequences (e.g., sending emails, making calendar changes, editing sensitive documents) without human review.

Reputational Risk:
Reduces the chance of the AI generating incorrect or inappropriate content based on sensitive data.

This is a proactive, architectural control that defines the AI's operational boundaries from the outset.

Analysis of Incorrect Options:

B. Enhance the training model's effectiveness.
While improving the model's accuracy and reducing errors is important, it is not a "guardrail." A more effective model might be better at its tasks, but it does not inherently prevent it from operating on sensitive data or performing unauthorized actions. This is about improving core functionality, not implementing security boundaries.

C. Grant the system the ability to self-govern.
This is the opposite of implementing guardrails. "Self-governance" implies giving the AI system autonomy to make its own decisions about what is right or wrong. Without predefined, human-created guardrails, this is extremely dangerous and could lead to unpredictable and uncontrollable outcomes. Guardrails are external controls imposed on the AI system.

D. Require end-user acknowledgement of organizational policies.
This is an administrative control aimed at users, not a technical control for the AI platform itself. While user training and policy acknowledgment are important, they are unreliable as a sole security measure. Users can make mistakes, ignore policies, or find ways to misuse the technology. A technical guardrail built into the system itself is a far more secure and enforceable method.

Reference:
This approach aligns with Domain 2.0: Security Architecture and Domain 1.0: Governance, Risk, and Compliance of the CAS-005 exam. The key principles are:

Secure by Design: Building security into the architecture of a system from the beginning, which includes limiting its capabilities to a well-defined scope.

Risk Mitigation: Proactively identifying and reducing the attack surface and potential for misuse.

The most effective way to secure the AI environment with guardrails is to technically restrict its capabilities (A), ensuring it cannot be used in a way that poses a risk to the organization, even accidentally.

Explanation:
The specific concern is an insider threat where a single employee with individual access to encrypted material could potentially misuse that access (e.g., decrypt and steal sensitive data). The goal is to technically prevent any one person from having the complete ability to access the encrypted data on their own.

Key Splitting (Sharding):
This is a cryptographic technique where a decryption key is divided into multiple unique parts (shards). A certain number of these shards (e.g., 3 out of 5) are required to reconstruct the original key and decrypt the data.

How it Addresses Insider Threat:
This technique implements a separation of duties and dual control for cryptographic access. No single employee ever possesses the entire key. To decrypt the material, multiple employees (e.g., from different departments) must collaborate and provide their individual key shards. This effectively mitigates the risk of a lone insider acting maliciously, as they cannot act alone.

Analysis of Incorrect Options:
A. SSO with MFA (Single Sign-On with Multi-Factor Authentication):
This improves authentication security by requiring a second factor to prove identity. However, once authenticated, the employee still has individual, complete access to the encrypted material. It does nothing to prevent a malicious insider from using their legitimate access to decrypt data.

B. Salting and hashing:
These are techniques used to protect stored passwords. A salt is added to a password before it is hashed to defeat precomputed rainbow table attacks. This is irrelevant to controlling access to encrypted data and does not address the insider threat scenario.

C. Account federation with hardware tokens:
Federation allows users to access multiple systems with a single set of credentials, and hardware tokens provide strong authentication. Similar to SSO, this is an access mechanism. It does not change the fact that once access is granted, the user has individual control over the encrypted material. It strengthens the gate but doesn't change what's behind it.

D. SAE (Simultaneous Authentication of Equals):
SAE is a cryptographic protocol used in Wi-Fi networks (WPA3) for establishing a secure connection. It is designed to prevent offline dictionary attacks on Wi-Fi passwords and is not relevant for managing access to stored encrypted data or mitigating insider threats.

Reference:
This solution falls under Domain 3.6: Cryptography and Domain 1.0: Governance, Risk, and Compliance of the CAS-005 exam. Key concepts include:

Cryptographic Key Management: Implementing controls like key splitting to enforce separation of duties.

Principle of Least Privilege and Dual Control: Ensuring that critical actions (like decrypting sensitive data) require the collaboration of multiple parties, preventing any single point of failure or misuse.

Key splitting (E) is the only technique that directly and technically addresses the risk of a single insider misusing their individual access to encrypted material.

Explanation:
The problem is data exfiltration to unsanctioned cloud applications (personal storage accounts like Dropbox, Google Drive, etc.). The goal is to not just block or alert, but to actively monitor and control the data that is being sent to cloud services.

Cloud-Access Security Broker (CASB):
A CASB is a security policy enforcement point that sits between an organization's on-premises infrastructure and a cloud provider's infrastructure. It acts as a gatekeeper to ensure secure cloud usage.

How it Decreases Risk:
A CASB provides several critical functions that directly address this risk:

Discovery & Visibility:
It identifies all cloud services in use (sanctioned and unsanctioned).

Data Loss Prevention (DLP):
This is the key feature. A CASB can inspect data in motion to the cloud. It can identify sensitive content (based on patterns, fingerprints, or labels) being uploaded to personal storage sites and block the upload in real-time.

Access Control:
It can enforce policies to allow, block, or limit access to specific cloud applications based on user, device, or location.

A CASB provides a proactive, data-centric control designed specifically for the cloud era.

Analysis of Incorrect Options:
A. Improve firewall rules to avoid access to those platforms & D. Deploy an internet proxy that filter certain domains:

These are similar network-based blocking solutions. While they can technically block access to the domains of popular storage platforms, they are very coarse and ineffective controls.

* Easy to Bypass: Employees can use personal devices on cellular networks to bypass corporate proxies and firewalls.

* Too Broad: It blocks the entire application, which might be used legitimately for non-sensitive work. A CASB offers much more granular control.

* Reactive: The list of personal storage sites is endless; new ones pop up constantly, making it a game of whack-a-mole.

C. Create SIEM rules to raise alerts for access to those platforms:
A SIEM is a detective control. It can alert after the data has already been exfiltrated. By the time the SOC analyst sees the alert, the sensitive data is already on a server outside the company's control. The requirement is to decrease the risk (prevent the leak), not just to discover it after the fact.

Reference:
This solution is a core component of Domain 3.4: Secure Network Architecture and Domain 1.4: Data Security of the CAS-005 exam. CASBs are a critical technology for implementing a data-centric security strategy in a hybrid cloud world.

While the other options provide partial, often ineffective solutions, implementing a CASB (B) is the most comprehensive and effective way to directly decrease the risk of data leaks to personal cloud storage accounts by inspecting and controlling the data itself.

Explanation:
The threat posed by quantum computing is highly specific to certain types of cryptographic algorithms.

Shor's Algorithm:
This is a quantum algorithm that, if run on a sufficiently powerful quantum computer, can efficiently solve the mathematical problems that underpin the security of most widely used public-key cryptography.

Vulnerable Algorithms:

These include:

RSA:
Based on the practical difficulty of factoring the product of two large prime numbers.

Diffie-Hellman & ECC (Elliptic-Curve Cryptography):
Based on the difficulty of the discrete logarithm problem.

The Risk:
A cryptographically relevant quantum computer (CRQC) could use Shor's algorithm to break these encryption and digital signature schemes, rendering them useless. This would compromise the security of virtually all secure web traffic (TLS/SSL), digital signatures, and encrypted data that has been stored for future decryption. This specific and existential threat to current standards is the primary driver for the development and deployment of Post-Quantum Cryptography (PQC) – new encryption algorithms designed to be secure against both classical and quantum computer attacks.

Analysis of Incorrect Options:

B. Zero Trust security architectures will require homomorphic encryption.
Zero Trust is a security model centered on the belief that organizations should not automatically trust anything inside or outside its perimeters. While homomorphic encryption (performing computations on encrypted data) is an advanced cryptographic technique, it is not a requirement for Zero Trust. Zero Trust primarily relies on strong identity verification and access controls. The push for new algorithms is driven by quantum threats, not by Zero Trust architecture needs.

C. Perfect forward secrecy will prevent deployment of advanced firewall monitoring techniques.
Perfect Forward Secrecy (PFS) is a feature of key agreement protocols that ensures a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. PFS is a security benefit, not a hindrance. It does not prevent advanced firewall monitoring; firewalls can still inspect TLS traffic if they are configured as a trusted man-in-the-middle. This option is a distractor and not related to the quantum threat.

D. Quantum computers will enable malicious actors to capture IP traffic in real time.
The ability to capture IP traffic is a function of network access (e.g., through a compromised node or wiretap), not computational power. Quantum computers do not provide a new capability to capture traffic; they threaten the ability to decrypt the captured traffic that was encrypted using vulnerable algorithms. The threat is to breaking the encryption, not the capture itself.

Reference:
This topic is a key part of Domain 3.6: Cryptography in the CAS-005 exam. It requires an understanding of:

Quantum Threats: The specific risk that quantum computing poses to asymmetric cryptography based on integer factorization and discrete logarithm problems.

Cryptographic Agility: The need to prepare for the migration to post-quantum cryptographic algorithms, a effort being led by standards bodies like NIST.

The main and direct reason for deploying new encryption algorithms is the vulnerability of current prime number-based systems to quantum attacks, as described in option A.

Explanation:
The issue is that known vulnerable open-source libraries are being detected late (during DAST), causing deployment delays. The best solution is to identify these issues earlier in the software development life cycle (SDLC), ideally during development or integration, before the application reaches the DAST phase.

Correct Option:

D. Using a software dependency management solution

Scans dependencies (open-source libraries) against CVE databases during build or commit time.

Identifies vulnerable libraries before code is deployed, shifting security left.

Integrates with CI/CD pipelines to prevent vulnerable components from progressing to later stages.

Incorrect Options:

A. Directing application logs to the SIEM for continuous monitoring
SIEM monitors runtime events and logs, not static vulnerabilities in libraries. It detects post-deployment anomalies but cannot prevent using vulnerable libraries early in the life cycle. Too late and reactive.

B. Modifying the WAF policies to block against known vulnerabilities
WAF provides runtime protection by blocking exploits, but it does not fix or identify vulnerable libraries during development. It’s a compensating control, not a shift‑left solution for early detection.

C. Completing an IAST scan against the web application
IAST (Interactive Application Security Testing) works during application testing (often in QA), still later than dependency scanning. It can find some library issues, but it’s heavier and not as early or efficient as a dedicated dependency management tool integrated into the IDE/pipeline.

Reference:
CompTIA CAS-005 Exam Objectives — Domain 2: Security Architecture (Software Assurance / Shift Left). NIST SSDF (Secure Software Development Framework) PW.1: “Identify and protect against use of vulnerable components.” OWASP Dependency-Check / SCA best practices.