Let's take a look at data disposition.
The idea is that data has incredible value,
not just on itself, but often an aggregate as well.
We accumulate vast amounts of data within most organizations, and we can
use that data to do different types of data analysis.
We often have referred to that these days as things like
machine learning and artificial intelligence.
But the idea is that it's a form of data mining. It's searching and
doing analysis of our data in order to support business functions such
as marketing or doing research, for example.
And one of the things that the cloud is especially good at
is being able to give us a platform to be able to host and
process vast amounts of data.
We even saw this, for example, in the contract awarded by the CIA in the
United States was that because they had so much data that came in from all
different sources and it needed to be processed quickly,
they needed to do real time or at least near real‑time analysis. And
for this, they found that using the algorithms and the capabilities
of the cloud were very good for that.
You can be sure that's very much a private cloud though because the data is
extremely sensitive. And so even though it has a vast amount of data that's very
much only for one customer with very limited access,
both in a physical, but also, of course, in a network type of sense as
well. The idea is that by using our data effectively, we are able to be
more efficient and more effective in what we do.
And the cloud works very well for collaboration,
things like business intelligence,
being able to tap into all of the information we have
from different parts of the world.
For example, even one large organization is always looking at weather.
So even though they are a retail company that is selling products to
customers, by feeding weather reports into their data analysis,
they are able to predict what is going to be required in a local store
based on the weather coming in in the next few days.
So, the cloud has, in many ways, enabled this by being able to
process and store vast amounts of data that were a little bit
impractical for most organizations in the past.
The challenge, of course, always is that when I have vast amounts of data,
I need to know how to be able to store it, process it, and
in some cases, we'll need to archive it,
keeping it maybe even off site for a number of years,
depending on regulations. And that data that's stored offsite
or archived needs also to be retrieved.
That means that if I need to retrieve archived data, there should be
clear procedures on how that data can be obtained.
And this quite often can mean working with a cloud service provider.
We have seen even how large cloud service providers are archiving
vast amounts of data into systems that are not online as such and
allow us to be able to remove the amount of data that's sitting there
in production systems.
But we need to work with a cloud service provider to enable that data access.
Usually, it's going to be a lot slower than the data, of course, that
is online all the time. But there should be some type of backup and
archive schedule that's used for this.
Do we automatically back everything up every day?
Do we archive data that hasn't been accessed in 30 days or 60 days?
And these are things that we have to build into our data handling
procedures. When it comes to data retention, we know that this is based a
lot on what does the business need, but also as we've seen on legal
requirements. We have a lot of data we may need to keep on our customers
if we've had a customer, say, we're a telecom. And we've had a customer
living in a house for 40 years, we need to keep a record of their old bills,
all our interactions with them, but we certainly don't
want to keep that in production.
We archive it off.
But in most cases, we can't just delete that until that
customer is no longer a customer.
It's the same with health information.
If we've provided health care for a person,
we are usually required to keep that available as long as that person is alive.
So there are,
we can say here, considerations that have to be built into
our archiving and retention process.
There's one other term we should bring in here, and that's the
term legal hold. Let's say, for example,
I have a customer who wants to initiate some type of lawsuit because
they're not happy with the service that my company provided.
And the moment I'm advised that there could be a lawsuit coming,
one of the things we're often required to do is immediately then
ensure that any data related to that customer or that area that's
subject to this type of court action is being preserved, and
that's called legal hold.
And, of course, that, in some cases, can mean that normally I would
have deleted data I didn't need after three months.
I might have to keep this for several years because it could be the
subject of a pending type of court action, so that's a legal hold.
And that's where we have to have what would be an exception to maybe
our data deletion policy.
When I have a paper document in my hand,
it's quite easy to make sure I have defensible destruction.
I stand, and I watch it go through a shredder, and I see that it's been
ground up into even little paper fragments and so on.
I know it was destroyed. But when I've stored something on the cloud,
how can I make sure that data was deleted? When we're dealing
with secure destruction by a cloud service provider, it's much
more difficult because I can't just do something like
overwriting. When I go to overwrite,
I don't even know if I'm overwriting to the same place my original data was.
My data might have moved around many times within the various systems and
hardware devices of the cloud service provider.
And so therefore, I should ensure that my contract to the cloud
service provider include the fact that all of their old hardware
will be destroyed. When a piece of equipment is being replaced by
the cloud service provider,
it will actually be physically destroyed, and that, of course,
can help ensure that any data that's on that will not be recoverable.
Now, this becomes a little bit of an onerous task because
there can be an awful lot of equipment, therefore, that needs
to be destroyed on a regular basis.
I know one cloud service provider,
they replace a piece of hardware every two minutes around
the world, and that's an awful lot of hardware then that has
to be then property destroyed.
And in a case like that, we've seen they've sometimes subcontracted that out.
And we've seen several cases where the subcontracting company instead
of actually destroying it actually was reselling it.
So, defensible destruction means that I try to make sure that not only do I
have a contract with a cloud service provider, but that that contract is
being audited and followed to make sure that they are then living up to the
terms of that contract as well. Hardware destruction is considered the most
secure and, in fact, the only truly secure way to ensure data deletion.
Overwriting, degaussing, purging, clearing, not usually good enough because
we could still have what we call data remnants, little bits of the data that
remain on that piece of hardware, especially with solid state.
Solid state is very difficult to truly clear the data that was on it,
and that may be retrievable using advanced systems.
We have seen this where we know that data has been recovered
that's been overwritten more than 100 times using things like
electron microscopes and so on.
Obviously, it's good to overwrite when we can.
It's good to degause, but in the case of a cloud, it's very difficult to make
sure I'm even overwriting to the same place my data was.
And, of course, since I don't have access to the hardware, I can't
actually ensure that the degaussing is being done or that the
hardware that was degaussed is tested to make sure that the
degaussing actually worked, either.
So some of the options we've had to ensure that as a cloud consumer,
how can I make sure my data cannot be recovered by the cloud provider?
And one of those is bit splitting. We protect data from compromising by
encrypting the data, but then we split the encrypted data into pieces
stored at different locations.
So even if a person was able to get access to the data at one location,
it would be incomplete data, and the unauthorized person will not
be able to understand or reconstruct the data.
We also have what we call erasure coding, data split into
fragments and built out with redundant characters.
The idea of this is that if I need to reconstruct the data,
I could do so by gathering a certain number of the fragments.
We often say that, for example, if I broke it into 16 fragments, I would
need 10 of those to be able to reconstruct the data.
So that's what we call n of m.
We need n number of fragments out of a total of m number of fragments.
And so what I've done, I took the data. I broke it into 16 pieces, but
all of those pieces kind of overlapped a bit. So as long as I had 10 of
them, I could actually recover the data.
This is also known as forward error correction. And yeah, all or nothing
transformation of the Reed Solomon was one of the examples of this.
The idea of cryptographic erasure, or sometimes called
crypto‑shredding, is the idea that what I will do as a cloud consumer
is ensure that all of my data on the cloud is encrypted.
I never store anything on the cloud without it being encrypted
first. I keep the key. And let's say I leave this cloud provider
to go to a different cloud provider.
Then all I need to do is retrieve my data off of the cloud provider, decrypt it,
and then when I load it on the new cloud provider systems,
I encrypt it with a different key, then I destroy the old key.
And what that means, of course,
is all of that data on the original cloud provider would not be recoverable.
The actual key has been lost, and it would not be computationally feasible
under today's processes to be able to recover the data.
The key points review. We've looked here at your data
protection. We know that this is a challenge,
especially when we're dealing with a cloud service provider
because we don't know what they actually do.
We hopefully try to protect ourselves through
contracts and service‑level agreements.
But in the end,
things like hardware destruction is something that is
really beyond our direct control.
We know that contracts and SLAs can specify what should be done,
but they don't guarantee that that was followed.
So therefore, I should try to ensure secure data deletion
maybe through audits or reviews of the cloud service
provider systems using some type of, for example,
an SSAE 20 or other type of agreed evaluation schema.