returnreturn
Follina a silent Client-Side

By:
CSIRT Team

SHARE

Twitter Facebook linkedin
References

⦁ NIST SP 800-61 Rev. 2
- Computer Security Incident Handling Guide
https://csrc.nist.gov/pubs/sp/800/61/r2/final
⦁ Public Incident Response Ressources
https://gitlab.com/syntax-ir/playbooks/

Guide to an effective IR Playbook

Let's imagine that you are on a normal working day, the phone rings and you receive the news: a cybersecurity incident has just exploded, the timer starts ticking, time is critical.
What do we do now? It's the question others ask us without knowing that we're not clear on how to act either.We are seized by urgency, every memory of our years of experience is blurred, every note we have taken during years of classes and trainings is out of reach, we make the decision: TURN OFF / CUT THE WIRES

We wake up! It was only a dream

Within the cybersecurity incident response we find a series of guides and procedures for the development of the different tasks, also called playbook. We can understand it as an emergency guide in the world of cybersecurity. A meticulously prepared plan that guides us through different stages, tells us in a way "what to do", step by step in stages to for example contain the situation.

The aim of these documents is not only to reduce the risks of improvisation under pressure but also to enable a more efficient response to the situations contained in the Playbook.Every second counts!

Elements of a Playbook

An effective incident response playbook generally contains just enough detail to allow you to understand what to do in a general way, without being a complete procedure, the "WHAT" not the "HOW". For example, a playbook designed for malware will not tell you what command to run on an infected terminal, but it may tell you to check for changes in OS services.

We can also find in these, several aspects relevant to incident management that are not directly related to the incident in progress, but are of value for other stages, such as notification of third parties, or collection of indicators for intelligence.

Here we prepare a list of key features that a playbook could contain:

Detection and Alert Generation Procedures: Clear instructions on how to identify and alert about the incident. What is an incident and what is not?

Roles and Responsibilities: Some detailed definition of the roles and responsibilities of the response team, including emergency contacts and larger scale decision-makers important for critical decision-making.

Incident Categorization: Some type of system to categorize incidents, according to severity, type and urgency, this helps us to prioritize the response.

Initial Response Steps: A step-by-step guide for initial actions once an incident is identified, typically including containment and evidence preservation.

Communication Procedures: Some definitions for communicating about the incident internally or externally (Customers, Authorities, Regulators, Other stakeholders).

Containment Strategies: Here we can find defined (when applicable), what are the methods and procedures to limit the scope and impact of the incident.

Eradication and Recovery Strategies: Instructions for removing the threat and restoring affected systems to their normal operating state.

Post-Incident Analysis: Procedures for reviewing and analyzing the incident after its resolution, identifying lessons learned and improvements for the future.

Documentation and Recording: Instructions on how to document all phases of incident management, which is crucial for subsequent analysis and possible legal investigations.

Testing and Upgrades: A definition of the process for periodically testing and updating the playbook to ensure that it remains relevant in the face of new threats and changes in the IT environment. This may be set out in other documents as well.

Checklists and Resources: Inclusion of practical checklists and links to useful resources, such as forensic analysis tools, external support contacts and communication templates. Functions as a basic toolkit.

Integration with Business Continuity Plans: We can say that a playbook will never be an isolated document, it is important that it is aligned and integrated with other plans such as BCP or DRP (Business Continuity or Disaster Recovery).

Key features of a Playbook

A well-crafted playbook is a vital tool that will guide the response team through the complexity (and stress) of responding to an incident, ensuring that every action taken is thoughtful and planned. And so we share with you some key characteristics for what we can call "A Good Playbook".

EStandardized: Steps and procedures should be defined at least on a large scale using some standard, aligning with best practices such as those established by NIST (U.S. National Institute of Standards and Technology) in its Incident Response Guide (NIST SP 800-61).


General Incident Response Stages - NIST800-61

Tailor-made: Contrary to the previous idea, an efficient playbook will be the one that best fits the organization. As in risk management, decisions are not directly related to the technology or the threat, the other side of the coin corresponds to the environment in which you are working, including among others technology, people, processes, experiences, maturity, compliance.

Downloading a model playbook for a particular threat from a public repository should only be used as a possible starting point, generic guides are of no real value.


Malware Incident Analysis Workflow Extract - Public Playbook

Post-Incident Analysis and Continuous Improvement: The process of analyzing and learning from each incident, that "continuous improvement" of security practices. We can align this point in the eyes of a standard, for example, with the continuous improvement approach of ISO/IEC 27001 and the PDCA (Plan-Do-Check-Act) cycle so typical when we talk about improvement.

Perhaps it is an overly optimistic view, consider that each incident is a unique opportunity to improve, a scenario where the only way to obtain value is to generate some change, record or knowledge, however minimal it may be, that will allow us to be better prepared for the next "Iteration".

Periodic Assessments and Drills Performing regular testing, simulation of incidents allows us to test the effectiveness of the playbook, we can find recommendations on how to approach these tests, for example in ISO/IEC 27035

These tests are the way we have to "bring the incident to our organizations" and in a controlled way to test what is planned.

Some conclusions

Incorporating these key features can ensure that response plans are not only effective, but also that they meet standards, we are building on experience, we are not reinventing the wheel.

The elaboration of a playbook itself is a process that from the beginning brings special value to the incident response, a progressive approach is usually the best way that will allow us to obtain great results over time. Consider this type of documentation as a living element that evolves along with the organization.

Within the perspective of custom playbooks, we can also mention that it will not be the same to act against a ransomware incident compared to a data exfiltration in the Darkweb. Each type of threat will have different tasks, priorities, responsible, each playbook will open the door to a set of these threats. We can always generate a new, more specific playbook, we must find the balance point for our environment.

Despite all the planning we do, we must know that we will encounter situations that are not defined in our procedures, at that moment is where the expertise and tenacity of the professionals involved in the incident will be crucial to navigate the incident, only using the playbooks as a compass.