Understanding CCSP Domain 6: Legal, Risk, and Compliance Essentials for Cloud Professionals

We discuss more privacy-specific regulations in section 6.2. The table below covers several other legal concerns that you need to be aware of:

Personal data is any information that relates to a person. It includes obvious things like addresses, phone numbers and social security numbers, but many other pieces of data also qualify as personal data. Personal information (PI) and personally identifiable information (PII) essentially mean the same thing as personal data, but different jurisdictions sometimes use their own terms with slightly different meanings. Another important term is protected health information (PHI), which we will cover in our discussion on HIPAA in 6.3. You may also come across personal cardholder information (PCI), which is essentially just a term for credit card details.

By now, it should be clear that organizations are obliged to protect data in line with the privacy regulations of the jurisdictions in which they operate. This is referred to as “regulated personal data”. On top of this regulated data, your organization also needs to consider the legal obligations of its contracts. This is referred to as “contractual personal data.”

Abiding by privacy stipulations in contracts is absolutely critical. No organization is one hundred percent vertically integrated, so suppliers are essential. Since we have to rely on the services of third parties and often have to share our data with them, contract law plays a vital role in ensuring that we meet our obligations, even when we no longer have full control over our data.

Some of the most prominent privacy regulations from across the globe are:

The flexibility and international nature of cloud services make them incredibly useful, but there are some drawbacks. One of the major ones is that different jurisdictions have varying data privacy regulations. If your company operates in multiple jurisdictions, or it has users in multiple jurisdictions, then it needs to be aware of which data privacy regulations apply. You need to be incredibly careful, because the flexibility of the cloud makes it easy to accidentally store data in ways that conflict with your obligations.

The following sections cover some of the more important privacy standards and regulations, such as ISO/IEC 27018, the Generally Accepted Privacy Principles (GAPP) and the General Data Protection Regulation (GDPR).

ISO/IEC 27018 provides a code of practice for protecting personally identifiable information (PII) in public clouds. It is intended to be used in conjunction with security controls and objectives from ISO/IEC 27002.

The Generally Accepted Privacy Principles (GAPP) framework was renamed the Privacy Management Framework (PMF). It is designed to help management create privacy programs that address both risks and obligations while also facilitating opportunities. It features nine separate components to help organizations address privacy and their obligations.

One of the important premises of the GDPR is that data protection must be incorporated “…by design and by default”. This means that the design of any new activity or product must consider the data protection principles. The GDPR’s seven protection and accountability principles are:

• Lawfulness, fairness and transparency
• Purpose limitation
• Data minimization
• Accuracy
• Storage limitation
• Integrity and confidentiality
• Accountability

The GDPR also contains eight privacy rights for data subjects. These are:

• The right to be informed
• The right of access
• The right to rectification
• The right to erasure
• The right to restrict processing
• The right to data portability
• The right to object
• Rights in relation to automated decision making and profiling

In 2022, the European Union and the United States agreed to the EU-US Data Privacy Framework. This voluntary framework grants companies a way to transfer personal data from the EU to the US in a way that protects their privacy and is consistent with EU law. It provides new rights to EU individuals whose data is transferred to participating American companies. These rights include the right to delete or correct inaccurate data, and to obtain access to their data. The EU-US Data Privacy Framework acts as a replacement to the EU-US Privacy Shield and the International Safe Harbor Privacy Principles, both of which faced legal challenges.

Privacy impact assessments (PIAs) were introduced as a way to analyze the impacts that information systems will have on privacy. They involve looking at how information is handled and whether the process conforms to privacy requirements. PIAs are sometimes required as part of regulation, such as the US E-Government Act of 2002.

We’ve already discussed service level agreements (SLAs) in Domain 5.3. Privacy-level agreements (PLAs) are conceptually similar, but with a focus on privacy. Instead of focusing on the amount of uptime and other service details, PLAs are contracts that stipulate how another party must protect an organization’s data. They can contain restrictions on things like:

• The location of data.
• Whether data can be transferred.
• How data is processed.
• How data must be secured.
• The monitoring that must be in place.
• Data portability options.
• Data retention requirements.
• Rules surrounding data breaches, such as how notification must take place, and within what timeframe.
• Accountability requirements.

Not only do our systems need to be secure, but we need to be able to prove they are secure to regulators, customers and other stakeholders. Audits give us a methodical way to probe into our systems to determine their current security posture, highlight weaknesses that need to be addressed, provide solutions that can enhance our security moving forward, and to demonstrate our compliance. There are many different audit frameworks that we can use, depending on the context.

In the cloud, the CSA Cloud Controls Matrix (CCM), which we discussed in Domain 1.4, is tremendously valuable. The matrix includes guidance on best practices for each control, as well as mapping for major standards and frameworks such as:

• HIPAA
• FedRAMP
• ISO/IEC 27001

There are three types of audits that you need to be aware of:

• Internal audits – These audits are conducted by auditors from the organization on the organization’s processes.
• External audits – These audits are conducted by auditors from the organization on supplier processes.
• Third-party audits – These audits are conducted by independent auditors on supplier processes.

It’s important for us to understand how cloud environments can impact our audit requirements. The massive differences in architecture between cloud and traditional computing mean that we need to completely change our approach to auditing. Some aspects of auditing in traditional environments become far too complex in the cloud, so we need to find other methods to achieve our goals.

One of the main assurance challenges that we find in clouds arises from the multitenant environment inherent in public clouds. The fact that cloud providers share their systems and resources across multiple tenants means that cloud customers cannot perform their own audits of public cloud providers. This is because allowing a customer’s auditors full access to the provider’s systems would risk the security and privacy of the other cloud customers sharing the public cloud. Instead of allowing each customer to conduct their own audits, we generally rely on third-party auditors to document the security posture of public cloud providers.

Auditing patch management is another major challenge in cloud environments because the population of systems is in constant flux. With things like immutable workloads, dynamic optimization, and VMs constantly spinning up and down, we run into substantial challenges. Immutable workloads also cause other problems when auditing patch management—you can’t patch them. Instead, you have to change the image.

The SSAE 18 standard defines three types of audit reports. These are known as System and Organization Controls (SOC) reports and they include:

• SOC 1 reports – These focus on financial reporting risks and controls.
• SOC 2 reports – These focus on what are known as the five trust principles: security, availability, confidentiality, processing integrity, and privacy. SOC 2 reports often contain a fair amount of confidential information about an organization and they should be protected from unauthorized disclosure. Because of this, you generally have to be an existing customer (or other relevant stakeholder) and sign an NDA before you can access a SOC 2 report. However, certain information contained within a SOC 2 report is valuable for potential customers to know. This is where SOC 3 reports can be helpful.
• SOC 3 reports – These are essentially stripped down and sanitized versions of SOC 2 reports. They are basically marketing tools that potential customers or interested parties can read to gain a basic understanding of a service provider’s controls and compliance.

As security professionals, SOC 2 reports are the most meaningful of the three. However, SOC 1 and 2 reports can also be divided into type 1 and type 2 reports. Note that type 1 and type 2 reports are subcategories of SOC 1 and SOC 2 reports. They are not the same as SOC 1 or SOC 2 reports.

The variations in SOC reports are:

Audit scope restrictions limit which functions and components are part of an audit. An audit scope statement is a document that formalizes what aspects the audit will cover, prior to engaging in the audit. They typically describe:

• The objectives of the audit
• The type of audit
• Limitations on the audit’s scope
• Deliverables
• Assessment requirements, criteria and ratings

Placing restrictions on the scope of an audit is important, especially for certain mission-critical components and production systems. We want to conduct our audits in a way that limits the risks to business operations. Some common audit scope restrictions include:

• When auditing can be conducted, such as the time of day.
• Which testing methods can be used.
• Which functions and components can be audited.

Gap analysis involves looking for any gaps between an organization’s controls and its corporate policy, contractual requirements, or the appropriate standards, such as ISO/IEC 27001. It may involve a random sampling of controls or conducting a complete assessment. The auditor then compiles a report that includes any gaps they have found, recommendations to address them, as well as a rating that specifies the level of compliance with the standard being measured against.

For audits to be comprehensive, they must be planned ahead of time. An audit plan involves:

• Defining the audit objectives
• Defining the audit scope
• Improving processes from past audits.

An information security management system (ISMS) is a framework of procedures and policies for managing your organization’s security. One of the most important documents on ISMSs is ISO/IEC 27001. This standard covers the requirements for establishing and improving an ISMS. An ISO/IEC 27001 audit formally documents the state of an organization’s security and provides recommendations on aspects that should be addressed.

ISO/IEC 27002 is a standard that complements ISO/IEC 27001. ISO/IEC 27001 covers the requirements for an ISMS, while ISO/IEC 27002 specifies the control objectives and best practices. It covers cryptography, human resource security, access control, incident response and more.

Another important standard is ISO/IEC 27017. This is a code of practice that adapts the information security controls from ISO/IEC 27002 for cloud services. ISO/IEC 27018 is another critical resource for those who work with clouds. It establishes a code of practice for protecting PII in public clouds.

Policies are documents that communicate management’s goals and objectives. The table highlights the differences between organizational and functional policies:

There are many different stakeholders involved in the audit process, and each of them have their own roles and responsibilities. Some of these roles are:

The North American Electric Reliability Corporation (NERC) is a nonprofit that oversees power systems across the US, Canada, and the Mexican state of Baja California. The Critical Infrastructure Protection (CIP) standard sets out security controls and other requirements for the bulk power system. However, it is no longer used.

The Health Insurance Portability and Accountability Act (HIPAA) is a US law that includes privacy and security stipulations for the healthcare industry. One major aspect of the law is its regulation of protected health information (PHI). This is personally identifiable information that is related to an individual’s health or healthcare. Due to the sensitivity of PHI, there are many requirements around organizations that collect or process it, as well as for organizations that process it on the behalf of others

The Health Information Technology for Economic and Clinical Health (HITECH) Act is an American law that was passed in 2009. Among its provisions are the promotion of electronic health records (EHRs) as well as bringing in new security and privacy regulations. These regulations include mandatory data breach notifications for entities regulated under HIPAA.

The Payment Card Industry Data Security Standard (PCI DSS) is a standard for organizations that handle credit cards and credit card information. The PCI DSS was created to increase controls around cardholder data and to reduce credit card fraud. The volume of transactions processed by a merchant helps determine the method used to validate compliance.

The Clarifying Lawful Overseas Use of Data (CLOUD) Act clarifies earlier US laws and grants law enforcement a mechanism to request access to data stored both in the US and in other countries. The mechanism contains limitations on data requests, with safeguards that recognize the right of a provider to challenge requests, especially when the request conflicts with the laws of other countries.

We discussed these topics in 6.1. Conflicting international legislation.

We need to consider the risks of cloud computing from an enterprise risk management perspective in the same way that we would assess any other third-party service, product, acquisition or divestiture. As part of our corporate governance, we want to manage our cloud risks appropriately so that we can gain the benefits from the cloud, without causing compliance and corporate reputation problems that would ultimately subtract value from the organization.

All major stakeholders should be involved in the decision-making process surrounding cloud endeavors. Our organizations need to ensure that potential cloud providers operate in a way that is consistent with our security, privacy and compliance needs. This involves assessing a potential cloud provider’s risk management program. We do this in a similar way to how we assess all third-party services, because each one can introduce new risks to an organization. We should take the following steps to effectively manage risks from third-party service providers:

• Understand the potential risks.
• Conduct due diligence before beginning the relationship.
• Have contracts in place that are based on our requirements.
• Have contingency plans for terminating the relationship.
• Continue due diligence throughout the relationship.
• Understand and effectively manage the relationship.

There are a wide range of controls that we can use to limit risks to our organizations. We also want to ensure that our cloud providers use the appropriate controls for their services. The seven major types of controls are below:

Safeguards are proactive controls; they are put in place before an incident has occurred to deter or prevent it from manifesting. Safeguards include directive, deterrent, preventive, and compensating controls.

Countermeasures are reactive controls. They act after an incident has occurred and aim to detect and respond to it accordingly. Countermeasures include detective, corrective, and recovery controls.

Controls can be further classified in three main categories:

A good security control should always include two aspects: the functional aspect and the assurance aspect, as shown in both the image and the table.

When selecting appropriate security controls, there’s a tendency to select the most expensive and top-performing solutions in an effort to provide the maximum level of security to an environment. However, this approach often isn’t cost effective. When deciding on whether to implement a security control, we should evaluate it against criteria such as:

• Alignment to organizational goals and objectives – Does the control help the organization achieve its goals and objectives, or is the control an impediment?
• Cost-effectiveness – Can the cost of the control be justified?
• Complete control – Are preventive, detective and corrective controls in place? These should be the minimum.
• Functional and assurance – Does the control meet both functional and assurance requirements?

The landscape covered by the risk management process is constantly changing—new assets are added, old assets are retired, new threats and vulnerabilities are identified, the potential impacts change, etc. The same applies to our cloud providers. This makes risk management a continuous process that is both arduous and time-consuming, but absolutely essential. A security-focused version of the Deming cycle, also known as plan-do-check-act (PDCA), is shown in the figure below, while the steps are defined in the table. It outlines the cyclical nature of many processes in security, including risk management.

Below contains a list of core terms used in risk management and how they fit together:

The figure below shows how all the terms mentioned in the table interconnect.

Two different forms of analysis can be used to rank the assets of the organization from most to least valuable: qualitative analysis and quantitative analysis. Their main characteristics are:

Risks involve three major components:

• Asset – Anything of value to the organization.
• Threat – Any potential danger that can cause damage to an asset. Threats include things like hacking, earthquakes, ransomware, social engineering, denial-of-service attacks, etc.
• Vulnerability – A weakness in an asset or a control that could be exploited by a threat. Examples include open ports with vulnerable services, lack of network segregation, lack of patching, etc.

To fully understand the risk for a given asset, we must assess the probability and impact of a threat. The impact is whatever negative consequences there may be to the asset or organization if an incident occurs. Finally, the probability is the likelihood of a given threat materializing. The figure below summarizes how these components fit together and how they can be used to identify the risks to a given asset.

There are many different roles in relation to data, and each of these roles have their own responsibilities. One of the most central roles is the data owner. Data owners are the individuals that create or procure the data and work with it on a regular basis. They are ultimately accountable for the asset (such as data) and its protection. Assets must be owned by someone, and owners are accountable for making sure that controls are in place to protect assets.

Owners can delegate responsibility for an asset, but they always remain accountable for the protection of the asset. In other words, accountability cannot be delegated to anyone else.

Below are the various roles and responsibilities relating to data protection within an organization.

There are laws in various jurisdictions that require organizations to provide notification if they have been breached. Below lists some of the most commonly known breach notification laws:

The Sarbanes–Oxley (SOX) Act was introduced in the wake of the financial fraud at Enron. Better controls were needed to prevent similar incidents from happening. The US Congress enacted SOX to limit financial fraud by public companies and thereby protect the financial interests of shareholders.

The General Data Protection Regulation (GDPR) is a set of data protection rules that apply to all EU member states. As we mentioned above, personal data breaches must be reported within seventy-two hours unless it is unlikely for the breach to pose a risk to the freedoms or rights of people.

After the risk analysis process, security should implement the most cost-effective treatments. The right approach depends on the value of the asset and the type of risk identified in the previous steps. The image below shows the ways that risk can be managed, using a diving board as an example.

• To avoid risk means to choose to stop doing whatever exposes the asset to risk.
• To transfer risk means to place the risk on another party, usually an insurance company.
• Sharing risk is similar to transferring risk and can be considered a subcomponent. It involves only shifting a portion of the liability or responsibility to another organization, rather than the entire load.
• To mitigate risk means to implement controls that reduce the risk to an acceptable level. Risk can never be eliminated or reduced to zero. However, it can be reduced enough that residual risk (the risk that remains after controls have been put in place) can be accepted or transferred.
• To accept risk simply means taking no further action to mitigate, transfer, share or avoid risk. This commonly happens when the cost of the control exceeds the value of the asset.

Some of the most popular risk management frameworks are:

Understanding the RMF is critical, as it underpins just about every facet of operational security governance within an organization. The seven steps of SP 800-37 are:

• Prepare to execute the RMF
• Categorize information systems
• Select security controls
  
• Implement security controls
• Assess security controls
• Authorize the information system and controls
• Monitor the security posture of the information system

Once controls have been decided upon and implemented, it’s important to understand how well they’re working. One of the best ways to do this is through metrics.

Different metrics will be valuable to different audiences. For example, senior management will be more interested in big picture metrics, while the facilities operations team is more likely to be interested in detailed metrics that apply directly to their everyday work. Once you have identified the risk metrics that matter to your audience, you can measure the critical risks and assess them according to a scorecard. For certain audiences, a simple representation of the risk level will be sufficient to communicate the risks that they should pay the most attention to. We often use risk categories such as:

• Minimal
• Low
• Moderate
• High
• Maximum or critical

When using the cloud, we need to also assess the risk environment of third-party vendors and services. If our organization is going to rely on a third-party vendor, then we need to understand what risks they bring to our organization. If the risks are too high, we may decide to seek out another solution instead. We can also implement measures to mitigate the risks, transfer the risks, or simply accept them.

Outsourcing is a central part of the cloud. When we sign up to a cloud provider, we are outsourcing some aspect of our business to the provider so that we can focus on our core business instead. The cloud is complicated, and outsourcing means that we are ceding some of our control and responsibility to the provider. However, our organization still remains accountable. Because our organization still retains accountability, we must ensure that the service from a cloud provider is able to meet our organization’s obligations, and that these requirements are clearly stipulated in the contracts.

The first step is to engage with all relevant stakeholders to determine what our requirements are, as well as the risks that a potential vendor could introduce.

When choosing a vendor, your organization should look for an established and reputable organization. It is often best to choose a provider that has a lot of experience in the service your organization wishes to acquire.

Your organization should also ensure that a potential vendor is able to handle your organization’s needs, and that it can meet all of your organization’s security, privacy and compliance requirements. Key things to watch out for are portability and interoperability with other services. You do not want your organization to face vendor lock-in, which occurs when it is too costly and difficult to move to a new provider.

There are a variety of contracts that can be signed between a service provider and a customer:

Conflicting international legislation

Legal framework and guidelines

eDiscovery

Forensics requirements

Difference between contractual and regulated private data

Country-specific legislation related to private data