Free CompTIA CAS-005 Practice Questions 2026 - Page 9

Explanation:
A core principle of Zero Trust (ZT) is "never trust, always verify." Context-aware access is the mechanism that enforces this by evaluating a request based on a wide range of contextual factors (user identity, device health, location, application sensitivity, etc.) before granting access.

The Role of Asset Inventory:
For the context-aware system to make an accurate access decision, it must have complete and accurate data about the context. One of the most critical pieces of context is the device making the request.

Why it's the Best Improvement:
An accurate asset inventory provides the system with definitive information about every device:

Is this a company-managed device that meets our security baselines (e.g., encrypted, has an EDR agent, is patched)?

Or is it an unmanaged/personal device?

What is the device's role and ownership?
This information is fundamental for the policy engine to decide whether to grant, deny, or limit access (e.g., "Block access from any device not found in the asset inventory" or "Grant full access only to compliant, company-owned devices"). Without an accurate inventory, the system cannot effectively assess device context, creating a major blind spot.

Analysis of Incorrect Options:

A. Secure zone architecture:
This is a more traditional network security model that relies on defining trusted internal zones (network segments) and untrusted external zones. This contradicts the Zero Trust model, which assumes no network is trusted. ZT focuses on protecting resources, not network segments. While segmentation is a component, "secure zones" are not the primary enabler of context-aware access.

B. Always-on VPN:
A traditional VPN provides access to a trusted network segment based on a single point of authentication. This is the antithesis of Zero Trust. ZT requires continuous verification of every access attempt to every resource, regardless of the user's network location (inside or outside the corporate network). An always-on VPN would bypass the need for fine-grained, context-aware access to individual applications.

D. Microsegmentation:
Microsegmentation is a crucial enforcement mechanism within a Zero Trust architecture. It involves defining granular security policies to control traffic between workloads within a network. However, it primarily operates after a user/device has been granted initial access to a network segment. It improves security inside the network but does not directly improve the context-aware access system itself, which is the gatekeeper that decides who gets in and under what conditions. The effectiveness of the context-aware system is a prerequisite for effective microsegmentation.

Reference:
This concept is central to Domain 3.0: Security Engineering of the CAS-005 exam, specifically the implementation of Zero Trust Architecture. The principle is:

Device Context is Key: The first pillar of most Zero Trust models (e.g., NIST, CISA) is a accurate and complete asset inventory. You cannot enforce policies on devices you don't know about.

Policy Decision Point (PDP):The context-aware access system (the PDP) requires high-quality data from multiple sources (Identity, Device Inventory, etc.) to make accurate allow/deny decisions.

Therefore, the most fundamental way to improve the effectiveness of the context-aware system is to ensure it has the most accurate data possible, starting with a definitive list of all assets (C. Accurate asset inventory).

Explanation:
The key phrase in the question is "the right to be forgotten." This is a specific legal term and a fundamental right granted to individuals under a particular regulation.

GDPR (General Data Protection Regulation):
This is the EU's comprehensive data privacy law. Article 17 of the GDPR explicitly outlines the "Right to erasure ('right to be forgotten')." It gives individuals the right to have their personal data erased under specific circumstances, such as when the data is no longer necessary for the purpose it was collected, or when the individual withdraws consent. The requirement to remove "untruthful data" aligns closely with the grounds for erasure under this regulation.

Scope:
While a news organization might have some exemptions for journalism and freedom of expression, they are still generally obligated to comply with data subject requests, especially when the information is factually incorrect.

Analysis of Incorrect Options:

B. COPPA (Children's Online Privacy Protection Act):
This is a U.S. law that applies to the online collection of personal information from children under 13. It requires verifiable parental consent. It does not contain any provision for a "right to be forgotten" for the general public.

C. CCPA (California Consumer Privacy Act):
This is a California state law that provides consumers with various rights over their personal information. While it includes a right to deletion, it is not traditionally referred to as the "right to be forgotten." More importantly, the GDPR is the regulation that originally coined and popularized this specific term and concept, and it has a broader global impact on organizations like a news publisher with an international online presence.

D. DORA (Digital Operational Resilience Act):
This is a EU regulation focused on financial entities (like banks and insurance companies). It aims to strengthen their IT security and operational resilience against cyber incidents. It has no provisions related to data subject rights or the erasure of personal data from publications.

Reference:
This question tests knowledge of Domain 1.0: Governance, Risk, and Compliance in the CAS-005 exam, specifically:

1.2: Understand legal and regulatory issues that pertain to information security, including data privacy laws like GDPR.

1.4: Understand data privacy and principles, such as the rights of data subjects.

The "right to be forgotten" is a hallmark of the GDPR, making it the most likely regulation the news organization is addressing.

Explanation:

The requirement is twofold:
The development team needs valid data for testing. This means the test data must be realistic and functional—it must maintain the format, type, and relationships of the original production data so that applications can process it correctly during testing.

The data cannot be in cleartext (plaintext) to comply with security regulations.

Tokenization:
This process replaces sensitive cleartext data (e.g., a credit card number) with a non-sensitive equivalent, called a token. The token is a random value that has no mathematical relation to the original data.

Why it's the Best Solution:
The key advantage for testing is that tokens preserve the format and length of the original data. A 16-digit credit card number is replaced with a 16-digit token. This allows the test application to function normally (e.g., validating field length, performing string operations) without ever exposing the real data. The original data is stored securely in a separate token vault.

Analysis of Incorrect Options:

A. Configuring data hashing:
Hashing is a one-way cryptographic function that produces a fixed-length string of characters (a hash). While excellent for verifying data integrity (e.g., checking passwords), it is not reversible and does not preserve the original data's format. A hashed Social Security Number becomes a long string of gibberish, rendering it useless for functional application testing where the correct format is required.

C. Replacing data with null records:
Replacing data with NULL values completely destroys the data's utility. The test data is no longer "valid" or realistic, as applications will not be able to perform meaningful operations or tests, breaking the first requirement.

D. Implementing data obfuscation (or masking):
Data obfuscation techniques (like shuffling, scrambling, or character substitution) can preserve format. For example, it might change "John Doe" to "Mike Smith". However, it often does not preserve referential integrity across databases. If the same original value is obfuscated differently in different tables, the relationships between those tables are broken, which can cause applications to fail during testing. Tokenization is superior because the same original value always generates the same token, preserving these critical relationships.

Reference:
This solution falls under Domain 3.6: Cryptography and Domain 1.4: Data Security of the CAS-005 exam. Key concepts include:

Data Masking/Obfuscation: Understanding the different techniques for de-identifying data.

Tokenization: Recognizing tokenization as the preferred method for scenarios where both data security and functional utility (like format preservation and referential integrity) are required, such as in development and testing environments.

Therefore, deploying tokenization (B) is the best solution, as it removes the sensitive cleartext data while providing realistic, functional data for testing.

Explanation:
The question is very specific: the goal is to find gaps in detection capabilities against Advanced Persistent Threats (APTs) that target a specific industry.

MITRE ATT&CK® (Adversarial Tactics, Techniques, and Common Knowledge): This is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations of cyberattacks, particularly those used by APT groups.

Why it's the Best Tool:

APT-Centric:
ATT&CK is built from the techniques actually used by advanced threat actors, including numerous named APT groups (e.g., APT29, APT41). It is the definitive framework for understanding sophisticated, multi-stage attacks.

Detection Focus:
The primary use case for ATT&CK is to map an organization's existing security controls (like SIEM rules, EDR alerts, etc.) to the techniques in the matrix. By doing this, a security analyst can easily identify techniques for which they have no coverage—these are the detection gaps.

Industry Targeting:
Many ATT&CK resources and reports detail which techniques are most commonly used by APTs against specific industries (e.g., financial, energy, healthcare).

Analysis of Incorrect Options:

B. OWASP (Open Web Application Security Project):
The OWASP Top 10 is a standard awareness document for web application security. It focuses on common vulnerabilities like injection, XSS, and broken access control. It is not designed for modeling the broad, enterprise-wide tactics of APT groups, which go far beyond just web apps.

C. CAPEC (Common Attack Pattern Enumeration and Classification):
Maintained by MITRE, CAPEC is a comprehensive list of attack patterns. While related to ATT&CK, its focus is more on the general methods attackers use at a technical level, rather than the specific behaviors of named threat groups. ATT&CK is more operational and directly tailored for defenders to improve detection and response, making it a better fit for this specific task.

D. STRIDE:
STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a threat modeling methodology originated by Microsoft. It is excellent for proactively identifying potential threats during the design phase of a system or application. However, it is not a knowledge base of real-world APT behaviors. It is a conceptual framework for generating threats, not for mapping an organization's existing detection capabilities against a known list of adversary techniques.

Reference:
This task is a core function of a modern security operations center and falls under Domain 4.0: Security Operations of the CAS-005 exam, specifically:

4.4: Incident Management: Using threat intelligence frameworks to guide security monitoring and improve detection.

Cyber Threat Intelligence (CTI): Leveraging ATT&CK to understand adversary behavior and perform defensive gap analysis.

For the specific goal of finding detection gaps against industry-specific APTs, ATT&CK (A) is the industry-standard and most effective framework to use.

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.