Free CAS-005 Practice Test Questions 2026

Explanation:

Why E is Correct:
Key stretching is a technique specifically designed to strengthen weak passwords, such as those entered by users. It works by taking a password and passing it through a computationally intensive algorithm (like PBKDF2, bcrypt, or Argon2) that requires a significant amount of time and resources to compute. This dramatically increases the effort required for an attacker to perform a brute-force or dictionary attack, as each guess must go through the same slow process. This can be implemented on top of the existing hashing mechanism (e.g., moving from a single SHA-256 hash to PBKDF2 with SHA-256 and a high iteration count) without necessarily replacing the entire underlying cryptographic module.

Why A is Incorrect:
Key splitting involves dividing a cryptographic key into multiple parts (shards) that are distributed to different entities. This is used for securing keys and enforcing control, not for strengthening the cryptographic process of password derivation.

Why B is Incorrect:
Key escrow is the process of depositing a cryptographic key with a trusted third party to be stored for emergency access (e.g., by law enforcement). This is a governance and recovery mechanism, not a technique for improving cryptographic strength.

Why C is Incorrect:
Key rotation is the practice of retiring an encryption key and replacing it with a new one at regular intervals. This is a vital practice for limiting the blast radius of a potential key compromise but does not inherently make the algorithm used to derive a key from a password any stronger. The password-to-key process could still be weak and vulnerable to attack.

Why D is Incorrect:
Key encryption (or key wrapping) is the process of encrypting one key with another key. This is used for secure key storage and transmission. While the stored password hashes should be encrypted at rest, this is a separate control. The core weakness of simple password hashing is the speed of the hashing operation, which key encryption does not address.

Reference:
This question falls under Domain 3.0: Security Engineering and Cryptography. It specifically addresses cryptographic techniques and their appropriate application, focusing on secure password storage mechanisms as outlined in best practices and standards like NIST SP 800-63B.

Explanation:

Why A is Correct:
This is the most direct and effective solution to the specific problem of "many false positives" from a code scan. Static Application Security Testing (SAST) tools are notorious for generating false positives, which can overwhelm developers and lead to real issues being ignored.

Limiting to a specific language:
SAST tools perform best when they are optimized for a particular language's syntax and common pitfalls. Running a tool configured for multiple languages against a codebase written primarily in one language can trigger irrelevant rules and generate false positives.

Tuning the rule set:
This is the critical step for reducing false positives. It involves customizing the tool's rules to match the application's specific framework, libraries, and architecture. This can include:

Disabling rules that are not relevant to the project.

Adjusting the severity of certain findings.

Creating custom rules to ignore known benign patterns specific to the codebase.

Providing the tool with paths to custom libraries so it can accurately track data flow.

Tuning transforms a generic scanner into a precise tool tailored to the environment, dramatically improving the signal-to-noise ratio.

Why B is Incorrect:
Configuring branch protection rules (e.g., requiring pull requests and approvals before merging) and dependency checks (SCA - Software Composition Analysis) are excellent DevOps security practices. However, they address different problems. Branch protection enforces process, and dependency checks find vulnerabilities in third-party libraries. Neither practice directly reduces the false positive rate of a SAST tool scanning custom code for flaws.

Why C is Incorrect:
Using an application vulnerability scanner (DAST - Dynamic Application Security Testing) in production is a reactive measure. It finds vulnerabilities in a running application after it has been deployed. The question is about improving the scan results before deployment. Furthermore, running a DAST tool does not fix the root cause of the poor results from the SAST (code scan) tool; it simply uses a different, later-stage tool to find a different class of issues.

Why D is Incorrect:
Updating code libraries is a crucial maintenance activity for patching known vulnerabilities in dependencies (addressed by SCA tools). However, it has no bearing on the accuracy of a SAST tool scanning the company's own custom code for logical flaws and coding errors. The false positives are generated by the tool's analysis of the code structure, not by the version of the libraries used during development.

Reference:
This question falls under Domain 2.0: Security Operations, specifically concerning security testing in the development lifecycle and the integration and management of tools like SAST to improve software security. It also touches on the analytical skill of selecting the correct mitigation for a given problem.

Explanation:

Why D is Correct:
Full disk encryption (FDE) solutions like BitLocker (Windows) or FileVault (macOS) have a strict hardware requirement: a Trusted Platform Module (TPM). A TPM is a dedicated cryptographic processor chip soldered onto the computer's motherboard.

If the audit finding states that the device configuration "does not support full disk encryption," the most fundamental and common reason is that the motherboard lacks this specific hardware component entirely.
Older computers or some very low-cost models were manufactured and sold without a TPM chip. Since the TPM is a physical hardware requirement, it cannot be added via software. The only remediation for such a device is to replace it with hardware that meets the compliance requirement (i.e., a motherboard with a TPM).

Why A, C, and E are Incorrect (HSM):
These options incorrectly refer to an HSM (Hardware Security Module). An HSM is a high-performance, external, or PCIe-based network device used to manage and protect cryptographic keys for servers, certificate authorities, and critical infrastructure. HSMs are not used for standard endpoint full-disk encryption. Endpoints use a TPM, which is a much smaller, cheaper, and less powerful cryptographic co-processor designed specifically for this purpose. Confusing TPM and HSM is a common distractor in exam questions.

Why B is Incorrect (vTPM):
A vTPM (virtual TPM) is a software-based implementation of a TPM used in virtual machines to provide the same functionality. The question is about physical "user endpoints" (e.g., laptops, desktops). A vTPM is not relevant to the physical hardware of an endpoint device. Furthermore, if a vTPM were corrupt, it could potentially be re-initialized or re-provisioned through software or hypervisor management, not necessarily requiring a full hardware replacement.

Reference:
This question falls under Domain 1.0: Security Architecture and Domain 4.0: Governance, Risk, and Compliance. It tests knowledge of hardware security capabilities (TPM vs. HSM) and the practical implications of enforcing compliance policies that have specific hardware requirements. Understanding the "why" behind a control is crucial for a CASP+.

Explanation:

Why B is Correct:
Prompt injection is a vulnerability specific to AI systems that use text-based prompts, particularly Large Language Models (LLMs). It occurs when an attacker crafts a malicious input (a "prompt") that tricks the model into ignoring its original instructions, bypassing safety filters, or revealing sensitive information. Input sanitation is a primary defense against this attack. It involves rigorously validating, filtering, and escaping all user-provided input before it is passed to the AI model. This helps to neutralize or render ineffective any malicious instructions embedded within the user's input, thereby preventing the model from being hijacked.

Why A is Incorrect:
Model inversion is an attack where an adversary uses the model's outputs (e.g., API responses) to reverse-engineer and infer sensitive details about the training data. This is addressed by controls on the output side (e.g., differential privacy, output filtering, limiting API response details) and model design, not by sanitizing the input prompts.

Why C is Incorrect:
Data poisoning is an attack on the training phase of an AI model. An attacker injects malicious or corrupted data into the training set to compromise the model's performance, integrity, or behavior after deployment. Defending against this requires securing the data collection and curation pipeline, using robust training techniques, and validating training data—measures that are completely separate from sanitizing runtime user input.

Why D is Incorrect:
A non-explainable model (often called a "black box" model) is a characteristic of certain complex AI algorithms where it is difficult for humans to understand why a specific decision was made. This is an inherent challenge of the model's architecture (e.g., deep neural networks) and is addressed by the field of Explainable AI (XAI), which involves using different models, tools, and techniques to interpret them. Input sanitation has no bearing on making a model's decisions more explainable.

Reference:
This question falls under the intersection of Domain 1.0: Security Architecture and emerging technologies. It tests the understanding of specific threats to AI systems and the appropriate security controls to mitigate them. Input validation/sanitation is a classic application security control that finds a new critical application in protecting AI systems from prompt injection attacks.

Explanation:
A Cloud Access Security Broker (CASB) is a security policy enforcement point that sits between users and cloud service providers. There are two primary deployment modes: API-based and proxy-based.

Why A is Correct:
A proxy-based CASB operates in-line, intercepting traffic in real-time between the user and the cloud application. This allows it to enforce granular access controls and policies immediately. Specifically, it can:

Block unapproved applications and services in real-time by denying connections to unauthorized cloud services.

Inspect and control data transfers (e.g., prevent uploads to personal cloud storage).

Enforce encryption and data loss prevention (DLP) policies on the fly.

This real-time blocking capability is a key advantage of proxy-based CASBs over API-based solutions, which are more focused on post-hoc monitoring and remediation.

Why B is Incorrect:
Privacy compliance obligations (e.g., GDPR, CCPA) are never "bypassed" by any deployment model. In fact, a CASB helps enforce compliance. User-based deployments (e.g., forward proxy) still must comply with privacy laws, and the deployment choice does not negate these obligations.

Why C is Incorrect:
While managing API keys for an API-based CASB can be administratively burdensome, this is not the primary reason for choosing a proxy-based CASB. The key differentiator is the need for real-time enforcement (like blocking) rather than just visibility and retrospective controls.

Why D is Incorrect:
Certificates for authentication (e.g., for SSL inspection) can be deployed to corporate devices remotely using mobile device management (MDM) or similar tools, regardless of whether they are connected on-premises. This is not a significant barrier and is not the main driver for selecting a proxy-based CASB.

Reference:
This question falls under Domain 1.0: Security Architecture. It tests the understanding of CASB deployment modes and their respective strengths. Proxy-based CASBs are chosen when real-time control and blocking are required, which aligns with the need to enforce policies for a distributed workforce accessing cloud services.

Explanation:

The requirements are:

Only execute internally signed applications:
This requires whitelisting based on code signing.

Prevent administrator accounts from installing unauthorized software: This requires enforcement that overrides even admin privileges.

Log attempts to run unauthorized software:
This requires detailed auditing of execution attempts.

Option D best meets all these requirements:
Application control (e.g., Windows AppLocker or SRP) can be configured to:

Allow only applications signed with enterprise-trusted root certificates (e.g., your organization's internal code signing certificate). This ensures only internally signed software runs.

Block hashes of specific unauthorized applications if needed.

Enforce policies that apply to all users, including administrators, preventing them from running unauthorized installers or executables.

Log all attempts to execute blocked software for auditing and alerting.

Why the other options are incorrect:

A) Maintaining account access through directory management:
While directory controls (e.g., limiting admin privileges) can help, they are not foolproof. Administrators may still have privileges, and this approach does not directly enforce code signing or log execution attempts.

B) Implementing a CSPM (Cloud Security Posture Management):
CSPM is for securing cloud infrastructure (e.g., misconfigurations in AWS/Azure). It does not control endpoint software execution or logging.

C) Deploying an EDR (Endpoint Detection and Response):
EDR is great for monitoring and responding to threats, but it is primarily detective rather than preventive. It might log installation attempts but cannot inherently prevent administrators from running unauthorized software or enforce code signing policies. Application control (option D) is the preventive measure.

Reference:
This aligns with Domain 1.0: Security Architecture (endpoint security) and Domain 2.0: Security Operations (policy enforcement). Application control with code signing is a best practice for locking down endpoints and meeting strict compliance requirements.

Explanation:
The security analyst has identified requests from IP addresses known for bot or illegitimate traffic. To determine if these requests are malicious, the analyst needs to inspect elements that can reveal the nature of the client making the request.

Why A is Correct:
The User-Agent string is a header in HTTP requests that identifies the client software (browser, bot, script, etc.) making the request. Malicious bots often use: Generic or spoofed User-Agent strings (e.g., "python-requests/2.28.1" for a script).

Outdated browsers (indicating automation).

Strings known to be associated with scraping tools or vulnerability scanners.

By analyzing the User-Agent, the analyst can distinguish between legitimate traffic (e.g., known browsers) and malicious automation (e.g., bots, scanners).

Why the other options are less effective:

B) Byte length of the request:
While unusual request lengths might indicate anomalies (e.g., buffer overflow attempts), they are not a reliable indicator of bot traffic. Legitimate requests can vary in length, and malicious requests might mimic normal sizes.

C) Web application headers:
Headers like Accept-Language or Referer can be manipulated by bots and are less definitive than the User-Agent for identifying automation.

D) HTML encoding field:
HTML encoding (e.g., Content-Encoding) relates to how data is formatted for transmission and is not typically used to distinguish malicious bots. It is more relevant for data processing than threat detection.

Reference:
This falls under Domain 2.0: Security Operations (threat detection). Analyzing User-Agent strings is a common technique for identifying bot traffic and automated attacks in web logs.

Explanation:
The security team knows that the malicious activity affects certain versions of an application. To determine the scope of impact, they need to quickly identify all systems within the organization that are running those vulnerable versions.

Why C is Correct:
A comprehensive and accurate asset inventory is a centralized database that tracks:

All hardware and software assets in the organization.

Software versions installed on each system.

Ownership and location of assets.

By querying the asset inventory, the team can instantly generate a list of all devices running the affected application versions. This directly answers the question: "Where is this vulnerable software deployed, and how many systems are at risk?"

Why the other options are incorrect:

A) Performing a port scan:
A port scan identifies open ports and services on network devices. It might reveal that a service is running, but it cannot reliably determine the specific version of an application (especially for custom or non-standard services). It is too slow and imprecise for this task.

B) Inspecting egress network traffic:
This helps identify data exfiltration or command-and-control communication from already compromised systems. It is useful for understanding what an attacker is doing but does not help in proactively identifying all potentially vulnerable systems that might not yet be compromised.

D) Analyzing user behavior:
This is used to detect anomalies like insider threats or compromised accounts. It does not help in mapping the deployment of a specific vulnerable application version across the enterprise.

Reference:
This aligns with Domain 2.0: Security Operations (incident response) and Domain 4.0: Governance, Risk, and Compliance (asset management). During an incident, an accurate asset inventory is critical for impact assessment and containment. Tools like CMDBs (Configuration Management Databases) are essential for this purpose.

Explanation:
The core issue involves third-party hardware devices that are part of the company's released products. To identify misconfigurations and vulnerabilities at an earlier stage (i.e., before the products are released or deployed), the company needs a proactive, systematic approach to manage risks introduced by suppliers and vendors.

Why D is Correct:
A supply chain risk management (SCRM) program is a comprehensive framework designed to:

Assess vendors before procurement (e.g., evaluate their security practices, development lifecycle, and testing protocols).

Establish contractual requirements for security (e.g., requiring vendors to provide Software Bill of Materials (SBOMs), undergo audits, or share vulnerability disclosures).

Integrate security checks early in the supply chain (e.g., during design and manufacturing phases rather than after delivery).

Monitor for vulnerabilities specific to third-party components (e.g., subscribing to vendor security advisories).

This proactive approach helps identify and mitigate issues earlier in the product lifecycle, reducing the risk of releasing vulnerable products.

Why the other options are incorrect:

A) Performing vulnerability tests on each device delivered by the providers:
This is a reactive measure. Testing devices after they are delivered is too late—it occurs at the end of the supply chain. It also does not scale well and may not catch all issues (e.g., firmware vulnerabilities).

B) Performing regular red-team exercises on the vendor production line:
This is impractical and often not feasible. Vendors are unlikely to allow external red-team exercises on their production systems. Red-teaming is typically used for internal security assessments, not supply chain oversight.

C) Implementing a monitoring process for the integration between the application and the vendor appliance:
This is useful for detecting runtime issues but is reactive. It occurs after integration and does not address vulnerabilities inherent in the hardware device itself before it is integrated.

Reference:
This question falls under Domain 4.0: Governance, Risk, and Compliance. It emphasizes the importance of supply chain risk management as a proactive strategy to identify and mitigate vulnerabilities introduced by third-party components, aligning with frameworks like NIST SP 800-161.

Explanation:
Let's evaluate how option B meets each requirement:

Isolate the OT network segment:
A bastion host (or jump server) acts as a single, hardened entry point into the OT network. This maintains isolation by ensuring all external access funnels through a tightly controlled gateway, preventing direct connections to critical OT assets.

Restrict Internet access:
The bastion host does not require general internet access for the entire OT network. Internet access can be restricted to only what is necessary (e.g., for the bastion host or update server to fetch updates), and the dedicated update server can be configured to pull updates in a controlled manner (e.g., from a trusted source).

Apply security updates to workstations:
A dedicated update server within the OT network can be used. This server can be periodically updated (via a secure process, such as manual transfer from an internet-connected system) and then distribute patches to OT workstations without requiring them to have direct internet access.

Provide remote access to third-party vendors:
The bastion host is specifically designed for secure remote access. Third-party vendors can connect to the bastion host (with strong authentication and monitoring), and from there, access only the specific OT systems they are authorized to manage.

Why the other options are incorrect:

A) Deploy a jump box on the third-party network...:
Placing the jump box on the third-party network (instead of the OT network) exposes it to external risks and may not adequately isolate the OT environment. Using physical delivery (e.g., USB drives) for updates is inefficient, insecure (risk of malware introduction), and not scalable.

C) Enable outbound internet access...
to any destination IP: This violates the "restrict internet access" requirement. Allowing unrestricted internet access from the OT network exposes it to significant threats and is a major security anti-pattern for OT environments.

D) Create a staging environment...
and enable automatic updates: A staging environment for vendors does not necessarily ensure isolation or secure access. Enabling automatic updates on OT workstations is risky because:

It may disrupt critical operations (updates must be tested in OT).

It requires internet access, violating the restriction requirement.

Automatic updates can introduce instability or unvetted changes.

Reference:
This aligns with Domain 1.0: Security Architecture (secure network design for OT/ICS). Using a bastion host and a dedicated update server is a best practice for maintaining OT isolation while enabling controlled access and patch management.

Explanation:
The goal is to reduce the privilege escalation attack surface for a containerized application. Privilege escalation in containers often occurs when an attacker gains access to a container running as the root user (UID 0) and then exploits vulnerabilities to elevate privileges on the host or within the container.

Why A is Correct:
This Dockerfile command creates a non-root user (user with UID 1000) and sets it as the default user for the container. By running the application as a non-root user, you:

Minimize the impact of compromise:
If an attacker breaches the container, they have limited privileges (non-root) by default.

Reduce privilege escalation risks:
It is harder to escalate to root within the container if the entrypoint or application does not run as root.

This is a foundational Docker security best practice and directly targets the privilege escalation attack surface.

Why the other options are incorrect:

B) Installing an EDR on the host and configuring alerting for root processes:
This is a detective control, not a preventive one. It may alert you when privilege escalation occurs but does nothing to reduce the attack surface or prevent it. Additionally, EDR on the host does not directly protect the container's internal runtime.

C) Designing a multicontainer solution with automatic remediation:
While automatic remediation can help respond to incidents, it is reactive. It does not prevent privilege escalation from occurring in the first place. This approach adds complexity without directly addressing the root cause (running as root).

D) Running the container in an isolated network and using a load balancer with ACLs:
This reduces the network attack surface (e.g., limiting inbound traffic) but does nothing to mitigate privilege escalation within the container itself. An attacker who exploits an application vulnerability (e.g., via HTTPS) can still escalate privileges if the container runs as root.

Reference:
This aligns with Domain 3.0: Security Engineering and Cryptography (container security). The principle of least privilege is critical for securing containers. Running applications as a non-root user is a primary recommendation from Docker and CIS benchmarks to minimize escalation risks.

Explanation:
The malware analysis has hit a dead end because the sample:

Does not execute in a sandbox:
It may have anti-sandboxing techniques.

No network IOCs:
It might not activate its network capabilities in the analysis environment.

No publicly known hash match:
It is likely a new or unknown variant.

No process injection method detected:
It may be using a novel technique or require specific conditions to trigger.

To proceed, the team needs to observe the malware's behavior in an environment where it will execute fully. A new deployed machine (e.g., a clean, isolated VM or physical system that mimics a real user environment) can bypass anti-sandbox checks and may allow the malware to reveal its true behavior, including network calls, process injection, or other IOCs.

Why the other options are incorrect:

A) Use an online virus analysis tool:
This is redundant. The team already has the sample and likely used similar tools (e.g., VirusTotal) to get the "no publicly known hash match" result. Repeating this won't help.

B) Check for anti-virtualization code in the sample:
While this is a valid step, it is something the team should do before running the sample. Since they already know it doesn't execute in a sandbox, they should now move to an environment that bypasses these checks (like a real machine).

D) Search other internal sources for a new sample:
This might help if the sample is corrupted, but the issue is likely environmental (the malware detects analysis). Finding another copy won't solve the execution problem.

Reference:
This aligns with Domain 2.0: Security Operations (malware analysis). When malware evades automated analysis, analysts must use more advanced techniques, such as running it in a realistic but isolated environment to capture its behavior.