Notes from Chris Dale's Practicing Incident Response

To further my knowledge of incident response (IR), I decided to watch a YouTube video by another SANS instructor, Chris Dale. [1]

Understanding the SANS and NIST Methodologies: Foundations for Effective Incident Response

IBM defines incident response as:

"Incident response (sometimes called cybersecurity incident response) refers to an organisation’s processes and technologies for detecting and responding to cyberthreats, security breaches, or cyberattacks. A formal incident response plan enables cybersecurity teams to limit or prevent damage." [2]

SANS practices a six-phase methodology for IR. It’s important to understand that this methodology isn’t a waterfall model. It’s not always a case of moving from one phase to the next in a linear sequence; sometimes, you may need to go back to a previous step to make adjustments before moving on. The SANS six-phase methodology consists of:

1. Preparation

In the Preparation phase, Chris Dale highlights that this is where we lay the groundwork for effective incident response. It’s about setting up processes, technologies, and training to ensure we're ready for potential incidents. This includes establishing robust logging and monitoring systems, creating and maintaining IR playbooks, and ensuring the team is well-trained. Essentially, it’s about getting everything in place so that when an incident does occur, we’re well-equipped to handle it.

2. Identification

Chris Dale refers to the Preparation and Identification phases as the "Study" phase. In the Identification phase, which mirrors NIST’s Detect and Analyse, the focus is on detecting and understanding the incident. Effective identification requires comprehensive monitoring tools and trained staff who can spot and analyse anomalies. This phase involves not just recognising an attack but understanding its nature and scope, which can significantly influence the subsequent response actions.

3. Containment

The Containment phase, according to Chris Dale, is crucial for stopping the incident from causing further damage. The goal here is to "stop the bleeding" and prevent the situation from worsening. This involves isolating affected systems, applying temporary fixes, and preventing the spread of the threat. Techniques might include segmentation, isolation, patching vulnerabilities, and changing passwords to limit further infiltration or lateral movement within the network.

4. Eradication

In the Eradication phase, Chris emphasises the need to completely remove the threat from the environment. This includes eliminating malware, deleting backdoors, and applying patches. It's important to ensure that all traces of the adversary are removed from the systems and that any vulnerabilities exploited during the attack are addressed. This phase is about clearing the way for recovery by ensuring that the threat is no longer present.

5. Recovery

The Recovery phase focuses on restoring normal operations and ensuring that systems are secure. According to Chris, this phase involves restoring affected systems from backups, monitoring for signs of re-infection or recurring issues, and confirming that the systems are operating normally. It also involves communicating with stakeholders and ensuring that business continuity plans are effectively implemented to minimise disruption.

6. Lessons Learned

Finally, Chris Dale underscores the importance of the Lessons Learned phase, which is often referred to as Post-Incident Activity in NIST’s framework. This phase involves conducting a thorough review of the incident to understand what happened, how it was handled, and what can be improved. It’s essential to document findings, update IR plans, and provide additional training to address any gaps identified during the incident. Despite the urge to quickly return to normal operations, taking the time for this review is crucial for improving future incident responses.

Comparing SANS and NIST Methodologies

This methodology is very similar to, but not identical to, the NIST IR Framework. The differences are:

• Identification is broken into two stages in NIST: Detect and Analyse.
• Containment, Eradication, and Recovery are combined into a single stage in NIST.
• Lessons Learned is referred to as Post-Incident Activity in NIST.

When developing playbooks, it’s essential to recognise that no two incidents are the same. Playbooks should be designed to guide responses rather than provide exact instructions. This flexibility ensures that each unique incident is addressed effectively, taking into account the specific context and requirements.

Evaluating Potential IR Scenarios

Scenario 1: Sensitive Information is Leaked and You’re Contacted by the News

Preparation:
Start by appointing a media contact to handle communications with the press and stakeholders. Inform the entire company or team about the situation and decide whether to notify peers, customers, suppliers, and other relevant parties. First and foremost, verify the authenticity of the leak to confirm it is not a false claim.

Identification:
Conduct comprehensive searches on the internet to gauge the extent of the leak. Consider employing strategies such as using a "honeypot" or fake user credentials to check if they have appeared on forums, pastebins, or dark web sites. This helps in understanding where and how the information was exposed.

Containment:
Determine the communication approach—whether to disclose the breach widely or to maintain a degree of secrecy. If transparency is the chosen route, carefully craft your messaging. Develop a detailed marketing and PR strategy to manage the situation and mitigate potential damage to the organisation’s reputation.

Eradication:
Address the root cause of the leak by removing any malicious elements responsible for the breach. Strengthen security controls to prevent future incidents and collaborate closely with legal and compliance teams to handle any legal implications and ensure compliance with regulatory requirements.

Recovery:
Restore affected systems to normal operation and continue to monitor for any signs of recurring issues. Implement the communications plan and follow the business continuity plan (BCP) to manage the aftermath and ensure that operations resume smoothly.

Lessons Learned:
Conduct a thorough post-incident review to document findings and assess the response. Identify any gaps or areas for improvement and update the incident response (IR) plan accordingly. Implement necessary training and awareness programmes to prevent similar incidents in the future and enhance overall incident response capabilities.

Scenario 2: IDE Plugins Used to Attack Developer Environments

Preparation: Establish clear usage policies for IDE plugins. Ensure that only trusted and vetted plugins are allowed in the development environment. Implement a vetting system to assess the security and legitimacy of plugins before they are used.

Identification: Monitor for unusual activity related to plugin usage, such as unexpected or suspicious downloads. If a plugin is downloaded outside of normal usage patterns, consider quarantining and further vetting it. Confirm whether the plugin is malicious, determine its payload, and assess its impact on the development environment.

Containment: Isolate affected systems to prevent further infiltration or lateral movement. Disconnect them from the network as a precaution. Apply necessary patches to address vulnerabilities exploited by the malicious plugin.

Eradication: Remove any remnants of the malicious plugin from the affected systems. Strengthen security measures by requiring admin approval for the download and use of untrusted plugins. Consider implementing access controls or a zero-trust approach to limit potential threats.

Recovery: Restore affected systems to normal operation. Monitor the environment for signs of recurrence or any residual issues related to the attack. Ensure that all systems are secure before fully reintegrating them into the network.

Lessons Learned: Conduct a comprehensive post-incident review to document what occurred and how it was handled. Update policies related to plugin usage based on the findings. Implement training programmes to raise awareness and improve response capabilities for similar incidents in the future.

Conclusion

In practice, scenarios like sensitive information leaks or attacks through IDE plugins underscore the importance of foundational principles. For instance, managing a sensitive information leak requires clear communication strategies and robust verification processes, while addressing malicious IDE plugins demands stringent vetting and continuous monitoring. By applying these fundamental steps to such specific scenarios, organizations can improve their ability to respond effectively, mitigate damage, and enhance their overall incident response capabilities.

To address a broader range of threats, such as DDoS attacks, phishing, and ransomware, it’s useful to apply general principles and methodologies. This approach ensures a comprehensive strategy for responding to various types of security incidents.

References:

[1] - Practice and prepare for Incident Response - https://www.youtube.com/watch?v=fS4t70gdhZA
[2] - What is Incident Response? | IBM - https://www.ibm.com/topics/incident-response