Is it just me, or does it seem like every day there’s another breach to worry about? RSA, Epsilon, Sony, now Citibank — it seems like a day doesn’t go by where there isn’t another high-profile breach in the news. It seems like everyone’s getting hacked, and it seems like it’s happening with increasing regularity.
Of course, to say that being a victim of a breach is “heavily impactful” to the business is an understatement; the costs of remediating a breach are astronomical and can wind up leaving services down, can lead to regulatory oversight, and can directly impact the organization’s bottom line. So preventing this kind of situation is obviously important, and it’s also a source of major stress for security professionals. It’s the kind of thing that keeps us up at night.
But this trend probably shouldn’t come as too much of a surprise when you stop and think it through. After all, consider the size of a typical enterprise IT environment: Not only is the typical environment extremely complex — and getting more and more complex as time goes — but it’s also incredibly large, with dozens of different platforms, multiple business partners, and hundreds or thousands of different network pathways. Add to that mix terabytes of confidential data that requires protection, and it should be no wonder that bad guys tend to get in.
It wouldn’t make much of an interesting sport since the deck is heavily stacked. As the defensive side of the equation, you only “win” by closing — and keeping closed — thousands or even potentially hundreds of thousands of different potential attack vectors. As offense, you “win” if you can find even one way to worm into the environment.
Risk Management Isn’t Certainty
To many folks, hearing it spelled out this way might sound a bit like “FUD” (fear, uncertainty and doubt). But in this case I’m not bringing it up to scare you. Instead, I’m bringing it up to illustrate a very specific point — namely, that organizations looking to prevent a breach disclosure scenario (which is increasingly becoming a stated mission of corporate information security programs) need to rethink honestly their current strategy. In most cases, assuming that a breach will inevitably happen and operating accordingly is the only logical plan of attack.
Here’s what I mean: Investment in preventative controls can only take us so far. A risk management approach to control selection and deployment — the fundamental premise on which most of us base decisions about how to secure the environment — always leaves open a chance that a breach can occur.
It has to. It’s the nature of the process. Risk management isn’t about creating certainties. It isn’t about eliminating all risk entirely. Instead, risk management is about creating an environment where risk is reduced to a tolerable level (your risk threshold). This implies that there will always be residual risks below your risk threshold that aren’t fully addressed once controls are selected and deployed.To see this in action, let’s break out how traditional risk management operates (simplified to illustrate the point):
- Identify threats
- Determine risk based on likelihood of a threat materializing
- Mitigate the highest risk areas
Granted, this is greatly simplified. But at the end of the process, risks should be mitigated so that they are reduced to something palatable to your organization and make sense within the budget constraints. But risks are never entirely eliminated. At the end of the process, there is always a non-zero likelihood that some catastrophic event could happen. And as long as there is that non-zero chance, we need to plan accordingly, because sooner or later, assuming a long enough period of time, we’ll win the “it’ll happen to us” lottery. Maybe tomorrow, maybe 20 years from now — either way, we need to think outside the box of prevention and look instead to impact mitigation to make sure that when and if this situation does happen to us, it doesn’t break our business.
Breach Impact Reduction
So all that being said, what can organizations do to decrease the impact footprint should a breach occur in their environment? For my money, there are five steps that make the most impact. They are:
- Encryption at rest
- Encryption in transit
- Data discovery and cataloging
- Logging and event correlation
- Defined responsibilities
The first two controls relating to encryption of data are key here. Encryption at rest refers to encryption of the data when stored; encryption in transit refers to encryption as it is exchanged from point to point. As we all know, encryption controls can be difficult and expensive to implement, but it’s worth mentioning that they have value even in situations when a breach can’t be prevented. From HITECH to state disclosure laws, all of the laws currently in effect have special provisions that allow an organization to refrain from disclosing a breach in the event that the data in question is encrypted.
Encrypting is great, but how do you know what to encrypt? That’s where the third control, data discovery and cataloging, comes in. This is the process of going through the environment and finding out exactly where the data that is governed by breach disclosure laws is located and storing that information for future reference (such as, for example, during the incident response or investigation process). Not knowing whether data in a particular location is regulated or not — and not knowing what controls you have or have not applied to it — means that in a breach situation you’ll have to err on the side of caution and disclose if you are unsure. Mapping it out now ahead of time nips that in the bud.
The last two controls – accurate logging and a defined responsibilities list of who is doing what in the investigation and response process — are key to making sure that (should you suffer a breach), that you are able to react quickly and gather the appropriate data that you need to support your investigation. The record-keeping ensures that you can accurately investigate, track what happened, and put together a cohesive story once you do; the process controls make sure that someone is accountable for representing that story accurately and in a timely fashion. Keep in mind that some of the breach disclosure laws have a built-in timetable (HITECH, California state laws), so being able to gather accurate data about the event quickly — and making sure there is a clearly defined communication channel for how that investigation is done — is critical.
Preventing a breach in the first place is obviously the ideal, but completely reducing risk to zero isn’t possible, at least not within the kind of budgets most organizations have available for IT. For security professionals looking to take some of the worry about breaches off their plate, minimizing the impact instead of putting all their eggs in the prevention basket can be a useful way to get ahead of the curve.
Loading ...
