Review of the publication NIST SP 800-61 "Computer Security Incident Handling Guide". Part 1.

Ruslan Rakhmetov, Security Vision

For effective response to IS incidents it is extremely important to build a clear process of cyber incident management in advance, because it is at the moment of incident occurrence, under conditions of stress and possible lack of resources, it is necessary to perform all the necessary response stages as correctly as possible. To solve this problem, you can use the guidelines in NIST SP 800-61 Rev. 2 ‘Computer Security Incident Handling Guide’ (‘Computer Security Incident Handling Guide’, version 2), which was released in 2012, but conceptually is not outdated, because the framework proposed in it can be adapted to modern technologies and current cyber threats. This document describes the organisational and technical aspects of responding to cyber incidents, and today's post is an overview of the organisational recommendations of NIST SP 800-61.

The NIST SP 800-61 document suggests using the following definitions:

- An event is any recorded occurrence on a system or network (e.g., a user connecting to a file server, a web request being processed by a server, an email message being sent, a firewall blocking a network connection).

- An adverse event is an event with negative consequences (e.g. deliberate software failure, unauthorised access to data, unauthorised use of elevated privileges, malware launch).

- A cyber incident is a breach or imminent threat of a breach of IS policies, acceptable use policies, or standard IS practices.

When building a cyber incident management process, it is important to develop a cyber incident response policy, plan and procedures.

A cyber incident response policy should be tailor-made for each individual organisation and should include elements such as:

1. A statement of the involvement of the company's leadership in the cyber incident response process and an understanding of its importance at all levels of the company;

2. Goals and objectives of the policy;

3. Terms and definitions to create a unified conceptual framework;

4. Organisational structure and allocation of roles, responsibilities, authorities and decision-making levels;

5. Levels of criticality and prioritisation of incidents;

6. Performance metrics for the cyber incident response process;

7. Forms for reporting and sending notifications.

The cyber incident response plan should reflect a formalised, agreed and organisation-specific approach to responding to cyber incidents, which will reflect the following elements:

1. The mission, strategy, and objectives of the cyber incident response plan;

2. Alignment of the plan by company leadership;

3. the company's overall approach to responding to cyber incidents;

4. Structure of the cyber incident response team;

5. The way the response team interacts with company employees and with other companies;

6. Metrics for assessing the capabilities and effectiveness of the company's cyber incident response function;

7. ‘A roadmap for increasing the maturity level of the company's cyber incident response function;

8. The relationship of the cyber incident response function to other functions in the company.

Cyber incident response procedures should be supported by a response policy and plan and should detail technical processes, actions, techniques, checklists, and reporting forms. Separate response procedures should be developed for each type of incident to address the specifics of the company's infrastructure and specific response activities for a particular type of incident.

As part of the development of cyber incident management documents, the format and method of interaction with third parties in the event of an incident should describe:

1. Media relations: designate a person responsible for media relations, consider the need to involve the legal department when communicating with the media, provide for the format and volume of information to be reported about the incident to reduce the amount of public information useful to attackers, consider a format for briefly discussing the details of the incident with media relations officers, provide for ways to update information about the incident to the media, instruct company employees on possible formats for interacting with the media, and provide information about the incident. It is also recommended to conduct practice interviews, working out in advance the answers to questions about who attacked your company and why; when, how and why it happened; how disruptive the incident was and how the internal investigation is progressing; what the consequences of the incident were; whether legally protected information (e.g. personal data) was affected; and what the preliminary financial impact of the incident is.

2. Government relations: Depending on the country, companies may be subject to different requirements for notifying government agencies when an IS incident is identified. A government liaison should be appointed who should be familiar with the format of the liaison and be legally and technically prepared.

3. Interaction with cyber incident response centres: mandatory reporting of information about a cyber incident to government cyber incident response centres (in Russia, these are FinCERT and NCSCI) or sharing information about incidents that have occurred and receiving assistance from industry or commercial cyber incident response centres.

4. Interaction with the Internet provider: blocking network traffic (e.g., in the event of a DDoS attack), saving and receiving logs of network connections.

5. Interaction with the owner of the attacking IP address: in case of an attack, it is possible to interact with the Abuse contact of an external ISP or with the owner of an offline system.

6. Interaction with vendors: interaction with an IS vendor can help when there are questions about the operation of an anti-virus or when false positives are likely, and interaction with a software vendor can help exchange information about possible vulnerabilities or new vectors of attacks on software.

7. Interaction with third parties affected by the incident: customers, counterparties, suppliers, contractors may be affected by an incident that occurred within the company, or they may report an incident that your company may be the source of. In both cases, the format of the interaction and the amount of information communicated externally should be anticipated.

NIST SP 800-61 also discusses various options for cyber incident response team structure, which may consist of full-time employees or be partially/fully outsourced:

1. Centralised response team: this model is appropriate for smaller organisations that are not geographically dispersed.

2. Distributed response team: this model is suitable for large geographically dispersed companies where each segment or branch is responsible for its own dedicated team. All branch response teams are centrally managed and coordinated by the head office.

3. Co-ordinating team: can be used to assist and provide services where there is no direct reporting line between the teams in the various branches.

The following factors should be considered when selecting a response team structure:

1. The need for a 24/7 team: the need for 24/7 operation may be dictated by the structure of the company's business processes, and a 24/7 on-call shift is recommended.

2. Full-time or part-time team members: Some phases of a cyber incident response may be performed by employees who work full-time in other departments, such as IT, but who are assigned to the response team for the duration of the incident.

3. employee motivation: the lack of skilled professionals and the complexity of working around the clock in the response team leads to expected recruitment challenges, so it is recommended to relieve team members of administrative burdens and reduce routine operations, which can be achieved, for example, by using IRP/SOAR-class solutions such as the Security Vision Incident Response Platform.

4. Costs: The company may underestimate the budgeting of a 24/7 shift, including labour costs and the costs of software and security software, as well as the technical support of the team (premises, communications, equipment).

5. Employee experience and expertise: handling cyber incidents requires specific expertise, and MSSP providers may have stronger expertise but lack a deep understanding of company-specific processes. In-house employees have a deep understanding of a particular company's infrastructure and business process context, but may lack a broad knowledge base of incident handling and up-to-date information on cyberattack trends.

The following factors should be considered when outsourcing some cyber incident response functions to contractors, such as MSSP providers:

1. assessing the quality of the outsourcing company's performance, not only current performance, but also future prospects for co-operation, including the outsourcing company's investment in its services and specialists.

2. Division of responsibilities: some critical operations the company will probably perform independently (e.g. isolation of hosts, disabling accounts, etc.), so it is necessary to define in advance the areas of responsibility and the actions to be performed.

3. Outsourcing sensitive information to a contractor: defining areas of responsibility, delineating access rights, signing non-disclosure agreements, using technical methods to conceal certain sensitive information can help to address the issue of internal information handling by outsourcers.

4. Lack of knowledge about the specifics of the organisation's infrastructure, lack of access to certain security event logs, lack of physical access to equipment - these typical limitations of contractors' work should also be considered.

5. Maintaining the level of internal competences: in various situations outsourcers' services may become unavailable, in which case it is important for the company to have its own employees who can correctly respond to an incident themselves.