As security professionals our job is to safeguard the Confidentiality, Integrity and Availability of the information and assets placed in our care.  A Security Incident is anything that happens which places one or more of those aspects at risk.  This usually will be as the result of a malicious act such as an attempted network intrusion, but it could also be as the result of incompetence – such as a cloud engineer making a mistake in the security of an online database and leaving it open to unauthorised access.

A Security Incident Response Plan (SIRP) is the pre-agreed action plan for dealing with the discovery, containment, mitigation, and recovery of a security incident.  Just like the whole office practices the Fire Evacuation Drill once or twice a year so everyone knows what to do on the day that the office fills with smoke, the Security Incident Response Plan should be tested or exercised regularly so the whole team is familiar and competent with their duties during a security incident – and as a result their actions make the situation better not worse.

The Incident Response Cycle

There are several models available for managing Security Incidents, and most organisations will create their own plan inspired by one of these proven models.  Here we will use as a reference the model from the CISSP objectives which is a seven-step cycle:

1. Detection
2. Response
3. Mitigation
4. Reporting
5. Recovery
6. Remediation
7. Lessons Learned

The Security Incident Response Plan (SIRP) should guide the security team and incident responders through the Incident Response Cycle.  A copy of the SIRP should be readily available in each location where the response team may be working, and available on paper! The incident being responded to may have compromised or rendered unavailable the systems where business procedures are usually stored.

Detection

In a sense, the SIRP is always active, because the security team is always trying to detect Security Incidents.  Tools such as Intrusion Detection/Prevention Systems are deployed to monitor network activity, SIEM systems monitor and correlate event logs from across the enterprise, users sat at their computer screen see a pop-up message from the anti-virus software.

An incident could also be detected through what starts as a run of the mill support request. This was the case for general John Kelly the US Secretary of Homeland Security whose mobile phone was compromised by malware in December 2016. But it was not discovered until the summer of 2017 when, having moved to the White House as Chief of Staff, he handed his phone to the IT support team complaining that he was not able to get it to do software updates and some of the apps were not working.

Applications crash and software reports errors all the time – but not all of these are security incidents.  IT support staff, users and security team members need training and guidance on how to correctly identify Security Incidents and when and how to invoke the Security Incident Response Plan.

Response

The Security Incident Response Plan needs to make it clear how to invoke the response plan and who is able to do so – and this information needs to be widely shared.  When the building is on fire everyone needs to know how to call the fire brigade and who will make sure the call is actually made.  The response phase deals the mobilisation of the team that will respond to the incident.

Different severities of incident require a different level of response.  A single laptop infected with a virus while it is not connected to the corporate network merits a different response from a large-scale ransomware attack against several file servers in the data centre.

As an incident unfolds the situation – or the understanding of the situation – may change and so the SIRP needs to make it clear how to scale the response up or down to reflect the changing severity of the situation.

The key to an effective response starts with the speed of response – the quicker an intrusion can be detected and contained the less damage or data theft can be completed by the attackers.  This is why regimes such as PCI-DSS place such emphasis on logging and monitoring of those logs – in order to spot security incidents as quickly as possible.

Mitigation

Mitigation describes the steps take to contain the incident – minimising the damage and data loss while preserving evidence helpful in later analysis.

The Mitigation phase of the plan must make it clear what should and should not be done as part of the initial triage of the incident. For example, a computer that is thought to be compromised by malware should rarely be turned off as this will risk losing forensic  evidence stored in volatile RAM – instead the device should be isolated from the network by disconnecting LAN cables or turning off the WiFi card and then left for forensic professionals to examine the device.

During mitigation the security responders may work to contain a network breach or the activities of an intruder without blocking their access completely or letting the intruder know they have been detected in order to gather evidence on the full scope of the attack.

Reporting

Who needs to be told what and when should be laid out clearly in the Security Incident Response Plan – especially for serious incidents that need to be reported to regulatory authorities or law enforcement.  Reporting during an incident includes not just the initial alert but also regular status reporting in language appropriate to the intended audience until the incident is resolved.

Recovery

Once the investigators have gathered appropriate evidence, and the breach has been contained the next phase is recovery of systems and services.  For a minor incident a simple reboot may be all that is needed while for a major incident a server may need to be wiped to the bare metal and reinstalled from scratch or backups.  If application source code has been compromised, then extensive code rebuilds and testing may be needed before a new trusted version of the application can be released into the production environment.

System recovery will normally invoke existing procedures developed as part of Disaster Recovery planning.  Using known, trusted and tested procedures is more reliable.  Care should be taken to ensure that all the latest security patches and security baselines are applied to systems before they are returned into service.

Remediation

In the remediation phase, the security team examines the incident logs and evidence in order to determine what allowed the incident to occur and identifies steps that can be taken to prevent a recurrence or similar incidents in the future. For example, if the attack vector was an SQL injection, then the remediation identified might be a combination of implementing a Web Application Firewall to protect the web application and changing the application code to better validate input to filter out SQL injection attacks.

Lessons Learned

The lessons learned phase is the post-mortem of the incident.  This is an opportunity to everyone involved to identify any lessons learned – what worked well and should be repeated and those things that should be avoided in future incidents.

The lessons learned may include identifying the need for training, improvements in documentation or configuration of security monitoring systems.

The lessons learned should drive changes to the Security Incident Response Plan and inform and improve the response to the next incident the security team responds to.

Resources for developing your Security Incident Response plan

The key to successfully responding to a Security Incident is having a team that knows and understands their role and the overall Security Incident Response Plan.  This familiarity only comes through practice – both through table-top exercises and also by responding to Red Team exercises conducted by trusted security advisors.

Two industry standards that will help you create your Security Incident Response Plan:

• NIST SP 800-61: Computer Security Incident Handling Guide
• RFC 2350: Expectations for Computer Security Incident Response