Security and Compliance
This is a guide on security and compliance.
Managing Compliance with Regulations and Controls
Well, the best way to manage compliance using different regulations and different security controls, is to have some type of methodology or architecture. And this would involve a wide variety of different practices. So you could use something like COBIT 5, for example, or a very popular solution that you might want to apply in your cloud implementation is to use ITIL 4. ITIL 4 has a wide variety of practices that we can use to manage compliance.
The first could be Service Configuration Management, which basically makes sure that you have accurate and reliable information. About the configuration of your cloud services, your instances, and all of the items that support them within where needed. You have Change Management. Change Management is the practice of making sure that changes in your cloud implementation, whether it be IAAS or SAAS or PAAS are implemented smoothly and successfully. And that lasting benefits are gained by managing these changes.
Continuity Management is the practice of making sure that service availability and performance are maintained at sufficient levels. In case of an event, an incident, or a disaster, cloud solutions are often a big part of disaster recovery or business continuity. Information Security Management involves making sure that you have a policy for the cloud, that governs your approach to cloud service provider security, including the shared responsibility between you and the provider.
There is continual service improvement, supporting good decision making. And continual improvement by decreasing the levels of uncertainty when dealing with your cloud provider. This could also include continual value cocreation between the provider and the subscriber. Incident Management, this is the practice of minimizing the negative impact of incidents or negative events, by restoring normal service operation as quickly as possible. This is one of the main advantages of using infrastructure as a service.
Problem Management is basically reducing the likelihood and impact of incidents, by identifying the actual and potential causes of these incidents and managing workarounds. Release Management is critical with platform as a service as you release different versions of your applications or your apps. This could also be automated and orchestrated by using managed services in the cloud. Deployment Management, basically moving new or changed hardware, software, documentation, processes, and services.
Or basically any other component from the development environment or the development account to the production account. This is part of your software development life cycle. Service Level Management is basically setting clear and concise business based targets for performance. So that the delivery of your cloud service can be assessed, monitored, and managed against these targets or baselines.
We often call these key performance indicators or critical success factors. Availability Management, this can involve making the right choice for block based storage or object based storage, based on various tiers. To get different levels of availability, four nines and five nines, using multiple zones or availability zones and replicating data between regions.
And finally, there's Capacity and Performance Management. Making sure that services achieve the agreed and expected performance levels based on service level agreements, or organizational level agreements, and they satisfy current and future demand in the most cost effective manner possible.
Legal Requirements and Risks within the Cloud
It's also important to be aware of certain legal requirements and regulations, and other risks that go along with a various aspects of dealing with cloud computing, and let's say international legislation, international conflicts, legal controls like privacy with the GDPR. Also the ability to do things like eDiscovery and Forensics and penetration testing.
So for example with Amazon Web Services, if you want to perform penetration testing on your own resources in your virtual private clouds, you actually have to go through the process of filling out some forms and giving approval before you can do that. So if you're going to set up a sandbox environment or a detonation chamber and you're going to test out malware, for example. And you're going to use exploit kits or pen testing, you have to get the approval of the cloud provider.
Also, as far as dealing with other entities like government entities and other countries. The cloud provider may have separate isolated private clouds or community clouds just for those implementations. So for example, AWS has GovCloud, Google Cloud also has a separate cloud for the US government. Other countries may participate, for example, Google has a separate cloud for China. So those things you must consider when your dealing with cloud providers.
[Video description begins] Screen Title: Geographic and Data Sovereignty Considerations [Video description ends]
There's also a variety of considerations for sovereignty of data. Typically, you want to be very careful storing data in other geographic regions where you may not have the sovereignty, okay? There's lots of variances between the type of data that you can store as well. There's variances in cultural norms. There's different customs from country to country. And that also can be customs as far as import export.
Also realize that if your country's involved, let's say, in what we would call a trade war, where you've got new tariffs imposed. That's something to consider as well. You have to consider cultural sensitivities and behaviors of people in different countries and the different types of data at rest and data in transit. So for example, various customs between let's say the United States and Europe or the Middle East and South America. Based on the region you're in, you can have different policies.
There can be different types of controls and different procedures. Their countries might have different regulations and different mandates, and there's a variety of these. For example, AGATE is French. It's a framework for modeling computer or communication systems architectures. You also have a European mandate, IDABC. That's the interoperable delivery of European e-government services, and that's basically for the EU. Launched in 2004 to promote the correct use of information and communication technologies for cross border services in Europe.
We've got the ISO, we've got OBASHI. The OBASHI is a methodology that provides a framework and a method for capturing, illustrating, and modeling the relationships. Dependencies and data flows between business and IT assets and resources in the business concept. There's also TOGAF as well. France also has the integrated architecture framework of Capgemini. In the United States, we have the Department of Commerce's Bureau of Industry and Security, BIS controls for non-military cryptographic exports.
So cloud computing is transcending traditional boundaries, and we call this deperimeterization. So deperimeterization, it's not just happening at the edge of the company or the corporate edge. But there's also deperimeterization happening between the boundaries of countries and governments and jurisdictional boundaries. So knowing the jurisdiction and data sovereignty when you're dealing with other countries is critical in the cloud. Because we're fragmenting traditional geographic boundaries.
So make sure you have some comprehensive insight into laws and regulations. Typically there's a compliance service at each one of the cloud providers. So if you go to Microsoft Azure, you go to Google Cloud, you go to AWS, they're going to have a whole compliance section. That'll provide information not just on how they're compliant but on how they help their customers become compliant. Try to keep the data local whenever you can.
And when I mean local, I mean local to your own jurisdiction. So you might be taking this training right now, and maybe you're in Europe, maybe you're in South America, or maybe you're in United States. So keep the data local whenever you can. Manage encryption and encryption keys, and also realize any type of export restrictions on cryptographic content. You want to make sure that you have a strong access control methodologies, security of data, it could be more complicated.
And more complex when you're now storing data and you're moving data between different regions and different jurisdictions. Also geo-redundancy will bring in duplication of data. So if you have snapshots and replication of data stored in other regions, other geographies. Well that geo-redundancy can cause a challenge for you. So you may have to go through some processes of de-duplicating.
So you don't have multiple copies of data at rest that are stored and then you have versioning issues and access control issues. We call this privilege creep, okay, or the versioning creep that can happen when you have redundancy of data. Not just across different geographic regions, but it could also be a problem when you have it across different availability zones or zones for high availability or fail over. So keep all these things in mind and realize that these are aspects of security that cannot be overlooked.
Privacy Issues and Jurisdictional Variation
Let's talk some more about privacy and realize that privacy is typically related to what we call PII, personally identifiable information. Basically referring to information that can be used to distinguish somebody's identity, or to trace their identity. Whether it's alone or combined with other information or other identifying data linked to an individual. We can also break these down into two categories. Contactual PII is basically protection of personal information controlled based on agreements.
For example, service level agreements or confidentiality agreements, or memorandum between two independent parties. Then we have regulated PII. This is the protection of information based on standards and mandates published by regulatory bodies such as HIPAA, PCI-DSS, and GDPR. Realize that there can be jurisdictional variation in privacy issues. So for example, what GDPR considers personal information is actually more strict and broader than the identifiers for HIPAA, for example.
We need to understand country-specific legislation related to PII and Data Privacy. For instance, the US-based personally identifiable information. And the European concept of Personal Data, make up a critical demarcation line related to data types and privacy consequences.
[Video description begins] Personally identifiable information is abbreviated to: PII. [Video description ends]
So we'll see little variation between individual states, let's say within the EU or within the United States. But between the two, we can see variances. And realize that we can say that all PII data is personal. Like full name, Social Security number, identifying numbers, phone numbers, email address. But not all personal data is PII data.
If you're trying to build a successful GDPR compliance program, make sure that you fully investigate at either Google or Microsoft Azure or AWS, their GDPR compliance program. You may have a Data Protection Officer, a DPO, or a Chief Privacy Officer, a CPO, that's going to be in charge of that particular mandate. And realize that GDPR is going to cover a wider range of PII including social media posts, photographs, transactional history. Much more data that relates to individual or identifiable persons either directly or indirectly.
[Video description begins] Screen Title: Privacy Issues Vary Based on Location [Video description ends]
Regardless, we need to be aware of the controls to implement, to guarantee confidentiality, integrity, availability, and of course privacy. In other words, for many organizations they're going to extend the CIA triad, going beyond just the simple CIA aspect, and add another tier known as privacy.
Audit Processes and Methodologies for the Cloud
As a security practitioner dealing with the cloud, auditing is one of those special challenges for us. The biggest challenge for auditors is actually getting familiar with cloud computing terminology, and having a working knowledge of a cloud system's composition and service delivery variations. To be an effective cloud security auditor, you will need to be familiar with the different aspects of the cloud system's infrastructure and delivery of services.
[Video description begins] Screen Title: Factors for Auditing the Cloud [Video description ends]
Some security factors that are more vital in cloud security auditing would be things like transparency, colocation data in de-duplication. The scale, the scope of projects and programs, security and privacy, and the complexity of dealing with the cloud. Another key aspect of auditing, there is a challenge for organizations now, is the fact that many of them have to have their hardware security modules on site to adhere to compliance or regulations.
Those HSMs are going to store access keys. They'll do client side encryption. They'll have private keys for the PKI. They're used for SSL offload from web servers. They're used for Oracle TDE, a wide variety of purposes. And a lot of the cloud providers offer cloud HSMs, or abstracted cloud-based multi-tenant hardware security modules of companies, let's say, like Gemalto.
And so one of the biggest challenges that companies like Google and Amazon are having right now, is being able to help their customers be compliant and to pass the audits. Especially the external audits, when they want to store the HSM or use a cloud-based HSM solution up at the cloud provider. And that's still a big challenge that we run in to today.
So there's a big push by companies like Microsoft and Oracle and IBM and AWS and others, to convince these external auditors for these different compliance programs to see a cloud-based HSM solution as secure as one that is stored on site. There are three main methodologies or types of audit reporting that are used for the cloud.
The older one would be SAS, the Statement on Auditing Standards Number 70. Service Organizations, SAS 70, was an authoritative auditing standard, that was developed by the American Institute of Certified Public Accountants, the AICPA.
[Video description begins] Statement on Auditing Standards is abbreviated to SAS and the American Institute of Certified Public Accountants is abbreviated to AICPA. [Video description ends]
The SSAE, the Statement on Standards for Attestation Engagements number 16, also known as SSAE 16, is an auditing standard for service organizations that supersedes SAS 70.
[Video description begins] Statement on Standards for Attestation Engagements is abbreviated to SSAE. [Video description ends]
And then we have ISAE, International Standard on Assurance Engagements number 3402. This provides assurance reports on controls at a service organization. And it was issued in December of 2009 by the International Auditing and Assurance Standards Board, IAASB.
[Video description begins] International Standard on Assurance Engagements is abbreviated to ISAE and the International Auditing and Assurance Standards Board is abbreviated to IAASB. [Video description ends]
Another group that's involved in auditing is the CSA, the Cloud Security Alliance. And they're urging standardization across the board, for auditing cloud confidentiality, integrity, and availability as opposed to using multiple auditing standards.
Outsourcing and Cloud Contract Design
This will be a short video. I just want to talk about three different aspects of dealing with cloud providers. Sometimes the cloud provider has its own separate types of contracts, its own separate service level agreements. Some organizations will consider the cloud provider as outsourcing. So you have to realize, do you have a separate outsourcing policy, and documentation, and agreements from cloud computing. Or are they integrated as a whole? This may involve bringing in a legal department, a legal team, law firm that you deal with dealing with contracts.
Also, remember that service level agreements are typically external. So if you have a cloud provider like Amazon Web Services, you would have a separate SLA with them. But outsourcing, if you're outsourcing and it's to a group that's part of your company, or a contractor, that may be more of an organizational level agreement, or an OLA. They have a lot of the same aspects, but realize that that may be part of your responsibility as a security practitioner to understand the different agreements, the memorandums, the contracts that you're dealing with.
All of these things are going to have to take into consideration three main factors. The business requirements, that can include accounting, that can include budgets, it could include business continuity planning. Tying the business goals and the mandates, and the mission of the organization. The charges of the organization tying that to security and to cloud security. Managing different vendors, okay, so Amazon, Microsoft, Google, they're going to be a vendor to you as a cloud provider.
You may have other vendors as well. Maybe you're working with Fortinet as a managed security service provider. Maybe you have a SaaS solution, so the vendor may be Microsoft 365 or Workday or Salesforce. So those agreements, how do they fit into your certification and your compliance and the regulations that you're subject to?
And of course, contract management. There's different areas of the contracts that may be special to a cloud provider or to an outsourced group. What ability do you have to audit that provider? What are the different metrics? What are the key performance indicators? What are the critical success factors? What are the key risk indicators? You have to have a glossary of definitions so there's an understanding between you and the vendor.
Between you and the provider, what all the terms mean. How are you going to litigate? Okay, are you going to have an arbitration first before litigation? And again, you want to think about penetration testing. You can’t just go up and start penetration testing and doing forensics at a cloud provider. There's agreements you have to go through, there's steps you have to go through.
Also, as far as business requirements, when you create that first account, or multiple accounts. Are you going to tie it to a corporate credit card or a personal credit card? Or are you going to do direct billing where you have to go to the different hoops to be able to get a monthly invoice from the cloud provider as well? So several factors when you design your agreements and your contracts in dealing with outsourced cloud providers and cloud service providers.
Survey of Common Regulations and Mandates
I want to finish out this course talking to those of you who are maybe dealing with cloud providers. And your organization or organizations that you work with are subject to mandates or regulations, like HIPAA, Sarbanes-Oxley, PCI-DSS, GLBA, GDPR, FIPS 140-2. Your service provider, your cloud service provider that is, whether it be Amazon Web Services, IBM Cloud, Oracle Cloud, whoever, will have a compliance area of their site. And so let's go take a look at Amazon's compliance area.
They are five times bigger than the next competitor, being Google. So that's kind of a good place to investigate how they approach their compliance. And remember, this is two fold, okay? They themselves are compliant and become compliant to different regulations and they also help their customers become compliant. So there's two different things. They can help their customers become compliant. Without themselves necessarily going through the hoops to be accredited or certified by some regulation.
So, let's go take a look at Amazon Web Services, so aws.amazon.com/compliance. So here we are at their website and I'm not signed into the console, so you don't have to have an account to come check this out. I do have an account but I haven't signed in. And so, what we see up here when we go to the compliance area is obviously some frequently asked questions. Talking about shared responsibility and that is something that we have discussed in this training, okay?
The shared responsibility model between you and your cloud source provider. Which can depend upon a wide variety of factors. Not just compliance but are you using infrastructure as a service and what managed platform as a service solutions are you using. If we go down here, we can see just some data privacy information. So here's data privacy and the GDPR which we've talked about. If we go up here to Compliance Programs and click on this link, we'll see the AWS compliance programs.
So, they start out with a bunch of global compliance and I mentioned the CSA. Remember, I talked about the auditing a couple of videos ago. Talked about the Cloud Security Alliance and their efforts to integrate and consolidate auditing. And you can see that we have the CSA controls and several ISO certifications. If we move on down here, we can see SOC 1, SOC 2, and SOC 3, and here's PCI-DSS level 1.
So these are global. If you want to see just ones in the United States, you can click over here and you can see the main ones here. A lot of these are government oriented, okay, Fed Ramp, DOD. I mentioned FIPS, so we've got FIPS, we've got FISMA, which is the Federal Information Security Management mandate. You've got HIPAA, you have ITAR, which is the International Arms Regulations. And obviously we've got MPAA for protected media content, okay. So protecting the integrity and anti-piracy of content distribution through let's say Amazon Web Services CloudFront. Obviously there is also NIST as well, and then of course if we go down, we see Asia Pacific and Europe.
For those of you in the UK, you'd be concerned with Cyber Essentials PLUS and G Cloud for government, UK standards. And so these are the main compliance programs. And you want to make sure that if you are subject to any of these, that you're going to go and take advantage of the resources that appear. We have a auditor learning path. We have an AWS compliance solutions guide.
There's workbooks, there's best practices. You can see several articles, several essentials and best practices. So AWS answers to key compliance questions. I want to check that out. It's a couple of years old but it's a really good article and it's only 12 pages long, so you might want to check that out. Okay, so again, the moral of the story here. Is that if you or your customer are subject to any of the global or country specific or regions specific regulations or mandates. It's imperative that you and your provider have a good understanding of the shared responsibility between the provider and the customer. The customer being you.