Operational Procedures practice questions

Remove all unnecessary packages and services

Why wrong: Removing all unnecessary packages and services is a sound hardening practice that reduces the attack surface, but it is typically categorized as Level 2 in the CIS Benchmarks. This is because the removal process can break expected functionality if an application relies on a particular package or daemon, requiring thorough business impact analysis and testing. Level 1 controls are intended to be low-impact, universally applicable security settings, so this action does not qualify as a Level 1 baseline.

Enable mandatory access control (SELinux) in enforcing mode

Why wrong: Enabling SELinux in enforcing mode provides strong mandatory access control, but it is commonly relegated to Level 2 because enforcing mode can deny legitimate application operations when policies are not fully tuned, potentially causing service outages. This requires significant policy customization and testing for each environment, making it disruptive for organizations not already prepared. A Level 1 control must be deployable with minimal operational friction, which enforcing mode does not always offer, so it is not the correct choice here.

Configure audit rules for file permission changes

Why wrong: Configuring audit rules to monitor file permission changes is a powerful forensic control, but it is generally assigned to Level 2 in the CIS Benchmarks. The reason is that extensive audit logging can generate large volumes of data, increasing storage costs and potentially causing performance degradation on busy systems. Additionally, the rule sets are highly site-specific—organizations may need to tailor them to their own compliance requirements—so they are not a uniform, low-impact Level 1 setting.

Disabling the user's network account immediately

Why wrong: This is a containment step, not evidence preservation.

Interviewing the user about their activities

Why wrong: Interviews are part of investigation but not evidence preservation.

Rolling patch deployment

Why wrong: Rolling patch deployment involves gradually updating a subset of systems at a time, often to minimize service disruption and test stability before full rollout. While a valid deployment strategy for non-critical updates, this phased approach is inherently too slow and deliberate for addressing a critical vulnerability that demands immediate, widespread remediation across the affected environment. It prioritizes availability and controlled risk over rapid, comprehensive mitigation of an urgent threat.

Patch compliance tracking

Why wrong: Patch compliance tracking is a post-deployment activity focused on auditing and reporting to ensure that required security updates have been successfully installed across all target systems. This process verifies the effectiveness of a patching initiative and identifies non-compliant assets, but it does not describe the actual procedure or method for deploying the critical patch itself. It's a measurement and verification step, not the immediate operational response to a vulnerability.

Standard patch management

Why wrong: Standard patch management typically involves a structured lifecycle that includes thorough testing in development and staging environments, scheduled deployment windows, and adherence to formal change management procedures. While crucial for maintaining system stability and minimizing operational impact for routine updates, this methodical approach introduces delays that are unacceptable when facing a critical vulnerability requiring immediate remediation. The time-consuming testing and approval phases inherent in standard processes would leave systems exposed for too long.

Current CPU utilization on firewalls

Why wrong: This metric represents a low-level operational performance indicator for network devices. While crucial for network engineers to monitor device health and capacity planning, it provides no strategic insight into the organization's overall security posture or risk landscape for executive decision-making. Executives require aggregated, risk-centric data to understand business impact, not infrastructure performance.

Patch installation status of all endpoints

Why wrong: The granular status of patch installations across all endpoints is an operational detail critical for IT and security teams responsible for vulnerability management and system hygiene. While vital for reducing attack surface, presenting this level of detail to executives would overwhelm them with tactical information rather than providing the strategic overview of risk and compliance they require. Executives need to know the impact of patching, not the individual status of each patch.

Number of IDS alerts per hour

Why wrong: Reporting the raw number of Intrusion Detection System (IDS) alerts per hour provides a tactical, high-volume metric that lacks the necessary context and aggregation for executive-level understanding. Executives are not concerned with the sheer volume of alerts, which can often include false positives, but rather with the actual impact of significant security incidents or the overall effectiveness of threat detection capabilities. They require insights into materialized risks or trends in critical threats, not operational noise.

Individual performance evaluations of team members

Why wrong: A post-incident review, particularly the "lessons learned" phase, is designed to improve organizational processes and procedures, not to conduct individual performance evaluations. Focusing on individual performance can foster a culture of blame, hindering open communication and honest assessment of systemic failures. The objective is to identify systemic weaknesses and enhance future incident response capabilities, not to discipline personnel.

Legal liability of the organization

Why wrong: While legal implications are a significant consequence of a data breach, determining the organization's legal liability is typically handled by legal counsel and is distinct from the technical post-incident review process. The primary goal of the technical review is to understand how the breach occurred and what can be done to prevent recurrence, not to assess legal culpability or prepare for litigation. Mixing these objectives can compromise the objectivity of the technical analysis.

Board of directors

Why wrong: The board of directors requires high-level information about organizational risk exposure, financial impact, and strategic threat trends rather than raw technical artifacts. A list of IoCs such as file hashes and C2 domains contains no executive context and would obscure the risk narrative. Board communications should be distilled into key risk metrics and mitigation status, not left as technical indicators for the C-suite to interpret.

Executive leadership

Why wrong: Executive leadership, like the C-suite, consumes threat intelligence at a strategic level, focused on how threats affect business objectives, regulatory compliance, and resource allocation. Detailed indicators of compromise lack decision-making context and are typically stripped of the tactical specificity this audience neither needs nor wants. An executive-facing summary would consist of executive dashboards and geographic campaign trends, not raw technical artifacts.

Network engineers

Why wrong: Network engineers typically require operational security guidance — such as firewall rule recommendations, filtering guidance, or network segmentation changes — rather than a raw IOC report. While they may act on specific malicious infrastructure, IoCs are normally handed to the security detection teams to convert into detect-and-respond actions. Without transformation into network-specific mitigations, the report has limited direct utility for infrastructure teams.

Boot the suspect system to check for running processes.

Why wrong: Booting the suspect system, particularly in normal mode, initiates the operating system and writes data to the disk—changing file access times, creating temporary files, and potentially altering user data or logs. This violates the core forensic principle of preserving evidence in its original state, as any modification can destroy or contaminate proof. Even if the system is booted from a live CD, the system's devices may still generate write activity, and performing a live boot is only justified in specific, carefully controlled scenarios where volatile data must be captured before powering down. In a routine forensic acquisition, the correct procedure is to keep the system powered off and use static imaging techniques.

Store original evidence on the same network as the investigation.

Why wrong: Storing original evidence on the same network as the investigation introduces a severe risk of corruption, accidental modification, or unauthorized access. For example, if the network is compromised by malware, the evidence files or the forensic images could be infected or altered, breaking their integrity and making them inadmissible in court. Additionally, network storage may have automated backup or indexing processes that modify file timestamps, and it can be accessible to other users, which creates a chain-of-custody violation. Original evidence should be stored on write-protected media in a physically secured, isolated evidence locker, ensuring that it is never exposed to a network environment that could change or contaminate it.

Reinstall the operating system before imaging to ensure stability.

Why wrong: Reinstalling the operating system before imaging would completely obliterate the original evidence—the process overwrites the disk's contents, destroys user files, deletes logs, and replaces system artifacts—thereby defeating the entire purpose of forensic preservation. The goal of digital forensics is to recover and analyze the evidence exactly as it existed at the time of the incident, not to create a clean or stable environment for the investigator. An unstable system does not justify such a destructive action; if a system is unstable, the investigator should still follow proper procedures for imaging the original media, even if it requires additional care or specialized tools. Reinstalling the OS would be tantamount to destroying evidence and could lead to criminal charges for obstruction of justice or evidence tampering.

Level 1 benchmarks are for Linux systems, while Level 2 benchmarks are for Windows systems.

Why wrong: Level 1 and Level 2 profiles exist for nearly every operating system, including Linux, Windows, macOS, and various network devices. The distinction between the levels lies in the depth of hardening and potential operational impact, not the platform. Conflating benchmark levels with OS type misrepresents how CIS organizes its guidance.

Level 1 benchmarks are for servers, while Level 2 benchmarks are for workstations.

Why wrong: The Level 1/Level 2 designation is independent of the device's role; CIS issues benchmark profiles for servers, workstations, cloud instances, and other infrastructure, with both levels available within each profile. For example, a server benchmark and a workstation benchmark each contain their own Level 1 and Level 2 recommendations. Misclassifying levels as server-only or workstation-only ignores that the same security-grade scale applies across diverse device categories.

Level 1 benchmarks are mandatory, while Level 2 benchmarks are optional.

Why wrong: CIS benchmarks are consensus-based recommendations, not regulatory mandates; even Level 2 is optional and should be adopted only after assessing the organization's risk tolerance and operational requirements. Labeling Level 1 as mandatory would incorrectly suggest that CIS or a governing body enforces compliance, whereas in practice any benchmark profile is a baseline that an organization can tailor or extend. The distinction between levels reflects hardening depth, not legal or policy obligation.

Notification to law enforcement

Why wrong: Contacting law enforcement is not the first action because the incident's scope, impact, and legal requirements have not yet been assessed. Premature notification can trigger formal legal processes and potentially compromise internal investigation flexibility, while the immediate priority is to verify the incident and initiate containment through the IR team. Law enforcement is brought in only when criminal activity or regulatory obligations are confirmed.

Press release to customers

Why wrong: Issuing a press release is premature because the organization has not yet confirmed the nature and scope of the incident or fulfilled internal communication protocols. Public statements made without verified technical details can mislead customers, create regulatory exposure, and damage trust, especially if the incident turns out to be benign or limited. External notifications should follow a coordinated plan after internal escalation and initial containment.

Update to the risk register

Why wrong: Updating the risk register is a post-incident or continuous-improvement activity, not an initial response action. In the middle of an active security incident, the response team must focus on triage, containment, and eradication; documenting risk register changes can wait until after stabilization, when lessons learned can inform future risk assessments.

Deliver technical indicators like IoCs to SOC analysts

Why wrong: Delivering technical indicators like IoCs (e.g., file hashes, IP addresses, domains) to SOC analysts is the hallmark of tactical intelligence. Tactical intelligence is designed for immediate, automated consumption—enabling detection at speed—but it lacks the broader context of an adversary's motivations, relationships, or campaign objectives. While IoCs are critical for short-term blocking and alerting, they become stale quickly and do not provide the deep campaign-level TTP analysis that operational intelligence offers.

Provide high-level trends to executive leadership

Why wrong: Providing high-level trends to executive leadership is the role of strategic intelligence, which summarizes the overall threat landscape, emerging risks, and potential business impacts for senior decision-makers. Strategic intelligence is intentionally broad and forward-looking, often covering industry-wide attack patterns or geopolitical shifts, but it lacks the specificity and actionable detail required for day-to-day defensive operations. It informs risk appetite and investment priorities, not the granular TTP analysis needed to stop a particular campaign.

Summarize geopolitical risks affecting the organization

Why wrong: Summarizing geopolitical risks affecting the organization is another form of strategic intelligence, focused on how nation-state relations, regulatory shifts, or regional conflicts might influence threat exposure at an enterprise level. This type of analysis helps executives understand the 'why' behind certain adversary behaviors, but it does not offer the tactical or operational detail needed to identify and respond to a specific intrusion campaign. It is essential for long-term planning, yet it is categorically different from the campaign-focused TTP analysis that operational intelligence delivers.

Run a full antivirus scan on the target drive

Why wrong: Running an antivirus scan on the original drive is not forensically sound because the scanner reads and opens files, altering access timestamps, and may write quarantine records, logs, or signature updates to the media. It can also flag and automatically delete or quarantine a suspicious file, destroying potential evidence. Antivirus scanning should be deferred until after a verified forensic image is created and analyzed in a sandbox.

Boot the system to ensure it is operational

Why wrong: Booting the suspect system is dangerous because the operating system immediately writes to the disk — updating logs, prefetch files, registry keys, and user-assist artifacts — and can trigger network communications or anti-forensic mechanisms that overwrite deleted data. It also destroys volatile memory contents that should be captured first under the order of volatility. If booting is absolutely required, it must be done in an isolated lab using a write blocker and with RAM acquired beforehand.

A generic statement that security is important

Why wrong: Useful reviews create concrete actions.

Deletion of all incident tickets

Why wrong: Tickets provide evidence and improvement history.

A blame list of individual analysts

Why wrong: Blame-focused reviews discourage reporting and do not fix process gaps.

Ship the image and document nothing

Why wrong: Risk acceptance requires evidence and approval.

Only rename the image tag

Why wrong: Renaming does not change vulnerable contents.

Ignore all base-image vulnerabilities

Why wrong: Inherited dependencies can still create exploitable paths.

Simply state the vulnerability exists and a patch is available

Why wrong: Simply stating a vulnerability exists and a patch is available fails to provide the necessary context for a critical issue. This approach lacks details on the severity, exploitability, or potential consequences, making it difficult for stakeholders to grasp the urgency or allocate appropriate resources for remediation. Effective reporting requires quantifying risk, not just identifying a problem.

Write a 50-page report covering every technical detail and mitigation option

Why wrong: A 50-page report, while exhaustive, is counterproductive for conveying critical information to executive leadership. Decision-makers require concise, high-level summaries that highlight key risks and actionable recommendations, not an overwhelming volume of technical minutiae. Such extensive documentation can obscure the most important points, delaying crucial strategic responses to the vulnerability.

Provide a full technical analysis of the vulnerability and remediation steps

Why wrong: Providing a full technical analysis, including granular details of the vulnerability and exhaustive remediation steps, is often too detailed for executive-level reporting. While essential for technical teams implementing fixes, this level of detail can overwhelm non-technical stakeholders, obscuring the overarching business risk. The focus for executives should be on strategic implications and high-level treatment options, not the intricate mechanics of the exploit.

Using YARA rules to detect malware in the environment

Why wrong: YARA rules are used during detection and analysis, not preparation.

Implementing network segmentation to limit lateral movement

Why wrong: Network segmentation is a containment strategy, not a preparation activity.

Conducting a root cause analysis after each incident

Why wrong: Root cause analysis is part of post-incident activity, not preparation.

Number of security incidents detected.

Why wrong: The 'Number of security incidents detected' is an ambiguous metric when evaluated in isolation. An increase could signify a more effective security program with enhanced detection capabilities, rather than a decline in overall security posture. Without context regarding the severity, impact, or the speed at which these incidents were resolved, this count alone does not directly reflect the efficiency or effectiveness of the security program's ability to prevent or mitigate threats.

Percentage of employees who completed security awareness training.

Why wrong: While 'Percentage of employees who completed security awareness training' is an important compliance and activity metric, it does not directly measure the overall effectiveness of the security program in reducing actual security incidents. High completion rates do not automatically translate into improved employee behavior or a reduction in human-related security breaches. The true measure of training effectiveness lies in the observable reduction of phishing click-through rates or social engineering success, rather than mere attendance.

Number of firewall rules configured.

Why wrong: The 'Number of firewall rules configured' is a configuration metric, not a performance indicator of a security program's effectiveness. A high count of rules does not inherently equate to better security; it could instead indicate unnecessary complexity, potential misconfigurations, or a lack of rule optimization, which can introduce vulnerabilities. The efficacy of a firewall is determined by how well its ruleset prevents unauthorized access and filters malicious traffic, not by the sheer quantity of rules.