Free CompTIA CAS-005 Practice Questions 2026 - Page 8

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.

Explanation:
The core problem is the insecure handling of highly sensitive cryptographic material (e.g., encryption keys, certificates) on personal, non-compliant devices (developer laptops). The best strategy is to centralize this function in a dedicated, secure, and certified hardware appliance.

Hardware Security Module (HSM):
An HSM is a physical computing device that safeguards and manages digital keys, performs encryption and decryption functions, and enforces strong authentication and access controls.

Why it's the Best Strategy:

Physical Security:
HSMs are tamper-evident and tamper-resistant, providing physical protection for keys.

Logical Security:
Keys are generated, stored, and used entirely within the HSM's secure boundary. They are never exposed in plaintext to the operating system, memory, or network, preventing theft from a compromised developer machine.

Centralized Management:
It provides a single, secure, and auditable platform for all cryptographic operations, replacing the insecure, decentralized practice of developers managing keys on their laptops.

Compliance:
HSMs are often required to meet stringent security standards like FIPS 140-2/3, PCI DSS, and others.

Analysis of Incorrect Options:

A. Disabling the BIOS and moving to UEFI:
Unified Extensible Firmware Interface (UEFI) is a more secure replacement for the legacy BIOS system, offering features like Secure Boot. While this is a good general security practice for hardening a laptop's boot process, it does nothing to address the specific, high-risk issue of how cryptographic keys are generated, stored, and used. The keys would still reside on the laptop's insecure storage.

B. Managing secrets on the vTPM hardware:
A virtual Trusted Platform Module (vTPM) provides TPM functionalities to virtual machines. A TPM is excellent for securing a device's platform integrity (e.g., for disk encryption, measured boot). However, it is not designed for the scalable, centralized management of production cryptographic keys across an enterprise. It is a local chip, and managing keys on a vTPM would still leave them distributed across various developer environments, not centralized.

C. Employing shielding to prevent LMI:
"LMI" is likely a typo or acronym error, but "shielding" often refers to protections against side-channel attacks or electromagnetic interference. This is a highly specialized control that might be used to protect specific hardware but is not a strategic solution for managing cryptographic material across an organization. It does not address the process flaw of developers handling keys on personal devices.

Reference:
This strategy is a fundamental best practice in Domain 3.6: Cryptography of the CAS-005 exam. Key concepts include:

Key Management Practices:
Understanding the importance of secure key generation, storage, distribution, and destruction.

Hardware-Based Cryptography:
Implementing FIPS-validated hardware (HSMs) to provide the highest level of assurance for cryptographic operations.

Migrating key management from insecure, distributed endpoints to a centralized Hardware Security Module (HSM) is the industry-standard and most secure way to address this critical risk.

Explanation:
The requirements are for high availability (HA) and disaster recovery (DR) across geographic distances. Let's map the solutions to the requirements:

Requirement:
Be survivable to one environmental catastrophe & Be recoverable within 24 hours

B. Allocate fully redundant and geographically distributed standby sites:
This is a classic DR solution. "Geographically distributed" ensures an environmental catastrophe (flood, earthquake, fire) at one location does not affect the other. "Fully redundant" means the standby site has the necessary hardware and infrastructure to take over operations, supporting the 24-hour Recovery Time Objective (RTO). This could be a hot or warm site.

E. Use orchestration to procure, provision, and transfer application workloads to cloud services:
This is a modern, agile approach to DR. Cloud services provide geographically distributed regions and availability zones. Orchestration tools (e.g., Terraform, AWS CloudFormation) can automatically "procure and provision" the entire environment in a new cloud region in minutes, meeting the 24-hour RTO. This makes the system highly resilient and survivable.

Requirement:
Be resilient to active exploitation of one site-to-site VPN solution.

Both solutions (B and E) inherently address this. If the VPN to one site is compromised, traffic can be automatically rerouted to the other geographically distinct site (B) or to the cloud environment (E), which would use its own secure connectivity (e.g., AWS Direct Connect, encrypted VPC peering).

Analysis of Incorrect Options:

A. Load-balance connection attempts and data ingress at internet gateways:
This improves availability and performance for incoming internet traffic at a single location. It does not provide geographic resilience against an environmental catastrophe or the compromise of an entire site's VPN.

C. Employ layering of routers from diverse vendors:
This is a strategy for increasing network device resilience against specific vulnerabilities or failures (vendor diversity). It might slightly improve uptime at a single site but does not provide a solution for recovering an entire site that has been lost or whose VPN has been exploited.

D. Lease space to establish cold sites throughout other countries:
A cold site has space and infrastructure (power, cooling) but no pre-configured hardware. Recovery often takes days or weeks to procure, install, and configure systems. This fails the 24-hour recovery requirement.

F. Implement full weekly backups to be stored off-site:
Backups are crucial for recovery (Recovery Point Objective - RPO), but they do not address recovery time (RTO). Restoring from weekly backups, especially full system restores to new hardware, would almost certainly take longer than 24 hours. This strategy alone does not meet the availability requirement.

Reference:
This design falls under Domain 2.0: Security Architecture and Domain 3.0: Security Engineering of the CAS-005 exam, specifically:

Disaster Recovery (DR) and Business Continuity (BC) Planning: Designing systems for high availability and geographic resilience.

Cloud Migration and Orchestration: Leveraging cloud services and automation for agile and resilient infrastructure.

Options B and E together provide a robust, multi-faceted strategy that meets all three stated requirements for survivability, recovery time, and network resilience.

Explanation:
The scenario describes a formalized threat intelligence sharing program between multiple organizations. This requires standardized languages and protocols to ensure that data from different sources can be understood, trusted, and automatically processed.

STIX (Structured Threat Information eXpression):
This is a language and serialization format used to represent cyber threat intelligence in a standardized and structured way. STIX defines a set of objects (e.g., Indicator, Campaign, Threat Actor, Attack Pattern) and relationships between them. This allows organizations to share complex threat information in a consistent manner that both humans and machines can understand.

TAXII (Trusted Automated eXchange of Intelligence Information):
This is the application protocol used to exchange cyber threat intelligence (CTI) information over HTTPS. TAXII defines how CTI servers and clients communicate. It supports common sharing models like hubs-and-spokes (a central platform, as described) and peer-to-peer. TAXII is the transport mechanism that would be used to share STIX-formatted data.

Together, STIX and TAXII form the foundational standards for automated threat intelligence sharing within and between organizations. They are often used by Information Sharing and Analysis Centers (ISACs), which is exactly the type of collaborative model described.

Analysis of Incorrect Options:

A. CWPP (Cloud Workload Protection Platform):
This is a security tool designed to secure workloads (e.g., virtual machines, containers) in cloud environments. It is not related to the process of sharing threat intelligence between organizations.

B. YARA:
YARA is a tool used to identify and classify malware. It uses text-based patterns (rules) to detect malware families. While YARA rules can be shared as a form of threat intelligence, they are a specific type of indicator. STIX/TAXII is a much broader, more structured, and standardized framework designed for sharing all forms of threat intelligence (not just malware signatures), which is what the question describes.

C. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge):
MITRE ATT&CK is a knowledge base and model for categorizing and understanding adversary behavior. It provides a common taxonomy that organizations can use to describe attacks. While ATT&CK is incredibly valuable for structuring and understanding intelligence (e.g., tagging STIX objects with ATT&CK techniques), it is not a sharing protocol. STIX and TAXII are the standards used to actually exchange that ATT&CK-informed intelligence.

F. JTAG (Joint Test Action Group):
This is a standard for testing, debugging, and programming printed circuit boards (PCBs) and integrated circuits at the hardware level. It is completely unrelated to cyber threat intelligence sharing.

Reference:
This knowledge is core to Domain 4.0: Security Operations of the CAS-005 exam, specifically:

4.4: Incident Management:
Utilizing threat intelligence to improve incident response.

Cyber Threat Intelligence (CTI):
Understanding the tools and protocols used to operationalize CTI, such as STIX/TAXII, which are industry standards promoted by organizations like OASIS and US-CERT.

To facilitate automated, structured threat intelligence sharing via a central platform, the organization must leverage the standard language (D. STIX) and the standard transport protocol (E. TAXII).

Explanation:
The root cause of the problem is that the application contains known vulnerabilities in third-party libraries. The best solution is one that automatically and continuously identifies these vulnerable dependencies before the application is deployed.

SAST (Static Application Security Testing):
SAST tools analyze an application's source code, bytecode, or binary code for security vulnerabilities without running the program. Modern SAST tools almost universally include Software Composition Analysis (SCA) capabilities.

SCA Functionality:
SCA is a specific type of analysis that automatically scans an application's dependencies (libraries, packages, frameworks) against databases of known vulnerabilities (like the National Vulnerability Database). It identifies outdated and vulnerable libraries exactly like the ones described in the question.

Integration Pipeline:
By integrating a SAST/SCA tool into the CI/CD pipeline, the development process gains an automated gate. Every time code is committed, the tool scans the dependencies. If it finds a known vulnerable library, it can fail the build and alert the developers immediately, preventing the vulnerable code from progressing closer to production.

Analysis of Incorrect Options:

A. Using IaC to include the newest dependencies:
Infrastructure as Code (IaC) is used to automate the deployment of infrastructure (e.g., servers, networks). It is not used to manage an application's software libraries or dependencies. Dependency management is handled by tools like Maven, Gradle, npm, pip, etc. While keeping dependencies updated is good practice, this option suggests using the wrong tool for the job and does not provide the automated scanning and alerting required.

B. Creating a bug bounty program:
A bug bounty program is a reactive measure that incentivizes external researchers to find vulnerabilities after an application is in production. The problem is that vulnerabilities are already being found by third parties in production. A bug bounty might find more, but it does not prevent known library vulnerabilities from being introduced in the first place. The goal is to shift left and find them earlier in the development process.

C. Implementing a continuous security assessment program:
This is a vague term that could encompass many things, including penetration testing and vulnerability scanning. While a good practice, it is often a post-deployment activity. The most effective and efficient approach is to catch these specific types of vulnerabilities (known library flaws) automatically in the pipeline before they ever reach a production environment where a continuous assessment would find them.

Reference:
This solution falls under Domain 4.3: Automation of Security Operations and Domain 4.4: Vulnerability Management of the CAS-005 exam. Key concepts include:

DevSecOps: Integrating security tools like SAST/SCA directly into the CI/CD pipeline to automate security testing.

Software Supply Chain Security: Managing and securing third-party dependencies to prevent known vulnerabilities from being deployed.

Integrating a SAST tool with SCA capabilities (D) is the most targeted and automated solution for preventing known vulnerabilities in third-party libraries from reaching production.