Since your company has computers, people, and things, security incidents will happen — so it’s critical to always have current security incident readiness plans in place. That way, you can mount effective incident response when you need to. Here are five things you can do to make sure you’re ready when (not if) your company experiences an information security incident or a physical security event.
1. Assemble Your Core Incident Response Team
Although titles may vary by company, your Core Incident Response Team should include key decision makers and tactical leaders from engineering, information technology, information security, legal, communications, change management, and executive leadership. Note that some key people are not senior leaders, but you rely on them to get things done — know who they are and include them. (Also, work to remove single points of failure – the topic of a different, upcoming post.)
2. Establish & Maintain Incident Handling Policies & Procedures
When was the last time you reviewed your security incident response policies and procedures for accuracy, completeness, and cross-functional alignment? It’s probably time to do it again.
Were these documents written before your company did that big lift-and-shift, or moved from Azure to AWS to GCP? Do they reflect the current realities of your business and its data-flows? Do they address the holistic nature of an IR as reflected by the composition of your Core Incident Response Team? Or are they really focused on IT and Engineering tasks?
Security incident response policies and procedures should be written by a cross-functional team to avoid a myopic focus on any single department. If departments like legal, PR, or customer support are working from independent plans, these should be merged and henceforth maintained collectively.
Make sure that all policies are clear, that they consider every department, and that the procedures for acting on these policies have been spelled out in detail and tested. The update cadence will be unique to your organization, and depends on a range of things, but it’s a good idea to plan, in the absence of an actual incident, on at least semi-annual review.
3. Create Security Incident Runbooks
A runbook (also called a playbook) specifies the specific technical and support tasks that must happen to enable action, and the order of operations. You can effectively evaluate your runbooks the same way you do policies and procedures: are they accurate and complete for where the organization is now? Are the decision-making procedures clear? Have you removed all single points of failure? Have you tested it recently to ensure it works?
If your runbook includes restoring from backups, when’s the last time you did that? How long did it take, and what were the recovery time and point objectives tested? Are these realities accurately reflected in your runbook’s assumptions?
4. Stage Security Incident Simulations
On a regular basis, especially in an environment where the company and/or staff are evolving rapidly, simulate an incident. This key security incident readiness exercise will allow you to see if there are missing parts of your policies, procedures, or runbooks, where coverage is incomplete or multiple things conflict. Does anything strand your team? What procedures should they follow when you run off the edges of your map, and how do they practice those?
5. Host Regular Tabletop Exercises (TTX)
Tabletop Exercises are key learning exercises. In them, you bring together your Core Incident Response Group for a few hours, and you discuss an incident scenario. The scenario should slowly unfold, over five-to-eight iterations, to simulate an unfolding incident and the cadence of new information you continually receive as events occur.
In each revolution, the teams should discuss touch-points, collaboration, actions, and plans – what would we do if this happened? What can we handle internally, and under what conditions do we bring in outside help? Etcetera.
One doesn’t “win” a TTX, and there are no truly “right” answers. The only “wrong” answer is not to conduct them.
* * *
The frequency with which any of these actions should be undertaken will vary broadly from organization to organization. In creating these policies, procedures, runbooks, and other plans, we recommend that you build in triggers for review. For example, staffing changes that affect the Core Incident Response Team, or significant changes to the company’s security or hosting environments, would be a trigger.
In the absence of those, or an actual incident, we advise at least semi-annual attention to security incident readiness assessment. If you’d like support and guidance through the process, Evertas can help.
