The Seven Incident Response Leadership Sins

 All incident response is not good incident response.  

The quality of a response to a cyber security incident is determined by the team's leader.  That might be you or someone that reports to you directly or indirectly. 

I've compiled a list of seven incident response leadership sins to help guide and evaluate whoever that is.

Unprepared For Incidents: Seems obvious but, having looked at a number of incident response teams in action, you'd be surprised. Incident response isn't about activity. An incident response team that is unprepared to quickly contain and quell a potential cyber security issue, disrupt the disruptive incident, understand that’s an incident is underway simply isn’t an effective team no matter the level of activity. 

Not Collecting Right Data: High fidelity data is key to knowing how to best respond to an incident and know how many resources are needed for containment. Accepting low fidelity data is a purposeful choice. Low fidelity data will increase churn and time to discovery.  

Not Coordinating the Team: Leading a response to an incident is a lot like conducting an orchestra. The good players combine into a great outcome. Your team will get across the finish line much faster. Failure to coordinate will negatively impact your time to resolution metrics. Put your ego to the side. You should also be training and rotating others to lead the team during incidents.  

Staying In the Team Comfort Zone: Is your team practicing a set of scenarios with a full team and only Jim knows how to do X? What happens if Jim is on vacation or, worse yet, has just left the company?  What happens if an incident involving APIs occurs and the team is only familiar with endpoint or cloud scenarios? What happens if half the team is remote or out for an event or involved in multiple incidents at the same time? You’ve got to practice responses with a subset of the normal team members and put them in scenarios that are outside their comfort zone. 

Not Identifying Places To Improve: Every incident should present opportunities to improve. Get to malicious attachments faster across multiple mail servers. Improve the configuration for the email filters. Get more observability in a given area. The list is endless even for a mature team. You should include these immediate opportunities in the initial report to executives. As an exec, you should dig into the "why" of the answers here.

Not Following Through: If lessons learned from actual incidents or pen tests don’t turn into vulnerability closures, playbook changes, additional tools, or headcount, you aren’t following through. We track each lesson learned and its current status. "Inconsistent" isn’t a word that execs should use to describe your incident response program. 

Not Communicating Reality To Execs: You should update executives as you are responding to incidents and also regularly in a more strategic way about the program.  Executive support is critical to building an effective cyber security incident response program. Lose them and you’ve lost your incident response program.  If execs don’t understand your challenges, they can’t help you resolve them. What do you do? What are the gaps? How do those gaps impact particular incidents? 

What did I miss? I'd love to hear your stories and feedback.

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1 or, have your own examples? Use #crazygoodcyberteams on twitter or Linkedin and I'll read it. 

SEE ALSO

The Magical Malware Deception 

The Breach Sure Bet

The Security Exception Ruse