Review of NIST Publication SP 800-61 "Computer Security Incident Handling Guide". Part 2

Ruslan Rakhmetov, Security Vision

In the previous article we described the organisational recommendations of NIST SP 800-61 ‘Computer Security Incident Handling Guide’. This article focuses on the technical recommendations for managing cyber incidents.

According to NIST SP 800-61, IS incident response consists of several interrelated processes:

1. Preparation

2. Detection

3. analysis

4. Containment

5. Remediation

6. Restoration

7. Post-incident actions

Next, we will describe in detail all the recommendations for building the above cyber incident management processes.

1. Preparation.

The NIST SP 800-61 document emphasises the importance of making maximum effort to prepare for responding to and avoiding cyber incidents.

1.1 Preparing to handle IS incidents.

NIST publication SP 800-61 emphasises the importance of full and early preparation of all resources and tools to effectively respond to IS incidents, as well as the need to have redundant, reliable means of communication, collaboration, and coordination in case they fail or are compromised.

1.1.1 Ways to communicate and ensure cyber incident response:

1) Contact information of IS Incident Response Team (hereinafter referred to as IRT) members, company employees, and external contractors, including contact information of primary and backup personnel, including phone numbers, email addresses, messenger aliases, and ways to verify the authenticity of the contact;

2) Duty shift information for other teams in the company, including information needed to escalate requests;

3) Ways for users to report incident information, including phone numbers, email addresses, web forms, messengers; and at least one method must allow for anonymous reporting;

4) Ticketing system for storing incident information and monitoring incident status (currently included in IRP/SOAR systems);

5) Smartphones for communication between CRIIB members with the necessary software installed;

6) Software for encryption of information, if necessary;

7) Dedicated meeting room/conference room (a.k.a. war room, literally ‘command centre’) for CRIIB members to work together;

8) Dedicated space for secure storage of incident-related items.

1.1.2 Software and hardware for analysing cyber incidents:

1) Devices and drives to create disc images, store logs, and store other incident-related information;

2) Laptops for analysts' work, including analysing data and traffic, and preparing incident reports;

3) Spare equipment, including workstations and servers, networking equipment, virtual machines for response activities such as information recovery or VPO analysis;

4) Clean drives;

5) Printer for printing significant information;

6) Packet sniffers and protocol analysers to capture and analyse network traffic;

7) Device and drive forensics software;

8) Media with software for collecting evidence from devices and systems;

9) Accessories for the correct and legally relevant collection of evidence and testimonies, such as video and audio recorders, evidence storage bags and envelopes, prepared forms for preserving evidence integrity (so-called chain of custody).

1.1.3 Methodological documents for incident analysis:

1) List of standard network ports and typical network ports used by the VPO;

2) Documentation on OS, software, protection systems, devices;

3) Network diagrams, lists of critical information assets in the infrastructure;

4) Baseline data on known normal behaviour of networks, systems, applications;

5) Cryptographic hash sum values of known critical files ( NIST NSRL repository data and xCyclopedia project data can be used).

1.1.4 Incident mitigation software: OS ‘golden images’ and distributions of incident recovery software.

1.2 Incident Prevention.

Cybersecurity and cyber incident prevention is important from a CRIIB perspective because too large a volume of incidents will not allow for a rapid response to each incident, which could result in significant damage, while providing valuable information and guidance to CRIIB members on defence weaknesses. The authors of NIST SP 800-61 emphasise that it is beyond the scope of this publication to list all the possible ways to prevent cyber incidents, but list the main areas of IS assurance:

1) Cyber risk assessment identifies and processes IS risks and identifies information assets whose security posture needs to be monitored and responds to related incidents;

2) Endpoint security should be ensured by applying standardised security configurations, updating software, enforcing the principle of least privilege, logging IS events, monitoring status and configurations;

3) Network security should operate on the principle of ‘everything that is not explicitly allowed is forbidden’ with protection of the perimeter, connection points and network links;

4) The fight against VPO should be provided at the OS level, server applications, at the client level;

5) Awareness-raising of users and administrators can contain ‘lessons learned’ about incidents that have occurred and should help employees to realise the importance of timely reporting of signs of an incident, and administrators to understand the need to securely configure IT systems.

2. Detection.

2.1 Cyberattack Vectors.

It is unrealistic to prepare for all cyber incidents, so the authors of NIST SP 800-61 recommend focusing on the most common types of incidents where common attack vectors apply. A separate response strategy should be developed for each type of incident. The document provides a limited list of generic attack techniques that can be used to develop detailed specific handling procedures (today, we can also recommend using the MITRE ATT&CK matrix to understand the tactics and techniques of modern cyber attacks). The list of typical attack vectors, as of the year of the NIST SP 800-61 publication (2012) was as follows:

1) External / removable drives;

2) Resource depletion (e.g. DDoS or brute-force attacks);

3) Web attacks (e.g. XSS);

4) Email attacks (malicious attachments, phishing);

5) Spoofing attacks (spoofing, MitM attacks, SQL injection);

6) Inadmissible use (violation of corporate policies on the permissible use of information resources);

7) Loss or theft of equipment, devices;

8) Other attacks that do not fall into the above categories.

2.2 Signs of a cyber incident.

One of the most challenging parts of a response can be correctly identifying and assessing potential cyber incidents, including determining whether an incident has actually occurred, what type of incident it is, and its scope and risk. The main challenges in identifying and assessing incidents are the large number of events from different sources, provided with varying levels of detail and accuracy, possible hidden and implicit signs of incidents, and the need for specialised technical knowledge to identify incidents.

Signs of cyber incidents can be broadly categorised into precursors and indicators of IS incidents:

1) A precursor is an indication that an IS incident may occur in the future (e.g., port scans, discovery of a new vulnerability in a company's infrastructure, threats from cyber groups). When precursors are identified, a cyberattack can be prevented by improving the security posture of the potential attack target and the granularity of monitoring.

2) An indicator is a sign that an incident has already occurred or is occurring right now (e.g., messages from antimalware systems, malicious activity, system failures, failed authentication attempts, messages from IT administrators).

Sources of precursors and indicators of cyber incidents can generally include alerts from protection systems (IDS/IPS systems, SIEM systems, anti-virus and anti-spam solutions, integrity monitoring software, messages from third-party monitoring services), logs (logs of OS, software, services, network devices, network flows (netflow, sFlow, etc.)), publicly available information (information about exploits, vulnerabilities), people (internal staff, third-party users).

3. analyses.

3.1 Primary analysis of incident information.

Most incident precursors and indicators can be inaccurate, so incidents can be quite difficult to identify and analyse. Some incidents can be identified by obvious symptoms (e.g., resource unavailability or defacement), but evidence of other incidents may be extremely subtle (e.g., an extra line in a configuration file), so identifying incidents is in many cases a creative task for skilled IS analysts. CRIIB members should analyse and verify each incident in a prompt and coherent manner, following a pre-designed process and documenting each step taken. In the event of a suspected ‘actionable’ incident, CRIIB members should promptly conduct an initial analysis to determine the scope of the incident (what networks, systems, applications are affected), who or what is causing the incident, and how the attack is being carried out (what tools and techniques the attackers are using, what vulnerabilities are being exploited). The initial analysis should provide enough information to prioritise follow-up actions, such as incident containment and deeper analysis of the incident's impact.

The authors of NIST SP 800-61 offer the following recommendations to simplify incident analysis and improve the effectiveness of verifying information about potential incidents:

1) Develop network and system profiles to understand the normal state and behaviour of systems for subsequent change detection, such as by installing integrity monitoring software, examining typical network traffic for different systems, and days of the week;

2) Understanding the normal behaviour of systems, networks, applications by examining audit logs and identifying suspicious events, while liaising with subject matter staff responsible for the relevant infrastructure elements is recommended;

3) Developing an audit log retention policy and configuring log retention times will help identify earlier significant IS events or detect previously undetected IS incidents;

4) Correlating IS events to better identify and understand a possible incident;

5) Time synchronisation across all elements of the infrastructure;

6) Maintaining and utilising an internal knowledge base with documentation, incident descriptions, error codes and alerts, listing effective ways of resolving incidents to facilitate the work of CRIIB members and accumulate experience in a unified information structure;

7) Using Internet search engines to obtain information on detected precursors and indicators;

8) Launching network sniffers to collect additional information from network traffic in case the existing information is insufficient;

9) Filtering data to analyse only significant indicators to speed up the search for attack traces in time-sensitive environments;

10) Requesting assistance from other teams, MSS incident response service providers for prompt resolution of the incident and identification of the causes of the incident to prevent its recurrence.

3.2 Documentation.

When an incident is identified, CRIIB members should immediately begin documenting all facts and evidence related to the incident, while avoiding subjective judgement of the facts identified and respecting the confidentiality, integrity, and availability of the information collected. A ticketing system can be used for documentation and should include the following information about the incident:

1) Current status of the incident (new, in progress, sent for investigation, closed, etc.);

2) Description of the incident;

3) Indicators relevant to the incident;

4) Other incidents related to the current incident;

5) Actions with the incident taken by all members of the CRIIB;

6) Evidence of the integrity of the evidence (chain of custody), in the event of the prospect of litigation;

7) Assessment of the negative impact of the incident;

8) Contact details of involved and interested parties (e.g. system owners, administrators);

9) A list of evidence and testimonies collected as part of the incident investigation;

10) Comments from CRIIB members;

11) A list of next steps to be taken.

3.3 Incident Prioritisation.

Incident handling should be prioritised on the basis of criticality due to resource constraints, assessing the negative impact of the incident on the business and the projected cost of recovering from the incident. Factors to consider include:

1) Functional negative impact of the incident: assessing the impact of the cyber incident on information systems, information, and users, considering both the immediate current negative impact and the long-term impact if the incident is not resolved. Possible categories for assessing the functional negative impact may depend on the volume of systems affected by the incident and the ability to provide services to users.

2) Informational negative impact of the incident: as a result of an IS incident, the confidentiality, integrity, and availability of information processed within the organisation may be affected, and the information may also belong not to the company itself but to its counterparties. Possible categories for assessing information negative impact may include internal confidential information, personal data of customers and employees, trade secrets, official secrets.

3) Incident recoverability: The consequences of some incidents cannot be easily recovered from (e.g., the consequences of a data breach), and the resources required for full recovery should be assessed on a case-by-case basis. The assessment of the ability to recover from an incident may depend on the availability of internal resources, the ability to obtain additional external resources, the predictability of recovery time, and an assessment of the fundamental feasibility of recovering from the incident (e.g., in the case of the release of internal confidential information to the Internet).

3.4 Incident Notification.

When analysing and prioritising an incident, relevant information should be communicated to stakeholders in accordance with the developed response policy, which should specify what information should be communicated to certain individuals in what way and with what frequency - this can be specified in the form of a communication matrix. It should also be possible to escalate an incident if the responsible person does not respond within a certain timeframe - this can be implemented in an escalation matrix. Consideration should also be given to how the incident will be communicated and updated, including ensuring that communication channels are protected and redundant in the event of unavailability or compromise.

4. Containment.

4.1 Selecting a deterrence strategy and methods.

Selecting a strategy to contain (also called containment) a cyberattack is critical to preventing the spread of a cyber incident to the infrastructure and to reducing the level of damage. Properly implemented containment also gives a company more time to develop a strategy for further response. For each type of incident, deterrence should be tailored to the risks and costs involved. Criteria for determining a containment strategy may include:

1) Potential damage to infrastructure and theft of assets;

2) The need to preserve legally relevant evidence of the incident;

3) Availability of services (network connectivity, services provided to others);

4) Time and resources to implement a containment strategy during an attack;

5) Effectiveness of the strategy (partial or complete containment);

6) Duration of the measures applied (temporary measures or workaround, medium-term measures, permanent measures).

In some cases, companies can redirect attackers to ‘sandboxes’ or honeypot / honeynet (bait traps) for controlled learning of attackers' tactics and techniques. It should also be borne in mind that containment techniques in general should be applied as soon as possible to prevent escalation of the incident and horizontal movement of the threat across the network, and some containment techniques may be detrimental to the attacked system.

4.2 Evidence collection and storage.

In order to collect and correctly store legally relevant evidence, rules should be developed and legally harmonised. An audit log should be kept for all evidence, which includes identification information (location, serial number, model name, host name, MAC and IP address of the device); name, title, contact information of the employee who collected or processed the evidence during the investigation; time and date of each evidence processing; and evidence storage locations.

4.3 Identification of attackers.

At the time of a cyberattack, it is best for defenders to focus on containing and eliminating the threat and recovering from the attack. While it is often difficult to unambiguously establish details about attacker entities, it may be appropriate to verify the IP address of the attacker through public IP address ownership verification services and in reputation databases, enrich IP address data from cyber intelligence data providers, and analyse possible communication channels between attackers and the attacked host.

5. Elimination.

The remediation phase follows the containment phase to eliminate all components of the incident, e.g., by removing VPOs, disabling compromised accounts, and eliminating all vulnerabilities used in the attack. During the remediation phase, it is important to identify all elements of the infrastructure that have been compromised in order to completely eliminate the threat. In some cases, however, remediation may be performed during the recovery phase or may not be necessary at all. The authors of NIST SP 800-61 point out that remediation activities are specific to each company and infrastructure, and therefore do not provide detailed instructions for implementing this step.

6. Recovery.

The recovery phase should restore the infrastructure to its ‘pre-attack’ state, restore normal business operations, verify that all systems are operational, and address vulnerabilities to prevent recurring incidents. As part of recovery, systems can be restored from backups (verify that backups were made before the incident), OS and software can be reinstalled from trusted repositories and golden images, software components can be updated, security updates can be installed, and passwords can be changed. You should also review the architecture and security settings of your network equipment, and enable advanced logging and traffic monitoring. Note that attackers often repeat attacks on once-attacked infrastructures, using the same methods that have already led them to success. Full recovery can take a long time, so focus first on ways to quickly improve the overall level of security before moving on to more extensive infrastructure changes.

7. Post-incident actions.

7.1 ‘Lessons Learned’ Analysis.

The stage of analysing the incident, implemented countermeasures and response actions as a result of the incident debriefing will help to improve the company's protection status, draw conclusions on the need to revise current response scenarios or IS policies in general, and allow CRIIB members to improve their skills. A closed incident debriefing meeting should be scheduled within a few days of the incident and should discuss:

1) What exactly happened and when did it happen?

2) How did CRIIB members and other company personnel handle the incident? Did everyone follow the procedures and regulations that were developed? Were these documents adequate to the situation?

3) What information was required as soon as possible?

4) Were actions taken that could have hindered recovery from the incident?

5) What should CRIIB members and management do differently the next time a similar incident occurs?

6) How can information sharing and communication be improved?

7) What corrective actions can prevent similar incidents in the future?

8) What precursors and indicators should be addressed in the future to prevent a similar incident from occurring again?

9) What additional tools and resources are required to identify, analyse, prevent future incidents?

7.2 Use of Incident Data.

The resources expended, types of incidents that occurred, and deficiencies in measures and defences should be analysed to reassess cyber risks, allocate additional resources, and select and implement additional measures and defences. Incident data can also help assess the effectiveness of the CRIIB and the processes in place by using the following metrics:

1) Time spent on incidents: total time spent by CRIIB members; time to detect and respond to incidents; elapsed time between all stages of response; speed of escalation and notification of responders.

2) Objective assessment of the incident: review of logs, reports, completed forms for compliance with established incident response policies and procedures; precursors and indicators that helped identify the incident; incident damage prior to detection; determination of whether the cause of the incident was identified, the attack vector and exploited vulnerabilities were identified, the characteristics of the attacked infrastructure elements were identified; whether the incident was a repeat of a previous incident; preliminary assessment of the financial loss; and a preliminary assessment of the financial impact of the incident.

3) Subjective assessment of the incident: self-assessment by the CRIIB members of their actions, the actions of their colleagues and the work of the CRIIB as a whole; assessment by the owner of the attacked system of the correctness of the response measures taken by the CRIIB.