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.
