LII:Choosing and Implementing a Cloud-based Service for Your Laboratory/Standards and security in the cloud

-----Return to the beginning of this guide-----

2. Standards and security in the cloud

Figure 3. The NIST Cloud Computing Security Reference Architecture provides a security overlay to the NIST Cloud Computing Reference Architecture, published in 2011.

In a 2010 Cloud Computing Adoption Survey by Mimecast, the leading response (46 percent of surveyed IT managers) to the question "Why did you decide against moving to the cloud?" was "security concerns." In a separate survey published around the same time by the IEEE and Cloud Security Alliance, "93 percent of respondents said the need for cloud computing security standards is important; 82 percent said the need is urgent." Fast-forward to today and it's easy to see worries about cloud security have eased somewhat in comparison. A Cloud Threat Report by Oracle and KPMG in 2020 found that "40% of cybersecurity and IT professionals from private and public businesses perceive public clouds as more secure than on-premise environments ... 12% believe public clouds are no more secure or insecure than what they can deliver with on-premises environments, and 2% think public clouds are less secure." A survey less than a year before found similar numbers, also noting, however, that while confidence in cloud security was strong, a strong majority of respondents (71 percent) still believe there are at least moderate concerns about "malicious activity in cloud systems."

To be sure, there are undoubtedly opportunities for malicious activity within the cloud, which has its own share of complexities. A 2023 collaborative report by Check Point Software Technologies and Cybersecurity Insiders points to annual increases in attack attempts on cloud-based networks, needlessly complex and inadequate security policies, and insufficient and unsecure cloud configurations and interfaces as being drivers of security mishaps in the cloud. Additionally, given that cloud computing is internet-based (i.e., networked), a networking approach based on normal internet and network standards is not sufficient to address the complexities inherent to many cloud computing implementations. From integrating public and private clouds to meeting regulations mandating localized data storage, additional considerations must be made as to how best ensure standardized cloud services remain driven on solid security principles. With the transition to cloud, on-site data storage has moved online, with its own set of security nuances. Additionally, increased scalability, interfacing, and proximity to other networked data and systems adds more complexity to security. As complexity is added, a more standardized approach is called for. Just as the Cloud Native Computing Foundation's (CNCF's) Certified Kubernetes Conformance Program attempts to ensure a standardized conformance of all Kubernetes instances to the Kubernetes application programming interfaces (APIs) for consistency and interoperability across cloud platforms, standards organizations like the Institute of Electrical and Electronics Engineers (IEEE), International Organization for Standardization (ISO), and National Institute of Standards and Technology (NIST) develop standards and guidelines to ensure quality and security across all cloud computing platforms.

The next few sections examine the various organizations, agencies, and industries developing and promoting standards, guidelines, and recommendations that shape the proper use of cloud computing platforms. Note that you won't see much about laboratories and cloud computing in this chapter, as we pan outward and look at cloud standards and security from up high. We'll focus on how all this information relates to laboratories in the coming chapters.

2.1 Standards and regulations influencing cloud computing

Numerous organizations have taken up the mantle in developing and disseminating cloud compliance standards, guidelines, and recommendations since the late 2000s, some independently (e.g., the Storage Networking Industry Association) and others by government mandate (e.g., National Institute of Standards and Technology). Some organizations have tailored their content to a specific industry (e.g., PCI Security Standards Council and the financial industry), while others have focused on a sector of business (e.g., FedRAMP and the U.S. Federal government). As the development of these standards, guidelines, and recommendations has continued, the groundwork has been created for future updates. NIST's early work with its SP 500-293 NIST Cloud Computing Technology Roadmap, Volume I and II and SP 500-299 NIST Cloud Computing Security Reference Architecture (Figure 3) have gone on to further define a modern approach to categorizing, evaluating, comparing, and selecting cloud services. And those documents were influenced by even earlier work by the Cloud Security Alliance's Enterprise Architecture efforts.

The work to improve and expand upon existing standards continues today, even as new service models for cloud computing emerge. Examples of the prior mentioned and other organizations contributing to these efforts are shown in Table 3.

Table 3. Organizations that have developed and are developing cloud compliance standards, guidelines, recommendations, and frameworks
Organization	Description	Link to standards, etc.
Crown Commercial Services and G-Cloud	Though not a standards organization, the U.K. Crown Commercial Service's (CSS's) G-Cloud program and framework allows companies considering selling cloud-based services to the U.K. government to make their services available "through a front-end catalogue called the Digital Marketplace." The framework agreements place specific requirements on the various services being offered by the provider, and in return, the provider can bid on government opportunities without going through the full procurement process.	G-Cloud standards, etc.
DMTF	Formerly known as the Distributed Management Task Force, DMTF "creates open manageability standards spanning diverse emerging and traditional IT infrastructures." This includes cloud standards, virtualization standards, networking standards, and more.	DMTF standards, etc.
European Telecommunications Standards Institute	ETSI "supports the timely development, ratification and testing of globally applicable standards" for information and communications technology (ICT) hardware, software, and services.	ETSI standards, etc.
General Services Administration and FedRAMP	Though not a standards organization, the U.S. General Services Administration's (GSA's) FedRAMP program "provides a standardized approach to security authorizations for cloud service offerings" for the U.S. Federal government. FedRAMP "standardizes security requirements for the authorization and ongoing cybersecurity of cloud services" as authorized by a number of regulations and policies.	FedRAMP standards, etc.
IEEE Computer Society and IEEE Standards Association	The IEEE Cloud Computing Standards Committee, which is chartered "to promote the development of standards in all aspects of the cloud computing ecosystem," has four working groups that help develop cloud computing standards for the IEEE Standards Association.	IEEE SA standards, etc.
International Organization for Standardization (ISO)	The ISO is a primary global standards organization that has been developing a wide variety of standards for decades. Numerous cloud-computing standards have been published under International Classification for Standards (ICS) code 35.210.	ISO standards, etc.
International Telecommunication Union (ITU)	The ITU is the United Nation's specialized agency for information communication technologies (ICTs). Among their activities, the agency develops technical standards and facilitates international connectivity in communication networks. Many recommendation documents have been developed through its Telecommunication Standardization Sector (ITU-T), SG13 Study Group, including cloud computing recommendations (Y Series).	ITU-T standards, etc.
National Institute of Standards and Technology (NIST)	NIST is a U.S. Department of Commerce institute which focuses on scientific measurement and standardization. They have developed a numbers roadmaps, guidelines, and definitions through its SAJACC and NCCP initiatives.	NIST standards, etc.
OMG Cloud Working Group	Previously known as the Cloud Standards Customer Council (CSCC), OMG's Cloud Working Group (CWG) "publishes vendor-neutral guidance on important considerations for cloud computing adoption, highlighting standards, opportunities for standardization, cloud customer requirements, and best practices to foster an ecosystem of open, standards-based cloud computing technologies."	CWG standards, etc.
Open Grid Forum (OGF)	The OGF is "an open global community committed to driving the rapid evolution and adoption of modern advanced applied distributed computing, including cloud, grid and associated storage, networking and workflow methods."	OGF standards, etc.
Organization for the Advancement of Structured Information Standards (OASIS)	OASIS Open is a standards body that "offers projects—including open source projects—a path to standardization and de jure approval for reference in international policy and procurement."	OASIS Open standards, etc.
PCI Security Standards Council (PCI SSC)	PCI SSC "is a global forum that brings together payments industry stakeholders to develop and drive adoption of data security standards and resources for safe payments worldwide."	PCI SSC Open standards, etc.
Storage Networking Industry Association (SNIA)	SNIA develops and promotes "vendor-neutral architectures, standards, and educational services that facilitate the efficient management, movement, and security of information," including the Cloud Data Management Interface (CDMI) standard.	SNIA standards, etc.
The Open Group	This organization attempts "to capture, clarify, and integrate current and emerging requirements, establish standards and policies, and share best practices."	Open Group standards, etc.
TM Forum	This global alliance attempts "to collaboratively solve complex industry-wide challenges, deploy new services and create technology breakthroughs to accelerate change." As a result of this collaboration, several technical documents and guides related to cloud computing have been developed.	TM Forum standards, etc.

However, organizational standards, guidelines, and recommendations alone do not influence how cloud computing services can and should be implemented and operated. Regulatory bodies, legislative bodies, and government agencies also directly or indirectly have an impact on cloud service operations. In some cases, the law, regulation, or guidance coming from such bodies may not even mention "cloud computing," yet because they mandate how specific data and information can be managed, used, and distributed, they ultimately influence what a cloud service provider (CSP) does and how they do it. This can be observed by more than a few of the examples in Table 4. The California Consumer Privacy Act, for example, makes no mention of the word "cloud," but CSPs and cloud users alike must consider aspects of the regulation, e.g., what can and cannot be done with a consumer's information based on location of the stored information.

Table 4. Examples of some common regulations, recommendations, and guidance that shape the proper use of cloud-computing platforms
Regulation, recommendation, or guidance	Creator	Description	Link
California Consumer Privacy Act (CCPA)	The State of California	The CCPA "provides California consumers with a number of privacy protections, including right to access, delete, and opt-out of the 'sale' of their personal information." Cloud solutions such as Google Cloud attempt to help users meet CCPA obligations, as well as meet their own commitments.	Link
Cloud Computing Regulatory Framework (CCRF)	Kingdom of Saudi Arabia	The KSA's CCRF "is based on international best practices and governs the rights and obligations of cloud service providers (CSPs), individual customers, government entities and businesses." It is one of only a few existing cloud-specific regulatory frameworks created by a government.	Link
Cloud Security Principles	Government of the United Kingdom	The U.K. developed a collection of 14 Cloud Security Principles that "include important considerations such as protection of data in transit, supply chain security, identity and authentication, and secure use of cloud services." This is an example of a national government developing a cloud-specific set of guidance for its public sector.	Link
Federal Information Security Modernization Act of 2014 (FISMA)	United States Government	Amending the prior FISMA 2002, FISMA 2014 achieves several things, chief among them giving Federal government the ability to better respond to cybersecurity attacks on its departments and agencies. Compliance with FISMA means implementing "recommended information security controls for federal information systems as identified in the NIST SP 800-53."	Link
General Data Protection Regulation (GDPR)	European Union	The GDPR is a non-trivial regulatory hurdle with positive intentions, with the goal of strengthening personal data protection in Europe. The regulation "lays out specific requirements for businesses and organizations who are established in Europe or who serve users in Europe." Cloud vendors like Google may stipulate in their contracts with European clients how they meet that guidance, as well as offer tools, documentation, and other resources to assist with assessment of the vendor's services.	Link
Guidance on Outsourcing to Cloud Service Providers	Germany's Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin)	BaFin's Guidance document on cloud service outsourcing "provides specific outsourcing guidance for financial institutions on contractual terms, including information and audit rights, the right to issue instructions, data security / protection, termination and chain outsourcing." Cloud vendors like Google may stipulate in their contracts with German clients how they meet that guidance.	Link
Health Insurance Portability and Accountability Act (HIPAA)	United States Government	The HIPAA Rules "establish important protections for individually identifiable health information ..., including limitations on uses and disclosures of such information, safeguards against inappropriate uses and disclosures, and individuals’ rights with respect to their health information." HIPAA compliance is so vital for some organizations that U.S. government entities like the U.S. Department of Health & Human Services (HHS) have published their own guidance towards how HIPAA covered entities can best comply when using cloud services.	Link
Joint Statement: Security in a Cloud Computing Environment	Federal Financial Institutions Examination Council (FFIEC)	In this document, the FFIEC—an interagency group of federal and state banking regulators—addresses "the use of cloud computing services and security risk management principles in the financial services sector" and "highlights examples of risk management practices for a financial institution’s safe and sound use of cloud computing services and safeguards to protect customers’ sensitive information from risks that pose potential consumer harm."	Link
OMB Circular A-130, Managing Information as a Strategic Resource	United States Government	This (revised) Obama-era circular "establishes general policy for the planning, budgeting, governance, acquisition, and management of Federal information, personnel, equipment, funds, IT resources, and supporting infrastructure and services," including cloud services. In addition to FISMA, this circular supports the FedRAMP program and its standardized security requirements.	Link
Personal Data Protection Law (KVKK)	Government of Turkey	Turkey's KVKK (Kişisel Verileri Koruma Kanunu) "regulates the protection of personal data and outlines the obligations that entities and individuals dealing with personal data must comply with." It has significant relevancy to cloud computing efforts in the country.	Link
Protective Security Policy Framework	Australian Government	The PSPF "assists Australian Government entities to protect their people, information, and assets, both at home and overseas." It contains multiple statements about how cloud computing should be handled.	Link

While Big Tech was as early as 2010 asking the U.S. government to take a more proactive regulatory approach to cloud computing, actual direct regulation of cloud computing by the world's governments has been limited. This leads to complicated viewpoints about the value of regulation vs. its drawbacks. Yes, careful regulation can help ensure consistent, affordable, and secure access to cloud services and may even encourage organizations to adopt the technology. However, a headstrong approach to regulations for CSPs, without sector- and industry-specific considerations, may have unintended consequences, e.g., unduly raising compliance costs or forcing insufficient levels of access control on an entity.

At least in the U.S., lawmakers and regulators may soon be pressured to increase regulatory approaches to cloud computing. This may be driven by the increasingly concentrated nature of cloud services in a handful of tech giants, though at the same time hampered by the widely varying approaches to addressing cloud-related issues via policy and regulation at the national and international levels. First, the very nature of these cloud services—and the ever increasing criticality they attain—as centralized services ensures the regulatory eye will increasingly be placed upon those cloud vendors. In fact, discussion about and designation of cloud services as critical infrastructure is already occurring in earnest, as they have "become essential to the performance of a growing swath of other sectors that have not heretofore been massively dependent on centralized cloud functionalities, and hence vulnerable to their disruption." A 2023 Digital Forensic Research Lab report by Zuo et al. highlights this further by nodding to the U.S. government's designation of "critical infrastructure" sectors and how their loss would result in a "debilitating effect on security, national economic security, national public health or safety, or any combination of those matters." Their report argues that "the maturation of current [regulatory] policy tools, and creation of others," is vital going forward. These and other such spotlights may lead to policymakers, regulatory bodies, and legislators being left with little choice but to move forward with more policy and regulation.

Second, and consequently, the development of such policy and regulation may not occur in a manner more unified with global perceptions but rather largely based upon localized values, interests, and priorities. The failure here is the lack of recognition of CSPs as being integral to individual, retail, corporate, organizational, and government operations around the globe, i.e. their centralized and concentrated position within a changing computing paradigm. As such, greater effort must be made by policymakers, regulators, and legislatures to find at least a minimum level of "compatibility and reconciliation" with other existing governance mechanisms, while carefully addressing both security of operation and operational robustness in tandem, such that there is greater harmonization globally. And through government-level support of harmonized controls—as well as a vested interest in promoting the responsible "development, dissemination, and operation of cloud infrastructure"—cloud users will stand a greater chance of reaping the economic benefits of adopting cloud computing.

Current and future regulatory action applies to several areas of cloud computing. How a CSP responds to and notifies affected users of a security breach is one concern. Up until 2022, the U.S. government didn't fully address in a unified fashion aspects of cloud security breaches such as protection obligations, reporting time, and required notification parties, nor any compensation mechanism for those affected. (All U.S. states and most territories did already have their own flavor of breach notification legislation, but like cannabis law, this was problematic in the face of a strong divergence with federal law or lack thereof.) In March 2022, President Biden signed into law the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA), which requires covered entities to report substantial cybersecurity incidents and any paid ransom for ransomware attacks, with more scope and definition to come. While this addresses some of the prior-mentioned aspects, its thoroughness towards protection obligations and compensation remains lacking. A year later, however, cybersecurity thought leaders like Viakoo's CEO Bud Broomhead positively acknowledge CIRCIA as "not the destination ... but an important waypoint toward it," with other activities like the creation of the Joint Ransomware Task Forces and Ransomware Vulnerability Warning Pilot Program further promoting stronger federal efforts towards cloud security.

Other areas of cloud security also face regulatory action. For example, the applications and algorithms that drive and collect data from users of cloud-enabled applications may also face regulatory scrutiny or control by a national government, as was seen with both China's and the U.S.'s scrutiny of the TikTok application, its algorithms, and its security. Data localization also remains a significant area of cloud computing regulation, not just for security concerns but also industrial policy, economic policy, privacy concerns, and human rights concerns. Other areas of concern that may see regulation include interoperability and portability, digital preservation (retention) obligations, and cross-border data transfer.

And then there's the proverbial "elephant in the room": overall data privacy and protection considerations in the cloud. This is a major concern typically because of statutes—like the California Consumer Privacy Act—that broadly protect a collective of affected individuals and how their cloud data is collected, preserved, organized, stored, and used not only within the governing entity (e.g., state, country, political and economic union) but also as its transferred to and from the governing entity. The previously mentioned data localization and cross-border data transfer issues fall under this heading. These often prove to be some of the most challenging regulations to develop, as lawmakers and regulators don't always anticipate the rate of change of technology. They're also difficult for CSPs and organizations to comply with, particularly due to the variance in requirements among all governing entities' laws.

Other approaches to regulation also affect how cloud computing services are implemented and managed. For example, rather than taking a broad approach towards regulation, addressing everyone providing and/or using cloud services, it's possible that regulators and legislators may take a more focused, sector-based approach. But that comes with its own set of problems, as Maurer and Hinck noted in their 2020 Carnegie Endowment paper:

[T]he impact of a cloud security incident usually depends on what type of data or service is affected. Thus, the most suitable potential regulatory requirements with respect to security may differ across sectors that deal with different types of data—from the highly sensitive, fast-moving data common in the financial sector to the more privacy-sensitive personal data used by medical service providers. However, crafting regulation on a sector-by-sector basis would likely create conflicting requirements and incomplete standards.

Finally, as a third option, rather than direct regulation of the broad market or even specific sectors, some governments may simply use their considerable weight to influence how CSPs provide their services, influencing future regulation, as Levite and Kalwani note in their 2020 paper for the Carnegie Endowment:

Finally, some of the efforts to influence CSP behavior may not come through explicit regulation, but rather through exercise of the government’s market power. Cloud adoption strategies and trends in e-governance have made governments some of the largest and most important clients of CSPs. Governments will likely use their market clout and status as a large and powerful consumer as a source of leverage over industry to set standards of contracting fairness and other provisions that transcend the immediate cloud service contracts they enter. While formally these provisions will only apply to government contracts, they could over time cross over to public clouds as well, or at least help set precedents that drive regulatory attention and inform industry standards. Yet over the longer run, government privatization of many services might actually weaken their leverage, given lock-in issues. How the balance between the two parties ultimately will play out remains to be seen.

Whatever direction regulators and legislators continue take, it ideally will be done with thorough consideration of how to implement regulation, as well as the potential effects regulation will have on various markets.

2.2 Security in the cloud

For any organization, managing security is a challenging yet necessary part of operations. This includes deciding on and implementing physical controls like locks, alarms, and security staff, as well as IT controls like passwords, role-based access control, and firewalls. Much of this security is governed by standards, regulations, and common business practices. Yet while those standards, regulations, and practices also play a pivotal role in how cloud services should be rendered and managed, it would be foolish to forget the human element of cloud security. Employees, contractors, and other users who misconfigure cloud resources, fail to implement robust cloud security architecture, fail to practice proper identity and access management, fall for phishing and other account exploitation attacks, poorly design application programming interfaces (APIs), or maliciously access and sabotage resources all pose potential risk to the security of cloud-based system.

While these and other security concerns of CSPs are valid, concerns are beginning to shift more towards how the decisions of an organization’s senior management affect the human element within the organization using and managing cloud services. Fortunately, the traditional management-driven business approaches towards on-premises computing projects—getting management buy-in; developing goals, scope, and responsibility documentation; identifying computing requirements and objectives; identifying risk; documenting and training on processes and procedures; monitoring performance; and employing corrective action—still largely apply to cloud implementation and migration projects.

Yet cloud security should be viewed more holistically, as a combination of standards, technologies, policies, and people influencing the end results. This sentiment is reflected in Kaspersky Lab's definition of cloud security, as "the whole bundle of technology, protocols, and best practices that protect cloud computing environments, applications running in the cloud, and data held in the cloud." And as was suggested prior, addressing cloud security requires more than a narrow local networking-based cybersecurity approach. Maurer and Hinck noted in 2020 that "cloud security risks are different from other types of cybersecurity risks because cloud security is networked, concentrated, and shared." The networking is often spread across multiple locations and services; those services are concentrated with only a few major CSPs, with security disruptions having a much broader effect for many customers; and security is a shared responsibility for those services, spread across at least two parties, requiring clear delineation of responsibility for security. With the increased popularity of hybrid and multicloud, these networking challenges also increase complexity, which means more attention to security is required by not only the CSP but also the customer. Adopting security strategies such as the "zero trust" model, which assumes an attempted connection is untrustworthy until proven as trusted, increasingly make sense in these complex cloud environments. Requiring every user and device to verify first "helps security teams protect the enterprise against both sanctioned cloud deployments and shadow IT as well as cloud providers whose own embedded security isn’t as robust as the organization requires."

Additionally, through its recent work on the challenges of conducting digital forensics in the cloud, NIST also highlights data replication, location transparency, and multi-tenancy as "somewhat unique" challenges to cloud computing, and by extension digital forensics in the cloud. Though digital forensics isn't the primary topic of this guide, it's useful to mention because the process of cloud computing forensic science includes determinations of chain of custody, data integrity, and confidentiality status of cloud computing data, all critical considerations of using, storing, and transferring regulated, protected data in the cloud, especially for laboratories.

This all leads to the questions of responsibility: who is ultimately responsible for the security of any given cloud service? From a shallow point of view, it may be easy, as a customer, to consider a CSP and say "their service, their responsibility." However, it's more complicated than that. This brings us to the topic of the shared responsibility model.

2.2.1 The shared responsibility model

In December 2019, software as a service (SaaS) cannabis software firm THSuite was discovered to have inadvertently left an Amazon Web Services (AWS) S3 bucket unsecured and unencrypted, exposing the fine details of tens of thousands of medical and recreational cannabis users associated with three dispensary clients in the U.S. Given that protected health information (PHI) was included in the exposed data, serious privacy concerns and legal repercussions were raised in the aftermath of this security failure. Today, this inadvertent security failure highlights the shared responsibility model (occasionally referred to as the "shared security model"), a security model that clarifies elements of responsibility between the customer and the CSP.

With its August 2010 update to AWS' Amazon Web Services: Overview of Security Processes documentation, the concept of a "shared responsibility environment" was added. To be sure, the concept of "shared responsibility" appeared before AWS began including it in its cloud security processes, as can be evidenced by 2004 New York State cybersecurity guidance and 2004 Northwestern University IT protocol for data sharing. However, among cloud providers, Amazon arguably brought the concept fully into the world of cloud computing. In their 2010 documentation, they described AWS's shared responsibility environment as such:

An example of this shared responsibility would be that a customer utilizing Amazon EC2 should expect AWS to operate, manage and control the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. In this case the customer should assume responsibility and management of, but not limited to, the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. Customers should carefully consider the services they choose as their responsibilities vary depending on the services and their integration. It is possible for customers to enhance security and/or meet more stringent compliance requirements with the addition of items such as host based firewalls, host based intrusion detection/prevention, encryption and key management.

This statement has since evolved into a full-blown shared responsibility model that not only AWS includes today as an integral component of security-related agreements with clients, but also a model other public cloud service providers have adopted (see the next subsection for examples). Continuing to use AWS as an example, a clear shared security responsibility model differentiates "security of the cloud" and "security in the cloud." According to AWS, security of the cloud states that AWS is responsible for the "hardware, software, networking, and facilities that run AWS Cloud services." Security in the cloud addresses the customer responsibility, based upon the services selected, including client-side data encryption and data integrity authentication, firewall configurations, and platform and application identity and access management. In this way, operating the IT environment is shared in a clearly delineated fashion. Similarly, management, operation, and verification of IT controls are also shared, where the physical and environmental controls are the responsibility of AWS, customer-specific security controls are the responsibility of the customer, and some controls have shared responsibility between both AWS and the customer.

The concept of shared responsibility between a provider and a customer has woven its way into the fabric of most cloud-based services, from SaaS to multicloud. A trusted CSP will make this responsibility clear at every step of the way, from early contract discussions to late-stage changes to customer services. However, pressure also remains solidly on the organization seeking cloud services—including the organization’s legal counsel—when making decisions about contracting for cloud computing services. This includes understanding aspects of consent, security requirements, reporting requirements, and enforcement mechanisms of any laws and regulations in the organization’s operating governing entity (e.g., state, country, political and economic union), as well as in other external governing entities where related data may inevitably be transferred, stored, and managed. And, by extension, the organization will need to verify the provider is able to comply with—and provide mechanisms to help the organization comply with—those laws and regulations. This is typically done by examining the CSP's documented compliance certifications, attestations, alignments, and frameworks (see the next subsection for examples). This includes System and Organization Controls (SOC) 1, 2, and 3 reports (which provide independent third-party assurances about the effectiveness of a CSP's security controls), Federal Risk and Authorization Management Plan (FedRAMP) compliance, Coalition of Cloud Infrastructure Services Providers in Europe (CISPE) Code of Conduct compliance, and more.

The next subsections examine public cloud, hybrid cloud, multicloud, SaaS, and other cloud services in relation to cloud security, providing examples of major CSPs in those arenas.

2.2.2 Public cloud

"The public cloud services market has more than doubled since 2016," found International Data Corporation (IDC) in 2020, noting that "the worldwide public cloud services market, including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), grew 26.0% year over year in 2019, with revenues totaling $233.4 billion." In November 2020, Gartner predicted global public cloud computing spend would increase more than 18 percent in 2021, with PaaS growth leading the way due to remote workers needing more powerful, scalable infrastructure to complete their work. Gartner added that "survey data indicates that almost 70% of organizations using cloud services today plan to increase their cloud spending in the wake of the disruption caused by COVID-19." By 2023, Gartner was predicting $600 billion in end-user spend on public cloud.

These statistics highlight the continued transition and investment into the public cloud for organizations, and recent surveys of IT professionals appear to find a matching level of increased confidence in the public cloud. But as reliance on the public cloud continues to grow, organizations inevitably discover new security and networking challenges, including difficulties keeping services seamlessly available and scalable, and network costs more affordable while limiting complexity upticks, which makes security more difficult.

As of August 2023, the bulk of public cloud market share is represented by 10 companies: Alibaba, Amazon, DigitalOcean, Google, IBM, Linode, Microsoft, Oracle, OVH, and Tencent. From a security perspective, we have to ask at a minimum four questions about these companies:

• What are their compliance offerings?
• Where is their SOC 2 audit report?
• What is their shared responsibility model?
• What is their architecture framework based upon?

In this context, compliance offerings are the documented compliance certifications, attestations, alignments, and frameworks a public CSP boasts as part of an effort maintain security and compliance for their cloud services. Each of the seven public CSPs has a landing page introducing customers to those compliance offerings (Table 5), though some vendors' pages are more clearly organized than others. Each offering then links off to another page, document, or related certificate explaining compliance. In particular, the SOC 2 audit report should be viewed, though most providers require you to be a customer or inquire with their sales department to obtain it. The SOC 2 audit results outline nearly 200 aspects of a CSP's security, as audited by an independent third party, providing the closest look one can get to a CSP's ability to assist with regulatory compliance (more on this in Chapter 4). As previously discussed, a shared responsibility (or shared security) model is the common approach to clarifying who's responsible for what portions of security, and each CSP has indicated somewhere what that model is. (In the case of Tencent, it's unfortunately buried in a 2019 white paper.) Public CSPs also provide some sort of "architecture framework," though this varies from provider to provider. For example, AWS and Google Cloud provide a framework that allows customers to stably and efficiently deploy in the cloud based on both best practices and the organization's unique requirements. Linode, Oracle, and Tencent don't seem to offer this type of framework for customers but still discuss their overall cloud architecture in a broad manner. See Table 5 for links to these four security research aspects for each public CSP.

Table 5. Public cloud providers and their compliance offerings, SOC 2 report, shared responsibility model, and architecture framework Company and offering Compliance offerings SOC 2 report Shared responsibility model Architecture framework Akamai (formerly Linode) Link Unknown (Presumably must be customer/contact sales to access) Link Link Alibaba Cloud Link Link (Must be customer/contact sales to access) Link Link Amazon Web Services Link Link (Must be customer/contact sales to access) Link Link DigitalOcean Link Link (Must email company to access) Link Link Google Cloud Link Link Link Link IBM Cloud Link Link (Must be customer/contact sales to access) Link Link Microsoft Azure Link Link (Must be customer/contact sales to access) Link Link Oracle Cloud Infrastructure Link Unknown (Presumably must be customer/contact sales to access) Link Link OVHcloud Link Link (Must be customer/contact sales or legal to access) Link Link Tencent Cloud Link Unknown (Presumably must be customer/contact sales to access) Link Link

Chapter 1 noted that for public cloud services, organizations tied to strong regulatory or security standards "... must thoroughly vet the cloud vendor and its approach to security and compliance, as the provider may not be able to meet regulatory needs." For example, public CSPs will allow you to enter into a Health Insurance Portability and Accountability Act (HIPAA)-compliant business associate agreement (BAA) with them, as required by the U.S. Department of Health & Human Services, but that does not mean you'd be running in a HIPAA-compliant fashion. If your organization is handling PHI protected by HIPAA, that organization is still responsible for having internal compliance programs and documented processes that support HIPAA, while also using the CSP's services in ways that align with HIPAA. That includes ensuring that the services your organization will utilize are indeed in-scope with HIPAA and other such regulations; not all services offered by a CSP are in-scope to a specific regulation. The BAA should make clear which services are covered for handling PHI and other sensitive or critical information. Additionally, your organization will still need to ensure the correct technical security controls are implemented to ensure compliance. Remember, you're working under the shared responsibility model.

2.2.3 Hybrid cloud and multicloud

The Flexera 2020 State of the Cloud Report and its associated survey found that 87 percent of respondents had already taken a hybrid cloud stance for their organization and 93 percent of respondents had already implemented a multicloud strategy within their organization. A 2020 report by IDC predicted 90 percent of enterprises around the world will be relying on some combination of hybrid or multicloud with existing legacy platforms by 2022, though they may not necessarily have a sufficient investment in in-house skills to navigate the complexities of rolling out those strategies. These complexities were discussed in Chapter 1; hybrid cloud reveals a greater attack surface, complicates security protocols, and raises integration costs, while multicloud brings with it differences in technologies between vendors, latency complexities between the services, increased points of attack with more integrations, and load balancing issues between the services. Broadly speaking, these complexities and security challenges arise out of the fact more systems must be integrated. Given these complexities, it's interesting to note that Flexera's survey numbers concerning hybrid/multicloud adoption have been going down since the 2020 report: in 2022 hybrid/multicloud adoption went down to 80/89 percent respectively, and in 2023 those numbers were down to 72/87 percent respectively. Comparing the survey results, single public cloud and multiple public cloud adoption has seen increases, taking away from hybrid cloud adoption significantly and multicloud adoption slightly (Table 6). This noticeable slowdown in more complex hybrid adoption for relatively "simpler" single and multiple public cloud options may be the result of a mix of hyper-expansion of complex cloud adoption coming to a close and cost-cutting and optimization efforts by cloud customers due to emerging "economic realities."

Table 6. Flexera State of the Cloud Report results for 2020, 2022, and 2023, comparing types of cloud adoption Year Single public Single private Multicloud → Multiple public Multiple private Hybrid 2020 6% 1% 93% 6% 0% 87% 2022 9% 2% 89% 7% 2% 80% 2023 11% 2% 87% 13% 2% 72%

As of August 2023, four providers of hybrid and multicloud technology and services stand out: Cisco, Dell, HPE, and VMware. These providers don't provide public cloud services but rather take a service-based approach to supplying hardware, software, and managed services to assist customers adopt a hybrid or multicloud approach for their business. From a security perspective, we have to ask at a minimum three questions about these companies:

• How do they manage your data and security in a trustworthy way?
• How are cloud technologies and services developed and audited for security?
• What public CSPs do they publicly state their technologies and services support or integrate with?

In this context of trust, these companies should have a "trust center" that helps consumers and enterprises find answers to security questions about their cloud technologies and services. A trust center was found for three of the four CSPs; HPE's trust center could not be located. Whether through internal secure development processes or external auditing practices, the security of the technology and services offered by these providers remains vital, and they should be able to demonstrate by explaining their development and auditing processes. Additionally, hybrid and multicloud providers should make clear which public CSPs are supported for or integrated ideally with the provider's hybrid and multicloud services. Not all public clouds are fully supported by these providers. See Table 7 for links to these three security and interoperability aspects for each hybrid/multicloud CSP.

Table 7. Providers of hybrid and multicloud technology and services, their trust center, their development and auditing practices, and supported public clouds Company and offering Trust center Development and auditing practices Public clouds supported (U.S.) Cisco CloudCenter and UCS Director (Note: CloudCenter becomes obsolete May 31, 2024.) Link Cisco was "evaluating SOC 2 as a potential roadmap item" for CloudCenter in 2019. Alibaba, Amazon, Google, IBM, Microsoft Dell Technologies APEX Link Link Alibaba, Amazon, Google, IBM, Microsoft HPE GreenLake Unknown Unknown Amazon, Google, Microsoft VMware Cloud Link Link (Must be customer/contact sales to access) Amazon, Google, IBM, Microsoft, Oracle

Managing your share of security in the hybrid cloud has several challenges. Most of those challenges involve attempting to manage and control multiple distributed systems. Giving administrators the ability to see into this complex network of components, at all levels, is critical. This is typically accomplished with a centralized management tool or platform based on open standards, providing automated management and control features that limit human error. Automation is also useful when scanning for and remediating problems detected with security controls, which in turn allows for documented changes and more reproducible processes. Disk encryption and network encryption tools may also need to be more robustly employed to protect data at rest and data in motion between private and public clouds. And of course, segmentation of services based on data sensitivity may be necessary.

Multicloud has its issues as well. "The challenge that multicloud presents to security teams continues to grow," said Protiviti cloud consultant Rand Armknecht in December 2020. "The number of services that are being released, the new ways of interacting, the interconnecting of services and systems, all of that continues to advance and all of these add new complexities into the enterprise security model." Given the differences in tools and security approaches between cloud providers, stitching together services cohesively requires strong skills, knowledge, and attentiveness. It also requires a security strategy that is well-defined and unified in its approach to data management, minimization, anonymization, and encryption when considering multiple CSPs. Middleware placed between the enterprise and the CSP—in some cases referred to as a cloud access security broker (CASB)—that can "consolidate and enforce security measures such as authentication, credential mapping, device profiling, encryption and malware detection" adds an additional layer of semi-automated security for multicloud.

2.2.4 Container security and other concerns

Before we move on to discussing SaaS solutions, let's take a quick moment to recognize a few additional security peculiarities particular to using cloud services and developing in the cloud. These peculiarities may not apply to you and your organization, but it's useful to recognize them, if nothing else because they highlight how deeply woven security must be into the thinking of CSPs and their clients.

First, let's look at container security. In Chapter 1, a container was referred to as "a complete runtime environment," but little else was said. In cloud computing, a container—as defined by IBM—is "an executable unit of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on desktop, traditional IT, or the cloud." These prove beneficial in cloud computing because containers act as a lightweight, portable way of replicating an isolated application across different environments, independent of operating system and underlying hardware. This essentially makes deployment into a cloud environment—or multiple clouds—a much more approachable task.

But with convenience also comes responsibility towards ensuring the security of the container. Unfortunately, the necessary precautions don't always get taken. According to GitLab's 2020 Global DevSecOps Survey, "56% of developers simply don’t run container scans, and a majority of DevOps teams don’t have a security plan in place for containers or many other cutting edge software technologies, including cloud native/serverless, APIs, and microservices." While GitLab reported that container scans were fortunately becoming more common in 2022, it would still appear more implementation teams should be updating and implementing revised security plans to address the complexities of container security, including the use of container orchestration, image validation, role-based access management, security testing, and runtime security monitoring. NIST's SP 800-190 Application Container Security Guide, while slightly dated, provides a useful reference for more on the topic of container security.

Some concerns also exist within the virtualization environment, which drives cloud computing. The virtualized environment allows containers to be implemented, but their smooth use depends on a virtualization component called a virtual machine monitor (VMM) or hypervisor, which acts as the "management layer between the physical hardware and the virtual machines running above" it, managing system resource allocation to virtual machines—and by extension, containers—in the virtual environment. Since hypervisors are shared in a virtualized environment, a compromised hypervisor (say through a malware attack or a means of gaining root privileges) puts the virtual machines running off the hypervisor at risk, and by extension any data running on those virtual machines. Limiting the risks to a hypervisor and its associated virtualized machines means ensuring de facto encryption is in place to protect copied images and other files, migrated virtual machines are protected at all points along the migration route, and proper encryption and key management mechanisms are in place for effective access management. While the concerns of hypervisor security are largely the responsibility of the public CSPs (Microsoft, for example, touts a multi-layer approach to securing its hypervisors in Azure), those running private clouds will have to be sure their attention given to hypervisor security is similarly strong.

Other areas of security concern are found in the overall networking of a cloud. There, attention to the various layers of firewalls, network traffic controls, transport-level encryption mechanisms, and encapsulation protocols is also recommended.

2.2.5 Software as a service

Finally, we address security when using SaaS. Though not the laboratory space, let's take a look at the financial sector to start. Like laboratories, banks are regulated not only to protect their own assets but also the assets of their customers, including customer data. Given the concerns about security in the cloud early in its history, it has taken some time for the financial sector to warm up to moving some of its functions into the cloud. However, since approximately 2016, banks and financial services firms have begun shifting to the cloud in droves. Writing for the World Economic Forum in December 2020, the CEO of Tenemos, Max Chuard, noted:

Cloud and SaaS present an alternative way of running a bank’s IT infrastructure. Core banking and/or the digital front office operates on a public or private cloud rather than on physical infrastructure in the bank’s premises. Banks pay a subscription to access the solutions. Both cloud and SaaS carries lower infrastructure costs, they allow products to be created, delivered and changed faster, and they offer immense resilience, scalability, and security. Cloud-based SaaS platforms are also continuously updated, meaning banks benefit from the latest innovations.

However, the improved security of cloud and SaaS does not preclude challenges. In the case of financial services firms, finding a balance between client-side encryption to protect financial data and its tendency to constrain overall performance and functionality is a real challenge. And that same challenge exists for other regulated (and less regulated) organizations turning to SaaS cloud solutions.

When moving to a SaaS-based approach to running critical systems, the shared responsibility paradigm says that both CSP and customer should be managing SaaS security. Are access and audit rights in the SaaS implementation as strong as they should be? How is data managed and processed in relation to location requirements? How are risks mitigated if the vendor goes out of business or changes its operational focus? What contingency plans are in place should the organization need to migrate to a new vendor or bring applications back in-house? What assessments and audits have been made of the CSP's security? (These and other questions are addressed further in Chapter 5.)

In 2018, Moody's Analytics pointed out "seven pillars of SaaS security wisdom." While they were looking at these pillars from the perspective of banks and financing, they are equally applicable to any regulated organization moving to SaaS cloud solutions, including laboratories. Those SaaS security pillars are:

1. Access management: Carefully control user access uniformly across the SaaS platform, using strong, vetted business rules (addressing user roles, data requirements, allowed system, allowed workflows, etc.) that have been documented, disseminated, and learned.

2. Network control: Decide what network mechanisms to employ in order to meet security goals, including jump servers, network access control lists, etc. if more granular access control is required.

3. Perimeter network control: Decide whether a simple firewall or set of firewalls is sufficient. Additional perimeter protections include intrusion detection and prevention systems.

4. Virtual machine management: Recognize that while costly, keeping virtual machines up-to-date is vital. Whether this is your responsibility or the CSP's, staying on top of patches and updates better ensures protection from the latest threats.

5. Data protection: Determine if the data encryption is sufficient for your regulatory needs to protect personally identifiable information. Best practices and standards should be guiding the endeavor to protect both data in transit and data at rest.

6. Data governance and incident management: Decide how data governance policies dictate your SaaS services. Data governance determines who has the authority to manage and control data assets and how authorized individuals are able to use those data assets. Not only does this also guide the first pillar, access management, but it also clarifies responsibilities for data management and security. This includes stating who's responsible for incident management and how the organization will go about monitoring, tracking, reporting, and learning from security incidents.

7. Scalability and reliability: Determine how scalable the underlying cloud infrastructure will be to run your SaaS applications. Is it horizontal or vertical scaling? Are proxy servers geographically distributed for a more robust service? And what assurances are in place should disaster strike (i.e., recovery plan)?

Like public, hybrid, and multicloud cloud services, SaaS vendors should make clear the security aspects of their solutions. Most major vendors like SAP, Adobe, and Atlassian will have a trust center for customers to gauge how the vendor's SaaS products are managed in reference to security and compliance. Some SaaS software vendors, however, will host and manage their solutions in a public cloud. Those SaaS vendors should have at a minimum one or more web pages explaining where their solution is hosted, what security controls are in place with that public cloud provider, and what additional security controls, if any, the vendor applies. Of course, access management and other security controls are still very much the responsibility of the customer.

References

-----Go to the next chapter of this guide-----

Citation information for this chapter

Chapter: 2. Standards and security in the cloud

Title: Choosing and Implementing a Cloud-based Service for Your Laboratory

Edition: Second edition

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: August 2023