Read Part 1 of this series exploring how to react after a serious security incident.
Security vendors know their products have blind spots. They know that there are areas of the attack surface they cannot protect. Despite this, vendors continue to make promises on which they cannot deliver. That’s why companies large and small continue to experience intrusions, incidents, and breaches despite being “protected” by their security vendors. Does this lead us to perpetual defeat in the depths of abysmal despair? Not quite.
In all seriousness, it does call us to reframe our thought process around security and privacy failures. It means thinking about “success” not as creating an incident-free utopia but, rather, creating an organization that can learn from those scary moments, dusting off our knees, and trudging forward even wiser and stronger.
I’ve said this before but bears repeating: Breaches can happen to anyone. That’s why a company’s response to a breach is more important than almost anything else. In fact, a company’s response is truly what sets it apart from other brands even after a relatively minor security incident.
So, what constitutes a “good” response following a security incident? At a high level, it’s a deliberate, calculated, and well-articulated plan that communicates key details, developed by several key players who are all working toward a common goal.
Finding the Right Words
In security incident response planning, both what you say and how you say it matters. In essence, a security incident response plan puts the right resources in the right place so that challenges such as data loss and reputational damage are kept to a minimum. Security teams utilize an incident response plan to identify, eliminate, and recover from a threat quickly and uniformly.
Incident response plans will look different from company to company, but they should address and provide a structured process for preparation, identification, containment, eradication, recovery, and lessons learned. A response plan is only valuable when it’s created ahead of time, of course. So, if you’re reading this and your organization doesn’t have an incident response plan in place … stop reading and create one now.
Or, if you’re not the person responsible for building one, send your IT and security leaders an email like the one below:
Subject Line: Do We Have An Incident Response Plan?
Body of Email: Been reading a lot about breaches and how they can happen to anyone. Just curious, do we have an IR plan in place? How can my team help?
Along the same lines, a breach notification letter is necessary whenever sensitive customer information is involved. The breach notification letter needs to meet different regulatory requirements depending on the industry. Get clear about what you need to disclose and what you shouldn’t disclose because it would give too much useful information to your adversaries far in advance.
The tone used to communicate a response is also critical. Executives should show they care for their employees and their customers and own up to their mistakes. Even if the breach was caused by a third party they picked, companies can’t ignore, cover up, or deflect blame once they’re under fire.
I get it. A breach is embarrassing. Asking customers to change their passwords is like a virtual walk of shame. No one wants to be in that position, especially when every word and decision is sure to be scrutinized and criticized by many. Security incident response, and certainly breach response, goes far beyond technology; it’s a pressure test of culture and security leadership. Companies with good culture — one that embodies true collaboration and solidarity — are much more likely to suffer minimal internal damage after a security incident.
Security team members must evaluate the ongoing work required and hold those needed accountable, but it is essential to act as one team rather than attack one another. Security incidents rarely have a singular point of failure, and everyone must come together — from the CISO to the security analyst — to resolve the issue.
Who Is Going to Help You Say It?
There are several departments — outsourced and internal — that should be sitting around the proverbial incident response table. While they will all play different roles, they’re all necessary to achieve the end goal: not making a misstep when it matters most. Legal, finance, communications, and security teams are integral during these moments.
Many companies choose to appoint an incident director or team leader who will coordinate incident response activity and move things along at a desirable pace. Their priorities are to make sure that all of the professionals involved are communicating with each other and remain focused on shared goal(s). There also should be a lead investigator who is responsible for collecting and analyzing evidence and determining the initial entry point of the malicious activity. The lead investigator will work with the security team and advise on what details they think will be valuable to customers in combating future security incidents. Acknowledge there will be some things influenced by outside parties they cannot control (even the National Security Agency or FBI at times).
There also should be a concerted communications effort that focuses on messaging to all audiences inside and outside of the company. Breaches can often be a PR nightmare if the people speaking to the media or replying with comments on social media aren’t prepared with the right information and what I call “red and green phrases” or rules. Often, communications teams don’t know much about IT security, so to avoid having them say things that endanger the investigation or reveal information you don’t want revealed, it’s wise to put together a list of red and green phrases — red phrases should be avoided; green ones are preferred. You don’t want spokespeople revealing too much or an incorrect detail about how the breach occurred and why you were caught flat-footed. You want them to tell the truth and protect the mission and identity of the company but in a way that doesn’t reflect poorly on it.
Understand the limitations of your current investments, but more importantly be honest on your ability to detect, disrupt, respond, and recover. Much of this success goes beyond software and depends more on what you’ve built and how you’ve trained ahead of time.
Stay tuned for Part 3, which will provide action advice on how to go forward once stuff hits the fan.