Effective Incident Response Starts Long Before the Incident

Cyber incident response is often viewed as a technical domain, with practitioners skilled in malware reverse engineering, network and host forensics, and a wide range of other DFIR skills.  If those skills are not available in-house, many 3rd parties stand ready to provide expert skills on retainer to anyone who might need them.   With the significant skills available to us, why is it then that so many incidents last longer than they should, have much larger impacts than expected, and leave incident response teams mentally shattered?

Often, when complete post-incident lessons learned exercises are conducted, the challenges come down to:

• Unclear or shifting objectives: Responders are unclear about the incident's overall goals and priorities.  Is the focus on containment?  Maintaining operations? Forensics?  If the overall objectives of the response, as well as short-term goals, are not consistent or clear, people don't know what to focus on first.  
• Unclear Leadership:  Individual incident responders receive directions and tasks from multiple leaders, leading to confusion on priority.  Worse, sometimes these directions and tasks directly conflict.  What is an individual to do when the "incident manager" gives one set of directions, while their immediate line supervisor, the one who does their annual review, gives another, different set of priorities
• Absent leadership - Often, leadership is distant, lacking, or seemingly occupied with other matters, leaving responders without clear direction.  This leads each individual to work on whatever is in front of them, trying to pick the highest-value task.
• Distractions - The incident puts many pressure on all aspects of the business.  This might lead individual business teams to reach out to individual responders to lobby for "their" system to be restored, "their" accounts not to be reset, or to ask for a "quick 5 minutes" for a status update.
• "Hero Syndrome" - Every company has them, the technical hero that is a cape short of being Superman or Wonder Woman.  Often in an incident, these heroes work for days straight without rest, showing superhuman endurance.  It is easy to forget these people are, in fact, human.  By not managing their work schedules, these exhausted superheroes burn out, start making mistakes, and eventually interfere with effective incident response as their judgment is impaired.

The question is: how do we get ahead of these problems and ensure a well-managed, well-executed incident response that returns the business to operation as quickly as possible?  Built on decades of incident response experience across fire, public safety, disaster, and other incidents, the Incident Command System (ICS), a part of the National Incident Management System (NIMS), provides a framework to address these issues and develop a coordinated incident response.  This is one area where those of us in cyber can and must learn from other incident response sectors.

ICS provides a standardized approach to the command, control, and coordination of resources within a structured framework that allows personnel from different organizations to work seamlessly together.  This is of critical importance, not only for IT incidents when you might need to work with corporate crisis management, law enforcement, national intelligence and 3rd party responders, but can be life-saving in operational technology, where incidents turn physical, and you interact with mine rescue, industrial fire, or other rescue teams.

The other unique gift that makes ICS suitable for cyber incidents is scale.  Yes, many different frameworks scale up to major incidents; ICS is one of the few incident systems designed to scale down to the smallest of incidents.  The minimum response team size for an ICS incident is two.  In practical terms, for a minor incident, it could be a single analyst in the SOC and the SOC lead as the Incident Commander.  This scale-down capability is ICS's secret superpower.  Suppose your central incident management system is only used on (hopefully) rare major incidents. In that case, the team gets rusty, the system is out of practice, and when the major incident comes, nobody remembers the system or their roles - people get to learn it again, from the beginning, with the pressure of an incident hanging over their heads - not a recipe for success.  By being able to scale down to a minor incident, ICS gets practiced regularly.  Repetition helps people learn the roles, terminology, and approach.  Then, when the big one happens, everyone won't have to start from scratch.  There is a core team that is comfortable with the approach, and as the incident expands, that core team can maintain the structure and cadence for the newcomers.

If you want to give ICS a try, MM-ISAC is here to get you started.  MM-ISAC members have access to the MM-ISAC Incident Response Plan.  This plan, based on ICS, takes an OT first approach to implementing ICS for IT and OT incidents.  In addition, we have developed a 1-day in-person training class.  This class, intended for all those who may have named roles within an ICS incident, introduces students to the NIMS and ICS frameworks, the planning cycle and its associated components and briefings, and the necessary ICS roles for all incident sizes.  To conclude the class, a 90-minute, realistic, intelligence-based tabletop, developed by MM-ISAC's Director of Intelligence, Cherie Burgett, will allow students to practice what they've learned on a simulated incident.

This training will be available in 5 cities globally next year.  Free for MM-ISAC members and available for a nominal fee for non-members, the training will kick-start your adoption of ICS.  Watch the MM-ISAC web page for cities and dates in early 2026.

ICS is key to building an industry that is resilient to the impacts of cyberattacks and can respond and recover quickly.  We're looking forward to supporting the adoption of this critical framework.  If you need support, please feel free to reach out!