Data Breach Triangle

Pragmatic Data Security: Groundwork

By Rich

Back in Part 1 of our series on Pragmatic Data Security, we covered some guiding concepts. Before we actually dig in, there's some more groundwork we need to cover. There are two important fundamentals that provide context for the rest of the process.

The Data Breach Triangle

In May of 2009 I published a piece on the Data Breach Triangle, which is based on the fire triangle every Boy Scout and firefighter is intimately familiar with. For a fire to burn you need fuel, oxygen, and heat -- take any single element away and there's no combustion. Extending that idea: to experience a data breach you need an exploit, data, and an egress route. If you block the attacker from getting in, don't leave them data to steal, or block the stolen data's outbound path, you can't have a successful breach.

To date, the vast majority of information security spending is directed purely at preventing exploits -- including everything from vulnerability management, to firewalls, to antivirus. But when it comes to data security, in many cases it's far cheaper and easier to block the outbound path, or make the data harder to access in the first place. That's why, as we detail the process, you'll notice we spend a lot of time finding and removing data from where it shouldn't be, and locking down outbound egress channels.

The Two Domains of Data Security

We're going to be talking about a lot of technologies through this series. Data security is a pretty big area, and takes the right collection of tools to accomplish. Think about network security -- we use everything from firewalls, to IDS/IPS, to vulnerability assessment and monitoring tools. Data security is no different, but I like to divide both the technologies and the processes into two major buckets, based on how we access and use the information:

1. The Data Center and Enterprise Applications -- When a user access content through an enterprise application (client/server or web), often backed by a database.
2. Productivity Tools -- When a user works with information with their desktop tools, as opposed to connecting to something in the data center. This bucket also includes our communications applications. If you are creating or accessing the content in Microsoft Office, or exchanging it over email/IM, it's in this category.

To provide a little more context, our web application and database security tools fall into the first domain, while DLP and rights management generally fall into the second.

Now I bet some of you thought I was going to talk about structured and unstructured data, but I think that distinction isn't nearly as applicable as the data center vs. productivity applications. Not all structured data is in a database, and not all unstructured data is on a workstation or file server. Practically speaking, we need to focus on the business workflow of how users work with data, not where the data might have come from. You can have structured data in anything from a database to a spreadsheet or a PDF file, or unstructured data stored in a database, so that's no longer an effective division when it comes to the design and implementation of appropriate security controls.

The distinction is important since we need to take slightly different approaches based on how a user works with the information, taking into account its transitions between the two domains. We have a different set of potential controls when a user comes through a controlled application, vs. when a user is creating or manipulating content on their desktop and exchanging it through email.

As we introduce and explore the Pragmatic Data Security process, you'll see that we rely heavily on the concepts of the Data Breach Triangle and these two domains of data security to focus our efforts and design the right business processes and control schemes without introducing unneeded complexity.

–Rich

The Data Breach Triangle

By Rich

I'd like to say I first became familiar with fire science back when I was in the Boulder County Fire Academy, but it really all started back in the Boy Scouts. One of the first things you learn when you're tasked with starting, or stopping, fires is something known as the fire triangle. Fire is a pretty fascinating process when you dig into it. It demonstrates many of the characteristics of life (consumption, reproduction, waste production, movement), but is just a nifty chemical reaction that's all sorts of fun when you're a kid with white gas and a lighter (sorry Mom). The fire triangle is a simple model used to describe the elements required for fire to exist: heat, fuel, and oxygen. Take away any of the three, and fire can't exist. (In recent years the triangle was updated to a tetrahedron, but since that would ruin my point, I'm ignoring it). In wildland fires we create backburns to remove fuel, in structure fires we use water to remove heat, and with fuel fires we use chemical agents to remove oxygen.

With all the recent breaches, I came up with the idea of a Data Breach Triangle to help prioritize security controls. The idea is that, just like fire, a breach needs three elements. Remove any of them and the breach is prevented. It consists of:

• Data: The equivalent of fuel -- information to steal or misuse.
• Exploit: The combination of a vulnerability and/or an exploit path to allow an attacker unapproved access to the data.
• Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive.

Our security controls should map to the triangle, and technically only one side needs to be broken to prevent a breach. For example, encryption or data masking removes the data (depending a lot on the encryption implementation). Patch management and proactive controls prevent exploits. Egress filtering or portable device control prevents egress. This assumes, of course, that these controls actually work -- which we all know isn't always the case.

When evaluating data security I like to look for the triangle -- will the controls in question really prevent the breach? That's why, for example, I'm a huge fan of DLP content discovery for data cleansing -- you get to ignore a whole big chunk of expensive security controls if there's no data to steal. For high-value networks, egress filtering is a key control if you can't remove the data or absolutely prevent exploits (exploits being the toughest part of the triangle to manage).

The nice bit is that exploit management is usually our main focus, but breaking the other two sides is often cheaper and easier.

–Rich