Reacting to a big breach
As I write this, the industry is still wagging its fingers at the latest big breach. But in the time that it takes to get this published, there could easily be another colossal security disaster that leaves large numbers of people’s private information exposed. And with every headline announcing a security failure comes the anger and blame-storming, a lot of it from security professionals. Understandable, but how useful is it?
Rather than face-palming all over Twitter, enumerating all the things they did wrong, and why they deserve getting hacked, there is a more useful response. As Rahm Emanuel said, “You never want to let a serious crisis go to waste.” A big public breach is a teachable moment for both you and your organization.
You can use the incident to re-examine your security posture and honestly ask yourself, could it have happened to us? Granted, it’s less fun than pointing fingers. In fact, it can get downright uncomfortable. But it’s a powerful exercise in reassessing your defensive capability in the face of known threat.
Before you begin, you need to make sure a significant portion of the facts have come out. Often, this can take weeks or months. Usually the first few days of a major breach are full of speculation and rumor. You need to have a good idea about what happened, so you will need to be patient before undertaking this exercise. It doesn’t mean you can’t communicate to your executives that you are starting this, it just means you can’t draw any meaningful conclusion until the facts solidify. Also, to do a useful compare/contrast exercise against your organization, you’ll need to consider the differences between the affected organization and yours. This includes industry, personnel, IT staff, technology, and overall Internet visibility. You can still learn things from breaches at organizations vastly divergent from your own, but factor those deviations into your analysis.
This exercise more or less ends up drawing one of two conclusions: this couldn’t have happened to us or we just got lucky it wasn’t us. Both conclusions, which have nuances, provide meaningful information.
The conclusion that “it couldn’t happen here” needs to be followed with a list of reasons why. These reasons are justification for the security controls and risk decisions you’ve made in the past. They’re proof that you’re doing the right things and need to continue to do them. This is a statement you can tout to executive leadership to maintain your budget and support the security program. It’s also something you can communicate to the general staff, adding a congratulatory note to “keep up the good work” in helping keep the organization safe.
The second conclusion is that the breach could have affected your organization but for the grace of the Internet gods, you were spared. When you conclude that, the first thing to do is make sure you haven’t been breached and just haven’t detected it yet. Check and double-check. This could be your wake-up call.
Once you’re reasonably sure that you did dodge that bullet, you can now build a list of lessons learned. With these, you can build a plan to make sure it won’t happen to you. Granted, there may be some things you can’t do anything about given things like embedded legacy technology that can’t be easily replaced, or risky business practices. Nevertheless, these facts need to be communicated so organizational leadership is aware. They can either give you support to remediate those risks or get insurance for them. Sometimes the changes are so simple (patching a particular type of technology) that you can deliver your message along with a statement that you’re no longer vulnerable because you’ve fixed the problem already.
Sometimes the conclusion is a muddled mixture of both: there are some things that lead to that breach that we are doing and others we already have secured against. This is still a useful message to carry upward.
Why communicate any of this? You can bet that when the breach happened, some of your execs wondered: could that have been us? Doing this analysis gives you a chance to either brag about how you’re better protected (and need their continued support), or it’s a chance to ask for more resources to ensure it won’t happen to you. The lessons can also go downstream as part of security awareness, making it clear what can happen when security is lacking.
No matter what, doing this analysis and sharing results is a win for you. You can communicate to the entire organization that the threat is real—which is why breaches happen—and that’s why we in Security are always on guard and looking for ways to improve.