+44 (0)203 88 020 88

Menu

Search

Cyber Security News & Articles

 

Cyber Security
News & Articles

Trusted Cyber Security Experts
25+ Years Industry Experience
Ethical, Professional & Pragmatic

What is a Security Incident Response Plan?

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:

 

 

Subscribe to our monthly newsletter today

If you’d like to stay up-to-date with the latest cyber security news and articles from our technical team, you can sign up to our monthly newsletter. 

We hate spam as much as you do, so we promise not to bombard you with emails. We’ll send you a single, curated email each month that contains all of our cyber security news and articles for that month.

Why Choose SecureTeam?

Customer Testimonials

“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”

Aim Ltd Chief Technology Officer (CTO)

"Within a very tight timescale, SecureTeam managed to deliver a highly professional service efficiently. The team helped the process with regular updates and escalation where necessary. Would highly recommend"

IoT Solutions Group Limited Chief Technology Officer (CTO) & Founder

“First class service as ever. We learn something new each year! Thank you to all your team.”

Royal Haskoning DHV Service Delivery Manager

“We’ve worked with SecureTeam for a few years to conduct our testing. The team make it easy to deal with them; they are attentive and explain detailed reports in a jargon-free way that allows the less technical people to understand. I wouldn’t work with anyone else for our cyber security.”

Capital Asset Management Head of Operations

“SecureTeam provided Derbyshire's Education Data Hub with an approachable and professional service to ensure our schools were able to successfully certify for Cyber Essentials. The team provided a smooth end-to-end service and were always on hand to offer advice when necessary.”

Derbyshire County Council Team Manager Education Data Hub

“A very efficient, professional, and friendly delivery of our testing and the results. You delivered exactly what we asked for in the timeframe we needed it, while maintaining quality and integrity. A great job, done well.”

AMX Solutions IT Project Officer

“We were very pleased with the work and report provided. It was easy to translate the provided details into some actionable tasks on our end so that was great. We always appreciate the ongoing support.”

Innovez Ltd Support Officer

Get in touch today

If you’d like to see how SecureTeam can take your cybersecurity posture to the next level, we’d love to hear from you, learn about your requirements and then send you a free quotation for our services.

Our customers love our fast-turnaround, “no-nonsense” quotations – not to mention that we hate high-pressure sales tactics as much as you do.

We know that every organisation is unique, so our detailed scoping process ensures that we provide you with an accurate quotation for our services, which we trust you’ll find highly competitive.

Get in touch with us today and a member of our team will be in touch to provide you with a quotation. 

0

No products in the basket.

No products in the basket.