When we look at data classification,
it's really no different in the cloud than it is within any organization.
But we're dealing with a third party, so it's important that all of the
parties to a contract know what the appropriate and proper protection of
data is, and the classification is way to indicate that. The purpose of
data classification is to ensure that data is provided an appropriate
level of protection.
We could also say an adequate level of protection as well.
Classification is sometimes also known as categorization.
It is something, which is the responsibility of the data owner.
Even though the data owner may never do the classification themselves,
they are responsible to ensure that it is being done in the proper
manner by those to whom that task has been delegated.
The basis for classification is based on business.
The idea that we have certain business elements that need data to be
classified because it should not be released, disclosed to unauthorized
people because it's important for business operations.
For example,
we can have ongoing projects and things that are happening
that we don't want people to know, part of our new
marketing plan or that sort of thing.
We also have different business functions that some business requires
the processing of personally identifiable information or even
protected health information, and we need to identify where we are
using data that does require protection.
But the basis for classification is also based very
much on laws and regulations.
We have laws that specify how data and what data must
be protected. For the most part,
data protection comes under two categories, sensitive and critical. Sensitive
data is data that could harm an organization or an individual if that data
was improperly modified or improperly disclosed.
So really, sensitivity is a measure of the level of confidentiality and
integrity protections we need to build into the data. Criticality deals
with how much the business requires that information to be available in
order for a business function to work.
And so criticality is usually related to availability.
Organizations are different, departments are different, systems are different.
So it could well be that one piece of information is very
critical in one system, but that same piece of information
is just nice to have on another.
But then we have to look at protecting that data appropriately so
that when it does require a high level of protection on one
system that that is a consistent way that the protection is
provided on other systems as well.
There is always debate about how many levels of data
classification an organization should have, and that is something
that has to be determined by the data owner.
It could well be that three levels are sufficient, whereas
in some organizations they need more.
The important thing is that each level should be distinct.
The handling requirements should be clearly articulated
or documented for each of the levels.
It should be easy for one person to know what are the requirements
on, say, another system for classification of it.
So it's not such that, well, I'm not sure if this should
be considered to be secret or top secret or business
private or business confidential.
No,
there should be clear guidelines that specify what are the
criteria for each of the levels of classification.
We could say those are documented parameters.
And in some cases, the default should be to go to a higher
level of classification rather than a lower, but that depends
a lot on the type of organization,
depends on laws, and depends, in many cases, on the
attitude of the data owner as well.
The process for data classification starts with something we looked at
at the beginning of this course, data identification.
This is a stumbling point for many organizations who don't really
even know what data they have or where it is.
So, it is important that we not only identify what data we have,
but where is it?
And that is the data mapping.
We do data flow diagrams,
how does it go from this system to another system? We do flow charts to
see the path data takes through the organization. And that information
provides what's required for the data owner to be able to put in place the
correct levels of protection for it.
We need to know who owns the data and, of course, then appropriately label it.
Even something like a report should always have a label
that says this is business private or business
confidential or for official use only.
So anybody who picks it up knows right away that this is something
that requires protection. When we look at labeling,
of course, the labeling is an indication of what the classification is.
It then mandates or indicates what type of handling provisions have to be taken.
Can this information be shared with a coworker?
Can it be shared with the customer?
Does this need to be securely destroyed at the end of life?
And so in many cases, the label is an important identifier to a user of
what they can and, of course, cannot do with that data.
It's important that the labeling is something that is done consistently.
We don't want a piece of information to be considered business
private on one system and not protected on another.
So, consistency is important here, which is why the use of
data flows is often very important as well.
We know that some departments may take data
protection more seriously than others.
We quite often see that there's a difference in culture
between sales and finance, for example.
But it's important that when we have something like credit card or payment
card information, even though that came in on a sales system that got
passed to finance for monthly recurring building,
it's important that it's protected consistently on
both sales and financial systems.
It could well be that we have two different system
owners who have very different cultures.
But the role of the data owner is to make sure that even though this piece of
data ends up on multiple systems with different system owners,
it is still protected consistently on all systems.
We've often heard people say,
well, I don't want to put a big red label on this that says top secret
because that'll just draw people's attention to it.
There could be some, should we say, merit to that argument.
It's the old story of, in some cases, that we hide something in
plain sight and maybe people don't notice it.
But the general rule is it's better to label it so people
know it needs to be protected, and anyone who sees it knows
right away that must be protected.
It can't be left lying around, for example.
But the challenge, of course, is that if I become too
compartmentalized so that we don't share information,
it could be we lose some of the synergies and some of the
benefits we have of people being able to work collaboratively.
And we don't end up with two people doing the same thing, but
because they can't share information,
we end up with duplication of effort as well.
So labeling is important.
The handling is important, and, of course, the most important of all that is
train people, what does it mean when a report on the bottom,
it says business private.
If they don't know what it means, then there's no sense putting a label on it.
And a very good example of this is emails.
Many organizations have a footer on the emails that says
this is a confidential communication.
Yeah, but if they put that on every single email, what does it mean?
Because many of the emails are not confidential.
It's an invitation to go for lunch, for example.
And so those are the sorts of things where we have to be careful
that we label things appropriately as well.