In part one of our series, our overview of Building an incident response plan, we discussed what regulations organizations will need to meet in order to address incident/breach response protocols laid out in the EU’s General Data Protection Regulation (GDPR). This week, we’ll talk to you about steps to take to actually create your company’s incident response program.
An incident response (IR) plan does not need to be overly complicated or require reams and reams of policy, standard, and other documentation. However, having a solid and tested framework for the program is key in the ability of an organization to respond to and survive a security incident.
There are many different incident response frameworks from security companies and organizations that are useful in their own ways. From my experience, the simplest, yet most robust framework to build upon is the US government’s National Institute of Standards and Technology (NIST) Special Procedure (SP) 800-61.
There are four key steps within this framework: preparation, detection and analysis, containment eradication and recovery, and post-incident activity.
In my opinion, preparation is probably the most important step in incident response. An organization that is not prepared to handle an incident will almost always fail to appropriately detect, let alone respond to, a security incident. Preparation, of course, includes establishing an incident response program, including all the necessary compliance and governance documentation (including policy, standard, and procedures, at a minimum). More on this later. But it also includes socializing the different aspects of this program so that it can be effectively executed. That includes the following steps:
In addition to staff being notified of security events via automated alerting (email, SMS, etc.), staff should perform threat hunting activities and review security tool administrative interfaces. They can do so through the following processes:
Once the breach has been secured, computers restored, and impacted customers notified, there’s one last stage to consider. Evaluating what happened after the fact can ensure a smoother response in case of future attacks.
I am the last person to push compliance or governance over technical action, as I have seen and created too many policy documents that just sit on shelves. However, I do feel incident response is one place where having solid governance and documentation is critical.
An incident response policy document should establish the IR program and team structure and, probably most importantly, emphasize ownership and buy-in for the IR program at the executive level. This document will provide the highest level of requirements for the program—the key policy statements. Any policy statement must be adhered to, and any deviations should be documented and approved within an organization’s risk management team.
These key policy statements should be in the IR policy:
The standards document will provide a bit more detail about the requirements for fulfilling the policy, and should also outline approved tools, technology, and techniques that can be utilized within the IR program.
It should be noted that while the statements within a standards document need to be adhered to with the same rigor as the policy, in some cases, especially with tools, techniques, and technologies, utilizing the specific approved tools may not be possible. This is where a key activity within incident response comes into play: documentation, documentation, and more documentation. All responders should clearly document what they are doing, when they are doing it, and what the outcomes were.
Overall, exceptions to the standard should be documented and tracked within the risk management program; however, if a remote office cannot utilize the “approved” forensic tool for checking a system in the middle of an incident, the standards should be designed so that the Incident Response Manager has the authority to provide an exception. This ensures that the person executing the action documents all of the steps they took to be able to gather and reproduce any evidence in a sound manner.
The types of information contained within the standards document should include:
These documents are the heart of the actual incident response activities. Procedures and guidelines should be written as detailed as possible. While the core of the incident response team may be able to acquire the image of a Windows laptop in their sleep, there may be other staff members that need to help out in a moment’s notice. Consider if, in the middle of a large incident, you have to get a non-technical person in a remote office to get you an image of a laptop. Having step-by-step instructions can mean getting the image to analyze in a few hours vs. getting it in a few days via the shipping department.
I am also of the mindset that creating detailed, step-by-step procedures or workflows can help staff get the basic steps done quickly and thus free themselves up to dig into the findings deeper to better understand what is going on. For example, within an email phishing workflow, I would identify the first steps, such as getting the headers, performing WHOIS on the domains in the headers, investigating any URLs with online tools, performing searches for the SHA256 of any attachments, and considering what should be documented in a report. Once those steps are completed, the analyst can then use their experience and expertise to identify the level of threat or determine that this may be a bigger event than a simple phish. Having the first handful of steps documented in detail allows the analyst to get through the basic stuff in about 15 minutes vs. an hour.
The following are some key items that should be considered for the procedures and guidelines documents:
Incident response has been a core information security tenant for many years and continues to be an important part of an organization’s information security program. New regulations, such as GDPR, continue to press the need for a solid, documented, tested, and robust IR program.
Your company’s incident response program does not need to be complicated, but it does need to be supported by executive-level leadership, staffed by trained and experienced personnel or outsourced to a reliable and competent MSSP, regularly tested for completeness and competency, and well-documented so an organization does not have to develop a strategy in the heat of the moment. With the right IR program in place, what could end up as an incredibly damaging event for the company might only be a tiny blip.
The post Building an incident response program: creating the framework appeared first on Malwarebytes Labs.