Difference between revisions of "User:Shawndouglas/sandbox/sublevel45"

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
[[File:Virtual data room.png|right|500px]]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 interface]]s (APIs), or maliciously access and sabotage resources all pose potential risk to the security of cloud-based system.<ref name="CSATop20">{{cite web |url=https://cloudsecurityalliance.org/download/artifacts/top-threats-to-cloud-computing-egregious-eleven/ |format=PDF |title=Top Threats to Cloud Computing: The Egregious 11 |author=Cloud Security Alliance |date=2020 |accessdate=21 August 2021}}</ref>  
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.<ref name="MuncasterData20">{{cite web |url=https://www.infosecurity-magazine.com/news/data-30000-cannabis-users-exposed/ |title=Data on 30,000 Cannabis Users Exposed in Cloud Leak |author=Muncaster, P. |work=Infosecurity |date=23 January 2020 |accessdate=21 August 2021}}</ref><ref name="TrendmicroUnsec20">{{cite web |url=https://www.trendmicro.com/vinfo/dk/security/news/virtualization-and-cloud/unsecured-aws-s3-bucket-found-leaking-data-of-over-30k-cannabis-dispensary-customers |title=Unsecured AWS S3 Bucket Found Leaking Data of Over 30K Cannabis Dispensary Customers |publisher=Trend Micro, Inc |date=27 January 2020 |accessdate=21 August 2021}}</ref> 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.


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.<ref name="CSATop20" /> 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<ref name="DouglasComp20">{{cite web |url=https://www.limswiki.org/index.php/LII:Comprehensive_Guide_to_Developing_and_Implementing_a_Cybersecurity_Plan |title=Comprehensive Guide to Developing and Implementing a Cybersecurity Plan |author=Douglas, S. |work=LIMSwiki |date=July 2020 |accessdate=21 August 2021}}</ref>—still largely apply to cloud implementation and migration projects.<ref name="KearnsPlanning17">{{cite web |url=https://www.mitre.org/publications/technical-papers/planning-management-methods-for-migration-to-a-cloud-environment |title=Planning & Management Methods for Migration to a Cloud Environment |author=Kearns, D.K. |publisher=The MITRE Corporation |date=December 2017 |accessdate=21 August 2021}}</ref><ref name="SheppardManaging15">{{cite web |url=https://www.itworldcanada.com/blog/managing-a-cloud-computing-project/374832 |title=Managing a cloud computing project |author=Sheppard, D. |work=IT World Canada |date=28 May 2015 |accessdate=21 August 2021}}</ref>
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<ref name="NYSCyber04">{{cite web |url=https://www.gc.cuny.edu/CUNY_GC/media/CUNY-Graduate-Center/PDF/Policies/IT/Cyber-Security-Dos-and-Don%E2%80%99ts.pdf?ext=.pdf |format=PDF |title=Cyber Security Dos and Don'ts |publisher=New York State Office of Information Technology and Services |date=12 December 2004 |accessdate=21 August 2021}}</ref> and 2004 Northwestern University IT protocol for data sharing.<ref name="NUProtocol04">{{cite web |url=https://www.it.northwestern.edu/bin/docs/ExchangeSharedResponsibilityData.pdf |format=PDF |title=Protocol for Exchange and Shared Responsibility for Institutional Data |publisher=Northwestern University |date=15 August 2004 |accessdate=21 August 2021}}</ref> 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<ref name="AWSAmazonWeb10">{{cite web |url=http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf |archiveurl=https://web.archive.org/web/20100823123605/http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf |format=PDF |title=Amazon Web Services: Overview of Security Processes |author=Amazon Web Services |publisher=Amazon Web Services |date=August 2010 |archivedate=23 August 2010 |accessdate=21 August 2021}}</ref>:


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."<ref name="KasperskyWhatIs">{{cite web |url=https://usa.kaspersky.com/resource-center/definitions/what-is-cloud-security |title=What is Cloud Security? |work=Resource Center |publisher=AO Kaspersky Lab |date=2021 |accessdate=21 August 2021}}</ref> 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."<ref name="MaurerCloud20">{{cite web |url=https://carnegieendowment.org/2020/08/31/cloud-security-primer-for-policymakers-pub-82597 |title=Cloud Security: A Primer for Policymakers |author=Maurer, T.; Hinck, G. |publisher=Carnegie Endowment for International Peace |date=31 August 2020 |accessdate=21 August 2021}}</ref> 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.<ref name="MaurerCloud20" /> 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."<ref name="PrattBuilding20">{{cite web |url=https://www.csoonline.com/article/3584735/building-stronger-multicloud-security-3-key-elements.html |title=Building stronger multicloud security: 3 key elements |author=Pratt, M.K. |work=CSO |date=14 December 2020 |accessdate=21 August 2021}}</ref>
<blockquote>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.</blockquote>


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<ref name="HermanNISTCloud20">{{cite web |url=https://csrc.nist.gov/publications/detail/nistir/8006/final |title=NISTIR 8006 NIST Cloud Computing Forensic Science Challenges |author=Herman, M.; Iorga, M.; Salim, A.M. et al. |publisher=NIST |date=August 2020 |accessdate=21 August 2021}}</ref>, all critical considerations of using, storing, and transferring regulated, protected data in the cloud, especially for laboratories.
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."<ref name="AWSSharedRespon21">{{cite web |url=https://aws.amazon.com/compliance/shared-responsibility-model/?ref=wellarchitected |title=Shared Responsibility Model |author=Amazon Web Services |publisher=Amazon Web Services |date=2021 |accessdate=21 August 2021}}</ref> 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.<ref name="AWSSharedRespon21" />


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.
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.<ref name="EusticeUnder18" /> 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)<ref name="MealusTheSOC18">{{cite web |url=https://medium.com/@paulmealus/the-soc-2-report-explained-for-normal-people-50b4626d6c96 |title=The SOC 2 Report Explained for Normal People |author=Mealus, P. |work=Medium |date=19 December 2018 |accessdate=21 August 2021}}</ref>, Federal Risk and Authorization Management Plan (FedRAMP) compliance<ref name="ETSIAbout" />, Coalition of Cloud Infrastructure Services Providers in Europe (CISPE) Code of Conduct compliance<ref name=AWSCISPE">{{cite web |url=https://aws.amazon.com/compliance/cispe/ |title=CISPE |publisher=Amazon Web Services |accessdate=21 August 2021}}</ref>, 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.


==References==
==References==
{{Reflist|colwidth=30em}}
{{Reflist|colwidth=30em}}

Revision as of 18:59, 21 August 2021

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.[1][2] 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[3] and 2004 Northwestern University IT protocol for data sharing.[4] 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[5]:

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."[6] 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.[6]

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.[7] 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)[8], Federal Risk and Authorization Management Plan (FedRAMP) compliance[9], Coalition of Cloud Infrastructure Services Providers in Europe (CISPE) Code of Conduct compliance[10], 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.

References

  1. ↑ Muncaster, P. (23 January 2020). "Data on 30,000 Cannabis Users Exposed in Cloud Leak". Infosecurity. https://www.infosecurity-magazine.com/news/data-30000-cannabis-users-exposed/. Retrieved 21 August 2021. 
  2. ↑ "Unsecured AWS S3 Bucket Found Leaking Data of Over 30K Cannabis Dispensary Customers". Trend Micro, Inc. 27 January 2020. https://www.trendmicro.com/vinfo/dk/security/news/virtualization-and-cloud/unsecured-aws-s3-bucket-found-leaking-data-of-over-30k-cannabis-dispensary-customers. Retrieved 21 August 2021. 
  3. ↑ "Cyber Security Dos and Don'ts" (PDF). New York State Office of Information Technology and Services. 12 December 2004. https://www.gc.cuny.edu/CUNY_GC/media/CUNY-Graduate-Center/PDF/Policies/IT/Cyber-Security-Dos-and-Don%E2%80%99ts.pdf?ext=.pdf. Retrieved 21 August 2021. 
  4. ↑ "Protocol for Exchange and Shared Responsibility for Institutional Data" (PDF). Northwestern University. 15 August 2004. https://www.it.northwestern.edu/bin/docs/ExchangeSharedResponsibilityData.pdf. Retrieved 21 August 2021. 
  5. ↑ Amazon Web Services (August 2010). "Amazon Web Services: Overview of Security Processes" (PDF). Amazon Web Services. Archived from the original on 23 August 2010. https://web.archive.org/web/20100823123605/http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf. Retrieved 21 August 2021. 
  6. ↑ 6.0 6.1 Amazon Web Services (2021). "Shared Responsibility Model". Amazon Web Services. https://aws.amazon.com/compliance/shared-responsibility-model/?ref=wellarchitected. Retrieved 21 August 2021. 
  7. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named EusticeUnder18
  8. ↑ Mealus, P. (19 December 2018). "The SOC 2 Report Explained for Normal People". Medium. https://medium.com/@paulmealus/the-soc-2-report-explained-for-normal-people-50b4626d6c96. Retrieved 21 August 2021. 
  9. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named ETSIAbout
  10. ↑ "CISPE". Amazon Web Services. https://aws.amazon.com/compliance/cispe/. Retrieved 21 August 2021. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel45&oldid=43759"