Trevor J. Morgan l Nov 4, 2021 l Data Protection

Breach Prevention or Breach Mitigation? Choose Wisely!

So here’s a philosophical question: is it better to try to prevent something unfortunate from happening, even if the prevention success rate is much below 100%, or ensure that if something unfortunate does occur, the negative effects are limited and mitigated 100% of the time?

I call this a philosophical question, and yet we deal with these types of trade-off decisions quite often. Do you do everything you can to prevent anything from hurting that new car, even up to keeping it secured in the garage and never driving it, or do you purchase a top-notch insurance policy to take care of any contingency so that the car is fully repaired or replaced in the event of an incident? What about your garden? Do you put up all sorts of fencing and other obstacles to keep those pesky bunnies away from your prize flowers, or do you spray the flowers with pungent rodent repellent so that even if they breach the fencing you meticulously erected, they simply don’t want anything to do with the foliage? Look around your daily life and see how much effort you put into incident prevention versus incident mitigation to ameliorate any ill effects that might occur after the fact.

CISOs and IT security decision-makers confront this very question as they manage the risk inherent in a data-rich enterprise. Most organizations collect, process, and store tons of information, a considerable amount of which is highly sensitive (think intellectual property and trade secrets) or private in nature (such as customer PII or PHI). That data is the crown jewel of any organization. Leadership makes decisions based upon it, product managers innovate new products and services in reaction to it, and sales executives find new contacts because of it. No doubt, data drives your business.

Having that highly valuable asset—which by the way is probably governed by strict regulations on how to handle and protect it—fall into the wrong hands would be catastrophic. It could generate negative publicity, lawsuits, compliance troubles, and reputational damage to the brand. This is the reason that CISOs and IT security decision-makers think the question through very carefully. Is the best investment in breach prevention, doing everything possible to keep threat actors out of the IT environment altogether, or in breach mitigation to make sure that threat actors can’t actually do anything with the information even after a successful breach? You could make an argument either way, and in reality the question isn’t an either-or but rather a both-and. Still, you can pick apart the problem and draw some interesting conclusions.

Given the explosive growth in attack vectors due to remote workforces and workflows, distributed IT infrastructures, vulnerable application stacks, and cloud-based services and resources, keeping threat actors out of an IT environment is actually becoming more and more difficult, if not unlikely. I’ve said many times before in various forums that hackers are persistent and patient—given enough time and incentive, they will find a way through or around any defensive perimeter you construct to keep them out. Am I suggesting that we give up the fight on the borders because they are doomed to fail under sustained attack? Hardly. What I am saying, though, is that having too much confidence in perimeter security and the notion that you are always able to keep the wrong people out of your environment is a bit of a pipe dream. It’s one tactic—a first-line tactic, actually—among many that you need to implement in order to keep your enterprise data and supporting IT resources safe.

In a series on Zero Trust that I wrote recently, I talked about the old medieval castle structure and the many different breach prevention methods they implemented to keep invaders out. From outer walls to inner walls, to moats and drawbridges, and then to inner keeps and narrow winding staircases, the architects of these amazing structures knew that eventually an unwanted invader or attacker would breach the outer perimeter. And perhaps the next one, and the one after that. When you really investigate defensive structures like this, you see that ultimately breach prevention gives way to breach mitigation. Hidden exits, multiple escape routes, and other types of misdirection helped to get people away from the invading hordes and keep them safe to fight another day.

At some point in the execution of a cybersecurity strategy, you have to face the fact that the environment is going to be breached no matter what defensive actions you take (and investments you make). By the way, this assumption is a core principle of Zero Trust, implying that your IT environment already has been attacked and that your enterprise data is already being compromised. The focus ultimately must shift from prevention efforts to mitigation efforts. If a threat actor finds a way through to the inside (or perhaps even starts from the inside), how can you ensure that the negative repercussions are minimal?

The answer is data-centric security, which means applying the protection method directly to the data instead of the resources or perimeters around it. We mitigate these types of cyber-attacks by neutralizing the data so that threat actors cannot comprehend it and therefore cannot leverage it for financial gain or blackmail. Data encryption is one type of breach mitigation, and in many cases it works just fine. You just have to know the limitations of each protection method. Encryption algorithms can be cracked, and operationally data encryption comes with some baggage in the form of key management and the distortion of the original data format. While these obstacles aren’t deal-breakers necessarily, you do have to work through them, with key management systems and processes as well as application modifications to handle encrypted data which isn’t in its original format that the application expects. These workarounds aren’t cheap.

Tokenization, by contrast, is a data-centric security method that provides pretty solid breach mitigation. Tokenization replaces sensitive data elements with representational tokens, but in so doing it preserves the data format and demands no exchange or management of keys. The best-case scenario is that you protect your data (tokenize it) when it first enters your data environment and never de-protect it, and you can do that because of format preservation. Combined with effective data discovery, data classification, and data lineage tracing, tokenization can prevent a successful intrusion from becoming a full-blown PR nightmare. If threat actors can’t read the data, understand the sensitive information, or leverage any of it for gain, then the threat is neutralized.

One warm, humid night this past summer, as I sat around a camp fire, I noticed that the mosquitos were out in force. While I had put out citronella candles and Tiki torches around the perimeter, those darn mosquitos had the nerve to ignore those defensive maneuvers and swarm me anyway. Fortunately, I had applied some mosquito repellent directly to my skin. Once or twice a mosquito buzzed nearby, but they all stopped short of landing and feasting on me. Breach prevented? Absolutely not. Breach mitigated? Absolutely!

Share this:  LinkedIn XING Email

What is the best way to protect data?

Short answer - it depends. Each data protection method has it's own set of strengths and weaknesses that make it ideal in certain situations and less ideal in others. To learn more, click the button below to download our free eBook "Data Protection Explained: Weighing the Different Data Protection Methods": 

Download eBook

Related posts