Preparing for an Incident Before It Occurs
In this article
In the previous post in this series, we discussed the importance of defining what a security incident looks like for your organization. Developing these indicators or criteria provide focus to your security team and avoids the common tendency to label every suspicious event as an incident. This definition is foundational to a well-crafted incident response program. It filters out the "noise" (i.e. unsubstantiated suspicious events) and puts your organization in a position of preparedness with the ability to respond decisively when a real incident is suspected.
Having defined the criteria for a security incident, we move on to discuss some elements that are shaped by that definition and found in every effective incident response plan.
Create a multi-faceted response team, made up of individuals with (a) the power to make immediate managerial decisions and (b) the technological skill to deal with the threat on the front line. Define a list of responsibilities beforehand and communicate them to your team. Run frequent tabletop exercises to ensure that each team member is familiar with the part he or she plays in resolving an incident. To be effective, this team must have representatives from leadership and the business owners whose data or assets may be affected.
Pro tip: Make sure your plan includes emergency contact details for all team members. Attacks do not always occur within your organization's hours of operation.
Not all incidents require the same response or team members. Most people think of a data breach when discussing security incidents. How does your organization respond to ransomware or a child pornography event? These situations may call in resources from a non-technical standpoint; human resources, legal, even third-party agencies like the FBI. Identifying an incident classification matrix beforehand will help you respond more effectively during the crisis.
Pro tip: Reach out to local law enforcement and your nearest FBI field office to develop those relationships and identify the best way to provide notification if necessary.
Once an incident has gone through preliminary triage, your response team needs a repeatable, well-defined process to identify the scope of the incident, remove the threat and return the business to normal operation. I recommend using NIST Special Publication 800-61 Revision 2 as a starting point. It lays out a multi-step methodology to help you respond systematically to incidents. Take that framework and adjust as needed for your organization.
Pro tip: For optimal results, identify the process flow that must take place during each step of the incident response workflow. Think of the "Five W's": who, what, when, where, why (and how).
That's a wrap on my three-part, incident response blog series. I hope you found it informative and helpful.
To continue the conversation and gain a better understanding of where your organization stands today in responding to a data breach, request our Security Tabletop Exercises Workshop. This two- to four-hour strategic planning session will explore areas like measuring and defining an incident, differentiating between a threat and a risk, proper internal and external communications after a data breach, the remediation process and real-world incident scenarios based on the experiences of instructors.