Data Protection: Clear the roadblocks to “DOING IT AND DOING IT AND DOING IT WELL.”

“Mmmm yeah (mmm) check it out… Make it hot, then we drop it, yeah. …You know how we do it. …You make ’em rise” – Doin’ it (LL Cool J)

It’s time to come clean. You must be honest with yourself and your organization. You either care about your data, or you don’t. Your organization either cares about its’ data, or it does not.

No judgement here if you don’t care about data or data protection. I would say, however, that if you personally do care, you cannot and must not care more than your organization. You’ll just lose cycles and sleep. If you find yourself in that situation, I recommend updating your resume and looking for the next step. The world needs people that care about their data… but I digress….

…Being “in the process” of rolling out “DLP software” to your endpoints is NOT the same as a Data Protection Program.

Let’s all agree that if you’re still reading this, you do indeed care about your data, and a proper data protection program. That being acknowledged, I think it would be helpful to define some bare minimum items that must be in place to properly say you have a “Data Protection Program”:

1. Executive and board level support (must have clout, and “guts”)
2. End user awareness
3. Documented data classification rules (this doesn’t have to be a final draft, and simpler is better)
4. Identified data owners and lieutenants
5. Documented incident management procedures, including notification plans and personnel action plans (hint this should NOT generally be your secOps team)
6. Basic rules in place that actually BLOCK.

See, it’s simple! Just six simple things and you’re set to go! What are you waiting for? It’s as easy as 1. 2. 3. 4. 5. 6… (said no one ever)

I would like to note that only one item in this list has anything to do with technology. Sorry to say, but being “in the process” of rolling out “DLP software” to your endpoints is NOT the same as a Data Protection Program.

The world needs people that care about their data…

So what is “really” stopping organizations from making progress on their data protection journey?

There are some basic roadblocks that are stopping organizations from making effective progress within their data protection program. Roadblock #0 is assuming or pretending you have a mature data protection program without validating any of the basic program components.

Roadblock #0 is assuming or pretending you have a mature data protection program without validating any of the basic program components.

Especially for new leaders and executives, taking an in depth look into an organization’s current program is not trivial. Identifying weaknesses where likely a lot of time, money, and resources have already been spent is never easy, nor is it politically popular. However, you must be honest with your organization. You may have to rip the Band-Aid off.

If you can provide an accurate “state of affairs” of your organization’s current policies and procedures, you have a foundation upon which you can build. It can help to overcome the other basic roadblocks and make forward progress much more attainable.

Roadblock #1 – Lack of corporate initiative (aka “guts”) to make it happen.

“No doubt, I’m the playa that you’re talkin’ about. But do you really think that you can work it out?” – Doin’ it (LL Cool J)

• Fact: Most users want to do the right thing
• Fact: Most everyday data exfiltration comes from inadvertent or non-malicious activity
• Fact: Data protection policies can improve business process
• Fact: Your end customers actually care about their data, and your security standards. Proven and advertised security practices can maintain and grow your customer base.
• Fact: A woodchuck would chuck as much wood as a woodchuck could chuck if a woodchuck could chuck wood.

Ultimately, if there is no executive sponsorship or mandate, your data protection policy is destined to stagnate (or worse, fail). If you have not achieved the desired executive buy in, start by quoting formal or mandated compliance regulations. If that is not successful, ask “What data loss would shut down the business?”. If that is not successful, perhaps you have bigger problem with your office space. You might want to mention a red stapler.

Roadblock #2 – Lack of end-user awareness

“So whatcha sayin’? I get my swerve on, bring it live” – Doin’ it (LL Cool J)

There is a strong appreciation and consideration in most organizations around the “end user” experience. In many environments, quite frankly, it is the end-users that make the world turn. Yes, there may be manufacturing plants, or assembly lines, but most organizations today just need their users to get things done.

Most organizations today just need their users to get things done.

The most successful data protection programs to date have had a significant amount of user awareness campaigns. Admittedly, there is no value in boiling the ocean. However, sending basic notifications that there are going to be new data policies, (i.e. locking down data written to USB devices) is something every single employee wants to hear. It’s not impossible that a “bad actor” will be scared. What is more likely, however, is that a legitimate user will notify their manager that they actually use USB drives to copy things to a locked down server. “It takes two hours for backup/restore, but that is “how it has been done”, they may say. Just like that, an immediate, cost-effective opportunity to save time, money, and resources has been identified. The user can be updated on proper procedure, and also the data is still safe.

Roadblock #3: Treating historic data like new data

“Conventional methods…kinda bore me” – Doin’ it (LL Cool J)

We’ve all heard general stats like 90% of the world’s data has been generated in the last two years. This seems to be taken as “fact”, even though the most relevant scientific article I found was written in 2013. That being said, we know we’re creating a significant amount of data daily. It is likely that this is accurate within your organization.

Even if you get proper executive sponsorship, relevant stakeholders involved, and a broad user acceptance team, you’re going to be awash in meetings trying to capture all aspects of every possible data usage situation.

Many organizations are looking very closely at their “existing data”. This is absolutely reasonable. To be fair, “Data Loss Prevention” would seem to refer to “existing data”. However, considering that most organizations have a VAST amount of structured and unstructured data, the concept of creating rules, policies, control points, etc. for every nuance and situation of that legacy data can seem insurmountable. Even if you get proper executive sponsorship, relevant stakeholders involved, and a broad user acceptance team, you’re going to be awash in meetings trying to capture all aspects of every possible data usage situation. With such a wide audience within an organization, identifying edge cases versus common business practices becomes extremely difficult (ahem, nearly impossible) in this situation.

Begin to identify “sources” of data. What new things are being created by my organization? What types of entities does my organization share with? Start by handling data that is brand new.

What to do? Consider tackling the smallest chunk of data very early in your program. I would argue that the smallest chuck of data is that which doesn’t exist yet. (It is tough to get smaller than zero, because I’ve never heard of “negative data”, unless you count fake news, which can indeed have a negative impact… I digress again…)

Very specifically, give your organization a “clean slate”. Begin to identify “sources” of data. What new things are being created by my organization? What types of entities does my organization share with? Start by handling the data that is brand new. If you start having meetings with the goal of answering these two questions, you’re going to be miles (or miles x 1.6 = km’s) ahead of many data protection initiatives. Think about how far along you’d be if you had a proper program in place since 2013.

Roadblock #4a and #4b – Mistaking data “identification” with data “classification”, and over-complicating data “classification”

The data protection community (not sure if this is a real entity, but if so, it’s analogous to “the man”, or “mother nature”) has done a very poor job standardizing around a set of terminology that can be used widely throughout an organization. This is extremely prevalent when considering the terms “identification” and “classification”. Many software vendors in particular distort these two key components in the way they implement policy and rule sets.

Part 4a – Identification versus classification. What the…?

“It’s our first time together…” – Doin’ it (LL Cool J)

The data protection community has done a very poor job standardizing around a set of terminology that can be used widely throughout an organization.

I submit the following great example image just below. This image “sort of” refers to data identification. Presumably the “risk levels” refer to some sort of “classification”. Yet, while attempting to be consumable this image exacerbates the problem. While this image does provide a “high level” assessment of data risk and grouping, this chart is not detailed enough to handle every situation. On top of that, it is not simple enough to ensure wide user adoption. It is an image that makes executives “feel good” about their non-existent (or very immature) data protection program.

This is not meant to be a jab at the creator of this image. However, the lack of clarity is exactly my point. A common end user might look at this chart and say “Not one of the examples actually refers to my situation. What do I do about X, and Y, and then Z, which don’t show up on the chart? “

When too much effort is put into users’ hands trying to “solve” data loss for an organization, they simply won’t do it. They will do what they have done for as long as is doable until something is done. What am I saying? The chart should be separated out. Users themselves, or a software tool, should identify the piece of data. That should be the extent of end-user involvement. Your governance team should have policies around how users (read: how the DLP tool sets installed around the users) handle identified data.

When too much effort is put into users’ hands trying to “solve” data loss for an organization, they simply won’t do it. They will do what they have done for as long as is doable until something is done.

Given all of the confusion around terminology, I would like to put a stake in the ground here around terminology: Data identification versus Data classification:

Data identification MUST BE determining ‘what’ data it IS. It is a work order, or an invoice, or new custom code, or a social security number, or a unique recipe, or… … Data identification MUST NOT determine how that data is handled, shared, or consumed.

Data classification MUST BE grouping identified data into useful buckets to help determine how the data is handled, shared, and consumed. Am I at risk if this is shared with the public? Is this free to be accessed by all employees, or only certain groups? Is this allowed to be sent to 3rd party vendors?

Take a look at the following image. While this “classification chart” doesn’t specifically identify data handling policies, it does provide a mapping of the risk levels and data buckets. Keep in mind also that not every nuance or situation is mapped. In particular, this chart is overly simplistic as to be consumable.

When assessing your data protection policy, you must consider BOTH identification and classification as a combined matrix. However, when you start to think about all of the possible columns and rows of classification and identification, it could make your head spin. This leads us to part B of this roadblock: over-complicating your classification.

Part 4b – “Analysis paralysis” trying to classify the ocean,

” All this time you’ve been telling that you was a Don. I tried to warn you…you wouldn’t listen” – Doin’ it (LL Cool J)

Your organization has A LOT of data, and data classification scenarios. There are likely multiple lines of business. Certainly there are multiple stakeholders. It would seem reasonable that in order to “ensure a proper data protection program”, and not have “business impact”, that all data and classification scenarios should be documented.

While this seems like a reasonable idea, the act of attempting to understand and capture every single data movement scenario prior to ‘starting’ your data protection program is basically insurmountable. Many organizations literally cannot move past this step. They have several meetings and hours of work, and yet the data protection problem seems to only grow larger and larger.

Let me offer a somewhat different example. Say you’re starting to look very close at your personal budget. There are A LOT of expenses. Mortgage, groceries, car payment, gas, homeowners insurance, car insurance, disability insurance, life insurance, property tax, electricity, natural gas, water, medical copay, dental, pediatric care, cell phone, home internet… Those are just some of the ‘core’ expenses. Then there’s things like Amazon Prime subscription, Netflix subscription, eating out, grabbing drinks with friends, happy hours, going to movies, babysitters, buying clothes, car washes…

…your data protection program is ever evolving. Get started, and then re-assess. Don’t have “analysis paralysis”.

Keep in mind that after “several meetings” those are the expenses that you were able to come up with. Have you truly “captured” everything? Not likely.

When you consider the complexity around the large number of “financial exfiltration vectors”, how are you expected to understand your personal finances? Now say you’re trying to “protect against some of those financial exfiltration vectors”… How do you go about assessing the situation? How do you even make progress?

Let’s add an additional component here. Imagine you obtain all sorts of advice/input around your financial situation from various “stakeholders”. Each stakeholder certainly has ideas, yet not all of them are equally vested in the problem. It becomes clear that this problem is growing larger and more complex. So how come you have made faster progress on your personal budget?

When you’re working on your “budget” program, and and are working to learn about your “financial” exfiltration, you have to start somewhere. One attainable and actionable approach is to start by grouping things much more broadly. Is this the “final draft” of the budget? Of course not. Yet it can drastically help to reduce complexity.

You can make very real progress even as your data protection program evolves.

If you look at “finance exfiltration vectors” such as going out to movies, going out to eat, happy hours, etc, wouldn’t it be easier to start by grouping these all into “entertainment”? Later, as your budget process matures, you can move to more detailed analysis. There’s an argument here that this correlates to a “data classification” program as well.

The reality is that your data protection program is ever evolving. Get started, and then re-assess. Don’t have “analysis paralysis”. Simplify your classifications. Start with just a few. Then, re-assess. Your program is evolving. Be flexible to evolve as your program evolves.

In conclusion: Don’t let these roadblocks get in the way of moving forward with your data protection program.

You can make very real progress even as your data protection program evolves. It is easy, and reasonable, to get into the minutiae of every edge case. Make a hard push towards the basics, and overcome those roadblocks. You can look like a data protection champion. Best of luck “doing it and doing it and doing it well”.

Thank you to LL Cool J, for telling us that we should be “Doin it” it well! Also, thank you to Ellie Goulding for asking “What are you waiting for?”

#StayVigilant
#StaySafe
#LookOutForEachOther