[BreachExchange] Reacting to a big breach

[Audrey McNeil]

https://www.helpnetsecurity.com/2018/01/08/reacting-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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180109/0df3dfbb/attachment.html>