Difference between revisions of "Incident Response"

Revision as of 09:06, 23 October 2018

Objective

"A computer security incident response team (CSIRT) is a concrete organizational entity (i.e., one or more staff) that is assigned the responsibility for coordinating and supporting the response to a computer security event or incident. CSIRTs can be created for nation states or economies, governments, commercial organizations, educational institutions, and even non-profit entities. The goal of a CSIRT is to minimize and control the damage resulting from incidents, provide effective guidance for response and recovery activities, and work to prevent future incidents from happening." (Robin Ruefle, 2007)

The CSIRT or Incident response team is a risk management function that responds appropriately to an incident, protecting the organization from further impact and directing recovery.

Process

NIST SP 800-61r2 details this process, which can be broken down into several steps:

• Detect
• Contain
• Eradicate
• Recover
• Lessons Learned

These are pragmatic and work well in an environment. When implementing Incident Response teams, it is advisable to seriously consider using a simple process first and build complexity based on lessons learned.

Tooling

The Incident Response team must be able to receive reports that an incident is occurring. It is ideal to have that come to a team, not an individual person. The organization should have a reporting mechanism which can be as simple as a shared email box or a website which collects critical information. Some organizations have a more detailed regulatory requirement.

That reporting mechanism should be setup in a way that

1. Makes reporting easy enough that there are few barriers to submission
2. Supports validating compliance with a policy for reporting incidents
3. Supports reporting the number of incidents and their severity/criticality

Ticketing

While a ticketing system for Continuous Monitoring, or that which is in use for Security Incident Investigations, may be applicable, the most important part of Incident Response is to track numerous activities which are assigned to various parties. Some organizations use the Enterprise ticketing system for Incident Response tasks if they are able to. Critical data elements for ticketing are:

1. The task name
2. The task description
3. The assignee
4. When the task was assigned
5. Notes
6. Any required logs

Ideally, the ticketing system will collect all this information under one project, epic or other overarching organization which allows for metrics. In mature organizations, the amount of time spent on the tasks can be collecting allowing for more robust reporting.

Incident Coordinators must track these assignments and validate their completion. The collection of these tasks in a ticketing system is ideal and reduces Enterprise Amnesia

Reporting

Reporting the status of the incident will be discussed under the Communications Section.

Each organization must adapt their reporting to their needs, however some good starting points for reporting are:

1. How many incidents are occurring, grouped by severity & criticality
2. What organizational units are affected by incidents
3. What the type of incident was (e.g. Policy Violation vs. Malware Infection)
4. Mean Time to Contain (MMTC) - which is the amount of time between when the organization discovered an incident was occurring and when the incident was declared contained.

Staffing

NIST SP 800-61r2 discusses Centralized, Distributed and Coordinating as Team types.

Budgeting

Communications

Documentation

Lessons Learned | Pain Points

Citations

Robin Ruefle. 2007. Defining Computer Security Incident Response Teams. Retrieved from https://www.us-cert.gov/bsi/articles/best-practices/incident-management/defining-computer-security-incident-response-teams

Additional Reading