Select Two (Multi-Select) Questions

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions to roles rather than individual users, simplifying administration. However, it does not natively support dynamic decisions based on environmental conditions like time of day or resource attributes. While RBAC can be extended with constraints, it lacks the fine-grained, attribute-driven policy evaluation required here. The scenario demands real-time contextual evaluation, which RBAC alone does not provide.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access based on security labels and clearances, typically used in military or high-security environments. It is rigid and centrally controlled, but it does not easily accommodate dynamic environmental attributes like time of day. While MAC provides strong confidentiality, it lacks the flexibility and fine-grained, context-based policy evaluation needed for the trading floor scenario.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to set permissions at their discretion. It is not centralized and does not support dynamic, attribute-based decisions. In a trading floor, DAC would lead to inconsistent policies and potential security gaps. It cannot enforce environmental conditions or provide the centralized auditing and policy management required. Thus, it does not meet the stated requirements.

Increase the model's temperature setting to make responses less predictable.

Why it fails: Temperature controls randomness in token selection; higher values make output more varied, not safer. Raising it could increase the chance of unpredictable or hallucinated content and does nothing to prevent sensitive data from being included. It is unrelated to data exposure risk and may worsen reliability in a customer support context.

Store the model weights in a versioned object storage bucket with access logging enabled.

Why it fails: Versioning and logging on model weights protect the integrity and auditability of the model artifact itself. They do not govern what data the model retrieves or returns at inference time. The risk described is runtime data exposure through responses, so this control addresses a different asset and does not mitigate the stated risk.

Fine-tune the model on a dataset of historical customer interactions.

Why it fails: Fine-tuning changes the model's behavior and style but can actually increase risk if the training data contains sensitive information that the model memorizes and later emits. It does not provide runtime control over which live data enters responses. This option fails to address the exposure risk and may introduce new leakage paths.

Enabling the sticky bit on /tmp

Why it fails: The sticky bit on the /tmp directory is a filesystem-level security control that prevents users from deleting files owned by others. While it is a necessary hardening step for multi-user environments, it provides no protection against physical access, bootloader manipulation, or unauthorized hardware-level changes during the system startup sequence.

Disabling the IPv6 network stack

Why it fails: Disabling IPv6 is a network hardening step that can reduce the remote attack surface and prevent certain types of tunneling or discovery attacks. However, it does not address physical security concerns or protect the boot process from being hijacked by an attacker who has direct access to the console.

Get-Process -IncludeUserName

Why it fails: While this command identifies running processes and their owners, it does not reveal the configuration of local groups or persistence mechanisms. It is useful for identifying rogue binaries but falls short of the specific requirement to audit groups and tasks.

Get-Service | Where-Object {$_.Status -eq 'Running'}

Why it fails: This command audits running services, which is useful for identifying unexpected background activity. However, it does not provide information about user account membership or persistence via tasks, which are the primary focus of the requested audit requirements.

Get-WinEvent -LogName Security

Why it fails: This command accesses the security event log. While useful for finding historical data, it does not directly query the static configuration of group memberships or scheduled tasks, which are better served by the specific cmdlets designed for system management and configuration auditing.

Grant the build service account passwordless sudo access to all commands to simplify automation.

Why it fails: Passwordless sudo to all commands means a compromise of the build service account yields full root control immediately. This removes privilege boundaries and maximizes the impact of an intrusion instead of containing it. It is the opposite of least privilege and undermines the defense in depth strategy the team is pursuing.

Disable SELinux on the build server to avoid build failures caused by mandatory access control denials.

Why it fails: Disabling SELinux removes a mandatory access control layer that confines processes to defined domains. Doing so makes a compromised build process more powerful, not less, because it can access files and sockets outside its intended role. This directly weakens defense in depth and contradicts the goal of reducing the impact of compromise.

Configuring the SIEM to drop logs that do not match the expected format to reduce noise.

Why it fails: Dropping logs that do not match the expected format can lead to loss of critical security events. While it may reduce noise, it also risks discarding logs that could contain indicators of compromise or that require investigation. A better approach is to parse and normalize logs, and if parsing fails, to route them for review. Dropping logs is not an essential task for normalization and enrichment; it can harm visibility.

Storing all raw logs indefinitely in their original format without normalization.

Why it fails: Storing raw logs indefinitely is costly and does not support correlation. Without normalization, the SIEM cannot easily correlate events across sources because field names and formats vary. While retaining raw logs for a period can be useful for forensic deep dives, it is not an essential task for normalization and enrichment. The goal is to make data usable for correlation, which requires normalization and enrichment, not just raw storage.

Increasing the SIEM's indexing speed by disabling timestamp recognition on all logs.

Why it fails: Disabling timestamp recognition would break event ordering and correlation, as the SIEM relies on timestamps to sequence events and correlate across sources. It might speed up indexing slightly, but at the cost of accuracy and functionality. Timestamp recognition is fundamental for log management and SIEM operations. This task is not essential for normalization and enrichment; it would undermine them.

Assign the 'Log on as a service' right to all domain users to ensure that any service can start without interruption.

Why it fails: Granting the 'Log on as a service' right to all domain users is a severe security misconfiguration. It would allow any user account to be used to run a service, increasing the risk of privilege escalation and lateral movement. Service accounts should be specifically designated and granted this right only when necessary. This option is incorrect because it broadens the attack surface and violates least privilege.

Configure all services to run under the Local System account to simplify management and ensure they have the necessary privileges.

Why it fails: Running services as Local System grants them extensive privileges on the local machine, which violates the principle of least privilege. If an attacker compromises such a service, they gain full control of the system. Instead, services should run under dedicated accounts with minimal rights. This option is incorrect because it increases the attack surface and does not protect against credential theft or privilege escalation; it actually exacerbates the risk.

Enable the 'Store passwords using reversible encryption' policy for all service accounts to allow easy recovery of passwords if needed.

Why it fails: Storing passwords with reversible encryption is a security risk because it allows passwords to be decrypted and read by anyone with access to the system. This policy is intended for legacy applications and should be avoided. Enabling it for service accounts would make credential theft easier, not harder. Therefore, this option is incorrect and would weaken security rather than harden it.

spctl --assess --verbose

Why it fails: The spctl --assess --verbose command evaluates the Gatekeeper assessment of an application or bundle. It does not list kernel extensions or provide information about loaded kexts. This command is used to check if an app is allowed to run, not to inspect kernel-level components. Thus, it is irrelevant for detecting malicious kernel extensions.

systemextensionsctl list

Why it fails: The systemextensionsctl list command shows installed system extensions and their approval status. System extensions are a newer mechanism that runs in user space, not kernel space. While they can be malicious, they are not kernel extensions. This command does not list kernel extensions, so it is not the best tool for checking for malicious kexts.

csrutil status

Why it fails: The csrutil status command checks whether System Integrity Protection is enabled. While SIP helps prevent unauthorized kernel extensions, this command only reports the SIP status. It does not list loaded kernel extensions or identify malicious ones. Therefore, it is not directly useful for detecting malicious kexts.

Analyzing the memory dump for malware signatures

Why it fails: Analyzing a memory dump is an Identification or investigation activity. Eradication is the process of removing the threat from the environment. Once the threat is identified, the focus shifts to neutralizing it, not continuing the analysis, which would have happened in the earlier identification and forensic investigation phases.

Drafting an incident report for executive leadership

Why it fails: Drafting an incident report is a task for the post-incident activity or documentation phase. While reporting is important for stakeholders, it does not contribute to the actual removal of the adversary's access or the restoration of the secure state of the systems, which is the sole focus of eradication.

Unmanaged Layer-1 hubs placed directly outside the perimeter firewall to mirror raw traffic into analysis buffers.

Why it fails: Unmanaged hubs cannot segment or filter traffic and introduce a single point of failure; they mirror raw frames rather than protect services. It is tempting because passive taps feed intrusion-detection analysis, but the design needs inline DDoS scrubbing, a WAF and stateful inspection instead.

Disabling all stateful inspection engines on perimeter firewalls to maximize throughput for inbound HTTPS sessions.

Why it fails: Disabling stateful inspection removes the control that filters malformed and exploit-bearing packets, directly undermining web application protection. It is tempting because stateful processing consumes resources during volumetric floods, but the design still requires inspection alongside DDoS scrubbing and a WAF.

It eliminates the need for host-based firewalls on individual servers.

Why it fails: Segmentation is a network-level control and does not remove the need for host-based protection. Defense in depth requires layers at both the network and host levels. Relying solely on network-level segmentation ignores the possibility of threats originating from within the network or bypassing the perimeter firewall.

It automatically encrypts all data in transit between segments.

Why it fails: Network segmentation controls traffic flow and access; it does not provide encryption for data in transit. Encryption requires the implementation of protocols like IPsec, TLS, or SSH. Segmentation and encryption are distinct layers of defense that must be implemented separately to provide true defense in depth.

To eliminate the need for regular security patching.

Why it fails: Defense in depth does not negate the necessity of vulnerability management or patching. Patching is a critical layer of defense that addresses the root cause of exploits. Relying on other layers to compensate for unpatched software is a flawed strategy that leaves the organization unnecessarily vulnerable to attacks.

To replace the requirement for user security awareness training.

Why it fails: Human users are often the weakest link in the security chain. No amount of technical layering can fully protect against social engineering if users are not trained. Defense in depth is intended to complement, not replace, the human element of an organization's overall cybersecurity and risk posture.

To centralize all logs into a single storage location.

Why it fails: While centralized logging is a best practice for visibility, it is a management and monitoring capability, not a primary objective of defense in depth. Defense in depth focuses on the layered application of security controls to stop attackers, whereas logging is primarily a detective and forensic capability.

Disabling all network connections to the endpoint.

Why it fails: Disabling all network connections makes the device non-functional in a modern business environment. While it stops ransomware from communicating, it is not a viable security strategy. Effective defense-in-depth relies on allowing necessary business traffic while inspecting and controlling that traffic, not simply severing all connectivity to the network.

Enabling guest access for easier file sharing across departments.

Why it fails: Enabling guest access increases the attack surface and allows unauthorized users to access resources. This is the opposite of good security hygiene, as it provides a path for ransomware to traverse the network more easily. Security controls should focus on restricting access, not facilitating open access across departments.

Manual execution of local PowerShell scripts by end-users with standard privileges

Why it fails: Standard users lack the necessary local administrative privileges to modify core Windows Update policy registry keys or execution parameters. Relying on manual user execution is insecure, unreliable, and undermines centralized enterprise security governance.

Direct packet injection via public Wi-Fi access points during routine employee travel

Why it fails: Injecting packets via public Wi-Fi access points is an attack technique, not a policy deployment channel, and provides no authenticated, auditable configuration path to clients. Packet injection belongs in penetration testing or traffic-capture scenarios, not update management.

Editing local security policy templates manually on every individual client workstation

Why it fails: Local security policy templates are per-device and unmanaged, so they cannot deliver cloud-linked Windows Update for Business settings consistently across a multi-site estate. Local policy editing is the right approach only for standalone machines outside any management authority.

Centralized distribution of symmetric keys.

Why it fails: Symmetric key distribution is handled by protocols like Kerberos or Key Management Systems, not PKI. PKI specifically focuses on the management of asymmetric key pairs and the verification of identities through X.509 certificates rather than the direct transmission of secret symmetric keys between various network clients.

Hardware-level encryption for disk storage.

Why it fails: Disk encryption is typically handled by Full Disk Encryption (FDE) tools or platform-specific features like BitLocker or dm-crypt. While PKI might assist in managing the keys for such systems, it is not the primary function of the infrastructure itself, which is designed for identity and trust management.

Real-time traffic flow monitoring and alerting.

Why it fails: Traffic monitoring and alerting are the responsibilities of Intrusion Detection and Prevention Systems (IDPS) or Network Monitoring Tools. PKI does not provide analysis of packet contents or network behavior, as its operational focus remains strictly on the management of public key assets and digital identity authentication.

Enforcing a password complexity policy for all database accounts

Why it fails: Password complexity reduces the risk of brute-force or guessing attacks, but the breach involved stolen credentials, so complexity would not have prevented it. It is a preventive control that does not address detection of future similar attacks. The scenario specifically calls for improving detection, not prevention.

Implementing full-disk encryption on the database server

Why it fails: Full-disk encryption protects data at rest if the disk is physically stolen, but it does not detect an attacker using valid credentials to access the database over the network. It is a preventive confidentiality control, not a detective one. The breach involved remote access, so encryption would not have helped detect or prevent it.

Configuring a next-generation firewall to block outbound traffic from the database server

Why it fails: Blocking outbound traffic can limit data exfiltration, but it does not provide detection of credential misuse or database activity. It is a preventive network control that may be useful but does not fill the stated logging and monitoring gaps. The investigation showed no host-based logging and no database monitoring, so detection controls are needed.

The file is encrypted with a stream cipher using a nonce that is reused across all files for simplicity.

Why it fails: Reusing a nonce with the same stream cipher key causes the keystream to repeat, so XORing two ciphertexts cancels the keystream and leaks plaintext relationships. It also does nothing to detect ciphertext modification, so it fails both the confidentiality and integrity expectations of the scenario.

A static initialization vector equal to the file creation timestamp is used for every encryption operation to ensure reproducibility.

Why it fails: A predictable, reused initialization vector in modes like CBC causes identical plaintext blocks to produce identical ciphertext and enables chosen-plaintext attacks. It also provides no integrity protection, so ciphertext modification would go undetected, failing the tamper-detection requirement.

The encryption key is embedded in the file header obfuscated with Base64 so the tool can decrypt without prompting the user.

Why it fails: Base64 is an encoding, not encryption; anyone can decode the header and recover the key, so a copied file decrypts without any passphrase. This defeats the core requirement that an attacker who copies the file cannot decrypt it without the user's passphrase.

Enable BitLocker with TPM

Why it fails: BitLocker encrypts the disk to protect data at rest, which is useful if the device is lost or stolen. However, it does not protect credentials in memory during runtime or prevent pass-the-hash attacks on a running system. Therefore, it does not directly mitigate the described threats.

Enforce SMB signing

Why it fails: SMB signing ensures the integrity and authenticity of SMB communications, preventing man-in-the-middle attacks and relay attacks. However, it does not protect credentials stored in memory or prevent pass-the-hash. While valuable, it does not directly mitigate credential theft from endpoint memory. Therefore, it is not a correct choice for this scenario.

Deploy Windows Defender Firewall with domain profile

Why it fails: Windows Defender Firewall controls network traffic but does not protect credentials in memory or prevent credential dumping. It can limit lateral movement but does not directly address pass-the-hash or credential theft. Thus, it is not a direct mitigation for the specified threats.

Reimage all affected endpoints and restore data from the most recent backups.

Why it fails: Reimaging and restoring from backups are Recovery-phase activities, not Post-Incident Activity. While they are essential to restoring operations, they occur before the formal lessons-learned review. Performing them does not fulfill the phase's goal of analyzing and improving the response process, so this is not an appropriate Post-Incident Activity task.

Isolate the compromised network segment to prevent the ransomware from spreading further.

Why it fails: Isolating a network segment is a Containment-phase action taken during the active incident to limit spread. By the time the organization conducts a formal lessons-learned review, containment has already occurred. Treating isolation as a Post-Incident Activity misplaces it in the lifecycle and does not contribute to the analytical and improvement goals of the phase.

Eradicate the ransomware binaries and remove persistence mechanisms from infected hosts.

Why it fails: Eradicating malware and removing persistence are Eradication-phase tasks that happen before recovery and post-incident review. The scenario is set after a major incident where eradication has presumably concluded. Including this as a Post-Incident Activity confuses the phase sequence and does not address the review-and-improve objective of the phase.

Implement a host-based intrusion prevention system (HIPS) on every endpoint to block malicious traffic at the source.

Why it fails: A HIPS can block malicious activity on an endpoint, but it is a host-level control and does not segment the network. If the HIPS is bypassed, disabled, or misses a threat, the endpoint can still communicate with peers on the same VLAN. The requirement is to limit spread across the network, which calls for network segmentation controls rather than relying solely on endpoint agents.

Deploy a honeypot on each VLAN to detect and automatically blackhole infected endpoints.

Why it fails: A honeypot can detect scanning or exploitation attempts, but it does not automatically blackhole infected endpoints and is not a segmentation control. It provides visibility, not containment. Placing one on every VLAN is also operationally heavy and does not prevent an infected host from reaching its peers. This option overstates the honeypot's role in limiting malware spread.

Configure DHCP snooping and IP Source Guard on all access ports to validate endpoint IP and MAC bindings.

Why it fails: DHCP snooping and IP Source Guard prevent IP spoofing and rogue DHCP servers, which are important integrity controls. However, they do not stop an infected endpoint from communicating with other endpoints using its legitimate IP address. Malware can still spread laterally over allowed protocols. These controls harden Layer 2 but do not provide the segmentation needed to contain an infection.