<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

9 Tips for an Effective Security Incident Response Policy (SIRP)

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

This article will point you to the core concepts within the SIRP so that you understand the purpose of this policy before writing your own.

What is an incident response policy?
The Security Incident Response Policy (SIRP) establishes that your organization has the necessary controls to detect security vulnerabilities and incidents, as well as the processes and procedures to resolve them.  

The tricky thing about this policy is that it needs to be both concise and comprehensive, and finding that balance can be a delicate dance. This article will point you to the core concepts within the SIRP so that you understand the purpose of this policy before writing your own.

First, take a deep breath.  We know that most people don’t love to write policies, but this one is absolutely critical to SOC 2.  It’s a policy that can greatly impact productivity, as well as customer perception, if written incorrectly.  

Early on in drafting a SIRP, you will need to start forming a distinction between a security alert and a security incident.  A security alert is something you probably already get a steady stream of throughout the day.  For example, you might receive an alert when someone scans your firewall for open ports or your anti-virus reports a critical system might be compromised.  An alert, from the SIRP’s point of view, becomes an incident once you start actively investigating it.  In the firewall example, if you log into the device to block the source of the port scanning, that would be considered an incident.  Use your security event logging system to help you strike the right balance of alerts versus incidents. If your alert triggers are too sensitive, your team members could suffer alert fatigue.  If the triggers are too lax, you could miss the warning signs of a serious incident.  

When you start getting into the practice of promoting alerts to incidents, expect there to be false positives. That is a natural part of the tuning process.  Use the false positives to help tune your process for promoting alerts to incidents. For example, you could tune your logging and alerting system to no longer generate alerts when the firewall is port-scanned.

Also, you do not need to overcomplicate the process to document incidents. Use your existing ticket system as an incident reporting ledger to keep your teams up to speed on the progress of an incident. This could be as simple as a Slack channel.  During the incident, create a single-use, dedicated Slack channel as a platform to attach logs, screenshots and other evidence. When the triage is complete, the corrective actions have been taken and the post-incident discussion has wrapped up, be sure you save all the evidence in a location that will be backed up for future reference and follow-up if needed.

You should also think about what you will do in the event of a serious incident, such as if the network has a security breach or a critical system storing personal information is compromised.  If you don’t have the in-house expertise to launch a full forensics investigation, you should have someone on retainer who does. Finalizing a relationship with a security breach forensics team in advance will save you a lot of time, money and stress when you’re in the heat of a serious incident.  When you need to reference the SIRP, you will likely be engaged in an incident response, with pressure mounting by the minute. The more careful thought and planning you can put into the SIRP ahead of time, the better. As you write the policy, ask yourself, “How can I keep this policy as simple and easy to follow as possible?”

Remember that a great time to put your SIRP to the test is when you are not in the middle of investigating a security incident.  Schedule a drill of this policy twice a year by choosing some “what if” scenarios and talking through them with your team.  Use your runbook, policies and procedures as a guide. Make sure everyone knows who should be notified in the event of an incident, what initial information about the incident should be gathered immediately, and how incidents should be categorized.  Also, ensure each resolved incident is subject to a post-mortem and root cause analysis.

In summary, here are 9 tips to help you create an effective SIRP:

  • Work to continually refine your threshold between security alert and security incident.
  • It’s ok for an incident to be resolved as a false positive, but use what you learned from it to further tune your alert promotion threshold.
  • Incident reporting can be conducted with a system your team is already using, like Slack or Teams.
  • Have an incident response team (often called a Computer Security Incident Response Team or CSIRT) on retainer to help in case of an emergency.  
  • The incident response team will likely collect information from you ahead of time so they can be as prepared as possible should you require their services.  
  • Information collected could include network diagrams, copies of your policies and incident response plan, asset inventory and IP addresses, and contact information for the chief information officer (CIO) and/or other leadership.  
  • The incident response team members might also have technical infrastructure in place to help you prepare for common attacks, such as a DDoS (distributed denial-of-service attacks).
  • They can also advise on table top exercises to practice to better prepare you for a data breach - even something as straightforward as running through your backup and restore process.
  • Test the SIRP regularly, and strive to keep it as simple - yet comprehensive - as possible.
 

About the Author

, Security Engineer / Podcaster, is the president of 7 Minute Security, an information security consultancy in the Minneapolis area. Brian spends most of his days helping companies defend their networks.

Since 2004, Brian has also run the blog/podcast called 7 Minute Security, where he shares what he has learned about information security into short, 7-minute chunks.

logo
💙 this post?
Then get all that strongDM goodness, right in your inbox.

You May Also Like

Automating access to cloud environments
Managing Access to Ephemeral Infrastructure At Scale
Managing a static fleet of strongDM servers is dead simple. You create the server in the strongDM console, place the public key file on the box, and it’s done! This scales really well for small deployments, but as your fleet grows, the burden of manual tasks grows with it.
Illustration of an technical employee who is offboarding from their employer.
All Offboard! The 2022 Tech Staff Offboarding Checklist
Offboarding technical employees can be a complex and arduous process with a lot of moving parts. The key to successful offboarding is to have a clear understanding of what needs to be done, who does it, and how to monitor for any shenanigans from former employees.
User Provisioning: How To Automate & Manage Credentials
How We Automate User Provisioning & Keep Track of Credentials
There are a number of ways to automate user provisioning but the real challenge lies in keeping track of those credentials.
SOC 2 dashboard
What Would My SOC 2 Dashboard Look Like?
As your organization pursues your SOC 2 certification, organization is critical. ‍You will be busy actively managing dozens of ongoing daily tasks, which can bury you in minutiae. But at the same time, you need to keep your high-level compliance goals in focus in order to successfully move your certification over the finish line.
SOC 2 Policies Guide
A Definitive Guide to SOC 2 Policies
In this post, we will help you get started with a hierarchy to follow, as well as a summary of each individual SOC 2 policy.