Conflicting International Legislation

Using distributed cloud services provides benefits for redundancy and data integrity and can even offer performance benefits by moving information systems closer to the end users. This can, however, lead to physical infrastructure, business operations, and customers that are all governed by completely separate and sometimes conflicting laws.

For example, the European Union (EU) is governed by a data privacy law known as the General Data Protection Regulation (GDPR), which is a wide-ranging law. A Brazilian company that handles or stores data of EU citizens is obligated to comply, even though they are not based in the EU. Further complicating matters, each EU member state has its own privacy laws—although they align with GDPR, there can be subtle variations, such as timeframes and procedures for reporting security breaches to the member state data protection authority.

Although cloud security practitioners are not expected to be legal professionals as well, it is important to be aware of the various laws and regulations that govern cloud computing. Laws can introduce risks to a business, such as fines, penalties, or even a loss of the ability to do business in a certain place. It is important to identify such risks and make recommendations to mitigate them just like any other risk.

As an example, GDPR forbids the transfer of data to countries that lack adequate privacy protections; a mitigation to avoid a GDPR fine might involve building an application instance in an EU cloud region and preventing transfer of the data outside the EU. However, some countries require companies operating in that country to respond to law enforcement actions, such as a warrant to turn over data. In this situation, the GDPR restriction on data transfers might be violated in order to comply with another country's legal requirements.

Because of the international nature of cloud offerings and customers, cloud practitioners must be aware of multiple sets of laws and regulations and the risks introduced by conflicting legislation across jurisdictions. These conflicts may include the following:

• Copyright and intellectual property law, particularly the jurisdictions that companies need to deal with (local versus international) to protect and enforce their IP protections
• Safeguards and security controls required for privacy compliance, particularly details of data residency or the ability to move data between countries, as well as varying requirements of due care in different jurisdictions
• Data breaches and their aftermath, particularly breach notification
• International import/export laws, particularly technologies that may be sensitive or illegal under various international agreements

Craig Mundie, the former chief of Microsoft's research and strategy divisions, explained it in these terms:

People still talk about the geopolitics of oil. But now we have to talk about the geopolitics of technology. Technology is creating a new type of interaction of a geopolitical scale and importance… . We are trying to retrofit a governance structure which was derived from geographic borders. But we live in a borderless world.

In simple terms, a cloud security practitioner must be familiar with a number of legal arenas when evaluating risks associated with a cloud computing environment. This does not mean, however, that they must be legal experts. As with many aspects of security, legal compliance requires collaboration; in this case, legal counsel should be part of the evaluation of any cloud-specific risks, legal requests, and the company's response to these.

Evaluation of Legal Risks Specific to Cloud Computing

The cloud offers computing capabilities that were unheard of a decade ago. CSPs can offer content delivery options to host data within a few hundred miles of almost any human being on Earth, offer novel architectures like microservices, and make computing power cheaper than it has ever been. Customers are not limited by political borders when accessing services from cloud providers, but this flexibility introduces a new set of risks. Legal, regulatory, and compliance risks in the cloud can be significant for certain types of data or industries.

Storing or processing data in multiple countries introduces legal and regulatory challenges. Cloud computing customers may be impacted by one or more of the following:

• Differing legal requirements: For example, state and provincial laws in the United States and Canada have different requirements for data breach notifications, such as timeframes. In addition, there are federal laws governing certain types of privacy data in these countries, which have separate breach reporting requirements. In building out incident response plans, security practitioners must account for the types of data they handle and the location of their users, as well as ensure that any incident communications procedures meet these legal reporting obligations.
• Different legal systems and frameworks in different countries: In some countries there is clear, written legislation in place, while in others legal precedent is more important. Precedent refers to the judgments in past cases and is subject to change over time with less advance notice than updates to legislation. Security practitioners will need to get input from legal counsel to ensure that the different types of legal systems and evolving requirements are understood and to take appropriate action to help the organization respond accordingly.
• Conflicting laws: The EU GDPR and the U.S. Clarifying Lawful Overseas Use of Data (CLOUD) Act can leave an organization in a legal mess. GDPR forbids transfer of EU citizen data without adequate protections, while the CLOUD Act requires U.S.-based companies to respond to legal requests for data regardless of where the data is physically located. Simply locating physical infrastructure in another country is not enough to avoid potential legal consequences in this scenario—different corporate structures may be required to avoid the risk of one country's law enforcement action leading to legal issues in another.

Legal Frameworks and Guidelines

Cloud security practitioners should be aware of the legal frameworks that affect the cloud computing environments. The following frameworks are the products of multinational organizations working together to identify key priorities in the security of information systems and data privacy.

eDiscovery

When a crime is committed, law enforcement or other agencies may perform eDiscovery using forensic practices to gather evidence about the crime that has been committed, which can be used to prosecute the guilty parties. eDiscovery is defined as any process in which electronic data is pursued, located, secured, and searched with the intent of using it as evidence in a civil or criminal legal case. In a typical eDiscovery case, computing data might be reviewed offline, with the equipment powered off or viewed with a static image, or online with the equipment powered on and accessible.

In the cloud environment, almost all eDiscovery cases will be done online due to the nature of distributed computing and the difficulty in taking those systems offline, though some offline analysis is also possible. Virtual machine (VM) images or snapshots may be analyzed without powering on the VM itself. Forensics, especially cloud forensics, is a highly specialized field that relies on expert technicians to perform the detailed investigations required for discovery while not compromising the potential evidence and chain of custody. Not all security practitioners will possess this set of skills, so it is important to identify where in-house resources can perform certain actions and where highly trained external resources are required. This may involve the use of dedicated digital forensics and incident response (DFIR) personnel or law enforcement.

Forensics Requirements

Digital forensics and eDiscovery requirements for many legal controls are greatly complicated by the cloud environment. Unlike on-premises systems, it can be difficult or impossible to perform physical search and seizure of cloud resources such as storage or hard drives. ISO/IEC and CSA provide guidance to cloud security practitioners on best practices for collecting digital evidence and conducting forensics investigations in cloud environments.

As discussed, DFIR is a highly specialized field within security and should be performed only by qualified personnel. Untrained or unskilled personal performing forensics run the risk of destroying or altering evidence, which renders it useless for investigation and prosecution. All security practitioners should be familiar with the following standards, even if they do not specialize in forensics:

• Cloud Security Alliance: The CSA Security Guidance Domain 3: Legal Issues: Contracts and Electronic Discovery highlights some of the legal aspects raised by cloud computing. This provides cloud security practitioners with guidance on negotiating contracts with cloud service providers in regard to eDiscovery, searchability, and preservation of data.
• ISO/IEC 27037:2012: This provides guidelines for the handling of digital evidence, which include the identification, collection, acquisition, and preservation of data related to a specific case.
• ISO/IEC 27041:2015: This provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are “fit for purpose.” Cloud consumers and security practitioners should pay close attention to the sections on how vendor and third-party testing can be used to assist with assurance processes.
• ISO-IEC 27042:2015: This standard is a guideline for the analysis and interpretation of digital evidence. Security practitioners can use these methods to demonstrate proficiency and competence with an investigative team.
• ISO/IEC 27043:2015: The security techniques document covers incident investigation principles and processes. This can help a security practitioner build processes for various types of investigations, including unauthorized access, data corruption, system crashes, information security breaches, and other digital investigations.

Difference between Contractual and Regulated Private Data

It is important to understand what types of data an organization is processing, where it is being processed, and any associated requirements such as contractual obligations. In any cloud computing environment, the legal responsibility for data privacy and protection rests with the cloud consumer, who may enlist the services of a cloud service provider (CSP) to gather, store, and process that data. The data controller is always responsible for ensuring that the requirements for protection and compliance are met, whether the data is processed in on-premises systems or a cloud solution. When third parties like a CSP are involved, it is important to ensure that contracts with the CSP stipulate data privacy, security, and protection requirements.

There are a number of terms that describe data that requires protection, and the specific types of data may have unique protection requirements. It is essential to understand what type of data is being handled, such as personally identifiable information (PII). This is a widely recognized classification of data that is almost universally regulated. PII is defined by the NIST standard 800-122 as follows:

“any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”

While NIST is a U.S. body, the definition of PII is similar to other standards and frameworks, such as GDPR. Different frameworks explicitly identify certain data points that may be unique, but in general any information that can be used to uniquely identify an individual is considered PII. Security practitioners should be aware of the types of data their organization handles and associated regulatory or contractual obligations.

Protected health information (PHI) is a U.S.-specific subset of PII and is codified under HIPAA. Data that relates to a patient's health, treatment, or billing for medical services that could identify a patient is PHI. When this data is electronically stored, it must be adequately secured by controls such as unique user accounts for every user, strong passwords and MFA, least privilege-based access controls, and auditing all access and changes to a patient's PHI data.

Table 6.1 summarizes types of private data and how they differ.

Country-Specific Legislation Related to Private Data

An individual's right to privacy, and therefore their right to have their data handled in a secure and confidential way, varies widely by country and culture. The global nature of the cloud and many services, such as social media apps, means that organizations face a much broader range of privacy compliance obligations. As a result, security practitioners need to be aware of the broad range of statutory and regulatory obligations around data privacy. These are based on the citizenship of a data subject, rather than the location of the organization's operations, and govern many aspects such as the jurisdiction for any legal proceedings.

There are many different attitudes and expectations of privacy in countries around the world. In some more authoritarian regimes, the data privacy rights of the individual are almost nonexistent. In other societies, data privacy is considered a fundamental right. Security practitioners handling privacy data should be aware of these requirements and seek qualified legal opinion on how these requirements govern their organization's operations.

There are hundreds of country- and region-specific privacy laws and regulations, and an exhaustive analysis is outside the scope of this reference guide. The first task that a security practitioner should perform when addressing privacy is identifying all relevant laws and regulations that govern the data their organization handles. Legal firms that specialize in international privacy laws exist, and should be engaged as needed to provide the necessary guidance.

Jurisdictional Differences in Data Privacy

Cloud computing resources enable global placement of infrastructure for processing and storing data, which brings with it challenges related to complying with overlapping, and often conflicting, privacy laws. Different laws and regulations may apply depending on the location of the data subject, the data collector, the cloud service provider, subcontractors processing data, and the company headquarters of any of the entities involved. Security practitioners must be aware of these challenges and ensure that their risk assessments adequately capture these risks. Mitigation activities should be implemented to ensure compliance, and consultation with legal professionals during the construction of any cloud-based services is essential.

Legal concerns can prevent the utilization of a cloud services provider, add to costs and time to market, and drive changes to the technical architectures required to deliver services. Nevertheless, it is vital to never replace compliance with convenience when evaluating services, as this increases risks. In 2020, the video conferencing service Zoom was found to be engaged in the practice of routing video calls through servers in China in instances when no call participants were based there. This revelation caused an uproar throughout the user community and led to the abandonment of the platform by many customers out of privacy concerns: see theguardian.com/uk-news/2020/apr/24/uk-government-told-not-to-use-zoom-because-of-china-fears. In this case, the impact was mainly reputational, as customers abandoned the platform because their data would certainly not enjoy the same privacy protections within China compared to other nations. While lost business can be hard to quantify, many privacy frameworks impose fines or other regulatory action for noncompliance.

Standard Privacy Requirements

With so many concerns and potential harm from privacy violations, entrusting data to a CSP can be daunting. Fortunately, there are industry standards that address the privacy aspects of cloud computing for customers. International organizations such as ISO/IEC have codified privacy controls for the cloud. Adherence to the privacy requirements outlined by ISO 27018 enable cloud customers to trust their providers.

ISO 27018 was published in July 2014 as a component of the ISO 27001 standard and was most recently updated in 2019. Security practitioners can use the certification of ISO 27000 compliance as assurance of adherence to key privacy principles, and CSPs can publish details of their ISO certification to provide assurance to their customers. Major cloud service providers such as Microsoft, Google, and Amazon maintain ISO 27000 compliance, which include the following key principles:

• Consent: Personal data obtained by a CSP may not be used for marketing purposes unless expressly permitted by the data subject. A customer should be permitted to use a service without requiring this consent.
• Control: Customers shall have explicit control of their own data and how that data is used by the CSP.
• Transparency: CSPs must inform customers of where their data resides and any subcontractors that might process personal data.
• Communication: Auditing should be in place, and any incidents should be communicated to customers.
• Audit: Companies must subject themselves to an independent audit on an annual basis.

Privacy and security concerns can generate conflict when monitoring is used to inspect network traffic or system usage. Organizations may have a legitimate need to observe what their users are doing, for example to identify users who violate policy by visiting inappropriate websites or sending protected data outside the organization's control. Monitoring tools can be useful, but the privacy rights of the users may conflict with this monitoring. In some jurisdictions, providing notice that a system is monitored is sufficient, while in others it is illegal to perform monitoring without a specific, documented reason. It is important to ensure that the monitoring strategy does not create a breach of privacy protections the users are entitled to.

Privacy Impact Assessments

Assessing the impact of systems and business processes is a familiar task—a business impact assessment (BIA) is a crucial element of performing continuity and resilience planning. Similarly, a privacy impact assessment (PIA) is designed to identify the privacy data being collected, processed, or stored by a system, and assess the effects that a breach of that data might have. Several privacy laws explicitly require PIAs as a planning tool for identifying and implementing required privacy controls, including GDPR and HIPAA.

Conducting a PIA typically begins when a system or process is being evaluated, though evolving privacy regulation often necessitates assessment of existing systems. The first step is to define a scope of the PIA, such as a single system or an organizational unit. Once the scope is defined, the types of data collected and data flow throughout the target system must be documented. These are critical for the next phase, which is analysis, since the types of data often dictate the required protections.

For example, a system that handles sensitive personal data like health records or financial transactions is regulated by privacy legislation that mandates specific security controls. The culmination of the PIA process is a documented impact assessment detailing the information in use, consequences of a breach or mishandling of the data, and required controls. These may include identifying a data or system owner and assigning them responsibility for ensuring that required controls are implemented, choosing technologies that offer required security capabilities, and architecting systems to meet the requirements. From a cloud security perspective, this may drive decisions about which CSP to use, which specific services can or cannot be used, and even whether the proposed system is appropriate for cloud hosting at all.

Methods of gathering information when conducting the PIA can include questionnaires and interviews with relevant staff, such as system architects, administrators, or even project leaders. Diagrams of systems, networks, or data flows can be created and are a useful tool when defining what data is being handled and where it exists during different lifecycle phases. This dictates the type and manner of controls implemented—for example, a system that does not archive data will not need any controls in place for data retention. Some regulatory frameworks mandate retention, however, so understanding if the data in question is regulated by one of these frameworks is an essential part of the analysis.

The IAPP has published guides and resources related to privacy efforts like PIAs. More details on the functioning and creation of PIA processes can be found here: iapp.org/resources/article/privacy-impact-assessment.

Internal and External Audit Controls

Audits help organizations communicate important details of their security and privacy controls, including the adequacy of control design and whether the controls are in place and achieving the desired level of risk mitigation. External auditors provide a trusted source of information that allows this information to be communicated with outside parties; CSPs can engage a third-party auditor to conduct a review and share that report with potential customers to earn new business. The auditor in this case is unbiased, so the level of trust in the report is higher than with an internal auditor, whose job security rests on the results of the report.

Internal audit and compliance does have a key role to manage and assess risk for both CSPs and cloud customers. External audits perform a vital function in evaluating controls but are typically expensive and happen relatively infrequently. An internal audit function can provide more continuous monitoring of control effectiveness and also brings more inside knowledge of the organization's operations. This can uncover issues that an outsider might miss, and the more frequent review schedule allows the organization to catch and fix any issues before they show up on a formal audit report.

An internal auditor acts as a “trusted advisor” as an organization takes on new risks. In general, this role works with IT to offer a proactive approach with a balance of consultative and assurance services. An internal auditor can engage with relevant stakeholders to educate the customer about cloud computing risks, such as security, privacy, contractual clarity, business continuity planning (BCP) and disaster recovery planning (DRP), compliance with legal and jurisdictional issues, etc. They fulfill this role both proactively, when projects begin, and also reactively, as they conduct audits of existing systems or processes and report on any weaknesses.

An internal audit can also mitigate risk by examining cloud architectures to provide insights into an organization's cloud governance, data classifications, identity and access management effectiveness, regulatory compliance, privacy compliance, and cyber threats. While more frequent audit schedules can create an operational burden, the rapidly evolving nature of cloud computing means that risks can change significantly in a short period of time. Waiting for the next annual external audit may allow risks to exist for much longer than desirable.

It is a best practice for an internal auditor to maintain independence from both the cloud customer and the cloud provider, even though they may be employed by one of these organizations. The auditor is not “part of the team” but rather an independent entity who can provide facts without fear of reprisal. To achieve this, most internal audit teams report to a different executive than their IT counterparts. Controls in place around the audit function typically focus on this separation of duties and minimizing potential for conflict of interest.

Security controls may also be evaluated by external auditors, and in many compliance frameworks the engagement of a third-party, unbiased auditor is required. An external auditor, by definition, is not employed by but does work on behalf of the firm being audited. This is similar to financial audits, which require an objective third-party auditor to review financial statements. External auditors are generally barred from offering advisory services due to the potential conflict of interest, so controls in place for selecting and interacting with the auditors must account for this requirement.

Other controls that should be in place for audits include the following:

• Timing: When audits must be conducted will likely be driven by business requirements, especially legal and regulatory frameworks that require reporting on or before a specific date. Contractual obligations may also drive this decision, as new customers may require proof of security controls within a specific timeframe after signing a contract. Audits happen regularly; these requirements are often gathered once, and then a recurring schedule is set based on them—for example, providing an initial SOC 2 Type II report to a new customer within 18 months of signing the contract, and then annually thereafter.
• Requirements for internal/external audit: Some legal and regulatory frameworks require the use of an independent auditor, while others are explicit in requiring a competent third-party auditor. Understanding these requirements is crucial to designing an audit approach. Even if an organization must engage an external auditor, internal audits can be used to perform spot checks or continuous monitoring that complements the external auditor's work.

Impact of Audit Requirements

The requirement to conduct audits can have a large procedural and financial impact on a company. In a cloud computing context, the types of audits required are impacted largely by a company's business sector, the types of data being collected and processed, and the variety of laws and regulations that these business activities subject a company to. In addition, customer requirements can be a significant driver, especially for organizations providing SaaS that is built on another CSP's infrastructure. While some elements of the security program are covered by the infrastructure CSP's controls and audit reports, the SaaS provider is responsible for implementing controls over their activities and providing an audit report showing how they are implemented.

Some entities operate in heavily regulated industries subject to numerous auditing requirements, such as banks or critical infrastructure providers. Others may be data processors with international customers, such as big tech companies like Apple, Facebook, Google, and Microsoft. This significantly increases the scope and complexity of the audit program, due to overlapping and sometimes conflicting requirements.

The dynamic and quickly evolving nature of cloud computing demands changes to processes associated with audits. For example, auditors must rethink some traditional methods that were used to collect evidence needed during an audit. As an example, consider the problems of data storage, virtualization, and dynamic failover.

• Is a data set representative of the entire user population? Cloud computing allows for the relatively easy distribution of data to take advantage of geographic proximity to end users, so obtaining a representative sample may be difficult since the data and system architecture can be dispersed.
• Physical servers are relatively easy to identify and locate. Virtualization adds a layer of challenge in ensuring that an audited server is, in fact, the same system over time.
• Dynamic failover presents an additional challenge to auditing operations for compliance to a specific jurisdiction. A system that is operating under normal conditions in a particular region can be compliant with legal obligations, but a disaster that causes failover to another region could be a violation of the regulatory requirements.

Identify Assurance Challenges of Virtualization and Cloud

The cloud is made possible by virtualization technologies. Abstracting the physical servers that power the cloud from the virtual servers that provide cloud services allows for the necessary dynamic environments that make cloud computing powerful and cost-effective. Furthermore, the underlying virtualization technologies that power the cloud are changing rapidly. Even a seasoned systems administrator who has worked with VMware or Microsoft's Hyper-V may struggle with understanding the inherent complexity of mass scalable platforms such as AWS, Google, or Azure cloud.

Migrating from on-premises to cloud hosting fundamentally changes the practice of risk management, which presents challenges to gaining the necessary assurance that controls are in place and reducing risk to an acceptable level. An on-premises system audit can be conducted by an organization using their own personnel. That same audit is likely impossible in a cloud environment for a number of reasons. CSPs rarely allow customers to perform their own audits of the CSP's facilities, and even if an auditor could gain access, finding the specific physical hardware hosting a cloud system may be impossible. This means that assurance must come from third-party-issued reports rather than direct observation, shifting the process to more of a supply chain or vendor risk management activity.

Depending on the cloud architecture employed, a cloud security professional must perform multiple layers of auditing. Elements of both the hypervisor and VMs themselves must be inspected to obtain assurance during the audit. It is vital for the auditor to understand the architecture that a cloud provider is using for virtualization and ensure that both hypervisors and virtual host systems are hardened and up-to-date. Change logs are especially important in a cloud environment to create an audit trail as well as an alerting mechanism for identifying when systems may have been altered in inappropriate ways by accidental or intentional manners.

Because of the shared responsibility model, some elements of auditing will be shared by the CSP and the cloud customer. Audits of controls over the hypervisor will usually be the purview of the CSP, since they control and manage the relevant hardware. VMs deployed on top of that hardware are usually under the direct control of the cloud customer, so assurance activities must be performed by either customer personnel or their third-party auditor. This is more complicated than auditing an on-premises environment where one organization has complete control over the infrastructure. Audit standards, as discussed in the next section, have evolved to deal with this complexity by specifying which controls are owned by the audited organization, and which are inherited from another provider.

Types of Audit Reports

Any audit, whether internal or external, will produce a report focused either on the organization or on the organization's relationship with an outside entity or entities. In a cloud relationship, oftentimes the ownership of security controls designed to reduce risk resides with a cloud service provider. An audit of the cloud service provider can identify if there are any gaps between what is contractually specified and what controls the provider has in place.

Restrictions of Audit Scope Statements

Audit scope statements are an essential part of an audit report. They provide the reader with details on what was included in the audit and what was not—if the reader is using a service that was not included in the scope of the audit, then the report provides nothing useful for making a risk decision. Learning to read audit reports and extract these important details is key to gaining assurance regarding the security controls in place at a CSP or other service provider.

Determining the scope of an audit is usually a joint activity performed by the organization being audited and their auditor. Several frameworks, such as SOC 2 and ISO 27001, include guidance on defining the scope of the audit, specifying which parts of the organization and services are included. The final scope is documented by the auditor in the resulting report and should be used by any consumers when determining if the services they are evaluating have been audited.

An audit scope statement generally includes the following information:

• Statement of purpose and objectives
• Scope of audit and explicit exclusions
• Type of audit
• Security assessment requirements
• Assessment criteria and rating scales
• Criteria for acceptance
• Expected deliverables
• Classification (for example, secret, top secret, public, etc.)

Any audit must have parameters set to ensure that the efforts are focused on relevant areas that can be effectively audited. Setting these parameters for an audit is commonly known as the audit scope restrictions. Why limit the scope of an audit? Audits are expensive endeavors that can engage highly trained (and highly paid) content experts. The auditing of systems can affect system performance and, in some cases, require the downtime of production systems.

Large organizations with multiple service offerings may also restrict the scope of an audit to a specific service or set of services for a variety of reasons. A newly created service may not have all relevant controls implemented, so an audit is largely useless until the service is complete and controls are implemented. In other cases, it may be a deliberate decision to exclude certain services from being audited, as the cost of implementing controls and auditing to verify their effectiveness is too high relative to the revenue the service generates.

Scope restrictions are of particular importance to security professionals. They can spell out the operational components of an audit, such as the acceptable times and time periods (for example, days and hours of the week), types of testing that will be conducted, and which systems or services are to be audited. Carefully crafting scope restrictions can ensure that production systems are not adversely impacted by an auditor's activity, and it is vital to ensure that systems that customers need assurance for are included in the scope. Scoping can also be a means of controlling costs related to compliance. For example, an audit on HIPAA compliance should only include systems that handle PHI; otherwise, the auditor will charge for time spent auditing systems that should have no valid reason to be audited.

Gap Analysis

As a precursor to a formal audit process, an organization may find a gap analysis a useful starting point. Gap analyses lack the rigor of a formal audit and can be a quick check of compliance, which is useful for organizations preparing to undergo a formal audit for the first time. They can also be useful when assessing the impact of changes to regulatory or compliance frameworks, which introduce new or modified requirements. A gap analysis identifies where the organization does not meet these changed requirements and provides important information to help remediate thee gaps.

The main purpose of a gap analysis is to compare the organization's current practices against a specified framework and identify the gaps between the two. These may be performed by either internal or external parties, and the choice of which to use will be driven by the cost and need for objectivity. If a gap analysis is being performed against a business function, the first step is to identify a relevant industry-standard framework to compare business activities against. In information security, this usually means a standard such as ISO 27002 (best-practice recommendations for information security management). Another common comparison framework used as a cybersecurity benchmark is the NIST cybersecurity framework.

A gap analysis can be conducted against almost any business function, from strategy and staffing to information security. The common steps generally consist of the following:

• Establishing the need for the analysis and gaining management support for the efforts.
• Defining scope, objectives, and relevant frameworks.
• Identifying the current state of the department or area (which involves the evaluation of the department to understand current state, generally involving research and interviews of employees).
• Reviewing evidence and supporting documentation, including the verification of statements and data.
• Identifying the “gaps” between the framework and reality. This highlights the risks to the organization.
• Preparing a report detailing the findings and getting sign-off from the appropriate company leaders.

Since a gap analysis provides measurable deficiencies and, in some cases, needs to be signed off by senior leadership, it can be a powerful tool for an organization to identify weaknesses in their efforts for compliance. It is also useful as a planning and prioritization tool, as any identified gaps can be evaluated against known risks. The gaps that correspond to risks should be prioritized first, since closing them also supports the organization's overall security risk management strategy.

Audit Planning

Any audit, whether related to financial reporting, compliance, or cloud computing security risk management, must be carefully planned and organized. This helps ensure that the results of the audit are relevant to the organization and contain useful information that can be used to help the organization improve on any identified weaknesses or deficiencies.

The audit process can generally be broken down into four phases, starting with audit planning. During this phase, the organization must perform several tasks, including the following:

• Document and define audit program objectives: This process must be a collaborative effort and begins with internal planning to determine what systems or processes are to be audited and what standards are to be used. In many scenarios, this will be done many months before the audit, since time is required to implement controls that are required by the chosen standard.
• Gap analysis or readiness assessment: A mock or mini audit, usually performed by internal personnel, can be useful in assessing the organization's ability to successfully undergo a full audit. In the process of implementing security and compliance controls, it is possible to overlook key tasks, and the changing nature of an organization can also render existing controls ineffective. Identifying and fixing these issues before a formal audit helps to ensure that the audit report does not contain unfavorable findings.
• Define audit objectives and deliverables: Once the organization is ready to undergo an audit, it is important to identify the expected outputs from the audit. These may include a report that can be shared with customers, data to be shared with leadership, and action items for security or compliance teams to address, among others. Many audit frameworks dictate the deliverables, such as a SOC 2 Type II, which always results in a SOC 2 report, or FedRAMP, which results in an authorization to operate (ATO).
• Identifying auditors and qualifications: Compliance and audit frameworks usually specify the type of auditor required, such as a partially independent internal auditor or completely independent third-party auditor. Frameworks that rely on third-party auditors often specify a standard and issue credentials to auditors authorized to perform specific types of audits, such as a CPA who can perform a SOC audit. Security practitioners must ensure that they engage an auditor with appropriate skills, credentials, and training.
• Identifying scope and restrictions: Once the auditor is chosen, they will usually work with the organization to define a scope and any restrictions or exclusions. This might include scoping the audit to just a set of systems or organizational units and is usually documented formally in the audit report. This allows consumers of the report to understand whether the systems or services they are accessing have been audited and whether any issues or deficiencies exist.

Once the audit planning process is completed, the actual work of the audit begins. After planning, there are three major phases of an audit, which include the following activities:

• Audit fieldwork: This involves the actual work the auditors perform to gather, test, and evaluate the organization. This includes examining evidence, interviewing organization personnel, and testing controls.
• Audit reporting: The report writing begins as the auditors conduct their fieldwork, as they capture notes and any findings. The formal audit report is typically provided in a draft form to allow the organization to challenge any incorrect information. Once agreed upon, the final audit report is issued.
• Audit follow-up: Various activities may be conducted after the audit, including addressing any identified weaknesses. Some auditors will perform retesting of fixed controls and issue an update or addendum to an audit report to indicate the organization's actions that addressed the original finding. This is useful, as consumers of the audit report will naturally ask what the organization has done to address identified findings, since they represent risks.

In many organizations, audit is a continuous process. This is often structured into business activities to provide an ongoing view into how an organization is meeting compliance and regulatory goals. As part of the audit planning process, scheduling and coordinating these audits can be challenging but is essential to prevent audits from adding too much operational overhead. Cloud security practitioners can utilize audits as a way to monitor the status of their compliance programs and therefore the status of their risk mitigation strategies.

Internal Information Security Management System

An information security management system (ISMS) is a systematic approach to information security consisting of processes, technology, and people designed to help protect and manage an organization's information. The ISO 27001 standard directly addresses the need for and approaches to implementing an ISMS, starting with an explanation of what the ISMS is and how it should align with other organizational processes:

The information security management system preserves the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.

It is important that the information security management system is part of and integrated with the organization's processes and overall management structure and that information security is considered in the design of processes, information systems, and controls. It is expected that an information security management system implementation will be scaled in accordance with the needs of the organization.

This International Standard can be used by internal and external parties to assess the organization's ability to meet the organization's own information security requirements.

Source: ISO/IEC 27001:2013

Information technology — Security techniques — Information security management systems — Requirements

An ISMS is a powerful risk management tool and is most often implemented at medium or large organizations where there is a formal need to quantify risk, develop and execute strategies to mitigate it, and provide formal reporting on the status of these risk mitigation efforts. It gives both internal and external stakeholders additional confidence in the security measures in place at the company.

Though the function of an ISMS can vary from industry to industry, there are a number of benefits to implementation that hold true across all industries.

• Security of data in multiple forms: An ISMS can help protect data in all forms, whether the organization relies on hard-copy, on-premises, or cloud-based information systems.
• Cyberattacks: Having an ISMS can make an organization more resilient to cyberattacks, because the risk of these attacks is known and formal processes exist to mitigate them. As the threat landscape evolves, the ISMS's continuous improvement efforts and ongoing risk management activities help the organization to respond effectively.
• Central information security management: An ISMS will put in place centralized frameworks for managing information, reducing shadow systems, and easing the burden of data protection. Organizations with multiple units or dispersed authority can benefit from a centralized source of information security risk management by sharing best practices and resources.
• Formal risk management: Having a codified set of processes and procedures in place can reduce operational risks in a number of areas, including information security, business continuity, and adapting to evolving security threats. Although an ISMS does not explicitly address operational issues like financial risk, it can help address operational risks like system interruptions. Most organizations rely heavily on technology systems, and a security risk management framework that addresses availability also addresses operational risks.

As with any major organizational element, an ISMS requires buy-in from company leadership to be effective. For CSPs an ISMS can provide a single organizational function for addressing risks that customers will ask about, such as the security of the data they put into the cloud and availability of systems hosted in the CSP's environments. For cloud customers, their own internal ISMS is the implementation point for all the security controls discussed throughout this book, including risk management activities associated with migrating to and using cloud computing.

Internal Information Security Controls System

As a companion to an ISMS, a system of information security controls provides guidance for mitigating the risks identified as part of the ISMS's risk management processes. Often known as control frameworks, these are considered best practices guidance that can give the organization a starting point when addressing their identified risks. As with all shared resources, some modifications may be required.

Scoping controls refers to identifying which controls in the framework apply to the organization and which do not. There may be controls that deal with business processes, system types, or even technologies that are not in use in an organization. Tailoring is a process of taking the applicable controls and matching them to the organization's specific circumstances, such as removing any guidance for Windows systems if an organization is exclusively Linux based. To use a clothing analogy, scoping refers to excluding the sections of a store that sell clothes designed for other age groups—adults are unlikely to find anything wearable in the children's department! Once an appropriate outfit is selected, tailoring can ensure that it fits your individual body type, resulting in the best fit.

There are a number of control frameworks to choose from and various reasons to choose one or another. Organizations implementing an ISO 27001 ISMS will find the ISO 27002 controls very easy to use, since they are designed to fit together. Other control frameworks include NIST Special Publication 800-53, the NIST Cybersecurity Framework (CSF), the Secure Controls Framework, and the CSA CCM.

In addition to providing a set of standardized control activities, these frameworks may also provide guidance and processes for the tailoring and implementation of activities needed to meet the objectives. For instance, the NIST CSF organizes controls based on their intended risk mitigation functions.

• Identify
• Protect
• Detect
• Respond
• Recover

For example, Identify controls are useful for identifying threats and risks, while Protect controls are designed to proactively mitigate identify risks. Once controls are in place, the Detect category includes controls related to detecting whether a security incident has occurred, while Respond and Recover focus on mitigating the impact and returning to normal operations. More information on the NIST CSF can be found at nist.gov/cyberframework/online-learning/five-functions.

Policies

Policies are a key part of any data security strategy. Policies provide users and organizations with a way to understand requirements and provide the organization to enforce these requirements in a systematic way. Employees and management are made aware of their roles and responsibilities via policies, which is a way for organizations to govern activities occurring during the course of operations. Policies are an important piece of standardizing practices in an organization.

From a cloud computing perspective, policies can be an important tool to govern migration to and use of cloud resources. While cloud computing offers significant benefits like cost savings, it can also introduce unexpected or unwanted risk. Policies communicate expectations such as acceptable use of cloud services, helping to ensure that the organization balances the benefits realized via cloud computing without taking on unacceptable risks.

Policies are a formal and high-level document that should be approved by the organization's management. They support strategic goals and initiatives and generally do not contain highly specific details like system configurations or step-by-step procedures. Without formal management approval and proper education for relevant stakeholders, policies will be ineffective, so it is important for security practitioners to devote adequate attention to them.

Identification and Involvement of Relevant Stakeholders

One key challenge in the audit process is the inclusion of any relevant stakeholders. This includes the organization's management who will likely be paying for the audit, security practitioners who will be responsible for facilitating the audit, and employees who will be called upon to provide evidence to auditors in the form of documentation, artifacts, or sitting for interviews.

Cloud computing environments can include more stakeholders than on-premises systems, because there can be multiple CSPs involved. For instance, a SaaS application may introduce both the SaaS vendor as well as their infrastructure provider, where an on-premises environment would involve only the organization's internal IT department. When it comes to performing audits, certain challenges can arise from these complicated supply chains,

It is important to both identify and involve all relevant stakeholders. If this is not done, any audit performed risks missing important details and information the auditors need to uncover potential weaknesses. This applies even without additional vendors or stakeholders—auditors will need access to relevant personnel such as system administrators and management inside the organization. When auditing a cloud system, stakeholders from the CSP may need to be informed or involved.

To identify relevant stakeholders, some key challenges that cloud security practitioners face include the following:

• Defining the enterprise architecture currently used to deliver services, including all service providers.
• Identifying any contractual obligations or requirements that impact audits, such as a limitation on the right to audit or resources provided by the CSP that can be used by customers when performing an audit. Most CSPs publish their own audit reports that detail controls under their purview, such as physical and environmental. Cloud customers may carve these requirements out of their audit scope and instead rely on the findings of the CSP's auditors.

Specialized Compliance Requirements for Highly Regulated Industries

Responsibility for compliance to any relevant regulations ultimately rests with the cloud consumer, and organizations that migrate to the cloud do not absolve themselves of risks associated with their information systems. Some industries have cloud-specific regulatory or compliance guidance, and some industries have extensive regulatory frameworks due to the sensitivity of the data handled by that industry. This significantly impacts the work of security practitioners, who may find their entire job description dictated by the compliance requirements.

Many CSPs have compliance-focused cloud service offerings, which meet the requirements of specific regulatory or legal frameworks. An organization's cloud computing strategy should be designed with regulatory compliance in mind, including mandating the use of compliant cloud service offerings. The cloud customer is unlikely to perform their own audit of a CSP and instead will rely on the CSP's published audit reports to gain assurance that the CSP's services implement adequate protections to meet the regulatory requirements.

Highly regulated industries typically involve highly sensitive data, such as health or financial information, or provide services that make them critical infrastructure, such as power and other utility providers. Organizations in these industries need to be aware of the regulations governing their operations and ensure that their strategy for using cloud computing enables them to be compliant. Examples of these regulatory frameworks include the following:

• North American Electric Reliability Corporation Critical Infrastructure Protection (NERC/CIP): In the United States and Canada, organizations involved with power generation and distribution must regulate their operations according to the CIP standards. This includes the use of any cloud computing resources, which must meet requirements like maintaining adequate security protections to prevent disruption of power generation and delivery.
• HIPAA and the Health Information Technology for Economic and Clinical Health (HITECH) Act: Both HIPAA and HITECH deal with PHI and implement specific requirements for security and privacy protections, as well as breach notification requirements. While cloud computing is not specifically addressed, these laws do identify required controls that must be in place for any system handling PHI. Cloud customers should verify their chosen CSP's ability to meet these requirements before processing any PHI in the cloud.
• PCI: PCI DSS specifies protections for payment card transaction data. Similar to HIPAA, it does not specifically address the use of cloud computing, but any CSP chosen must be able to meet the PCI DSS standards for data security and privacy. Reviewing the CSP's audit reports to gain assurance is a key task for a security practitioner.

Since public CSPs do not generally allow individual customers to perform audits, organizations in highly regulated industries may seek out a different cloud deployment model. If enough organizations need cloud computing, creating a community cloud might be a feasible option. Since the user community shares the same regulatory requirements, the community cloud can be specifically designed to meet those needs. This simplifies the task of compliance, and any audits performed on the cloud will be specific to the industry-specific regulations, which will make security activities easier for all customers of that community cloud.

Impact of Distributed Information Technology Model

Cloud computing enables distributed IT service delivery, with systems that can automatically replicate data and provide services from data centers around the globe. Auditing such a complex environment requires significant modifications from traditional computing models, where it was possible to point to a specific data center and specific server rack where data or systems were hosted.

One obvious impact of this distributed model is the additional geographic locations auditors must consider when performing an audit. An important term in audits is sampling, which is the act of picking a subset of the system's physical infrastructure to inspect. For example, when performing a configuration audit on a system with 100 web servers, an auditor might pull configuration information for 20 of them to perform checks. The time needed to audit all 100 is prohibitive, so reviewing 20 percent is adequate to determine if the organization's configuration management policy is being followed.

Now expand this problem from 100 servers in a few data centers in one country: auditors now face hundreds of data centers in many different countries. Further complicating the issue is virtualization, which means the virtual servers that are part of a specific system could exist on any one of thousands of hardware clusters around the world—and their location can change almost instantly. This is an obvious benefit for system availability but makes the process of sampling much more difficult.

CSPs have found ways to collect evidence that provides auditors with sufficient assurance that they have collected a representative sample. This can include continuous monitoring strategies that capture information on a frequent enough basis to supply the auditor with sufficient, competent evidence. However, the cost of audits with geographically distributed systems will be greater, as the auditors may have to perform physical site inspections that require travel.

Legal jurisdiction issues can also complicate the process of conducting audits. While the process of auditing is not necessarily illegal, issues associated with auditors traveling and gaining access to facilities can add complexity to the audit process. For example, gaining access and approval to do business in some countries requires visas and work permits, which must be approved before an audit can take place. As with other aspects of cloud security, practitioners should coordinate with appropriate legal resources to determine any needs related to international auditing.

Assess Provider’s Risk Management Programs

Prior to establishing a relationship with a cloud provider, a cloud customer needs to analyze the risks associated with adopting that provider's services. The goal of this is the same as performing risk assessments for on-premises infrastructure, but the method of gaining assurance is different. Rather than performing a direct audit, the customer must rely on their supply chain risk management (SCRM) processes. Similar to shifting IT control away from the customer to the CSP, SCRM requires new approaches.

First and foremost in SCRM is evaluating whether a supplier has a risk management program in place, and if so whether the risks identified by that program are being adequately mitigated. Unlike traditional risk management activities, where the organization can directly review their own processes and procedures, SCRM may require an indirect approach. The major CSPs do not permit direct customer audits or assessments, so cloud customers must review audit reports furnished by the CSP to gain the information needed.

SOC 2, ISO 27001, FedRAMP, and CSA STAR have all been discussed in previous sections of this chapter. CSPs will engage a qualified third-party auditor to perform an audit and issue a report using one or more of these frameworks, and possibly others, depending on the markets the CSP is trying to win business in. Some customers are required to choose CSPs that are compliant with a particular framework, such as U.S. government agencies that must use FedRAMP-accredited CSPs. Nonregulated organizations may be able to choose a CSP that provides an audit report that offers adequate assurance, such as picking a CSA STAR Level 1 CSP. Although the Level 1 self-assessment provides only low assurance, the lower cost associated with a less-audited environment may be appropriate for lower-sensitivity data.

When reviewing an audit report, there are several key elements of the report to focus on. These include any scoping information or description of the audit target. Some compliance frameworks allow audits to be very narrowly scoped, such as SOC 2. If the CSP's SOC 2 audit did not cover a specific service a customer wants to use, then the audit finding does not provide any value. Also important to review are any findings, weaknesses, or deficiencies identified in the report, as these represent inadequate or nonfunctional risk mitigations. If the risk applies to a service the customer is not using, the finding can be ignored, but if it does impact a service in use, then that risk is inherited by the customer. This may drive changes, such as enhanced customer-side controls, tracking the CSP's mitigation and resolution efforts, or even migrating to another CSP altogether.

There are resources that can help organizations build out or enhance their SCRM program. NIST has a resource library that includes working groups, publications, and other resources, available here: csrc.nist.gov/Projects/cyber-supply-chain-risk-management. ISO 27000:2022 specifies a security management system for security and resilience, with a particular focus on supply chain management. It extends concepts found in the ISO 31000:2018 standard, which focuses on enterprise risk management. Both standards provide guidance for identifying and assessing a supplier's security controls, policies and procedures, and the effectiveness of their security risk mitigations.

Two other important aspects to consider when evaluating a CSP's risk management program include the company's risk profile and risk appetite. Risk profile describes the risk present in the organization based on all the identified risks and any associated mitigations in place. For example, technology startups typically have much higher risk than established financial services firms. This is due to several factors, including the age of the company and maturity of their risk management programs, as well as the varying amount of regulation each industry faces.

Risk appetite describes the amount of risk an organization is willing to accept without mitigating—once again a startup is likely to accept more risk than a bank simply due to the resources required to mitigate those risks. A cash-strapped startup cannot staff up a risk department, so it must accept more operational and technology risk. Both of these factors should be considered by any cloud customers when evaluating a provider's risk management program. These details may be provided in audit reports as part of the provider's description of their ISMS, or in other documentation like security whitepapers.

Differences between Data Owner/Controller vs. Data Custodian/Processor

An important distinction in data is the difference between the data owner (data controller) and the data custodian (data processor). While these nuanced definitions may seem unneeded, they do have implications for managing risks associated with privacy data. It is helpful to start with some definitions:

• A data subject is the individual or entity that is the subject of the personal data.
• A data controller is the person (or company) that determines the purposes for which, and the way in which, personal data is processed. This entity owns the data and, importantly, risks associated with any breaches of the data.
• The data processor is anyone who processes personal data on behalf of the data controller. This entity is a custodian of data, who is charged with implementing protections at the direction of the data controller.

For example, let's say BikeCo sells bicycles and allows users to provide personal data online to fulfill orders. They use a CSP, called CloudWheelz, to host their website and customer database, as well as an online payment processor, Circle, to handle payment card transactions. In this case, any customer is the data subject, and BikeCo is the data controller. Both CloudWheelz and Circle are data processors that act on behalf of the data owner. In the event that either CloudWheelz or Circle suffers a data breach, BikeCo is still legally liable for the data. If they have not taken adequate steps to ensure that their data processors implemented adequate protections, regulatory agencies are likely to assess significant penalties.

The distinctions are important for regulatory and legal reasons. Data processors are responsible for the safe and private custody, transport, and storage of data according to business agreements. Data owners are legally responsible (and liable) for the safety and privacy of the data under most international laws. When data controllers use processors, they must ensure that security requirements follow the data. This is often achieved via contract clauses that specify data protection and handling requirements, breach notification timelines, and possibly risk transfer such as the requirement for the processor to carry insurance that helps defray costs associated with a security incident.

Regulatory Transparency Requirements

A cloud security professional should be aware of the transparency requirements imposed on data controllers by various regulations and laws around the world. Many of these were written before cloud computing was as pervasive as it is today, so it is also important to stay informed about changes, as well as new regulations that come into force and impact the organization. Many legal firms will provide this kind of guidance as a service, and in-house legal counsel can also be a useful resource to identify regulatory requirements and any changes needed to come into compliance.

The following is a short and noncomprehensive list of several important regulatory frameworks that require transparency related to data security and privacy. Security practitioners in organizations regulated by these frameworks must be aware of the frameworks and work to implement the required controls. As a data owner or processor, cloud security professionals must be aware of all relevant regulatory requirements.

Risk Treatment

Risk treatment is the practice of modifying risk, usually to lower it, which can be achieved in a number of ways. Risk treatment begins with identifying and assessing risks, typically by measuring the likelihood and impact of their occurrence. Not all risks can be treated equally, so risk management usually prioritizes those risks that are higher impact and likelihood first. These risk assessment procedures should be documented as part of the organization's ISMS.

Once risks are identified, risk treatments should be selected to reduce the likelihood or impact (or both). Treatments that reduce likelihood are proactive, and sometimes known as safeguards, while risks that reduce the impact after a risk has occurred are reactive and known as countermeasures. These are collectively referred to as controls, which should be using a cost-benefit analysis to achieve acceptable risk mitigation at an adequate price.

There are four main approaches to treat risk, and many organizations will use more than one treatment option for the same risk. The options are as follows:

• Avoid: The organization can avoid risk altogether by not engaging in a particular activity, such as not doing business with EU citizens to avoid GDPR compliance fines. However, this also means losing out on new customers, so it is not unusual for this treatment option to go unused.
• Transfer: The organization can transfer risk to another organization, which is typically an insurance company. An organization's insurance policy pays out in the event of a cyber incident, which helps to offset the financial impact. Insurance carriers are in the business of managing risk, and it is unlikely a carrier will offer insurance if the organization cannot show they have adequate risk mitigations in place. Therefore, risk transfer is often used in conjunction with risk mitigation.
• Mitigate: The organization implements controls to reduce the likelihood and impact of the identified risks. It is common for multiple controls to be layered in a risk mitigation, such as proactive access controls to prevent unauthorized system access, and data encryption to prevent an attacker from reading any data they do gain access to. This reduces the impact of a breach.
• Accept: All risks are accepted by organizations, and risks that are not mitigated or transferred are accepted as is. Mitigated risks should be evaluated to determine if the residual risk, that is, the risk that remains after the control is implemented, falls below the organization's risk tolerance. If the residual risk remains too high, other mitigations or risk transfer should be implemented.

It is important to remember that risks are never entirely eliminated. Mitigations and transfer reduce the risks, and cloud security practitioners should keep this in mind as they perform tasks like evaluating CSPs and selecting security controls for implementation.

Risk Frameworks

Similar to security control frameworks, there are several risk management frameworks available for security practitioners to use as guides when designing a risk management program. Many of these are published by the same bodies that publish the control frameworks, and they are complementary. Organizations designing an ISO 27001 ISMS can easily utilize the relevant ISO standard for designing a security risk management program. These standards are known as risk management frameworks (RMFs).

It is important to note that risk management is not only a security activity. Other departments typically pursue risk management as well, which means the security team might be required to work in a collaborative way when conducting risk assessment and management. Some organizations may find a single risk management function to be useful, so executives have a single view of risk and associated metrics. Other organizations may allow different departments to conduct risk management differently, especially if there are conflicting regulations that govern the activities.

In the cloud computing arena, a cloud security professional should be familiar with the ISO 31000:2018 guidance standard, the European Network and Information Security Agency (ENISA)'s cloud computing risk assessment tool, and NIST standards such as 800-146, “Cloud Computing Synopsis and Recommendation,” and 800-37, “Risk Management Framework for Information Systems and Organizations: A System Lifecycle Approach for Security and Privacy.”

Metrics for Risk Management

There are some key cybersecurity metrics that companies can track to present measurable data to company stakeholders. Each organization should evaluate its strategy, risks, and management requirements for data when designing a metrics program. Some metrics that are commonly tracked include the following:

• Patching levels: How many devices are fully patched and up-to-date? This is a useful proxy for risk, as unpatched devices often contain exploitable vulnerabilities.
• Time to deploy patches: How may devices receive required patches in the defined timeframes? This is a useful measure of how effective a patch management program is at reducing the risk of known vulnerabilities.
• Intrusion attempts: How many times have unknown actors tried to breach cloud systems? Increased intrusion attempts can be an indicator of increased risk likelihood.
• Mean time to detect (MTTD), mean time to contain (MTTC), and mean time to resolve (MTTR): How long does it take for security teams to become aware of a potential security incident, contain the damage, and resolve the incident? Inadequate tools or resources for reactive risk mitigation can increase the impact of risks occurring.

Metrics provide vital information for decision makers in the organization. Metrics that are within expected parameters indicate risk mitigations that are operating effectively and keeping risk at an acceptable level. Metrics that deviate from expected parameters, such as MTTD increasing, can indicate that existing risk mitigations are no longer effective and should be reviewed.

Assessment of Risk Environment

The cloud has become a critical operating component for many organizations, so it is crucial to identify and understand the risks posed by a CSP. Cloud providers are subject to risks similar to other service providers, but since they provide a critical service to many organizations, the impact of these risks is increased. It is important to consider a number of questions when considering a cloud service, vendor, or infrastructure provider.

• Is the provider subject to takeover or acquisition?
• How financially stable is the provider?
• In what legal jurisdiction(s) are the provider's offices located?
• Are there outstanding lawsuits against the provider?
• What pricing protections are in place for services contracted?
• How will a provider satisfy any regulatory or legal compliance requirements?
• What does failover, backup, and recovery look like for the provider?

It can be a daunting challenge for any cloud customer to perform due diligence on their provider. However, since the customer organization still holds legal accountability, it is a vital step in selecting and using a vendor. Designing a SCRM program to assess CSP or vendor risks is a due diligence practice, and actually performing the assessment is an example of due care. As a data controller, any organization that uses cloud services without adequately reviewing and mitigating the risks is likely to be found negligent should a breach occur.

There are frameworks for evaluating vendor and infrastructure risks, which provide guidance on designing and executing the required processes. Some of these are general technology risk management frameworks, while others are specifically designed for cloud computing.

Business Requirements

Before executing a contract with a CSP, it is important for any business to fully understand their own business needs to select a CSP that can adequately meet those needs. The evolution of the cloud means that more and more IT functions can use cloud computing. Once an organization deems cloud computing fit for their needs, the process of codifying these needs and identifying CSPs that meet them can begin. In legal terms, a cloud customer and a CSP enter into a master service agreement (MSA), which is defined as any contract that two or more parties enter into as a service agreement.

Many organizations will have standardized contract templates, and the task of creating and maintaining these is usually not assigned to the security team. Legal counsel is most often responsible for these contracts, but input from the security team is essential to ensure that security requirements make it into these templates. Common areas of security that should be addressed in contracts include any compliance requirements the customer is passing along to the CSP, as well as important processes and parameters the CSP must meet, such as the duty to inform the customer of a breach within a specific time period after detection.

Another important legal document that may be required is a statement of work (SOW). SOWs are usually created after an MSA has been executed and govern a specific unit of work. For example, the agreement to use a CSP's services at specific prices would be documented in the MSA. A SOW could be issued under this MSA detailing requirements, expectations, and deliverables for a major project, such as paying the CSP to assist with a migration from on-premises to cloud hosting.

The greater specificity of a SOW allows for more granular security requirements that are specific to that unit of work, such as the use of physically secured transport and secure handling of hard drives that the CSP takes and migrates data into their systems. If this activity is performed only during the initial migration, these requirements do not make sense in the overall MSA since this physical data transfer is not part of the ongoing services the CSP provides.

The final legal document where business requirements can be captured is the service level agreement (SLA), which specifies levels of service the CSP is obligated to provide. SLAs measure common aspects of service delivery like uptime and throughput and are often tied to system requirements the organization needs in order to function properly.

The SLA is a legally binding agreement, and if the CSP fails to provide the specified levels of service, the customer usually has recourse options defined. These may include refunds or credits for the service and possibly the ability to terminate the contract without penalties. While this is a dramatic option, if a CSP is unable to meet the organization's required service levels, then the organization should be free to seek out another provider. Contracts often contain penalties for early termination without cause, so monitoring the service levels and properly documenting any shortcomings is essential, as this often enables the customer to terminate the contract with cause and avoid the termination fee.

Vendor Management

As discussed previously, the process of managing risk is complicated when parts of the organization's IT infrastructure exist outside the organization's direct control. The practices of SCRM and vendor management overlap significantly, though in many cases vendor management will include more activities related to operational risks.

Vendor management concerns existed for traditional, on-premises infrastructure, but the activities required for cloud computing necessitate different processes and approaches. Selecting a vendor for on-premises hardware might have been a once-and-done activity, since hardware would be expected to last for a defined period of time; at the end of its useful life, assessment of replacement vendors would be conducted.

Cloud computing requires more continuous management activities, since it involves outsourcing ongoing organizational processes and infrastructure to a service provider. This redefined relationship requires a great deal of trust and communication with vendors. Cloud professionals need strong project and people management skills to be successful when performing activities such as the following:

• Assess vendors: Security practitioners should participate in the initial selection process for a CSP, which involves assessing security risks present in CSP and related services. Once a CSP has been selected, ongoing assessments should be conducted at a specified frequency. For many customers, this process will entail reviewing security reports like a SOC 2 on an annual basis after the CSP has undergone their yearly audit.
• Assess vendor lock-in risks: This assessment will require knowledge of not only the CSP's offerings but the architecture and strategy the customer organization intends to use. Simply moving physical services into virtual cloud-based equivalents is unlikely to face lock-in risks, as all CSPs offer basic IaaS that can host a virtualized server. Using any unique CSP offerings, such as artificial intelligence/machine learning (AI/ML) platforms, can result in a system that is dependent on that specific CSP. If the CSP suffers a breach or discontinues the service, the customer organization has no effective means of mitigating that risk, short of completely rebuilding the system from the ground up using another CSP's offerings.
• Assess vendor viability: This is often a process that is not conducted by the security team, as it deals with operational risk. Customers assume significant risk if a CSP is hosting mission-critical systems but is unable to continue their operations, which could be caused by issues like bankruptcy. Assessing the viability of vendors may involve reviews of public information like financial statements, the CSP's performance history and reputation, or even formal reports like a SOC 1, which identifies potential weaknesses that could impact the CSP's ability to continue operations.
• Explore escrow options: Escrow is a legal term used when a trusted third party holds something on behalf of two or more other parties, such as a bank holding money on behalf of the individuals buying and selling a home. In IT services, escrow is often used as a way to hold sensitive material like source code or encryption keys. Exposure of the information to unauthorized parties could be damaging but may be necessary in extreme circumstances. For example, a CSP that performed custom software development may wish to protect the intellectual property of their source code, but if they go out of business, their customers are left with an unmaintainable system. In this scenario, an escrow provider could hold a copy of the source code and release it to customers in the event the provider is no longer in business.

Contract Management

The management of cloud contracts is a core business activity that is central to any ongoing relationship with a CSP. Organizations must employ adequate governance structures to monitor contract terms and performance and be aware of outages and any violations of stated agreements. A standards body known as the OMG Cloud Working Group publishes a useful guide to cloud service agreements, including defining and enforcing contracts, managing SLAs, and building programs to govern these service arrangements. The guide can be found here: omg.org/cloud/deliverables/Practical-Guide-to-Cloud-Service-Agreements.pdf.

Supply Chain Management

Supply chain attacks are increasing in frequency and severity and have been on this track for some time. Back in 2015 the retail company Target was attacked using a vendor with weak security controls. In 2020, governments and major companies around the world were impacted by an attack against a popular SolarWinds network monitoring tool that was shipped to customers with compromised code. The popular open-source library npm has come under repeated attack, since so many open-source software (OSS) packages it hosts are incorporated into other software tools used by organizations all over the world.

Managing risk in the supply chain focuses on both operational risks, to ensure that suppliers are capable of providing the needed services, and security risks. This includes ensuring that suppliers have adequate risk management programs in place to address the risks that they face. Without these controls, risks that impact your organization's suppliers can easily turn into risks that impact your organization. If a major CSP does not enforce environmental controls and server equipment begins to fail, this translates to loss of availability for all of the CSP's customers.

The supply chain should always be considered in any business continuity or disaster recovery planning. The same concepts of understanding dependencies, identifying single points of failure, and prioritizing services for restoration are important to apply to the entire supply chain. Proactive measures including contract language and assurance processes can be used to quantify the risks associated with using suppliers like CSPs, as well as the effectiveness of these suppliers' risk management programs.