A cyber incident response plan is a critical element of any organization’s ability to manage and recover from a cybersecurity incident. Security practitioners know this, yet 43% of companies don’t maintain a plan to respond to a cyber attack. This statistic says nothing about the percentage of organizations that have an up-to-date and at-the-ready incident response (IR) plan. It is incumbent upon security leaders to initiate and drive the process of developing, testing, and regularly reviewing the IR plan, but when it comes down to brass tacks, failure to create a current and executable plan has the potential to negatively impact operations across the entire company.
Which is why companies need to carefully craft a reliable incident response plan.
As with many other security tasks and responsibilities, doing so is a knotty process that involves recruiting colleagues (business as well as IT), drafting a plan on which everyone agrees, finding time for everyone to review and practice the plan, then convincing everyone to go through this process on a continuous basis to ensure applicability. If you’re reading this and rolling your eyes at how simple it looks on paper, you’re not alone. “Easier said than done” is an excellent cliché to apply here.
Nonetheless, an IR plan is incredibly important, so Infosec Insider asked Seth Jaffe, VP of Incident Response and General Counsel at LEO Cyber Security, how he would advise companies looking to match the creation of an IR plan to positive outcomes.
A lot of companies don’t develop or refresh an IR plan because it’s hard to unearth the value if the organization has not experienced a major cybersecurity incident or if the plan is so cumbersome it adds friction to an already stressful event. Jaffe says this doesn’t have to be the case, that incident response teams can drive (and derive) value by shifting the IR plan to an executable format. “Executable, by its nature,” Jaffe says, “means that a team member, even one with just a base level understanding of incident response, can pick up the plan and move the ball forward.”
To help security and incident response teams turn the IR plan “shelfware” into an executable roadmap the company can use before, during, and after an incident, Jaffe shares his top five recommendations.
One of the biggest mistakes a company can make when drafting its incident response plan is to be overly prescriptive when it comes to naming the players who will take part in incident response, warns Jaffe. With employee churn and job changes, if you’ve designated “Bob in HR” and “Alice in IT,” in the IR plan, “it will be outdated before the year is out.” Instead, list the job titles rather than specific individuals’ names (e.g., “Legal” or “Communications” managers/directors/VPs/C-levels) as the designees who will contribute to the plan. Using discipline classifications instead of proper names will account for natural job fluidity yet allow everyone involved to understand that that the head of HR—whether it’s Joan or Jim, at the time—must be part of incident response.
Is there anything worse than needing information to do your job but having to sift through mountains of emails or documents or paperwork to find one, small data point? This could be the textbook definition of many companies’ IR plans. To be effective, an IR plan is detailed and specific, but not everything in the plan is relevant to everyone. As such, Jaffe recommends that the “procedures” section be broken out from the full document (in addition to being included). Create a concise, concrete “procedures” document that team members can reference separately if need be so that they aren’t trying to flip through a 65-page document to find definitions of required activities. Many activities are consistent from incident to incident, says Jaffe, so make it easier for team players to find what they need to do their jobs and you’ll see enhanced cooperation.
As with procedures that team members have to follow, it’s best to highlight rules and decision trees in their own easy-to-find-and-follow document. “Major decisions by incident response team members or a steering committee should not indiscriminately be buried in a plan,” warns Jaffe, “but rather memorialized in a quick reference document.” He offers examples like “Attorney-Client Privilege,” “Third-Party Vendor Engagement,” and “Law Enforcement Involvement,” saying that “if a team member suggests calling in a forensic consultant, everyone involved knows to pull out the vendor rule for guidance.”
Designate decision makers
During the stress of a cyber incident, it’s natural for certain people to want to take charge. While an incident response certainly requires leadership, too many cooks in the kitchen spoil the soup. As with the company’s overall organizational chart and decision trees for other processes, a director or leader should be stipulated in the plan. Jaffe says, “That top person manages the communications of team members, watches the big picture, liaises with non-team members, and orchestrates the response.” Failure to designate a leader of the response and subordinate decision makers will only serve to create additional confusion during a time that is already riddled with chaos.
A thorough IR plan relies on the existence of other critical information, such as network diagrams, organizational charts (with contact information), the names of administrators who have privileged access to software and services, etc. But not all of this information can be put directly into the IR plan (lest the 65-page plan turns into a 200-page document that no one can reasonably use). However, whenever possible, says Jaffe, cross reference this critical information with links and/or instructions.
“Reference ancillary resources,” he offers so that people can find what they’re looking for without having to rely on memory or a best guest. Once again, make it easy for everyone on the IR team to find what they’re looking for and they’ll be more likely to stick to the plan.
The name of the game when it comes to creating an effective and actionable incident response plan is executability: How easy is it for everyone involved in incident response to find the information they need to do their jobs to the best of their ability? An IR plan should smooth processes, alleviate additional stressors, and ensure that people have a clear set of guidelines for what to do and whom to contact when a cybersecurity incident hits. Including these five elements in your IR plan will get you several steps closer to ensuring your documents are up-to-date and applicable.