Make your incident response policy a living document

Your organization needs an incident response policy. You may have one, you may not, and either way it is a good time to review what should be covered by your IRP, because having a bad policy can be worse than having none at all.

Many common cybersecurity frameworks and regulations -- including the National Institute of Standards and Technology's Special Publication 800-61 Revision 2, the New York State Department of Financial Services Section 500 and the International Organization for Standardization cybersecurity framework -- specifically require organizations to have a documented incident response policy. Determining what goes into such a policy can be difficult, though. It's almost impossible to create a detailed, specific policy for coping with what is effectively unknown. Cybersecurity attacks, in a very real sense, represent Donald Rumsfeld's famous "unknown unknowns." We can't predict what the hackers will come up with next. If we could, ensuring cybersecurity would not be such a challenge.

However, there are some clear steps an organization can take to ensure that when -- not if -- it experiences a security incident, the team is ready to respond as effectively as possible. These steps include the following:

• Defining incident. An organization's incident response policy needs to include a precise definition of a security incident. For example, "an event or anomaly that has been determined with high probability to indicate a breach." 
• Defining risk-based prioritizationsof incidents. Responders need to classify incidents based on severity. Classification should be simple (high, medium and low) and based on the scale and scope of the attack as well as the impact on confidentiality, integrity and availability of information and operations in the context of enterprise risk.
• Describing the security response organization. The description should do the following:
  • include staff roles, responsibilities and levels of authority;
  • address compliance and regulatory requirements;
  • include overarching guidelines for external communications; and
  • describe handoff and escalation points in the incident management process.
• Determining plans and procedures of the policy. These cover the specific nuts and bolts of response, including metrics for measuring the incident response capability and its effectiveness, checklists, detailed processes and forms the incident response team uses.
• Having a battle-tested approach to internal and external communications. Incident response policies should include plans and timeframes for communicating proactively with both internal stakeholders -- including legal, human resources and client services -- and external ones, such as customers, the press and law enforcement. Where possible, the plan should include scripts the team can build on when issuing statements and updates.
• Having a templated approach for incident detection, analysis, containment and remediation. The more cookie-cutter the response, the faster and more effective it is. The incident response policy should quickly classify incidents into categories -- denial of service, data exfiltration and so on -- and prescribe broad-based approaches to responding to each category.
• Generating an auditable log that can serve as proof of chain of evidence. A security breach is a disaster, but it is also very likely a crime. That means that data is evidence -- and the best way to protect that evidence is to have in place automated logging systems that track and document how evidence has been captured and preserved. Logs can serve as technical documentation for post-mortems and should include a variety of information:
  • identifying information -- e.g., the location, serial number, model number, hostname and message authentication code and IP addresses of a computer;
  • name, title and contact information for each individual who collected or handled the evidence during the investigation;
  • time and date -- including time zone -- of each occurrence of evidence handling; and
  • locations where evidence was stored.

• Conducting effective post-mortems. The incident response policy should call for holding a "lessons learned" meeting with all involved parties after a major incident. This is critical when it comes to improving security measures and the incident response process. The National Transportation Safety Board (NTSB) provides a good model that focuses on fact-finding rather than fault-finding. Senior management should consciously create an NTSB-like culture, even going so far as to name its team the Information Safety Board. The post-mortem should generate two things: an incident report, which serves as institutional knowledge for future reference, and a list of any changes needed in the policy and the security infrastructure. These two documents ensure that future responses are faster and more effective.

The incident response policy should be embedded in the hearts and minds of the response team via regular drills, practice and repetition -- particularly including creative war-gaming exercises.

Once an incident response policy is in place, the organization should engage in regular reviews -- even if there have not been actual incidents to respond to -- and should conduct war games. War games are creative exercises in which the incident response team reacts to a set of hypothetical scenarios. The military has long conducted war games because they work. The trick in conducting effective war games is to develop scenarios that incorporate multiple unplanned events to generate "perfect storm" scenarios. For instance: What if the attack vector is some internet of things device, and a lateral attack on the heating, ventilating and air conditioning system brought the data center down? Or what if a Session Initiation Protocol man-in-the-middle attack compromised sensitive voice calls at the same time that a distributed denial-of-service attack took down the email server? Or even: What if a key person is out with the flu?

An effective policy should cover not just the broad-stroke, big-picture outlines of how the team should respond to an issue, but should also include detailed checklists and procedures that make the response as swift and automatic as possible. It should also be a living document, updated through regular reviews and post-mortem "close the loop" revisions. Most importantly, the incident response policy should be embedded in the hearts and minds of the response team via regular drills, practice and repetition -- particularly including creative war-gaming exercises.