Incident management

• Making essential information available
• Log management and evidence capture
• Evidential data capture
• Technical response
• Triage
• Containment
• Analysis
• Remediation / eradication
• Recovery

Network information

Having a clear understanding of your network is important for all response stages. It can reduce the discovery phase of a technical investigation from days to hours. It can also ensure successful containment and remediation actions are taken.

Network diagrams and supporting information should be available to show at least:

• Internet gateways
• IP address ranges and any separate VLANs
• remote access
• key systems (file servers, platforms, domain controllers, webservers)
• physical locations of servers

You should also document all security devices and software which could be useful during incident response.

Evidence and log availability

Any incident will require at least some basic data for triage and analysis.

Keep in mind that evidence can be just as important for proving something didn't occur, as proving that it did.

Types of evidence and logs

When considering what and how to go about logging, you should refer to good practice guidance and gather input from any external security providers. The NCSC's Introduction to logging is a good place to start your research.

You should also explore a number of incident scenarios, so that you know what data may be required in order to investigate such events.

Typical log and evidence categories should include:

• External network communications:
• Network traffic – metadata and packet capture (firewalls, IDS/IPS, proxies, DHCP, DNS)
• Emails - email logs, full email files, audit logs for the email systems
• Authentication and access:
• Account activity - domain controller and active directory logs
• Remote logins - as above plus potentially RDP, VPN and similar
• (other) Internal network activity:
• Local system activity - event logs, antivirus logs, any other host security software logs, and full images or memory dumps of the systems
• Web facing systems: Web logs and potentially similar host logs to above
• Other systems and specialist software may also need to be considered:
• information storage (document management systems and databases)
• financial systems
• operational technology systems – you should consider what logs and evidence exist for these
• cloud service specific logs

Asset and configuration information

In addition to these logs and evidence sources, you should also document your IT assets and configurations.

This information is particularly useful during incident response as it will help you to understand the 'where' and 'what' of the assets which are affected and assess the severity of the incident.

The NCSC's Introduction to logging provides greater detail on how logs can be organised and retained. However, we outline below a minimum and enhanced approach to logging and evidence capture.

The minimum:

• Document what log and data sources are available, to save valuable time during an incident
• Know how to access and retrieve logs for analysis, and who can do this
• Check that the logs are easily searchable - for example, can you search for a specific IP in firewall logs over the last 2 months?
• Ideally, retain logs for at least 3 months – longer if possible - and ensure archived logs can still be extracted
• Be able to provide access to physical machines. If full disk encryption is used, ensure decryption keys can be obtained and data decrypted.

To enhance evidence and logging for investigations:

• Ensure all evidence or log sources are synced to the same time server and timezone (this can help immensely in correlating events)
• Train staff on the basics of capturing memory and disk images if appropriate
• Ensure all logs have the relevant fields, or related logs are available to correlate - for example there may be a need to correlate DHCP logs with firewall logs in some setups
• Ability to retrieve logs in plain text format for analysis by other parties if required

Additional measures to improve evidence capture and log availability:

• Stream logs to a central location and system to enable rapid correlation and analysis (such as SIEM tool or SOC). This may also include local event logs from hosts.
• Retain full packet capture (for a shorter time)

The technical response typically consists of the triage, containment, analysis, remediation and recovery stages. These stages may include non-technical elements such as media handling or legal considerations. Note that team skills and experience are just as important as technology to a successful response.

The stages of technical response are shown in the diagram below. A fuller diagram showing other non-technical elements is provided in the Cyber Incident Response Process section.

A fluid process

The stages within the technical response process cycle and overlap. For example, some less critical analysis may take place during the remediation phase. Similarly, containment and mitigation actions may be taken throughout the initial analysis stages.

The capabilities of your suppliers

If you rely on suppliers (such as managed infrastructure or hosting providers) to undertake technical actions, you should consider their capabilities, availability and the Service Level Agreements (SLAs) in place with them.

Triage involves the classification of the incident type and severity, so that subsequent actions can be prioritised. It is primarily guided by clear set of incident type definitions, and the observed impact of the incident. A more detailed treatment of the the classification process, can be found in the section on Developing Cyber Incident Processes.

This stage is heavily reliant on the availability of evidence and data along with the ability to analyse it.

In this phase, action is taken to prevent further spread of the threat, or in some way lower its impact.

This work should be undertaken as soon as possible, and should continue throughout the incident response process. See the remediation section below for a list of specific actions.

Typically, the priority at this stage is to learn enough to contain, and ultimately remediate an attack. However, to do this, you may also need to understand both the conditions which enabled the attack and develop a detailed picture of the attacker's actions while they had access to your systems.

As you discover new information, you may need to cycle between this stage and your containment / mitigation work.

In order to perform some basic triage and analysis in-house, the following steps may be useful:

• Engaging with users to understand what they observed or did (e.g. clicking a link)
• Analysis of logs such as Active Directory, remote access and email to understand the activity. In some cases, this may involve basic searching of network traffic logs (e.g. firewall)
• Use of open source threat intelligence (e.g. blogs and open source sandboxes).

Many incidents require more complex analysis. This will include such things as:

• Full host (disk/mobile/server) forensics
• Network traffic and log analysis (often very high volumes so can require specialist tools)
• Advanced malware analysis
• Correlation of many different event, log and data sources

This type of analysis is often outsourced to specialists. However, for organisations which are heavily targeted, growing a more advanced capability in-house can be beneficial and reduce costs. It also means the people doing the analysis will already have an in-depth understanding of your networks.

Analysis may continue during the remediation / eradication stage in some cases. For example, when enough of the threat is understood to fully remove it from the network, but more analysis is needed to establish exactly what happened during the attack, so that legal, regulatory, and other external stakeholders can be informed.

In this stage, the threat is fully removed from your network.

Containment and Remediation, while different, often require similar capabilities:

• Isolation of systems (can include critical systems, virtual machines, websites)
• Reset of credentials and ability to block or lockdown remote access
• Blocking in/outbound traffic and emails
• Removing malicious files (clean or rebuild machines, clean user profiles, scan with AV, deploy a script).

Remediation requires careful planning.

At this point, there is a high level of confidence that the attacker has been removed. The primary goal at this point is a return to 'business as usual.' This means getting the network back to a clean state, and finalising things like regulator, media and customer handling.

With clean systems back online, temporary blocks and other measures can be removed, unless you see value in keeping them on a more permanent basis.

Considerations for technical recovery

In the worst case scenario, where data or systems are damaged (e.g. encrypted by ransomware) or lost, backups should be available to recover from and/or spare devices and systems made available.

To aid the recovery process, you should:

• Have offline / segregated backups of your data as online backups could be affected.
• Retain backups for a period of time, rather than just have a single rolling backup as this does not provide much protection if an infection/damage isn't noticed before the backup is overwritten.
• Consider how long it may be before something is detected and ensure your backups are kept for longer – a month at least.
• Consider making backups of system configurations (e.g. specialist systems)
• Review the availability of spare devices. You may need to replace or fully rebuild devices if the infection is unknown and/or hard to remove.