CAS-005: CompTIA SecurityX

If the agent was not running on a Windows 10/11 device, the code would return NON_COMPLIANT, which should block access. That would not explain why the employee was allowed on the network. Also, “false positive” would mean the system flagged a compliant device as noncompliant, but the scenario is the opposite: a prohibited device gained access.

A “true positive” would mean the system correctly detected noncompliance and blocked or flagged it. But the employee was allowed onto the network. Additionally, the code checks only agentRunning, not whether the agent is installed; if the agent is missing, agentRunning would be false and the device would be NON_COMPLIANT for osVersion >= 10, again not matching the outcome.

If the OS version is higher than 11 (still >= 10) and the agent is running, the code returns COMPLIANT. That would be a correct allow decision (a true negative in the sense of “no policy violation detected”), not an explanation for a personally owned device being allowed due to a logic flaw. The scenario points to an unintended allow, not a proper compliance pass.

A honeypot is a decoy system/service intended to be probed or compromised so defenders can detect and study attacker behavior. While it can improve detection if attackers interact with it, it does not directly ensure detection when adversaries access real sensitive data and systems. It is better for adversary characterization and research than for guaranteeing alerts on sensitive-resource access paths.

Attacker simulators (often referred to as breach and attack simulation tools) help validate security controls by emulating TTPs and measuring coverage. They are useful for continuous testing and purple teaming, but they are not a direct mitigation for the specific finding of “attackers accessed sensitive information without detection.” The organization needs detection tripwires and monitoring improvements, not just more simulation.

A honeynet is a network of honeypots designed to lure attackers into a controlled environment for observation. Like a honeypot, it can provide intelligence and some detection value, but it may not be touched by an adversary who is successfully operating within production systems. It is more complex to deploy and maintain and is less directly tied to detecting access to actual sensitive documents/accounts.

Client-side processing is not a reliable security control because the attacker controls the browser and can modify requests (e.g., via proxy tools). Even if JavaScript validates ItemID, an attacker can send a malicious ItemID directly to the server. Server-side protections are required for injection flaws, so this does not address the root cause.

Data normalization improves database structure and reduces redundancy (e.g., splitting data into related tables). While important for integrity and performance, it does not prevent an attacker from injecting SQL through concatenated queries. Normalization addresses schema design, not secure query construction or input handling.

Escape character blocking (or escaping) is a weak and error-prone approach. Attackers can bypass filters using alternate encodings, DB-specific syntax, comment styles, or unexpected character sets. Escaping may be part of defense-in-depth in some contexts, but it is not the preferred control compared to parameterized queries.

URL encoding only changes how characters are represented in transit (e.g., spaces to %20). It does not neutralize SQL metacharacters once decoded by the server framework, and it is not intended as an injection defense. Attackers can still deliver payloads that decode into malicious SQL fragments.

Changing kubernetes.core.k8s to kubernetes.core.k8s_service is not a security fix. The generic k8s module is valid for managing Kubernetes objects from YAML definitions, including Service resources, so the issue is not the module name itself. This change would be a functional refactor at most and would not address insecure exposure, authentication, or control-plane hardening. Security questions should focus on reducing attack surface, not swapping equivalent automation modules.

Changing the hostname from COMPTIA001 to localhost would be operationally incorrect and would not remediate the security issue. Kubernetes nodes and automation systems rely on stable, unique host identity for certificates, networking, and management. Replacing a real hostname with localhost can break resolution and create ambiguity rather than improve security. The problem is not the hostname value but the insecure configuration choices around orchestration access.

Changing state: present to state: absent would simply remove the Kubernetes object instead of fixing the security weakness. Deleting a Service definition is not a targeted remediation for insecure control-plane or automation configuration. Security hardening should address how access is exposed and controlled, not arbitrarily remove resources that may be required for operations. This option confuses resource lifecycle management with actual security remediation.

Changing insecure-bind-address from localhost to COMPTIA001 would make an insecure endpoint more accessible from the network, which is the opposite of hardening. For any setting labeled insecure, best practice is to disable it entirely or keep it tightly restricted, not expose it to a broader interface. Binding to localhost limits exposure to the local machine, whereas binding to the host identity can allow remote access depending on name resolution and interface mapping. This option increases attack surface and is therefore not a valid security correction.

Incorrect. The CRM company’s customer can mandate requirements contractually and may audit or request evidence, but it does not operate the CRM company’s infrastructure or platform. The customer’s role is to define expectations and verify via governance mechanisms (e.g., due diligence, audits), not to implement configuration management, patching, or lifecycle management within the vendor’s environment.

Incorrect. In PaaS, the CSP is responsible for many underlying components (physical security, hypervisor, core platform services, and often platform patching). However, the CRM company remains accountable to its customer for compliance. The CSP may help satisfy requirements via certifications and SLAs, but it is not the party responsible for ensuring the CRM customer’s regulatory obligations are met overall.

Incorrect. Regulatory bodies define requirements, publish standards, and may enforce compliance through audits, penalties, or licensing actions. They do not manage a specific company’s configurations, patching schedules, or lifecycle processes. The regulated entity (here, the CRM company providing the SaaS) must implement and demonstrate compliance, including managing third-party providers like the CSP.

Testing status is not the first priority during an active disaster. Even if plans were untested, the organization must still execute DR/BC actions immediately to restore service and protect people and assets. Also, focusing on whether IR plans were tested emphasizes incident response rather than disaster recovery; a data center fire is primarily a continuity/availability crisis requiring DR activation now, not plan validation.

Verifying hot/warm/mobile sites and providing leadership updates are important, but this is not the first action. During a fire, the organization should formally activate the DR/BC process and command structure, then execute failover and recovery steps. “Ensure sites are available” is also unrealistic at this moment—availability should have been established during DR planning, not discovered during the crisis.

Initiating Company A’s processes and performing a BIA are planning and governance activities, not immediate disaster response. A BIA is performed ahead of time to define criticality, RTO/RPO, and prioritization; doing it during an active outage delays recovery. Also, forcing Company A’s procedures onto Company B’s environment during a crisis increases risk and confusion, especially when Company B’s data center is the one affected.

Incorrect for the stated issue. Increasing length to 12 generally improves entropy and resistance to brute force, but it does not prevent an employee from reusing a password that is already known to attackers. A longer password can still be compromised if it appears in breach corpuses; reuse controls are the primary need here.

Incorrect for the stated issue. Adding case sensitivity (requiring upper/lower) increases complexity and may marginally improve guessing resistance, but it does not stop reuse of a previously compromised password. Attackers commonly try case variants, and users often make predictable capitalization changes; this does not address reuse directly.

Incorrect. Reducing maximum age to 30 days forces more frequent changes. Modern guidance warns frequent forced changes can lead to weaker, more predictable passwords and reuse patterns (e.g., incrementing numbers). It still doesn’t prevent selecting a password from a compromised list, and it doesn’t stop history bypass if minimum age remains 0.

Incorrect and harmful. Removing complexity requirements would likely reduce password strength and increase risk. It also does nothing to prevent reuse of compromised passwords. Even though modern standards emphasize screening against compromised lists over arbitrary complexity rules, removing complexity without adding screening is a net negative.

Incorrect. Increasing maximum age to 120 days reduces how often passwords change, which can be beneficial for usability, but it does not address reuse of compromised passwords. If users are already reusing known-compromised passwords, extending the change interval could prolong exposure rather than mitigate it.

False positive requires that a security control generated an alert, but the activity was benign. The stem explicitly states the event did not create an alert, so there is no positive detection to evaluate. Additionally, the USB hardware ID is confirmed not on the allow list, which is a policy violation and not something you would typically dismiss as a false positive.

True positive would mean an alert fired and correctly indicated malicious or policy-violating activity. In this scenario, there was no alert at all, so it cannot be a true positive. The analyst’s later discovery of an unauthorized USB indicates a detection/control gap rather than a successful detection event.

True negative means no alert occurred because there was no malicious or unauthorized activity. Here, the analyst confirmed the USB hardware ID is not on the allow list, indicating unauthorized use. Therefore, the absence of an alert is not a correct outcome; it suggests missed detection rather than a properly quiet system.

Body encryption is not provided by a digital signature alone. Email encryption (confidentiality) requires encrypting the message content using the recipient’s public key (S/MIME or PGP encryption). Signing provides integrity and authenticity, but the message body can still be readable in plaintext unless encryption is separately applied. Many secure email solutions support “sign and encrypt,” but they are distinct functions.

Code signing refers to digitally signing software (executables, scripts, drivers, macros) to prove publisher identity and integrity of code. While it uses similar cryptographic primitives (certificates and signatures), it is not the security feature provided by an email signature. Email signing is about the message content and sender identity, not validating software artifacts.

Chain of custody is a procedural and documentation concept used in forensics and legal contexts to prove evidence handling integrity over time (who had it, when, and how it was stored). A digital signature can help preserve integrity of a message, but it does not establish end-to-end chain-of-custody records or handling procedures by itself.

Non-repudiation is a security property where a party cannot credibly deny an action (often achieved via digital signatures, logging, and timestamps). While code signing can support non-repudiation, the question asks how users confirm software is legitimate during installation. The practical mechanism is code signing, not the abstract concept of non-repudiation.

Key escrow is the practice of storing encryption keys with a trusted third party or internal escrow service to enable recovery (e.g., when users leave or keys are lost). It is used for data availability and compliance, not for proving that an installer is authentic. Escrow does not provide end users with a verification mechanism for software legitimacy.

Private keys are required to create digital signatures, but simply having private keys does not allow users to verify legitimacy. Verification depends on the signed artifact, a corresponding public key, and a trusted certificate chain (PKI) plus revocation checking. The correct control is the process of code signing and certificate management, not the key alone.

Incorrect. Automatic updates improve patch compliance, but the scenario already involves monthly patching and the issue is a newly migrated application with a reported overflow and improper exposure. Auto-updates do not directly address the immediate requirement to restrict access to internal users, nor do they guarantee a fix for an application-level overflow without a vendor/app patch.

Incorrect. Enabling external traffic contradicts the security policy requiring internal-only access and increases risk because the application is already publicly exposed. In cloud environments, opening security groups to the internet (0.0.0.0/0) is a common misconfiguration that expands the attack surface and makes exploitation of vulnerabilities like buffer overflows more likely.

Incorrect. DLP focuses on detecting/preventing sensitive data exfiltration (e.g., PII, PCI) after access to data paths exists. It does not mitigate the root issue of a buffer overflow vulnerability or the misconfiguration of public exposure. DLP can be valuable as a detective/compensating control, but it is not the best answer for immediate mitigation here.

Incorrect. Nightly vulnerability scans are a detective control that can help identify exposures and missing patches, but they do not prevent exploitation of a known buffer overflow or enforce internal-only access. Scanning is useful for ongoing assurance and compliance, yet the question asks what to implement to mitigate the reported issues, which requires preventive controls.

Delivery receipts are not an inherent capability of PKI. They are generated by messaging systems, mail servers, or application protocols to indicate delivery or read status. PKI may be used to sign such receipts so they cannot be altered without detection, but PKI itself does not create or manage receipt workflows. The presence of certificates does not equate to transport acknowledgment functionality.

Attestation is not a general message security capability provided by PKI. It usually refers to proving the integrity or measured state of a device, platform, or workload, often using TPMs or specialized attestation services. Certificates can participate in attestation architectures, but PKI alone does not make a message an attestation artifact. In the context of message capabilities, attestation is outside the standard PKI services being tested here.

Digital rights management (DRM) enforces usage controls (view, print, copy, forward) and can apply encryption tied to identities. While DRM can be triggered after a document is classified, it does not help the DLP system discover or correctly label unlabeled documents containing cardholder data. DRM is a protection/enforcement mechanism, not a primary content detection method for PCI patterns.

Network traffic decryption enables inspection of encrypted traffic (TLS interception) so DLP can analyze data in transit. However, the scenario focuses on documents in a cloud document repository (data at rest) and the need to label them correctly in the future. Decrypting network traffic may help with uploads/downloads, but it does not provide the core content-identification logic needed to detect cardholder data within documents.

Watermarking adds visible or invisible markings (e.g., “Confidential”, user ID, timestamp) to deter leakage and support attribution. It is typically an output control applied after a document is already classified or labeled. Watermarking does not help the DLP system detect cardholder information inside unlabeled documents, so it won’t solve the root problem of correctly labeling documents based on their content.

OCSP (Online Certificate Status Protocol) is a revocation-checking mechanism that lets a client query whether a certificate is still valid or has been revoked. It is useful for certificate status validation and can be optimized with OCSP stapling, but it does not allow one certificate to represent multiple domain names. Therefore, it does nothing to reduce the number of certificates needed for many hosted sites. Its purpose is certificate status checking, not certificate name consolidation.

A CRL (Certificate Revocation List) is a published list of certificates that a CA has revoked before their expiration dates. Clients or systems can consult the CRL to determine whether a certificate should no longer be trusted, but this is unrelated to how many domain names a certificate can cover. CRLs may affect revocation operations and trust decisions, but they do not help minimize certificate count. The question is about multi-domain coverage, which CRLs do not provide.

Incorrect. Digital signatures do not provide confidentiality because they do not encrypt the content; they only sign a hash to prove integrity and authenticity. If confidentiality is required, the code (or the distribution channel) must be encrypted separately (e.g., TLS for transport, encrypted containers, or application-level encryption).

Incorrect. While some DRM systems may use signatures as part of a broader licensing and trust model, DRM integration is not the primary reason organizations prefer digitally signed code. The core security benefits are authenticity (origin assurance) and integrity verification, independent of any DRM or licensing mechanism.

Incorrect. Code signing does not verify the recipient’s identity; it verifies the signer/publisher to the recipient. Recipient identity verification is typically handled through client authentication mechanisms (e.g., mutual TLS, user certificates, Kerberos, or strong authentication) rather than code signing.

Incorrect. A valid signature does not ensure the code is free of malware; it only indicates who signed it and that it has not changed since signing. Malware can be signed using stolen keys, mis-issued certificates, or even legitimately by malicious actors. Organizations still need malware scanning, reputation services, sandboxing, and runtime protections.

Exploitation frameworks (e.g., Metasploit) are primarily used to validate and operationalize known vulnerabilities, chain exploits, and demonstrate impact. They are not designed to systematically discover new vulnerable code paths in custom components. They can help confirm the bug bounty RCE and test compensating controls, but they are less effective than fuzzing for broad, proactive discovery of additional variants.

Software composition analysis (SCA) identifies known vulnerabilities in third-party libraries and dependencies by comparing versions to CVE databases and advisories. The scenario specifies a custom application component, so SCA may not reveal the root cause or additional vulnerable paths in the custom code. SCA is still a best practice, but it does not directly address discovering new, unknown vulnerabilities in bespoke logic.

Reverse engineering can reveal vulnerable code paths by analyzing binaries, control flow, and unsafe functions, and it can be useful when source code is unavailable. However, it is time-intensive and not as scalable for proactively uncovering many input-driven edge cases across an application. For systematically finding additional exploit paths similar to an RCE report, fuzzing is typically faster and more comprehensive.

An HTTP intercepting proxy (e.g., Burp Suite) is useful for manual testing of web applications, manipulating requests, and identifying issues like injection, auth flaws, and logic bugs. However, it is generally less effective for systematically uncovering deep component-level vulnerabilities and edge-case parsing issues that lead to RCE. Proxies support DAST-style exploration, but fuzzing is better for broad path discovery in a specific component.

Salted hashing strengthens password storage by preventing rainbow-table attacks and ensuring identical passwords hash differently. However, the vulnerability here is not weak hashing; it is that the code unconditionally jumps to the allow path before checking credentials. Even with salted hashing, the bypass remains because the verification step is skipped.

Input validation on USERID and PASS can prevent malformed input, injection, and unexpected parsing behavior. But the shown flaw is a direct logic/control-flow error: `JUMP TO :ALLOWUSER;` executes before validation. Validating inputs does not stop the unconditional jump from granting access.

TOCTOU remediation applies when a resource is checked and later used, and an attacker can change it between the check and the use. Here, the issue is not a race between checking and setting ACLs; it is that ACLs are set without any successful authentication due to the unconditional jump.

Encrypting the database connection (e.g., TLS) protects credentials and queries in transit and reduces eavesdropping/MITM risk. It does not fix the application logic that grants access without verifying credentials. The authentication bypass would still occur even with perfectly encrypted DB communications.

The CA is the component that ultimately signs and issues certificates, and it can reject requests based on policy or workflow outcomes. However, the specific task of validating the subject's identity is classically associated with the Registration Authority or an RA-like approval process. In PKI role separation, the RA performs identity proofing while the CA performs certificate generation and signing. Therefore, the denial would have occurred at the identity-validation step before the CA issued the certificate.

An IdP provides authentication and identity assertions for access management systems such as SAML, OAuth, or OpenID Connect. Although an IdP may authenticate a user accessing an enrollment portal, it is not the standard PKI component that performs certificate subject validation and approval. PKI enrollment decisions are governed by certificate policy and RA/CA workflow, not by the IdP itself. Therefore, an IdP is not the step where certificate issuance would be denied for failed subject identity validation.

Incorrect. SSH keys are used for SSH authentication and key exchange, not for S/MIME or PKI-based email encryption. Email encryption errors are typically related to X.509 certificates, trust chains, revocation status, or identity binding to an email address. Mixing SSH key validity dates with email encryption is a distractor and does not fit the described symptoms.

Unlikely. An expired certificate could prevent encryption, but the scenario points to a recipient-specific security error while the recipient can still send encrypted emails to internal users. Expiration would usually produce a clear “certificate expired/not valid” message and would also commonly impact the recipient’s ability to sign/encrypt depending on their client behavior. The more classic single-recipient issue is identity mismatch.

Unlikely. Incorrect OCSP/CRL configuration on the internal company’s email servers (or clients) would typically affect certificate validation broadly—multiple external recipients or all encrypted messages—rather than only one specific external recipient. Also, unencrypted email working does not help isolate revocation settings, and the problem being isolated to one recipient suggests a certificate/identity issue for that user.