Incident Response and the HSE Case Study Flashcards

High-Level Incident Response and the NIST Framework

The process of addressing a security concern transitions through several phases, starting from the initial generation of an alert to the final determination of whether an incident is serious, and ultimately how to recover and remediate systems. This high-level workflow focuses on the actions taken after an alert is received, moving through stages of containment, eradication, and recovery.

  • Containment: The immediate objective of "stopping the bleeding" to limit the spread of damage.

  • Eradication: The process of removing attacker footholds, backdoors, and malicious software from the system.

  • Recovery: The phase where systems are restored to normal operations.

Terminology and Definitions

Precise definitions are essential for categorizing and responding to various system behaviors:

  • Event: Any discrete observable occurrence happening on a network or system, such as a login attempt or a firewall blocking a connection.

  • Adverse Cybersecurity Event: An event where the security state is ambiguous. It does not necessarily indicate malicious activity but requires investigation. Examples include a login from an unusual device or an unfamiliar geographic location.

  • Cybersecurity Incident: An event that has been confirmed as malicious and poses an imminent threat to, or actually compromises, the confidentiality, integrity, or availability of systems or information. An example is a compromised account used to exfiltrate sensitive data to a suspicious location.

The NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework (CSF) 2.02.0 provides the foundations for modern incident response planning. Unlike previous iterations that provided concrete, linear life cycles, the 2.02.0 version is outcomes-based and high-level, allowing organizations to implement plans tailored to their specific risks and assets.

The Framework Pillars

  • Govern: The overseer function involving the high-level planning and supervision of cybersecurity strategy.

  • Identify: Focuses on asset management and risk management, identifying what systems exist and what vulnerabilities they possess. This includes vulnerability enumerations.

  • Protect: Involves mechanisms and safeguards used to manage and mitigate risks.

  • Detect: Systems and processes used to spot potential incidents through logging and alert rules.

  • Respond: The actions taken in direct response to a detected incident.

  • Recover: The activities required to return to normal operations after an incident.

Implementation Tiers

NIST provides support documents that serve as implementation patterns. These help organizations develop customized plans by breaking categories down into specific outcomes. For example, under the incident analysis category, outcomes might include:

  • Finding the root cause of an incident.

  • Recording all actions taken, ensuring integrity and provenance for investigation records.

  • Collecting high-quality data to understand the event depth.

Simplified Incident Response Workflow

A practical, simplified adaptation of the NIST framework categories facilitates classroom management and real-world understanding through a linear path, even though real-world response is often cyclical and involves overlapping stages.

Stage 1: Monitoring and Detection

  • Continuous observation of system activity to identify suspicious behavior.

  • Alerts are generated for adverse cybersecurity events.

  • The goal is to decide if the event indicates an incident and requires further action.

Stage 2: Classification and Triage

  • Prioritizing events based on confidence in evidence.

  • Assessing the urgency and scope: which network aspects are affected and if the threat is ongoing.

  • Determining if escalation is necessary.

Stage 3: Investigation and Scoping

  • Recreating the incident story to find the root cause (cause and effect).

  • Identifying the extent of the harm and whether attackers are still active.

  • Techniques include correlating logs from endpoints and networks using a SIEM (Security Information and Event Management) system.

  • Meticulous record-keeping is required, such as logging the order of discovery to identify gaps in response.

Stage 4: Containment

  • Limiting damage by isolating affected systems (using firewalls or EDR systems).

  • Disabling compromised accounts or sessions.

  • Blocking malicious "phoning home" communications to external command-and-control servers.

  • Restricting internal lateral movement by disabling services like Remote Desktop.

  • Containment must balance security with the potential harm of taking essential services offline.

Stage 5: Eradication

  • Removing attacker access and persistence mechanisms (malware, backdoors).

  • Revoking compromised credentials and issuing new ones.

  • Patching vulnerabilities used during the initial entry.

  • Reformatting hosts or using golden images to ensure a clean state.

Stage 6: Recovery and Improvement

  • Restoring systems in order of criticality.

  • Learning lessons from the incident to improve future response posture.

  • Organizations are responsible for their own iterative learning based on local outcomes.

Case Study: HSE Ireland Cybersecurity Incident (2021)

The health care system in Ireland (HSE) suffered a major failure in incident response during the pandemic in 20212021. This case illustrates how ignoring early warning signs can lead to catastrophic outcomes.

Timeline of Failure

  • Patient Zero: An employee opened a malicious Excel document attachment, running a script that established a foothold.

  • Persistence: Two days after initial infection, a persistence mechanism was created to survive system reboots.

  • March 31: Antivirus software on a workstation detected Cobalt Strike (a red-team tool frequently used maliciously) and MimiKatz (a credential-theft tool).

  • Missed Opportunity: The antivirus was running in "monitor mode" rather than "block mode." It generated an alert, but it was not human-monitored, potentially because the team was lax or overwhelmed by log volume.

  • May 12: A third-party endpoint monitoring provider escalated an alert regarding malware on 22 HSE servers and requested a scan.

  • May 13: The provider reported many unhandled threat events on at least 1616 systems.

  • HSE Response: The HSE requested that the servers simply be restarted. This was largely ineffective for remediation and risked losing volatile memory data useful for investigation.

  • May 14: Conti ransomware was activated, encrypting systems across the national healthcare network, including several hospitals.

Containment Challenges

  • The HSE network was flat and unsegmented, making it easy for the threat to spread laterally.

  • Lack of visibility prevented a "scalpel" approach to containment.

  • The Nuclear Option: HSE chose to remove all connectivity for the National Healthcare Network, cutting off hospitals, offices, and patient information systems.

  • Impact: 3131 out of 5454 major hospitals suffered service disruptions or cancellations. Emergency care continued with significant delays due to the shift to manual processes.

Decryption and Recovery

  • May 21: Seven days after the ransomware activation, the attackers provided a decryption key for free.

  • Theories for the Free Key: Potential conscience regarding hospital targets (as suggested by an Irish Times article mentioning German police), political pressure on the gang's host government, or a "goodwill gesture" to encourage payment for the stolen data itself.

  • Tooling: The original decryption tool was buggy. A New Zealand-based company created a improved version of the tool which the HSE used for the restoration process.

Questions & Discussion

Fail-Safe Defaults

  • A principle from the Saltzer and Schroeder paper states that systems should have a fail-safe default. In the HSE case, failing to block malicious services (failing unsafe) allowed the infection to persist. It is generally better to have false positives (blocking a benign service) than false negatives (allowing a malicious service).

Resistance to Ransom

  • Norse Kaijo Case Study: This company refused to pay a ransom demanding 4,000,0004,000,000. They reasoned that since they would have to perform recovery and spend tens of millions of dollars to secure their systems anyway, paying the ransom provided no long-term guarantee of safety. They were able to recover because they were prepared with good backups.

Discussion on Attacker Intentions

  • A student suggested the free decryption tool might have been used to exfiltrate more data. While possible, investigators usually analyze such tools in isolated environments. The consensus remains that the attackers provided the key without payment, potentially due to the unintended severity of targeting a national health infrastructure compared to a typical corporate target like a university.