CompTIA SecurityX (CAS-005) (CAS-005) — Questions 901–973

Proper error handling in a RESTful API must never expose stack traces or internal implementation details to the client. Stack traces can reveal file paths, database schemas, library versions, and logic flows that attackers can exploit to craft targeted attacks. Instead, the API should return generic error messages (e.g., '500 Internal Server Error') while logging full details server-side for debugging.

A Secure Web Gateway (SWG) sits at the network edge and inspects outbound web traffic, enforcing URL filtering, malware blocking, and acceptable use policies — exactly the function described. In a SASE architecture, SWG is the component that governs user web access regardless of location, applying policy based on categories, reputation, and content inspection. It is distinct from ZTNA (which controls application access), CASB (which governs cloud service usage), and SD-WAN (which optimizes WAN transport).

Using a base image with only the required packages directly reduces the attack surface by eliminating unnecessary binaries, libraries, and services that could contain vulnerabilities. This practice aligns with the principle of minimalism in container security, where every extra package increases the potential for exploitation. Unlike multi-stage builds or RUN command consolidation, this approach targets the root cause: the contents of the image itself.

Hypothesis-driven hunting starts with a hypothesis about potential adversary behavior, then searches for evidence. IoC-driven uses indicators of compromise, and TTP-driven focuses on tactics, techniques, and procedures.

A third-party security assessment is a mandatory due diligence step before entering into a contract with a new cloud service provider. This assessment evaluates the vendor's security controls, compliance posture, and risk profile against the organization's requirements, ensuring that the vendor meets minimum security standards before any data or systems are entrusted to them. Without this pre-contract assessment, the organization would be accepting unknown risks that could lead to data breaches or compliance violations.

The exhibit shows a high number of failed authentication attempts (e.g., 500+ in a short window) against a single user account, which is characteristic of a brute-force attack. This attack systematically tries multiple password combinations to gain unauthorized access, often targeting a specific username or service. The log entries indicate repeated login failures without any evidence of intercepted traffic or session manipulation.

An account lockout policy is the correct control because it directly mitigates brute-force attacks by temporarily disabling the account after a predefined number of failed login attempts (e.g., 5 failures within 15 minutes). This prevents an attacker from continuously guessing passwords from a single IP address, as the account becomes unavailable for further attempts until the lockout period expires or an administrator intervenes.

Using the 'strings' utility extracts readable ASCII/Unicode text from a binary without executing it, which is a classic static analysis technique for examining suspicious files. It reveals embedded URLs, file paths, error messages, and other indicators of compromise without any runtime risk.

The strongest approach combines a cryptographic baseline using SHA-256, remote append-only storage of that baseline to resist tampering by a local root attacker, and automated deviation alerting. MD5 is collision-prone, auditd logs lack baseline comparison and automation, and SELinux is preventive rather than detective. Only the agent with remote append-only baseline storage meets all three requirements.

To manage fourth-party risk, organizations can require their vendors to flow down security requirements to subcontractors and include right-to-audit clauses that extend to subcontractors.

These are standard IANA port assignments for common protocols. Correct matches: Port 80=HTTP, Port 443=HTTPS, Port 22=SSH, Port 21=FTP. Common confusions involve swapping port numbers for similar protocols.

A Cloud Access Security Broker (CASB) is specifically designed to discover cloud applications in use (shadow IT), enforce security policies, and provide visibility and governance over cloud service usage. It sits between users and cloud providers, applying policy via inline proxies or API integrations. This matches the question's three requirements — discovery, policy enforcement, and visibility — which are CASB's core functions.

A Hardware Security Module (HSM) is a dedicated tamper-resistant hardware appliance designed to generate, store, and manage cryptographic keys, with physical and logical protections that prevent key extraction. For TLS termination, HSMs provide FIPS 140-2/3 validated key storage and can perform cryptographic operations without exposing private keys. This directly addresses the requirement to prevent key extraction.

In the cloud shared responsibility model for IaaS, the customer is responsible for managing the guest operating system, including patch management, security updates, and configuration. The cloud provider is responsible for the hypervisor, hardware, and physical security of data centers. Therefore, guest OS patch management is the customer's responsibility.

The cloud storage bucket policy shown includes a `Principal: "*"` with `Action: "PutObject"` and no `Condition` block restricting the source IP or requiring authentication. This means any unauthenticated user on the internet can upload objects to the bucket, which is a classic data ingestion vulnerability. Option C correctly identifies this as allowing anonymous PUT operations from any source.

The EU-US Data Privacy Framework permits transfers to US importers that have self-certified and appear on the Department of Commerce's Data Privacy Framework List. Verifying that the HR platform holds active certification is the foundational requirement; without it, the framework cannot be invoked and another transfer tool would be needed.

To detect techniques like process injection and credential dumping, the EDR must monitor system behavior rather than rely solely on signatures. Behavioral monitoring allows the EDR to identify suspicious actions such as unexpected process memory modifications or access to LSASS. Other options are security controls but not detection capabilities for these specific threats.

Using try-except blocks in Python allows the script to catch and handle exceptions (e.g., missing environment variables, API call failures) gracefully without crashing. This is a fundamental secure coding practice that prevents unhandled errors from exposing sensitive information or causing unpredictable behavior in automated compliance checks.

To prevent direct access from a compromised web server to internal database servers, the engineer should implement a firewall rule that allows only specific, required traffic. This enforces least privilege and segmentation, blocking unauthorized connections. Allowing all traffic, sharing a VLAN, or relying solely on an IDS would not prevent lateral movement.

Host-based firewalls with workload identity tags and an SDN overlay with distributed policy enforcement both enable granular, identity-aware microsegmentation across hybrid cloud environments. They enforce least-privilege access, limit lateral movement, and provide east-west visibility. The other options either provide broad connectivity, address non-security concerns, or operate only at the perimeter.

Local internet breakout with integrated NGFW and SWG at the branch enables direct cloud access while still inspecting traffic for threats. This design eliminates the need to backhaul traffic to a central data center for security inspection, balancing performance and security for branch offices.

A formal communication plan with predefined templates, contact lists, and approval workflows ensures that external stakeholders receive timely, accurate, and authorized information during a breach. This directly addresses the identified gap. SIEM, tabletop exercises, and insurance do not provide the structured communication process required.

Code signing uses a digital signature (typically RSA or ECDSA) to bind the publisher's identity to the code. The primary purpose is to verify both the integrity (the code has not been tampered with) and the authenticity (the code comes from a trusted source) before deployment. This is achieved by hashing the code and signing the hash with the publisher's private key; the recipient verifies the signature using the publisher's public certificate.

The communication plan is a component of incident response that focuses on information sharing with stakeholders, including executives, legal, regulators, and customers. Its primary goal is to ensure timely, accurate, and compliant messaging. Technical containment and evidence handling are separate processes, making the stakeholder communication purpose the correct choice.

Base and exponent blinding combined with constant-time arithmetic randomize the intermediate values on which the leakage depends, so power and EM traces no longer correlate with the secret exponent. Secure boot, at-rest encryption, and rate limiting all leave the runtime arithmetic unchanged and therefore do not stop differential power analysis by an attacker with physical measurement access.

A SOC 2 Type II report provides an independent auditor's opinion on the design and operating effectiveness of controls over a period of time (typically 3-12 months). This gives a comprehensive, time-tested view of the provider's control environment, unlike point-in-time assessments.

Cross-border transfers outside an adequacy decision require a valid Chapter V mechanism. Standard Contractual Clauses impose enforceable obligations on the importer, and following Schrems II they must be accompanied by a transfer impact assessment and supplementary measures where destination laws undermine protection. Consent, codes of conduct, and improperly approved Binding Corporate Rules do not meet the combined contractual and assessment requirements described.

Just-in-time (JIT) temporary privilege elevation ensures contractors only receive the minimum necessary permissions for a limited duration, reducing the attack surface and preventing standing privileges. This aligns with the principle of least privilege and zero-trust architectures, often implemented via tools like Azure AD PIM or AWS IAM Access Analyzer with time-bound policies.

Threat modeling during the design phase is the best practice for addressing security requirements early because it proactively identifies potential threats, attack vectors, and vulnerabilities in the system architecture before any code is written. By analyzing data flow, trust boundaries, and threat agents (e.g., using STRIDE or PASTA methodologies), security controls can be integrated into the design, reducing costly rework later. This aligns with the 'shift left' principle in secure SDLC, ensuring security is not an afterthought.

If users can reach the web server on port 443 but not on 8443, the firewall is clearly permitting traffic to that host, so the most likely cause is that the web server process is not listening on port 8443. A service that is not bound to a port cannot accept connections regardless of firewall rules, which explains why one port works and the other does not.

Rate limiting per API consumer is a capability unique to API gateways because the gateway understands API keys, OAuth tokens, and consumer identities, allowing it to enforce quotas and throttling on a per-client basis. A traditional WAF operates at the network/HTTP layer and inspects traffic patterns for attacks but does not natively identify API consumers or apply per-consumer quotas. This makes per-consumer rate limiting the distinguishing capability in this comparison.

Parameterized queries (prepared statements) separate SQL logic from user data by using placeholders (e.g., `?` in MySQLi or `:param` in PDO). The database driver automatically escapes the input values, ensuring they are treated as data, not executable code. This directly prevents SQL injection because the query structure is fixed before user input is bound.

The two correct design choices are tokenization with a hardened token vault and strong TLS for data in transit. Tokenization reduces the value of stored data and can shrink the cardholder data environment, while TLS 1.2 or higher with strong ciphers protects data moving across open, public networks. Together they address both the storage and transmission requirements in the scenario without relying on a third party's compliance to cover the organization's own obligations.

The described need is centralized ingestion, normalization, correlation, retention, and custom detection across many log sources, which is the core purpose of a SIEM. Vulnerability scanners, network performance monitors, and configuration databases each serve different operational functions and none provides the combined correlation and retention capability required.

Memory capture is the correct first step because running processes, active network connections, and encryption keys exist only in volatile memory (RAM) and are lost on shutdown or reboot. Tools like DumpIt or winpmem preserve this state, including the process-to-connection mapping needed to identify which process initiated the encrypted channels. The order of volatility in digital forensics dictates that RAM be collected before disk or logs, since it is the most transient evidence.

SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing the program, making it the correct choice for finding vulnerabilities before compilation. It integrates into the IDE or CI pipeline and can flag issues like hardcoded secrets, injection flaws, and insecure API usage at the code level. Because it works on the code itself, it is the only option that fits the 'before it is compiled' requirement.

Application-level encryption with deterministic encryption for the searchable field ensures that data is encrypted before storage and remains unreadable if the database is compromised. Deterministic encryption allows equality searches on that field without decrypting the entire dataset. Other methods either leave data readable in memory, prevent searching, or introduce a separate high-value target.

To detect brute-force attacks based on failed login attempts, the SIEM needs logs that record authentication failures. Application authentication logs provide this information with sufficient detail (source IP, timestamp, outcome). Other sources either lack authentication context or are derived alerts, making them less suitable for building a precise correlation rule.

IoT devices with limited processing power cannot efficiently perform asymmetric operations, so pre-provisioning keys from a cloud-based HSM during manufacturing ensures secure key generation and storage without burdening the device. The HSM provides tamper-resistant key generation and lifecycle management, and the keys are injected into the device's secure storage (e.g., eFuse or secure element) before deployment, eliminating the need for on-device asymmetric cryptography.

Running a container as a non-root user with dropped capabilities is the most secure approach because it follows the principle of least privilege. By default, containers run as root, which grants unnecessary kernel capabilities that could be exploited for privilege escalation. Setting a non-root user and using `--cap-drop=ALL` with selective `--cap-add` ensures the application retains only required permissions, reducing the attack surface without breaking functionality.

A key management system (KMS) with automatic key rotation ensures that encryption keys are securely stored, rotated, and managed, which is essential for protecting data at rest. Without proper key management, encryption can be rendered ineffective if keys are compromised or stale. This control directly supports the confidentiality of PII stored in the cloud.

Isolating VNFs is the most important security consideration because VNFs share the same hypervisor and commodity hardware, so a compromise in one VNF could allow an attacker to move laterally to other VNFs or the underlying host. Without proper isolation (e.g., using VLANs, VXLANs, or micro-segmentation), the entire multi-tenant environment is at risk, undermining the high-availability design.

Input sanitization and parameterized queries prevent injection attacks when the script processes user-supplied data, such as image names or tags. In the context of container scanning, unsanitized input could lead to command injection or SQL injection if the script queries a vulnerability database. This aligns with secure coding practices for automation scripts, ensuring that the script does not inadvertently execute malicious commands or expose sensitive data.

Credential dumping via LSASS (e.g., Mimikatz reading lsass.exe memory) is classified under the Credential Access tactic in MITRE ATT&CK, specifically technique T1003 OS Credential Dumping. The tactic describes the adversary's goal of stealing account names and passwords to use for lateral movement and privilege escalation. LSASS holds cached credentials and Kerberos tickets, making it a prime target for this tactic.

Time-based token claims are only meaningful when the issuer and validator share a common time reference. Synchronizing both systems to the same authenticated NTP sources eliminates the skew that causes valid tokens to be judged expired or not yet valid, fixing the rejections without loosening token lifetimes or removing expiry enforcement.

Fileless malware executes in memory using legitimate system tools, so detecting it requires monitoring of scripting and management interfaces like PowerShell and WMI, as well as analyzing in-memory process behavior and API calls. These capabilities allow EDR to identify malicious activity without relying on file signatures. The other options are either preventive measures or ineffective against fileless threats.

Federated identity management using SAML enables users to authenticate via external identity providers (e.g., social media platforms) while the corporate system retains control over access policies through the exchange of SAML assertions. This architecture decouples authentication from authorization, allowing the corporate service provider to enforce its own rules based on trusted identity claims.

TLS 1.3 mandates the use of ephemeral Diffie-Hellman key exchange (DHE or ECDHE) for all handshakes, which provides forward secrecy by generating a unique session key for each session that cannot be derived from the server's long-term private key. This ensures that even if the server's private key is compromised later, past session keys remain secure and cannot be reused.

Ansible is the most appropriate choice because it is agentless (no agent installation required) and uses push-based communication over SSH to enforce configurations. It uses YAML-based playbooks to define desired states, making it ideal for automating consistent configuration across multiple Linux servers with minimal overhead.

SAML assertions carry the authentication and authorization claims that the service provider (SP) trusts. Without a digital signature, there is no cryptographic integrity protection, so an attacker who can intercept or manipulate the SAML response (e.g., via a man-in-the-middle or by tampering with the POST binding) can alter the assertion contents—such as changing the user identity or elevating privileges—and the SP has no way to detect the modification. This is the most significant risk because it directly undermines the trust model of SSO.

Hypervisor-based introspection enforces policy outside the guest OS, so even root-level malware cannot disable the control. It provides tamper-resistant visibility and can prevent execution of unauthorized binaries, meeting the agentless and root-resistant requirements. Agent-based tools and log correlation are either bypassable or detective only.

VLANs logically segment the flat network into separate broadcast domains, and ACLs applied at the Layer 3 boundary (e.g., on the switch virtual interface or router) enforce least-privilege access by permitting only necessary traffic flows between segments. This approach meets HIPAA's technical safeguard requirements (45 CFR § 164.312(a)(1)) for access control and integrity without the operational overhead of physical separation or the security risk of a single DMZ.

Continuous compliance monitoring requires automated, real-time checks against policies and regulations. Automated auditing tools can continuously assess controls and generate alerts.

GDPR grants data subjects several rights, including the right to erasure (right to be forgotten), right to data portability, and right to object to processing. The right to rectification is also a right but is not listed as an option. The right to data monetization and right to unlimited storage are not GDPR rights.

Reviewing logs allows the analyst to understand the attack patterns and identify false positives. Creating custom rules tailors the WAF to the specific application, reducing false positives. Switching to blocking mode after tuning ensures that legitimate traffic is not disrupted while attacks are blocked.

The primary benefit of using a FedRAMP Authorized CSP is that the CSP has already undergone a rigorous third-party assessment and continuous monitoring process. This allows the agency to reuse the existing authorization (via the 'JAB' or agency Provisional Authorization), significantly reducing the time, cost, and effort required for the agency's own assessment and authorization (ATO) process. It does not eliminate the agency's responsibility for risk management or compliance with FedRAMP Moderate controls, but it leverages the CSP's proven security posture.

Static application security testing (SAST) is a white-box testing method that analyzes source code, bytecode, or binary code for security vulnerabilities without executing the program. It is an essential component of a secure software development lifecycle (SSDLC) because it enables early detection of flaws such as SQL injection, buffer overflows, and cross-site scripting during the coding and build phases, reducing remediation cost and risk.

The HIPAA Security Rule distinguishes between required and addressable implementation specifications. Unique user identification is explicitly required for access control, ensuring accountability and traceability. Addressable specifications like emergency access, automatic logoff, and encryption require a risk-based decision but are not mandatory in all cases.