data plays a very important role to every company, and it's the biggest asset for many well before the cloud,
even before computers for that matter. Protecting data in particular information has been a long standing concern.
Cloud brings a new twist to age old methods for data protection. The security implications for multi tenancy, shared responsibility and new ways of processing data using cloud provider services all need to be addressed with management, operational and technical controls. Those controls provide preventative detective and corrective capabilities
in this module will be covering the perspectives you need to account for
to be effective managing information in the cloud.
It starts with understanding the governance domains,
then the data security lifecycle and will finish off reviewing how functions actors and controls provide a systematic way to analyze data. It's interactions and define access controls.
The rest of this video will focus on the first area, which is information governance domains.
Information classifications can be described as the process of grouping data into categories, toe identify and necessary security controls.
The classifications are building blocks for other information governance decisions.
These classifications air building blocks for other information governance decisions.
For example, classifications levels determine things like what could go in the cloud and what cannot, what needs to be encrypted and other information like that.
Your organization may have its own standards to define in group those controls.
You may even be the person responsible for establishing such standards.
Federal information processing standards creates a publication that the U. S government follows. This is called Phipps 1 99 and it defines groups for classifying data into low, moderate or high table on the right shows this classifications criteria. Your company may use this standard, or it may have its own.
The 5th 1 99 table refines each data category by expanding on the impact of each category based on the C I A. Triad.
When I say CIA, I'm not referring to the Central Intelligence Agency.
Rather, I'm referring to the three objectives. Confidentiality, integrity and availability, and they're very common way to assess cybersecurity. It's not something specific to Phipps or the Sea CSK exam, but it's so generally used it's worth spending a moment to review each of them.
Confidentiality basically means making sure only the right people can access the information.
Integrity means making sure that the information cannot be altered in an unacceptable way. Typically, this means Onley. Certain people have the right to change the information, and it often means that there will be an audit trail to make sure you keep track of who made what changes when,
and availability ensures that you can access the information when you should be able to access it well, actually, dive a bit deeper into the nuances off availability in the cloud in particular, when you consider accessing data from different devices and different locations,
if this is the first time you've been exposed to the CIA, Triad paused, of course, and take a moment to research it a little bit further is really is cornerstone to information management.
As for this video, we're going to continue to move through the other domains of information governance.
Your information management policies have a tight binding to the classifications levels.
Typically, each level will have certain rules. All the rise called policies that defined things such as
What data can go, Where can it be on a company network off the company network? Does it need to stay on a special network that is not connected to the Internet
well controls are required if data goes in the cloud.
The level of control you have in managing data in the cloud varies based on the SP I model, you may recall we previously discussed the SP I model SAS Pass and I *** I asked, gives you much more control and sass. You have to ask a lot more questions of the provider to make sure the data is managed in ways that meet your policies. I'll give you a great example.
I was working with a company and we were evaluating a providers static application security testing service and in their model, we as a company would upload our source code to the provider. They would run a variety of tools and utilities to examine the source code
and identify security flaws or at least potential for security flaws in that code.
Source code is definitely a sensitive information area, especially when you're talking about it being code for software that resides in applications. That the company I was working for sold
we have to ask the question, Do we trust the provider and we can do a lot in terms of at test stations and other information to ensure that the provider really gets restricted from who they can send that code to, how they can use it themselves, who has ownership and so forth.
But what we came to also find out is that there are other tenants using this same provider. And this left a large concern about having that code be co mingled with other tenants and those other tenants, maybe even malicious trying to access our code. So we didn't know who all those other tenants were
and going by default. We're going to say we didn't want to trust those other tents.
So the SAS provider said, Hey, I think I have a solution to this problem. What if I gave you
a specific encryption key that was unique to your business? And each one of the other tenants have their own unique encryption key.
Therefore, each tenants data would be encrypted at rest, using different encryption keys, and you'd have to have access to that encryption key in order to retrieve the data.
And, of course, we could rotate that encryption key on a regular basis.
So fair enough, this is a good compromise. Also a great example. Where in the SAS model. You don't have as many controls as you would otherwise in. I asked Model.
So the SAS provider tuned their solution and it aligned with our information governance policies. So it worked out well.
Location and jurisdiction policies. These policies. They're going to be similar to your information governance policies, but with a specific focus on where the data resides.
Being that cloud is global, it's important you have policies that define what can be stored where in domain. Three we spent a fair deal of time reviewing various regulations about data privacy. Your company policy should consider these legal requirements. As you may have noticed,
these regulations are changing quite a bit, so it takes a lot of effort to update and revise your policies
so they stay aligned with these evolving landscape.
In fact, you want to be sure to work with legal teams to make sure you have a good grasp of those laws and make sure you have good contractual obligations with your cloud provider to uphold those laws. Moreover, it will be important that your contracts with the cloud provider uphold any additional policies specific to your own company.
The concept of Leafs privileges to grant Onley those permissions required by someone to do their job
Segregation of duties is the assignment of various steps in a process to different people in different groups. The intention behind doing this is to eliminate instances where somebody could engage in theft or other fraudulent activities by having an excessive amount of control over the process.
Your authorisation rules for data in the cloud will actually be similar to the rules you have for on premise.
But now you have to hold 1/3 party, the cloud provider, accountable for physical access. This ties into ensuring contract items are, as expected.
Also keep in mind, especially in SAS. You would be limited to technical rule sets you can create based on the controls that your cloud provider themselves supports.
For example, if you're hosting an employee information with a Cloud Providers SAS system,
but you only want select people from HR and certain managers to see those employees salaries the cloud provider has to provide you with some mechanisms to configure the application, so only those people are authorized to see the salaries.
Maybe the cloud provider only supports having the HR department seeing salaries, and then they the cloud provider. They need to enhance the product itself so that you can allow additional managers to see salaries of the employees.
If you don't have rights to own the data, you are a custodian. This could be the case if you're collecting individual data. But local laws like GDP, are make it clear you aren't the owner of that data.
Some other things to take into account
who manages the data, custodial responsibility and use limitations. Your cloud provider is probably a custodian, but maybe the terms and conditions with business customers say otherwise. I have seen SAS providers stipulate that they have legal ownership rights of data managed in their system. This is another way of saying that
when your company is using their staff system
all the information you're providing about your company, you are essentially giving to that cloud provider and they own that information and they can do different things with that information. And now when we're talking about company specific information, this is a big deal because a lot of those privacy laws use laws that we've talked about applying to individuals
don't apply to company or corporate information.
So that means that the SAS provider has a lot of flexibility and what they can do with that data. This isn't a common paradigm, but it is again, something you're gonna really want to watch out for.
Other questions include. Is there a chain of custody on data management? In other words, are there multiple layers of data construed Ian's?
So are you have stood custodian of customer data
and then you're using a SAS toe host that customer data
and the SAS is a custodian of that customer data, and the SAS is actually running with, Let's say, a major cloud provider. They're using the infrastructure as a service. And so then that cloud provider is also a custodian of the day that now we have multiple layers and multiple tiers. So please remember, your organization is ultimately responsible whether you get the owner
of data or custodian of data.
So it's important you have an end and understanding of who you're working with and who you're working for and who you're relying on
from top of the stack to the bottom of the stack.
This domain of information governance is very similar to location and jurisdiction policies. You're gonna be relying on very similar regulations when making these determinations. So these two facets of information governance often intertwine.
Contracts are a key tool for managing cloud providers, and your information governance will rely on contracts as well
and security controls. Your ability to manage information will be limited to the dials and knobs that the provider gives you to work with.
In the example of the static analysis SAS provider. We had no controls to deal directly with the concern about data being co tenant with other companies.
But the provider gave controls in form of the company specific encryption keys, and those addressed our governance concerns. In the SAS model, you rely more on your provider to have controls passes in the middle, and the I asked model is the least reliance on the cloud provider.
So to summarize this video, we looked across the variety of domains for information. Governance
is included information classification, information management policies, location in jurisdiction, policies, authorizations, ownership, custodianship, privacy, contractual controls and finishing it off with security controls. So let's continue this evaluation of information governance in our next video