Difference between revisions of "Incident Response"

Revision as of 13:04, 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 can be considered a risk management function that responds appropriately to an incident, protecting the organization from further impact and directing recovery. It may also be considered a part of Operations.

Process

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

• Detect
• Contain
• Eradicate
• Recover
• Lessons Learned

Adding to this, it is recommended to have a process for Table Top exercises.

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

Some tools which may be considered including

1. Reporting system for users to report incidents
2. A central repository for collecting large files from numerous locations
3. Out of band communications channels, if needed
4. Screen sharing and phone bridge information
5. Communication templates
6. The Documentation should including policy supporting the requirement to report incidents within a specified time frame. Refer to any regulatory compliance that you may need to adhere to.

Forensics teams, whether staffed internally, through a vendor or hybrid model, will likely require additional tools.

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.

Regardless of the team composition, it is advisable to consider no less than one individual who is accountable for the CSIRT Process and is an Incident Coordinator with an assigned backup. Depending on the size of the organization, more than one coordinator may be required.

The Coordinator must be empowered through the accountability to request that Ancillary teams perform in response to an incident. That coordinator also acts as a conduit for Communications to Senior Management and directs response according to any input from the response team.

In Federated models of CSIRT, the CSIRT owner becomes a collection point whereby the Federated teams should be required to report their incidents above an established severity and criticality so that such incidents may be tracked. The organization should not be surprised by a severe incident which a subsidiary or federated team is responding to.

Budgeting

In the beginning, the most important budget is that of the CSIRT owner and Coordinator. Whether that role is a Full Time Employee (FTE) or a partial FTE, there will be impact to the staffing of the organization. Factoring that in and having a checkpoint to review the number and severity of incidents is a good practice to consider.

Communications

During an Incident, there are several important factors to consider for Communicating in addition to any that your team has identified.

1. Have a planned Communication template with minimum data elements which will be reported on. These should including the state of the incident, its severity, who is responding and next expected communication.
2. Establish communication cadence based on severity and criticality at regular intervals.
3. Ensure that there is a forum, bridge, chat session or similar medium where required team members can join during an incident with ease
4. Anticipate the need to

As with all the material here, use your own judgement.

Documentation

1. Documenting the process and presenting that process to stakeholders is a helpful tactic. Getting their input and alignment is also helpful.
2. A policy which identifies that reporting incidents is mandatory and the time frame by which those incidents must be reported is helpful.
3. Have an Incident Response plan
4. Consider starting with simplicity and alignment
5. Documenting the evaluation criteria for severity and criticality is helpful

Lessons Learned | Pain Points

• Lean and agile can work.
• Establish communication protocols in advance, this can be quite helpful
• Simple is better than complex and complex is better than complicated.

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

NIST SP 800-61r2