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

[Audrey McNeil]

http://www.theregister.co.uk/2016/03/15/data_ownership_classification/

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160315/38082588/attachment.html>