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

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
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.  
Finally, we address security when using SaaS. Though not exactly 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.<ref name="MoodysBest18">{{cite web |url=https://www.moodysanalytics.com/articles/2018/best-practices-for-saas-security |title=Best Practices for SaaS Security |work=Moody's Analytics |publisher=Moody's Analytics, Inc |date=April 2018 |accessdate=21 August 2021}}</ref> However, since approximately 2016, banks and financial services firms have begun shifting to the cloud in droves.<ref name="DeloitteCloud19">{{cite web |url=https://www2.deloitte.com/global/en/pages/financial-services/articles/bank-2030-financial-services-cloud.html |title=Cloud banking: More than just a CIO conversation |publisher=Deloitte |date=2019 |accessdate=21 August 2021}}</ref> Writing for the World Economic Forum in December 2020, the CEO of Tenemos, Max Chuard, noted<ref name="ChuardCloud20">{{cite web |url=https://www.weforum.org/agenda/2020/12/cloud-and-saas-technology-can-drive-inclusive-banking/ |title=Cloud and SaaS technology can drive inclusive banking. Here are 3 reasons how |author=Chuard, M. |work=World Economic Forum |date=10 December 2020 |accessdate=21 August 2021}}</ref>:


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."<ref name="IBMContainers19">{{cite web |url=https://www.ibm.com/cloud/learn/containers |title=Containers |author=IBM Cloud Education |publisher=IBM |date=12 August 2019 |accessdate=21 August 2021}}</ref> 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.<ref name="GoogleContainers">{{cite web |url=https://cloud.google.com/containers |title=Containers at Google |publisher=Google Cloud |accessdate=21 August 2021}}</ref>
<blockquote>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.


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."<ref name="GLABegin">{{cite web |url=https://about.gitlab.com/topics/application-security/beginners-guide-to-container-security/ |title=A beginner’s guide to container security |work=GitLab |accessdate=21 August 2021}}</ref> As such, it would 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.<ref name="GLABegin" /><ref name="NIST800-190_17">{{cite web |url=https://csrc.nist.gov/publications/detail/sp/800-190/final |title=SP 800-190 ''Application Container Security Guide'' |author=Souppaya, M.; Morello, J.; Scarfone, K. |publisher=NIST |date=September 2017 |accessdate=21 August 2021}}</ref>
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.</blockquote>


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.<ref name="BarrowcloughSecuring18">{{cite journal |title=Securing Cloud Hypervisors: A Survey of the Threats, Vulnerabilities, and Countermeasures |journal=Security and Communication Networks |author=Barrowclough, J.P.; Asif, R. |volume=2018 |at=1681908 |year=2018 |doi=10.1155/2018/1681908}}</ref> 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.<ref name="BarrowcloughSecuring18" /> 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.<ref name="BarrowcloughSecuring18" /> 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<ref name="SharmaHypervisor20">{{cite web |url=https://docs.microsoft.com/en-us/azure/security/fundamentals/hypervisor |title=Hypervisor security on the Azure fleet |author=Sharma, Y.; Lyon, R.; Lanfear, T. |work=Microsoft Documentation |publisher=Microsoft |date=10 November 2020 |accessdate=21 August 2021}}</ref>), those running private clouds will have to be sure their attention given to hypervisor security is similarly strong.
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.<ref name="DeloitteGetting19">{{cite web |url=https://www2.deloitte.com/content/dam/Deloitte/ch/Documents/financial-services/deloitte-ch-fs-Cloud-for-Swiss-Banks-report-digital.pdf |format=PDF |title=Getting cloud right: How can banks stay ahead of the curve? |publisher=Deloitte |date=2019 |accessdate=21 August 2021}}</ref> And that same challenge exists for other regulated (and less regulated) organizations turning to SaaS cloud solutions.


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.<ref name="BoydAchieving18">{{cite web |url=https://www.sdxcentral.com/cloud/definitions/achieving-network-security-in-cloud-computing/ |title=Achieving Network Security in Cloud Computing |author=Boyd, N. |work=Cloud HQ |publisher=SDxCentral, LLC |date=20 July 2018 |accessdate=21 August 2021}}</ref>
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?<ref name="MoodysBest18" /> (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<ref name="MoodysBest18" />:
 
: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.<ref name="OlavsrudWhatIs21">{{cite web |url=https://www.cio.com/article/3521011/what-is-data-governance-a-best-practices-framework-for-managing-data-assets.html |title=What is data governance? A best practices framework for managing data assets |author=Olavsrud, T. |work=CIO |date=18 March 2021 |accessdate=21 August 2021}}</ref> 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. Most major vendors like SAP<ref name=SAPTrustCenter">{{cite web |url=https://www.sap.com/about/trust-center/certification-compliance.html |title=SAP Trust Center |publisher=SAP America, Inc |accessdate=21 August 2021}}</ref>, Adobe<ref name="AdobeTrustCenter">{{cite web |url=https://www.adobe.com/trust.html |title=Adobe Trust Center |publisher=Adobe, Inc |accessdate=21 August 2021}}</ref>, and Atlassian<ref name="AtlassianTrustCenter">{{cite web |url=https://www.atlassian.com/trust |title=Atlassian Trust Center |publisher=Atlassian, Inc |accessdate=21 August 2021}}</ref> 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==
==References==
{{Reflist|colwidth=30em}}
{{Reflist|colwidth=30em}}

Revision as of 19:08, 21 August 2021

Finally, we address security when using SaaS. Though not exactly 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.[1] However, since approximately 2016, banks and financial services firms have begun shifting to the cloud in droves.[2] Writing for the World Economic Forum in December 2020, the CEO of Tenemos, Max Chuard, noted[3]:

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.[4] 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?[1] (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]:

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.[5] 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. Most major vendors like SAP[6], Adobe[7], and Atlassian[8] 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

  1. ↑ 1.0 1.1 1.2 "Best Practices for SaaS Security". Moody's Analytics. Moody's Analytics, Inc. April 2018. https://www.moodysanalytics.com/articles/2018/best-practices-for-saas-security. Retrieved 21 August 2021. 
  2. ↑ "Cloud banking: More than just a CIO conversation". Deloitte. 2019. https://www2.deloitte.com/global/en/pages/financial-services/articles/bank-2030-financial-services-cloud.html. Retrieved 21 August 2021. 
  3. ↑ Chuard, M. (10 December 2020). "Cloud and SaaS technology can drive inclusive banking. Here are 3 reasons how". World Economic Forum. https://www.weforum.org/agenda/2020/12/cloud-and-saas-technology-can-drive-inclusive-banking/. Retrieved 21 August 2021. 
  4. ↑ "Getting cloud right: How can banks stay ahead of the curve?" (PDF). Deloitte. 2019. https://www2.deloitte.com/content/dam/Deloitte/ch/Documents/financial-services/deloitte-ch-fs-Cloud-for-Swiss-Banks-report-digital.pdf. Retrieved 21 August 2021. 
  5. ↑ Olavsrud, T. (18 March 2021). "What is data governance? A best practices framework for managing data assets". CIO. https://www.cio.com/article/3521011/what-is-data-governance-a-best-practices-framework-for-managing-data-assets.html. Retrieved 21 August 2021. 
  6. ↑ "SAP Trust Center". SAP America, Inc. https://www.sap.com/about/trust-center/certification-compliance.html. Retrieved 21 August 2021. 
  7. ↑ "Adobe Trust Center". Adobe, Inc. https://www.adobe.com/trust.html. Retrieved 21 August 2021. 
  8. ↑ "Atlassian Trust Center". Atlassian, Inc. https://www.atlassian.com/trust. Retrieved 21 August 2021. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel45&oldid=43764"