Free CompTIA CAS-005 Practice Questions 2026 - Page 5

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.

Explanation:
The DevSecOps team's task is to identify syntax errors in the code as part of the CI/CD pipeline.

Why A is Correct:
Static Application Security Testing (SAST) is a white-box testing method that analyzes source code for flaws before the application is compiled or run. It is designed to detect:

Syntax errors (e.g., missing semicolons, incorrect language constructs).

Security vulnerabilities (e.g., SQL injection, buffer overflows).

Coding standard violations.

SAST tools (e.g., SonarQube, Checkmarx) integrate directly into the CI/CD pipeline to scan code as it is committed, making them ideal for catching syntax errors early in the development process.

Why the other options are incorrect:

B) Software composition analysis (SCA):
SCA focuses on identifying vulnerabilities in third-party libraries and dependencies, not syntax errors in the custom code.

C) Runtime application self-protection (RASP):
RASP is a security technology that runs on the server and protects applications during execution (e.g., blocking attacks in real-time). It does not analyze code for syntax errors.

D) Web application vulnerability scanning:
This typically refers to Dynamic Application Security Testing (DAST), which tests running applications for vulnerabilities (e.g., OWASP Top 10). It occurs after deployment and cannot detect syntax errors in the source code.

Reference:
This aligns with Domain 2.0: Security Operations (DevSecOps integration). SAST is the primary tool for identifying syntax errors and security flaws in source code during the CI/CD pipeline, supporting shift-left security practices.

Explanation:
This scenario presents a classic risk management decision. When the cost to mitigate a risk (e.g., implementing a technical control, hiring additional staff, purchasing new hardware) exceeds the value of the asset itself, it is financially impractical to mitigate the risk directly. In such cases, the optimal risk response is to transfer the financial burden of the risk to a third party.

Risk Transfer:
Purchasing insurance is the primary method of transferring financial risk. The organization pays a premium to an insurance company. If the risk is realized (e.g., a data breach, system failure, or natural disaster causes loss), the insurance policy covers some or all of the financial damages. This allows the organization to prioritize its resources on mitigating risks where the cost-benefit analysis is favorable, while still managing the high-cost, low-probability risks through financial means.

Prioritization:
By transferring the risk, the team is effectively prioritizing it appropriately. They are acknowledging the risk exists but are choosing the most cost-effective strategy to handle its potential impact, rather than ignoring it or spending excessive resources on it.

Analysis of Incorrect Options:

A. Data labeling:
Data labeling is a data governance and security control. It involves tagging data with classifications (e.g., Public, Confidential, Restricted) to ensure it is handled and protected according to its sensitivity. While this is a crucial security practice, it is a form of risk mitigation or avoidance. If the cost of implementing and maintaining data labeling for this specific asset is already deemed too high, this option does not solve the financial dilemma presented in the question.

B. Branch protection:
Branch protection is a specific feature in version control systems like Git. It enforces workflows for collaborative development by restricting who can push to certain branches, requiring pull requests, and mandating status checks before merging. This is a technical control designed to mitigate risks related to code integrity and security (e.g., introducing vulnerabilities, breaking builds). Like data labeling, it is a form of risk mitigation whose cost may have already been factored into the team's determination that mitigation is too expensive.

C. Vulnerability assessments:
A vulnerability assessment is the process of identifying, classifying, and prioritizing weaknesses in a system. This is a foundational step in risk identification, not risk response. The question states that the risks have already been identified and analyzed ("cost to mitigate... is higher than the asset values"). Conducting another assessment does nothing to address the chosen response to the risk; it only re-discovers the same problem.

Reference:
This concept falls directly under Domain 1.0: Governance, Risk, and Compliance of the CAS-005 exam objectives, specifically focusing on risk assessment, analysis, and response strategies. It aligns with standard risk management frameworks like NIST SP 800-37 (RMF) and ISO 27005, which define the four risk responses:

Avoid:
Eliminate the risk entirely by discontinuing the activity.

Transfer:
Shift the risk to a third party (e.g., insurance).

Mitigate:
Implement controls to reduce the likelihood or impact of the risk.

Accept:
Acknowledge the risk and monitor it without taking action.