Data classification for dummies.
Catching up on my blog feeds, I see that Rich has been having a heated discussion on data classification and labels. I agree with him: beyond a very high level, data classification is too costly to be useful in most environments. When you start trying to get granular in your classification (“this document is confidential, this table is sensitive, these app pages are TopSekrit ...”), you immediately run into the temptation to label them so that they stay classified for everyone else to see. This leads to problems:
- Are you labelling the data, or the container holding the data? (Look at my examples above. Those are all containers, not the data. And yet, this is how people try to label things.)
- If you’re labelling the container, what do you do when the data moves to a different container? (This is one of Rich’s arguments.)
- If you’re labelling the data, how does it stay labelled as it flows through different formats and containers? (Imagine trying to tag ones and zeros, as “Ben” points out in the comments of Rich’s posting.)
In my experience, people don’t want to spend more than a bare minimum of brain cycles classifying data. They don’t WANT to have meta-thoughts about the data they’re working with: how it’s classified, how long it’s retained, or whether it’s going to be transferable in its current form to where it needs to go. They just want to work with the data and go home. In the IT field, we really enjoy classifying and modelling and thinking meta-thoughts way too much; our customers don’t. We should stop inflicting our anal retentiveness on them in the name of security.
And yet, at the same time, the business users can understand which kinds of data are confidential. Not because it’s labelled that way, but because in the context of their business process, they know which kinds of data in the wrong hands can lead to fraud, theft of trade secrets, or political or personal embarrassment. If you use the Boss Test—ask them, “Would your boss be angry if you posted this on the Internet / left it in a taxi / sent it to the wrong person?”—they can answer that. They do know—because they understand the business.
So in order to bolster data security, we need to do two things:
1. We need to make sure that each user understands the business classification of the data they work with. Which pieces of information are the company’s intellectual property; which information is absolutely not to be released until a certain date; what constitutes PII when you have enough of the elements in one place.
2. We need to teach them which technical measures they need to take when they understand that their data needs protecting. What to do with it, what not to do with it. And I don’t mean telling them not to post it on the Internet; they get that. We need to teach them not to put it on a web server that is Internet-accessible, even if they haven’t created a link to it, because they need to learn that a link isn’t the only way to get to data on a server. We need to teach them that sending email over the Internet is like sending a postcard that everyone along the way can read. We need to make sure they know the different ways you can shoot yourself in the foot by configuring and using software the wrong way.
Only in this way can we put the responsibility for data protection back on the business, which is where it should have been all along, and stop banging our heads against DLP appliances. If DLP solutions are only good for “stopping stupid,” well, there are different ways to cure stupid. We should help the business protect itself against mistakes wherever possible, but the brunt of our security efforts should be in removing the ignorance of the user, not in relying on technology to try to replace the user’s thought processes.
And I know this is going to sound totally heretical, but we shouldn’t try harder than the CEO. If s/he isn’t that concerned about data loss, there is no helping that organization until and unless something actually happens. Shrieking about risk isn’t going to help, and will only annoy the people around you. Because data protection belongs to the business, and because the CEO makes a risk decision every time the budget is signed off, we should be urging the CEO to make the organization’s business policies known.
Remember: the CEO probably understands the total business risk better than you do.
