When it comes to protecting our data in the cloud,
we need to monitor for compliance.
This is why we have to take a look at cloud data event management as well.
What we see is that, in many cases, cloud
deployments are kind of forgotten about.
In fact,
many organizations have no idea how many different cloud
deployments they're using until maybe they install something
like a CASB and it opens their eyes to see how much data they
have in various places on the cloud.
We need to monitor for compliance,
compliance with contracts and service‑level agreements.
The first step is always to ensure there's a contract there that stipulates and
mandates what type of data protection must be provided as an agreement between
both the cloud consumer and cloud service provider.
Then we monitor for compliance.
We review the logs. Who accessed the data? And this is
something that should be done on a regular basis.
Are people accessing the data at strange times? Are people accessing
the data who don't have a business need to know? And this is something
that we have to look for to try to discover if there is some misuse of
our data or inappropriate access.
We should carefully review access controls.
Maybe a person worked in one area and needed access to this data, but
they've moved. They don't need that anymore, and that should be removed
under principles of, say, need to know. We should make sure we have
encryption and the encryption is being applied.
We've seen cases where an organization believed that all of their
network traffic was encrypted, but when they started to look at it,
it obviously wasn't being encrypted.
The other thing we should review is to make sure that old
equipment is being destroyed, and no one is going to be able to
pick up our data off of a piece of equipment that a cloud
service provider has discarded.
When we do log review, one of the problems is that there's just too much of it.
We have enormous amounts of log data and certainly not enough
time to be able to look at it all manually.
There is a cost associated with storing logs, as well as the performance
impact on our networks and systems from creating all of these logs. But we
need a team of people that has the skills and, of course, tools necessary to
be able to take a look at a log and find the things that are important to
doing analysis of those logs. A lot of the different events we are going to
look for, we're going to examine according to what IP address maybe did they
come from?
Where in the world were they located at the time? And, of course, to try
to identify who it was. Was it an authorized entity or was it a suspicious
entity trying to get access to our systems?
The idea of geolocation and identifying where a person is
is also used within an organization.
Maybe a person's access is different if they're in the office than, for
example, if they're not working in the office that day,
they're working from home or at a remote location. There can come
times that we need to do an investigation. And an investigation in
the cloud becomes a little more challenging because we have to have
the cooperation of the cloud provider to provide us the logs and
information we need.
So there should always be within a service‑level agreement an establishment of
a communication path or liaison who we can reach out to that is our primary
point of contact if we need some information. That liaison will then ensure
that the information we get is complete and hasn't been altered in some way
before it was provided to us.
So this should be done through, obviously, a formal
agreement because an investigation could, of course, end
up being a legal matter as well.
And this also should review what happens if law enforcement needs access to
our data? There can be times that maybe law enforcement shows up at a cloud
service provider and they want access to our data.
We want to make sure that they only get access to the
data that they are authorized to obtain.
But obviously, we want to be compliant with any type of
court mandate, warrant, and so on.
And the idea of law enforcement is an important thing here because, in
some cases, even a cloud provider may be required not to disclose the
fact that some type of warrant has been issued.
We want to cover this. We want to deal with what happens if the
cloud provider finds out that one of our employees was maybe
doing something that is improper,
even possibly illegal based on those cloud‑based services as well.
We want to be compliant with the needs of regulators who when
they're trying to enforce things like privacy laws,
want us to be able to prove that unauthorized people aren't looking
at our data, for example. We also have to look at this area of
criticality and therefore data availability.
Will the data be available when it's required in a timely manner, for
example? And that includes not just production data,
but sometimes archived data.
Even going back in logs, how long do we keep our logs?
Do we keep them for 7 days,
30 days or years? As well as if a request comes in, how quickly
can that data be then provided back to us?
It also should be in some type of acceptable format.
We put the data in a format that we'll be able to read or use as well.
One of the things that has been a tremendous advantage for many
companies ever since the days of managed security service providers
was the use of a security operation center.
Now, many companies have their own,
but especially many small companies, it just wouldn't pay for them
to try to develop the skills or the personnel necessary to do
proper investigations and monitoring.
So, those were often provided through a managed security
service provider as a third‑party service.
But now we also see, of course, many of the cloud providers
provide this type of a service as well.
The advantage is that, let's say,
a cloud provider hosts information for 100 different companies, and they are
setting up through their security operations center monitoring of all of their
hardware, networks, and that allows, of course,
a central point of monitoring for those 100 companies.
And it means that the people working in the SOC are getting a lot more
experience than they would if they worked for any one of those individual
companies. They obtain the skills they need. They have the experience.
They're able, in many cases, to be able to detect something, which is
abnormal faster than somebody else.
There's also an advantage.
Let's say of those 100 companies, one of them had a problem.
Now the staff that is working on resolving that problem learns and can
go to the other 99 companies and make sure they're not vulnerable or
exposed to that same type of attack as well.
There's a lot of advantages through these types of
centralized monitoring systems.
When we need to do an investigation in the cloud, obviously
this depends on our type of deployment model.
In the case of Software as a Service,
everything rests really with a cloud service provider with the exception
of things like access control. I, as a cloud consumer, determine who has
access of my employees to the data, but all of the data logs and
everything are really held by the cloud service provider. In the case of
Platform as a Service, this can be a split responsibility.
I still manage access control, but it could well be that I have certain logs
that I manage, but there could be ones that are managed also by the cloud
service provider as well, say, a database journal.
If Infrastructure as a Service, really the primary
responsibility is going to be that of the cloud consumer.
The only things that the cloud service provider could be involved in was,
say, physical access or the security of hardware and so on.
One of the things that's important when we do an investigation
is to be able to identify who was involved.
And it's important here that we have the ability through logging,
for example, to track all activity and be able to associate that
activity with an identifier, whether or not that's a user ID or
an IP address and so on.
But these logs are important.
They're necessary in order to do an investigation and hopefully
get the right results from that investigation.
So therefore, we should very strictly control who has access to those
logs. We'll often see that logs will be written off to a separate system
where even a system administrator is not going to be able to get in and,
say, delete any entries in those logs.
When we create the log,
we then calculate what is the hash of that log so that over time
we can prove that log has not been altered.
It's still the original genuine log that was created at the time of
the incident. Storing everything on a separate system can be good, For
one, it may be a little less expensive,
but also it can prevent unauthorized access, as well as, as we did
with databases with remote journaling, one of the big advantages was
that if the primary hardware was damaged,
we still have all the log entries on that separate system so
we can investigate and know what happened or if, in the case
of a database, rebuild lost data.
Doing research of, say, forensics in support of
investigation is often called data discovery.
When we do this, we have to be careful that we do not violate a person's rights.
Everybody has certain reasonable expectations of privacy, for example.
And if we allow a person to use their bring your own device
laptop, both for personal and for business use,
I have to be careful that if I'm doing an investigation,
I'm not looking into their personal data.
There is a requirement here to comply with regulations.
People should know whether or not activity is being logged,
and, of course, they should know whether or not we are
monitoring their traffic as well.
An important thing in supporting an investigation is the
establishment of an unbroken record of everything that has
happened with any type of evidence during the investigation, and
this is called a chain of custody.
It's an unbroken record of who had access to that.
What did they do with it?
And, of course, when was this?
How did they protect it and so on? The problem is that in the cloud
this becomes more difficult because it's not one person who's the
evidence custodian who can demonstrate they have had control of
that evidence at all times.
No,
originally it came from somebody at the cloud provider out to the cloud
consumer. And so there's already a bit of a break there in the evidence
chain. When our evidence is provided by a third party,
it's never going to be as trustworthy as something that
we then actually gathered ourselves.
How do we know that that third party didn't alter it,
for example? How trustworthy are they? And as well, did they have
the skill to make sure that all of the relevant evidence was
obtained and provided? So for all of this,
we should have clearly defined procedures.
How do we protect our information and our investigations so that we hopefully
will have genuine correct information so that the correct analysis can be
done? One thing that should be brought in here is the idea of non‑disclosure
agreements. A non‑disclosure agreement means that if a person has access to
certain sensitive information, they will not share that with anyone else.
They will not disclose that to someone else.
And that, of course, goes everything from business partners to
competitors to, of course, even a partner or spouse.
The idea of the NDA is that a cloud provider's staff can have access to our
sensitive data, and they have to know that it's not permissible for them to
discuss our data with anyone else at any time.
In summary, this is the most important domain of the CCSP.
We've looked at the importance of securing data in the cloud,
and, of course, this included looking at the areas of data
classification and from that ownership,
the appropriate controls such as access control and masking, and, of
course, having a log so we have a record of what actually was done.
This in the end was all about securing data throughout the data
lifecycle so that it was protected at all times, in all forms, and,
of course, in all places.