Incident Response

Incident response is an area that one hopes never to enact. However, I have led several cybersecurity incidents throughout my career. It's a unique experience to be called by the FBI indicating they've found some of the company's data on the dark web and then investigating to find that you've been compromised.

 

The key to responding to an incident occurs long before the incident occurs. It involves extensive IR planning which includes identifying all roles that may be involved in an incident and playbooks outlining possible scenarios. As we developed these documentations, we realized that this is a continual process. As new attack vectors emerge, new responses need to be included in our playbook. We want to minimize as much guess work as possible during an incident and lay out as many check list steps as possible. We review our playbooks quarterly or when a new unique threat has emerged.

 

Once our documentation workflows are in place, we engage with the people we've identified for specific roles, and  conduct tabletop exercises. I try to get scenarios and support from outside sources and keep the topic and scripts to a very small group of people to keep it fresh for those engaged in the exercise. I prefer to conduct these exercises over a few days, with each day bringing a new set of information into the escallating scenarios. These thought exercises can happen both through email and through short meetings. On the final day, I bring the entire team together for a discussion and lessons learned. These lessons learned then feed back into our living documentation cycle to better align our IR plan. One of my favorite scenarios is bringing in information from two separate attacks. It's a natural human reaction to try to bridge these scenarios as a single incident, but this exercise highlights how critical it is for the team to remain diciplined and not jump to conclusions.

 

With proper preparation, addressing an actual cybersecurity incident should be less stressful. One of the key stressors I've found from experience is, after verifying an incident, giving the appropriate people the authority to contain the incident. This may involve shutting down a server, or a certain portion of the network and identifying those people who can and giving them the authority to do so is absolutely critical.

Certifications

• Certified Information Security Manager (CISM) #1841436

• Certified Incident Handling Engineer (CIHE) #14282-162-075-8681

• ISO 27001 Lead Auditor (TPECS)

• Certified Project Manager (CPM)

• Project Manager Professional (PMP)