Who watches over your data – and how do you know it won't go AWOL?

You can trust your staff. Trusting their infosec knowledge, though...

There are a couple of alternative interpretations of the concept of data ownership. The first relates to the legal ownership of data – the intellectual property aspects such as copyrights, designs and trademarks.

Now, while that's a world I did work in for a few years it's the other interpretation I'm concerned with here: the idea of who is responsible for looking after each bit of data that's processed and stored within an organisation.

Some of it's structured ...

The typical organisation has a wide selection of data, and most of it is usually pretty unstructured. The minority of structured items tend to fall into the same pots in each organisation: the first obvious example is that human resources information and the associated payroll details are always structured.

Common example number two is the rigour that the finance team will always apply to the processing and storage of the company's accounting detail.

… but the rest of it isn't

For the remainder, the level of structure applied to the storage of data is generally down to how organised each of the different departments actually is. It's not that everyone just throws their data in a single folder at random, just that most people tend to start organised and then let things go over time.

How many of us have a home directory and a team directory, each nicely organised but each with a “stuff to file one day” folder full of stuff that never gets either filed or thrown away?

Why does it matter?

At a basic level a bit of disorganisation doesn't hurt anyone. The problem is when time passes and you start to lose track of what the current version of anything actually is, and what stage each document had reached in its lifetime.

So you've finished that tender document for the new fleet of vans for your retail company, you've saved it in a server folder, then you've shared it with colleagues for their comments and corrections.

A few days later you've received comments via email and some people have run up their own versions of your original with Track Changes turned on. So you end up with a few versions of your own document intermingled with “Fleet Tender v1 – John Comments”, “Fleet Tender v1 – Revised” and so on. Worse still, people then share early versions with others, so you find unofficial versions becoming accepted as the “correct” document.

At this point you're thinking: “Sounds like I need a document management system” – and you probably do – but what matters most is that on the first page of the document you stipulate the version and the document owner, along with where the master version lives. The document management system helps, sure, but the essential component is the ownership and the clarity of that ownership.

Which leads to …

When you know who owns an item of data within the organisation you can consider classifying it. By classification I mean labelling it (electronically, preferably) with the appropriate level of confidentiality. At this point let's mention briefly what I mean by “classified”. I don't mean the stereotypical MI5 drama approach, where spooks stamp CLASSIFIED all over documents and treat the word as synonymous with “secret”. I mean the traditional meaning where you give the data a classification, generally starting with “public” and working up to “super-duper-secret”.

“But it's obvious when something's secret!” you cry. Errr … yes, but only to the people closest to the data item in question.

Let's take an example. Say you have a number of procedure documents that detail how to set up LAN switches, routers and the like. Pretty standard stuff – you probably cribbed much of the content from the Internet anyway and tweaked it to fit your company. The latter is important, though. Would you send a copy to a friend at another company to help her out with her LAN setup? Maybe, but you shouldn't: if someone outside the company has your cheat sheet for setting up a router then you may be handing them IP addresses or login names on a plate, and showing them the bits of the security hardening that you've missed.

What classifications should I use?

It's up to you, but try not to go for more than four or it'll get confusing. Often two is enough – “public” and “confidential”, where “public” information is allowable for transmission outside the company and “confidential” isn't.

Generally you'll have at least three, because for internal dissemination there's bound to be information you're happy for all staff to read (process and procedure documents or the staff phone book, for instance) and stuff you're not (payroll data is the obvious one there). Oh, and go for the approach where any document that doesn't have a classification is assumed to be stamped with the strictest level of classification.

Training the data owners

Whichever approach you use, though, you need to train your data owners. In the example I gave regarding router config cheat sheets, it might not even occur to the average network engineer that sending it to an external friend may have security implications. You need to train the data owners, then. You could take the approach that senior managers are the owners for all data within their divisions, but this would take too much of their time and so in reality they'll delegate the responsibility for owning and classifying data (which means the delegates need the appropriate training).

Of course it's still the senior manager's arse that gets kicked for breaches (ownership = accountability = the buck stops here) so he or she will need to be confident that they're delegating responsibility (responsibility = the duty of doing the work but without the accountability) to competent individuals who are sufficiently knowledgable not to get them shot.

Training the rest

And although it's obvious that the people owning and classifying the data need to be trained, it should also be obvious that everyone in the organisation is trained to understand the classification scheme and how it relates to them. Let's take another example. Imagine you've received yet another prospective client's security questionnaire to fill in, and it asks for copies of your security procedures.

It's understandable that someone might be tempted to zip them up and send them over – after all, the implication is that the third party won't do business with you if you refuse to answer their requests. In fact you shouldn't send these documents out, because they give clues to your processes and may give an intruder (or a competitor) some useful information.

But if your staff know that they're not allowed to send out anything unless it's classified as “public”, regardless of the subtleties of the request, there's no room for doubt and your integrity is preserved.

Summary

Data ownership and classification are both a pain in the backside. At a corporate level you have to assign ownership for vast swathes of data to senior people and then deal with the training aspects both for them and for the people to whom they delegate the responsibility of maintaining, storing, updating and classifying the documents. But in these days when you want to be compliant with the process and security standards that are becoming more and more popular, it's an evil you have to live with.

So start as soon as you can: no matter how big your corporate data collection is now, it's only ever going to get bigger. ®

Sponsored: Becoming a Pragmatic Security Leader




Biting the hand that feeds IT © 1998–2019