Call us today on: +44 (0)203 88 020 88
SecureTeamSecureTeamSecureTeamSecureTeam
  • Home
  • Our Services
    • Infrastructure Testing
      • Internal Network Penetration Test
      • External Network Penetration Test
      • Wireless Network Penetration Test
      • Vulnerability Assessment
      • Network Segregation Test
      • Voice over IP (VoIP) Penetration Test
    • Application Testing
      • Web Application Penetration Test
      • Mobile Application Penetration Test
      • Desktop Application Security Assessment
      • Citrix Breakout Test
    • Configuration Review
      • Windows Server Build Review
      • Linux Server Build Review
      • Citrix Configuration Review
    • Information Assurance
      • ISO 27001 Gap Analysis
    • Cyber Essentials
  • News
  • Articles
  • About
    • About SecureTeam
    • STORM Appliances
      • Installing a STORM Device
      • Returning a STORM Device
    • White-Label Consultancy
    • Jobs
    • Cookie Policy
    • Privacy Notice
    • Website Terms & Conditions
  • Contact Us

Articles

Home  >  Articles  >  Information Assurance  >  What is a Security Incident Response Plan?
NextPrevious

What is a Security Incident Response Plan?

Articles, Information Assurance | 15 April, 2021 | 0

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.

 

Contents

  • 1 The Incident Response Cycle
  • 2 Detection
  • 3 Response
  • 4 Mitigation
  • 5 Reporting
  • 6 Recovery
  • 7 Remediation
  • 8 Lessons Learned
  • 9 Resources for developing your Security Incident Response plan

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

 

 

Subscribe to our monthly cybersecurity newsletter
Stay up-to-date with the very latest cybersecurity news & technical articles delivered straight to your inbox
We hate spam as much as you do. We will never give your email address out to any third-party.

cyber security, Security operations

Related Post

  • Top 15 Most Exploited Vulnerabilities for 2021

    By Mark Faithfull

    The 15 most targeted security vulnerabilities of 2021 have just been published in a joint advisory from the NCSC.  These are the main ways hackers are attacking businesses around the world. Cybersecurity authorities across multipleRead more

  • What is passwordless security?

    By Mark Faithfull

    At the RSA Conference in 2004, Bill Gates predicted the death of the password. 17 years later Microsoft is finally bringing that prediction to pass with the roll out of passwordless logins for Microsoft 365Read more

  • Key lessons from the 2021 Data Breach Investigations Report

    By Mark Faithfull

    The 2021 Data Breach Investigations report provides insights from the analysis of over 29,000 real world cyber security incidents from 2020 helping Security Managers track the evolving behaviour and tactics of threat actors. The VerizonRead more

  • What’s new in CIS Controls v8?

    By Mark Faithfull

    The world has changed, and the CIS Controls have evolved to reflect those changes.  The increased use of cloud computing, remote working, virtualisation, and outsourcing have all redefined and blurred the edges of the corporateRead more

  • Why Java is recommending you uninstall Java

    By Mark Faithfull

    Java is used by 90% of the Fortune 500 companies, is the second most popular programming language on the planet.  So why does Java prompt users to uninstall it? Remove Java when it is noRead more

NextPrevious

Recent Posts

  • HTML Phishing on the rise
  • Microsoft patches critical zero-day
  • NCSC offers free email security tool
  • Top 15 Most Exploited Vulnerabilities for 2021
  • NHS Targeted in Phishing Campaign

Tags

Adobe Android Apple blockchain Bluetooth Chrome Cisco credential stuffing cyber crime cyber essentials cyber security cyber security news Data Protection DDoS Dell DNS Exchange Server exim formjacking GDPR Google IoT Linux microsoft Mozilla ncsc npm patching penetration testing phishing ransomware RDP SAP security breach Security operations security testing SIEM software development Spectre supply chain attacks Sysinternals vulnerability management web applications web browsers wireless

Archives

  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • July 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
BCS Cyber Essentials Cyber Essentials Cyber Essentials PLUS ISO 9001 ISO 27001
information. secured.
  • Home
  • Our Services
    • Infrastructure Testing
      • Internal Network Penetration Test
      • External Network Penetration Test
      • Wireless Network Penetration Test
      • Vulnerability Assessment
      • Network Segregation Test
      • Voice over IP (VoIP) Penetration Test
    • Application Testing
      • Web Application Penetration Test
      • Mobile Application Penetration Test
      • Desktop Application Security Assessment
      • Citrix Breakout Test
    • Configuration Review
      • Windows Server Build Review
      • Linux Server Build Review
      • Citrix Configuration Review
    • Information Assurance
      • ISO 27001 Gap Analysis
    • Cyber Essentials
  • News
  • Articles
  • About
    • About SecureTeam
    • STORM Appliances
      • Installing a STORM Device
      • Returning a STORM Device
    • White-Label Consultancy
    • Jobs
    • Cookie Policy
    • Privacy Notice
    • Website Terms & Conditions
  • Contact Us
SecureTeam