Operating Systems practice questions

FTK Imager

Why it fails: FTK Imager is a widely used forensic tool primarily designed for Windows environments to perform disk imaging and logical file extraction. While it does support volatile memory acquisition on Windows systems, it cannot be natively executed on a live Linux server to capture its RAM.

WinPmem

Why it fails: WinPmem is an open-source physical memory acquisition tool specifically engineered for Microsoft Windows operating systems. It utilizes a dedicated kernel driver to read physical memory, making it completely incompatible with and unable to run on Linux architectures.

dd

Why it fails: The dd utility is a standard command-line tool used for copying and converting raw data, typically utilized for creating bit-stream disk images of storage drives. It is not suitable or safe for live memory acquisition on modern Linux kernels, as reading directly from /dev/mem or /dev/kmem is heavily restricted or disabled for security reasons.

Shut down the file server and domain controller to protect critical systems from potential encryption.

Why it fails: Shutting down critical infrastructure like file servers and domain controllers is premature and highly disruptive, impacting business operations unnecessarily when these systems are not confirmed to be compromised. Furthermore, powering off these servers would destroy valuable volatile memory data, such as active network connections, running processes, and logged-in users, which could be vital for understanding the broader scope of the attack if they were indeed targeted or compromised. The immediate priority is containing the *known* infection.

Power off the three infected workstations immediately to contain the encryption process.

Why it fails: Powering off the infected workstations immediately, while seemingly containing the encryption, would destroy critical volatile memory data. This includes running processes, network connections, open files, and cached credentials, all of which are invaluable for forensic investigators to determine the initial compromise vector, the malware's behavior, and potential command-and-control communications. Preserving this evidence is paramount for a thorough incident response.

Apply the latest SMB vulnerability patch to the file server and domain controller to block the propagation vector.

Why it fails: Applying patches to the file server and domain controller, while a good long-term security practice, does not address the immediate threat of active ransomware on the three workstations. The encryption process on the already infected machines would continue locally, and patching does not prevent lateral movement from systems already compromised and potentially exploiting other vulnerabilities or credentials. Containment of the active threat takes precedence over preventative patching at this stage.

OpenVAS

Why it fails: OpenVAS is an open-source vulnerability manager that executes network-level scans to identify known CVEs and security weaknesses across distributed endpoints. It relies on the Greenbone Community Feed to detect active exploits and misconfigurations, making it a general-purpose vulnerability scanner rather than a specialized tool designed for local system hardening and compliance verification.

Nessus

Why it fails: Nessus is a commercial, network-based vulnerability scanner developed by Tenable that primarily identifies missing patches, open ports, and software exploits. While it supports compliance auditing through custom policy templates, its core architecture is optimized for remote vulnerability assessment rather than dedicated, host-level configuration compliance auditing.

Qualys

Why it fails: Qualys is an enterprise-level, cloud-native vulnerability management platform that provides broad visibility into global IT assets. While it offers policy compliance modules as part of its larger suite, its primary design centers on continuous vulnerability lifecycle management, asset discovery, and threat prioritization across hybrid cloud environments.

dd

Why it fails: While dd (dataset definition) is a standard command-line utility used for bit-by-bit disk imaging and copying files, it is not suitable for reliable live memory acquisition on modern Linux kernels. Attempting to use dd on /dev/fmem or /dev/mem often results in incomplete captures or system crashes due to kernel restrictions and memory space layout randomization.

FTK Imager

Why it fails: FTK Imager is a widely used GUI and command-line forensic tool primarily designed for creating disk images and capturing RAM on Windows operating systems. It does not support native volatile memory acquisition on Linux systems, making it inappropriate for this specific platform-dependent task.

WinPmem

Why it fails: WinPmem is an open-source memory acquisition tool specifically engineered to capture physical memory from Windows environments. Because it relies on Windows-specific drivers and API calls to access physical memory address space, it cannot be executed or used to dump RAM on a Linux target machine.

Vulnerability scanner

Why it fails: A vulnerability scanner, such as Nessus or OpenVAS, is a diagnostic tool used to identify security weaknesses, including missing patches, misconfigurations, and known vulnerabilities, within a network or system. While it provides critical insights into an organization's security posture by detecting unpatched software, it does not possess the functionality to deploy or apply those patches. Its role is solely assessment and reporting, not remediation.

Configuration management tool

Why it fails: A configuration management tool, like Ansible, Puppet, or Chef, primarily focuses on maintaining a desired state for systems and deploying software or configurations consistently. While it could be leveraged to push certain updates, it lacks the specialized features of a dedicated patch management system, such as robust patch testing environments, dependency checking, or integrated rollback capabilities specific to security updates. Its general-purpose nature makes it less efficient for the comprehensive and continuous process of security patch deployment.

Security information and event management (SIEM) system

Why it fails: A SIEM system aggregates and correlates security logs and event data from various sources across an IT environment to detect anomalies, identify potential threats, and generate alerts. Its core function is to provide centralized visibility into security incidents and compliance, enabling rapid response to detected issues. However, a SIEM is purely an observation and alerting platform; it does not have any native capabilities to initiate, manage, or automate the deployment of security patches to endpoints.

Remove the server from the network immediately.

Why it fails: Removing the server from the network immediately, while seemingly secure, is often impractical and detrimental in a financial institution. Such a drastic action would likely disrupt critical business operations, halt ongoing compliance audits, or prevent essential regulatory reporting, leading to significant financial and legal repercussions. This approach prioritizes security over availability and business continuity without exploring less disruptive mitigation strategies.

Accept the risk and document the exception.

Why it fails: Accepting the risk and merely documenting an exception is an insufficient response, particularly given a 72-hour remediation policy for vulnerabilities. This approach fails to actively mitigate the identified security weakness, leaving the financial institution exposed to potential breaches, data loss, and severe regulatory penalties. Risk acceptance is typically reserved for low-impact risks or when all other mitigation options are exhausted and formally approved at a high organizational level, which is not the case here.

Apply a custom patch developed by the manufacturer.

Why it fails: Applying a custom patch developed by the manufacturer is highly improbable and unrealistic for an end-of-life (EOL) operating system. When an OS reaches EOL, the manufacturer has officially ceased all support, including the development of new security patches or custom fixes. Even if an unofficial patch were somehow created, it would lack vendor backing, potentially introduce new vulnerabilities or system instability, and would not be a reliable, long-term solution for a critical financial system.

Install a network-based intrusion detection system to monitor the server.

Why it fails: Installing a network-based intrusion detection system (NIDS) at this stage is a proactive security enhancement, but it does not address the immediate need to investigate the already reported suspicious connections. An IDS would primarily monitor future traffic for known attack signatures or anomalies, offering little insight into the historical or current nature of the specific suspicious communications that have already occurred or are ongoing. This action is a long-term control, not an immediate incident response investigation technique.

Isolate the EMR server from the network and run a full forensic analysis.

Why it fails: Isolating the EMR server from the network and immediately initiating a full forensic analysis is a drastic containment and recovery step that is premature without further investigation. While isolation is crucial for containing confirmed threats, doing so without understanding the nature of the suspicious traffic could unnecessarily disrupt critical hospital operations if the connections are legitimate. A full forensic analysis is resource-intensive and typically follows initial identification and containment, not precedes it.

Block all outbound traffic from the EMR server to the internet immediately.

Why it fails: Blocking all outbound traffic from the EMR server to the internet immediately is an overly aggressive containment measure that could severely disrupt legitimate hospital operations. EMR systems often require outbound connectivity for updates, integrations with external services, or even legitimate vendor support. Implementing such a broad block without first understanding the nature of the suspicious traffic risks causing significant availability issues and impacting patient care unnecessarily.

Disable verbose output to reduce clutter.

Why it fails: Disabling verbose output merely changes the level of detail presented in the scan report, making it potentially easier to read by suppressing less critical or redundant information. However, it does not alter the underlying scanning methodology, the depth of the probes performed against target systems, or the logic used for vulnerability identification. Therefore, reducing output clutter has no impact on the accuracy of vulnerability detection or the reduction of false positives or negatives.

Increase scan frequency to monthly.

Why it fails: Increasing scan frequency to monthly improves the timeliness of vulnerability detection, allowing organizations to identify newly emerging threats or configuration drift more quickly. However, the frequency of scans does not inherently improve the accuracy of the individual findings themselves. If the scanning methodology lacks depth, such as being uncredentialed, simply running it more often will still yield the same quality of potentially inaccurate or incomplete results.

Use a different vulnerability scanner.

Why it fails: While different vulnerability scanners possess unique signature databases and detection capabilities, simply switching to an alternative tool does not guarantee improved accuracy without addressing fundamental scanning methodologies. If the new scanner is still configured to perform uncredentialed scans, it will face the same limitations in assessing internal system states and confirming patch levels. Therefore, a different tool may still produce a similar rate of false positives or miss critical vulnerabilities without authenticated access.

Nessus

Why it fails: While Nessus can perform compliance checks on container hosts, it is primarily a network-based, general-purpose vulnerability scanner. It lacks the native capability to deeply parse container image layers, manifest files, and application-level dependencies within a container registry or CI/CD pipeline.

Burp Suite

Why it fails: Burp Suite is an interception proxy and dynamic application security testing (DAST) tool designed to analyze running web applications for vulnerabilities like SQL injection and cross-site scripting. It does not scan static container images, their base operating system packages, or their embedded library dependencies.

OpenVAS

Why it fails: OpenVAS is an open-source network vulnerability scanner designed to detect security issues across active network hosts, operating systems, and services. It is not architected to unpack container image filesystems, inspect Dockerfiles, or analyze software composition (SCA) within container registries.

Running a full antivirus scan on the workstation

Why it fails: Running a full antivirus scan on the workstation is primarily a detection and remediation step, not an immediate containment action for an active ransomware infection. While it might identify some malicious files, it is unlikely to stop an ongoing encryption process and could consume critical system resources, potentially accelerating the encryption or alerting the attacker to the detection, prompting further malicious actions or deletion of forensic artifacts. The primary goal in an active ransomware scenario is to prevent further spread, which scanning alone does not guarantee.

Disabling the user's Active Directory account

Why it fails: Disabling the user's Active Directory account primarily restricts network access and authentication for that user. While it can prevent the user from logging into other systems or accessing network shares, it does not stop ransomware that has already executed on the local workstation from continuing its encryption process or attempting to spread laterally using existing local privileges or cached credentials. The ransomware's local operations are largely independent of the user's AD account status once execution has begun, making this an ineffective immediate containment strategy.

Rebuilding the workstation from a known good image

Why it fails: Rebuilding a workstation from a known good image is a crucial step in the recovery phase of an incident response, aiming to restore the system to a clean state. However, it is not an immediate containment action. Attempting to rebuild a system while it is actively infected and potentially connected to the network risks further compromise or data loss, and it fails to address the immediate threat of the ransomware spreading to other systems. Containment must precede recovery to prevent wider impact and ensure the source of infection is isolated.

Only a generic statement that risk exists

Why it fails: Providing only a vague assertion of risk fails to give system owners the actionable intelligence required for remediation. Without specific CVE identifiers, CVSS scores, or host details, administrators cannot prioritize patching efforts or assess the actual threat vector within their specific environment, rendering the report useless.

Update the incident ticket and wait for the team to review

Why it fails: While updating the ticketing system is necessary for maintaining an accurate audit trail, relying solely on this passive method during an active incident introduces unacceptable latency. Ticketing queues are not constantly monitored in real-time by all responders, meaning critical, time-sensitive updates could sit unread while the threat propagates.

Send a detailed email to the incident response team

Why it fails: Email is an asynchronous communication medium that lacks guaranteed immediate delivery and visibility during high-stress incident response scenarios. Responders are often focused on containment and mitigation tasks, meaning an email notification may be overlooked, delaying critical decision-making when seconds count.

Post the information on a public forum for awareness

Why it fails: Disclosing active incident details on a public forum violates basic operational security (OPSEC) and non-disclosure agreements, potentially exposing sensitive corporate data or vulnerabilities to malicious actors. This action tips off the adversary that they have been detected, allowing them to alter their tactics, destroy evidence, or accelerate their payload delivery.

Assume the latest arriving event happened last

Why it fails: This assumption is fundamentally flawed in distributed systems and SIEM environments. Network latency, queuing delays, and processing variations across different log sources and collectors mean that events can arrive at the SIEM out of chronological order relative to their actual occurrence time. Relying on ingestion order for incident reconstruction would lead to an inaccurate and potentially misleading timeline of security events, hindering effective analysis and response.

Discard every source except the firewall

Why it fails: Discarding valuable telemetry from identity and cloud logs severely cripples a security investigation. A comprehensive understanding of an incident often requires correlating events across multiple domains, such as network activity (firewall), user actions (identity), and cloud resource interactions. Removing these diverse data points eliminates crucial context and visibility, making it impossible to reconstruct the full attack chain or identify lateral movement and privilege escalation, thereby weakening the overall security posture.

Level 1 is more restrictive and secure than Level 2

Why it fails: This reverses the actual CIS relationship: Level 1 defines baseline hardening settings that provide meaningful security benefit while minimizing the risk of breaking applications or services, making it the less restrictive, not more restrictive, of the two profiles.

Level 1 is for cloud systems, Level 2 for on-premises

Why it fails: CIS Benchmark levels are not scoped by deployment environment; both Level 1 and Level 2 profiles exist for cloud, on-premises, and hybrid platforms alike, and the distinction is based purely on hardening depth and risk tolerance, not on where the system is hosted.

Level 2 is only for DoD environments

Why it fails: This confuses two separate hardening frameworks: DISA STIGs are the Department of Defense-specific configuration standards, while CIS Benchmarks are published by the Center for Internet Security and Level 2 is simply their more stringent profile, with no organizational restriction to DoD environments.

Creating a forensic image of the infected systems for later analysis.

Why it fails: While creating a forensic image is essential for preserving evidence and supporting post-incident analysis, it does nothing to stop the malware from continuing to communicate or spread across the network. Containment must occur first to halt active propagation; imaging is a preservation step, not a containment action. In this scenario, it is a wrong answer because it fails to address the immediate threat.

Identifying and patching the vulnerability exploited by the malware.

Why it fails: Identifying and patching the exploited vulnerability is part of eradication and recovery, not immediate containment. Patching requires vulnerability analysis, patch availability, and deployment, during which malware can continue spreading; it also does not remediate systems already compromised. Thus, it is not an appropriate initial containment action for an active outbreak.

Notifying law enforcement agencies about the incident.

Why it fails: Notifying law enforcement is a legal and procedural obligation that may be required by policy, but it is not a technical containment action. It has no effect on malware execution, communication, or spread, and should occur in accordance with the incident response plan after containment is initiated. Consequently, it is incorrect in the context of immediate incident containment.

Wireshark

Why it fails: Wireshark's core purpose is deep packet inspection and live protocol analysis, capturing frames off the wire for offline examination. It does not query external intelligence sources, maintain reputation databases, or enrich an IOC's context by itself; rather, it would be used after an incident to inspect traffic patterns. For static IOC enrichment, it offers no registration or device-level metadata, so it is not a suitable analysis tool.

Nmap

Why it fails: Nmap is an active network scanning tool used to discover hosts, map open ports, and detect service versions on a target network during penetration testing or reconnaissance. It generates its own traffic and requires a live target to scan, whereas IOC enrichment relies on passive queries to third-party databases to gather existing context. Running Nmap against a known IOC IP provides no historical or threat intelligence data, and could even alert network defenders, so it is not an enrichment technique.

Using a higher scan intensity

Why it fails: Using a higher scan intensity increases the rate of concurrent connections, timeouts, and service probing aggressiveness. This may cause the scanner to receive incomplete or ambiguous responses from overloaded targets, leading it to misidentify services and flag false vulnerabilities. Intensity affects performance and network tolerance, not the precision of the detection logic, so it cannot reduce false positives. In fact, aggressive scanning can introduce more extraneous findings by interpreting transient network errors as vulnerabilities.

Scanning from multiple IP addresses

Why it fails: Scanning from multiple IP addresses distributes the scan load and can help bypass rate limits or network path restrictions, but it does not alter the scanner's detection logic or how it interprets responses. False positives arise from plug-in logic and target response characteristics, which are independent of the source address. Using multiple sources may even introduce variability, because different paths or network segments can yield inconsistent responses, worsening false positives. It has no effect on reducing the number of false findings.

Scanning only during business hours

Why it fails: Scanning only during business hours changes when the scan runs but has no effect on the scanner's detection mechanisms. False positives are produced by plug-ins misinterpreting target responses or lacking context, which is unrelated to the time of day. In fact, business hours might see live user activity or dynamic services that could complicate responses, potentially increasing noise. The accuracy of a scan depends on its configuration, not its schedule, so this does not reduce false positives.

They are mandatory for compliance with DoD STIGs

Why it fails: CIS Level 1 benchmarks are baseline recommendations intended for all systems, not a DoD STIG mandate; STIGs are separate documents. This option is tempting because both frameworks overlap in hardening guidance, but Level 1 is defined by low performance and functionality impact, not by any specific compliance regime.

They are the most restrictive settings, suitable for high-security environments

Why it fails: Level 1 benchmarks are baseline settings with minimal operational impact, not the most restrictive tier; Level 2 covers defence-in-depth for high-security environments. This option is tempting because higher levels do tighten controls, but Level 1 is explicitly the practical, broadly applicable profile.

They include advanced settings that require extensive testing

Why it fails: Level 1 covers baseline, essential hardening settings intended for any system with minimal operational impact; extensive testing and advanced, environment-specific controls define Level 2. Choosing it here misstates the level's scope, though it would fit a hardened, high-security deployment where Level 2 is mandated.

Burp Suite

Why it fails: Burp Suite is an intercepting proxy for testing web application traffic, so it inspects HTTP requests rather than image filesystem layers. It cannot enumerate installed packages or OS libraries inside a Docker image. It would be correct when assessing a web app's authentication, session handling or injection flaws during a penetration test.

Nessus

Why it fails: Nessus performs host and network vulnerability assessment against running systems, not static analysis of image layers. It cannot unpack a Docker image or map packages inside it to CVEs. It would be the right tool for scanning deployed hosts and exposed services across an estate, which is a different task from pre-deployment image inspection.

OpenVAS

Why it fails: OpenVAS scans live hosts over the network for exposed services and missing patches; it does not parse image manifests or layer contents. Docker images are static artefacts, so no network target exists before deployment. OpenVAS would be the right choice for vulnerability assessment of running infrastructure, not registry images.

Immediately apply the patch to all systems to minimize exposure

Why it fails: Deploying patches directly to production without prior validation bypasses critical quality assurance controls. This reckless approach can trigger severe system instability, application incompatibility, or unexpected downtime across the entire enterprise infrastructure, turning a potential security risk into an immediate operational self-inflicted denial of service.

Review the CVSS score to decide if the patch is necessary

Why it fails: While Common Vulnerability Scoring System (CVSS) metrics help security teams prioritize which vulnerabilities to address first based on severity, they do not dictate whether a specific vendor patch is safe to deploy. Relying solely on CVSS scores bypasses the essential testing phase, potentially introducing breaking changes to critical business workflows.

Verify patch compliance by checking the vendor's advisory

Why it fails: Checking the vendor's advisory is a useful step for understanding the vulnerability's scope and verifying compliance post-deployment, but it does not validate the patch's behavior within your specific environment. Compliance verification is a retrospective audit activity rather than an active risk-mitigation step during the initial deployment phase.