Security Operations practice questions

Wait for the next scheduled maintenance window to apply the patch

Why it fails: Delaying patching for critical vulnerabilities increases risk of exploitation.

Deploy the patch immediately without testing to all systems

Why it fails: Immediate deployment to all systems may cause instability; a staged approach is better.

Test the patch in a staging environment and then deploy to production

Why it fails: Normal testing is appropriate for non-critical patches, but critical vulnerabilities may require expedited testing.

Increasing log retention for the system

Why it fails: Log retention helps with detection, not prevention.

Implementing strict password policies

Why it fails: Password policies do not protect against network-based exploits.

Conducting regular security awareness training

Why it fails: Training addresses human factors, not technical vulnerabilities.

Perform advanced forensic analysis on the affected system.

Why it fails: Advanced analysis is Tier 3 responsibility.

Conduct threat hunting to identify similar patterns.

Why it fails: Threat hunting is Tier 3 activity.

Implement a firewall rule to block all traffic from that location.

Why it fails: Implementation of changes is not a Tier 1 task.

Apply compensating controls if the patch cannot be installed.

Why it fails: Compensating controls are a later step if patching is not possible.

Deploy the patch immediately to all production servers.

Why it fails: Patching should be tested first to avoid disruptions.

Test the patch in a staging environment.

Why it fails: Testing occurs after vendor release.

Increase logging and monitoring of the system.

Why it fails: Monitoring detects but does not prevent exploitation.

Perform weekly vulnerability scans on the system.

Why it fails: Scans identify vulnerabilities but do not protect against exploitation.

Apply a virtual patch using an intrusion prevention system (IPS).

Why it fails: IPS can block exploit attempts; however, a WAF is more specific for web apps.

The email includes an attachment from a trusted source.

Why it fails: An attachment from a trusted source is not itself an indicator; the risk lies in unexpected files, macro-enabled documents or mismatched extensions. Attackers spoof trusted senders, so trust must be verified out-of-band. Attachments are the correct focus when checking for malicious payloads, but mere trusted origin is benign.

The email has a professional signature with contact details.

Why it fails: A professional signature with contact details is normal in legitimate business mail and proves nothing about origin; attackers routinely copy genuine signatures. Verifying the sender domain and inspecting headers for spoofing is what actually detects phishing. Signatures are simply expected formatting in ordinary corporate correspondence.

The email is from a known colleague.

Why it fails: Mail from a known colleague is routine and carries no inherent phishing signal; attackers impersonate colleagues by spoofing or lookalike domains. Confirming the actual sending domain and header authentication results is what exposes impersonation. Familiar internal senders are expected in normal business traffic, not treated as suspicious.

Apply a workaround from the vendor and skip patching

Why it fails: While workarounds may help, patching is the definitive fix.

Wait for the scheduled patch cycle to test thoroughly

Why it fails: Waiting could leave the organization vulnerable to active exploits.

Disconnect the VPN appliance until the next patch cycle

Why it fails: Disconnecting may impact business operations; patching is preferred.

Application logs

Why it fails: Application logs record software-level events, not the authentication, process-creation and service-stop activity needed to reconstruct why antivirus was disabled. They are tempting because application logs do capture some security-relevant errors, and would be the right first choice when investigating a crashing or misbehaving application rather than host-level tampering.

Firewall logs

Why it fails: Firewall logs show allowed or denied connections and traffic volume, but not the local process, account or command that disabled the antivirus. They are tempting because the spike is outbound traffic, and firewall logs would be the correct first choice when the question asks which destination or port the exfiltration used.

Authentication logs

Why it fails: Authentication logs record sign-in, logon and credential events, so they cannot reveal why endpoint protection was disabled or what executed afterwards. It is tempting because authentication logs are a standard early pivot in triage, and they would be correct when investigating suspicious logons or credential misuse.

Application logs

Why it fails: Application logs record app-specific events, not OS-level privilege changes.

System logs

Why it fails: System logs record service events, not necessarily privilege changes.

Firewall logs

Why it fails: Firewall logs show network traffic, not user privilege changes.

Vulnerability scanning tools

Why it fails: While useful, vulnerability scanning is often a separate function; the question asks for essential SOC components, and SIEM, patch management, and configuration management are foundational.

Data backup and recovery procedures

Why it fails: Backup is important but typically managed by IT operations, not SOC.

Emergency patching without testing

Why it fails: Emergency patching is an exception, not part of the standard lifecycle.

Verifying backups before deployment

Why it fails: While good practice, it is not a defined step in the patch lifecycle.

Separation of duties

Why it fails: Separation of duties splits a sensitive task among multiple people so no single person can complete it alone. Here the failure was not about one person holding too much authority; it was about the backup being continuously reachable and therefore encryptable alongside the primary data. Applying separation of duties would not have preserved a recoverable copy of the files in this scenario.

Least privilege

Why it fails: Least privilege limits each account to only the access needed for its role. While excessive rights can widen ransomware spread, the described failure is the absence of an isolated, recoverable backup copy. Even perfect least privilege on user accounts would not restore encrypted files if the only backup was online and also encrypted during the same incident.

Non-repudiation

Why it fails: Non-repudiation provides proof that an action occurred and cannot be denied, typically through signatures or tamper-evident logs. It supports investigations and accountability but does nothing to keep a usable copy of data. Here the problem is recovery capability after encryption, not proving who performed an action, so non-repudiation is unrelated to the loss.

Security log with event ID 4663 (An attempt was made to access an object)

Why it fails: Event ID 4663 indicates that an object was accessed, but it does not specifically record USB device connections or file copies to removable media. It can show file access attempts if object access auditing is enabled, but it lacks the context of the destination being a USB drive. It is less direct than logs that track device installation or file system changes.

System log with event ID 20001 (Device installation)

Why it fails: Event ID 20001 in the System log is related to device installation, but it is not a standard Windows event ID for USB device connections. The correct event IDs for USB device installation are typically found in the Security log or via other sources. This option is a distractor because it incorrectly associates the System log with device installation events.

Application log with event ID 1000 (Application error)

Why it fails: Event ID 1000 in the Application log indicates an application crash. It has no relevance to USB device connections or file copying. It would not provide evidence of an insider threat involving removable media. This option is clearly incorrect for the scenario.

Discretionary Access Control (DAC), because each file owner decides who may access the file.

Why it fails: DAC lets resource owners set permissions at their discretion, which is flexible but inconsistent and hard to audit. The requirement here is a standardized rule based on group membership, not owner discretion. Relying on DAC would allow individual owners to grant access that violates the Payroll and HR policy, so it does not satisfy the stated control objective.

Rule-Based Access Control, because access is granted only during approved payroll processing windows.

Why it fails: Rule-based access control makes decisions from global rules such as time-of-day or network location restrictions. The scenario does not mention time windows or location constraints; it defines access by group membership. Although time-based rules could supplement the design, they are not the primary model that maps Payroll and HR members to read and modify permissions.

Mandatory Access Control (MAC), because the operating system enforces labels that users cannot change.

Why it fails: MAC enforces access through system-assigned sensitivity labels and clearances, typically found in high-assurance environments such as government classified systems. The scenario describes ordinary business roles like Payroll and HR, not label-based clearance levels. While MAC is more restrictive, it does not map cleanly to role membership and would add unnecessary complexity for a payroll file server.

Send a company-wide email naming the affected user and describing the suspected malware family.

Why it fails: Broad disclosure at this stage can compromise the investigation, embarrass the employee, and tip off an attacker who may still have access. Notification should follow the incident response plan and involve only those who need to know, such as the IR lead and legal. Containment focuses on limiting technical impact, not on organization-wide communication.

Immediately reimage the workstation and return it to the user so business operations are not interrupted.

Why it fails: Reimaging is a remediation and recovery action, not containment. Performing it during containment destroys evidence, prevents scope determination, and may leave the initial infection vector unaddressed, allowing reinfection. The host should be isolated and evidence preserved first; rebuild only after the root cause is understood and eradication is verified.

Delete all files created in the last 24 hours from the workstation to remove the malware.

Why it fails: Deleting files destroys evidence and may not remove persistence mechanisms such as scheduled tasks, services, or registry entries. It can also break legitimate business data. Proper eradication requires identifying the malware artifacts first, then removing them in a controlled way after evidence collection and scope analysis.

SOC Manager

Why it fails: The SOC Manager handles staffing, metrics, process governance and stakeholder reporting, not alert triage. The role is tempting because managers oversee the escalation process, but Tier 1 analysts perform initial triage and decide whether an alert warrants escalation to Tier 2.

Tier 3

Why it fails: Tier 3 analysts perform deep-dive threat hunting, malware reverse engineering and advanced incident response, receiving work already escalated. The tier is tempting because it handles the most complex cases, but triage and the initial escalate-or-close decision belong to Tier 1.

Tier 2

Why it fails: Tier 2 performs deeper investigation and incident response on alerts already escalated by Tier 1, so it does not own initial triage or the escalate-or-close decision. It is tempting because Tier 2 handles the substantive analysis, which would be the correct answer if the question asked who investigates confirmed incidents.

Application logs

Why it fails: Application logs record events generated by application code, such as errors and transactions, not Windows account authentication. They would be relevant for a failing line-of-business app, but logon attempts against a domain controller appear in security auditing, not application channels.

Firewall logs

Why it fails: Firewall logs record permitted or denied connections by IP, port and protocol, not authentication outcomes or account names. They would confirm the internal host reached the domain controller, but the failed-then-successful logon pattern is captured in authentication events, not network flow records.

System logs

Why it fails: System logs capture operating system events such as service starts, driver faults and reboots, not per-account authentication attempts. They might show the domain controller's health, but the repeated failed logons followed by success are recorded as security audit events, not system channel entries.

24 months retention, 12 months immediately available

Why it fails: PCI DSS requires 12 months of retention with the most recent 3 months immediately available for analysis, so 24/12 overstates both figures. It tempts because longer retention appears safer for audits, yet the standard's actual baseline is one year total and three months readily accessible.

6 months retention, 1 month immediately available

Why it fails: PCI DSS mandates a minimum of 12 months retention, with 3 months immediately available; 6 months and 1 month both fall short. Six months is tempting because it resembles common internal log-retention baselines rather than the standard's actual figures.

12 months retention, 6 months immediately available

Why it fails: PCI DSS requires at least 12 months of retention, but only the most recent 3 months must be immediately available for analysis, not 6. Twelve months is tempting because it matches the retention half of the requirement exactly.

Rotating logs daily

Why it fails: Rotating logs daily only starts new files; it neither prevents nor detects modification of existing entries, so an attacker can still alter them. Rotation is tempting because it limits file size and aids retention management, and it would be the right control for storage housekeeping, not for tamper prevention.

Encrypting logs with a symmetric key

Why it fails: Symmetric encryption hides content but the same key both encrypts and decrypts, so anyone holding it can re-encrypt altered records, leaving no detectable change. It is tempting because it protects confidentiality at rest, which suits data-privacy requirements, but integrity requires hashing or write-once remote storage.

Storing logs on the local system drive

Why it fails: A local drive offers no write-once protection: anyone with host access, including malware running as root, can edit or delete files directly. It is tempting for simplicity and speed of local writes, and suits transient troubleshooting logs, but tamper prevention demands shipping logs to a remote immutable store.

The email has a professional signature with contact information

Why it fails: A professional signature with contact details is normal business correspondence and signals nothing malicious; phishing indicators include mismatched sender domains, urgency, and suspicious links. It is tempting because attackers sometimes omit signatures, so a missing or inconsistent signature would be the correct indicator to flag.

The email comes from a known colleague and contains a file attachment they mentioned earlier

Why it fails: A known colleague referencing a previously discussed attachment matches expected behaviour and is a benign pattern, not a phishing indicator. It is tempting because attackers spoof trusted senders, so an unexpected attachment from a colleague would be the correct indicator when the context does not match prior communication.

The email is sent during regular business hours

Why it fails: Sending during business hours is normal behaviour and reveals nothing about legitimacy; attackers routinely schedule messages to blend in. It is tempting because unusual timing can accompany some attacks, but the reliable phishing indicators are sender-domain mismatches, urgent language and suspicious links, not the clock.