{"id":97628,"date":"2019-03-14T06:00:47","date_gmt":"2019-03-14T13:00:47","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=97628"},"modified":"2019-05-06T15:31:57","modified_gmt":"2019-05-06T22:31:57","slug":"stay-secure-multi-cloud-environment","status":"publish","type":"post","link":"https:\/\/www2.paloaltonetworks.com\/blog\/2019\/03\/stay-secure-multi-cloud-environment\/","title":{"rendered":"How to Stay Secure in a Multi-Cloud Environment"},"content":{"rendered":"

\"Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. The trick is to reduce your risk of exposure regardless of the products or patches.\u201d<\/em><\/p>\n

\u00a0\u2013 Bruce Schneier<\/em><\/p>\n

\u00a0<\/em><\/p>\n

Bruce Schneier<\/a>\u00a0penned these\u00a0insightful words<\/a>\u00a0in April of 2000. Scroll forward 19 years and we now find ourselves in a world where disruption and innovation are a daily occurrence due to the low barriers to entry created by public cloud. How do security leaders design a strategy that effectively addresses the processes and tools required to manage\u00a0the new risks and threats\u00a0cloud presents?<\/p>\n

First, let\u2019s start with a definition of what we mean by multi-cloud. When we say \u201cmulti-cloud\u201d we simply mean the parallel usage of two or more cloud service provider (CSP) platforms. And \u201ccloud\u201d generally describes a computing platform that falls into three categories: IaaS, PaaS & SaaS. While each of these represent their own unique security challenges, we\u2019ll stay laser focused on IaaS & PaaS where there are currently three ruling titans: Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.<\/p>\n

 <\/p>\n

Challenges of a Multi-Cloud Environment<\/strong><\/p>\n

In our conversations with clients there is almost always one universal thread no matter where they are in their cloud journey: how do we enable the business to operate with freedom in the cloud but also put the proper guardrails in place to prevent them from taking unnecessary risks?<\/em><\/p>\n

We believe a fundamental understanding of the shared responsibility model<\/a>\u00a0is key as this is the main differentiator when compared to legacy on-prem environments. Once this model is understood and clearly documented and agreed to in an organizational\u00a0RACI<\/a>, we recommend customers conduct a risk assessment informed by a thorough understanding of\u00a0security in the cloud<\/a>.<\/p>\n

Critical to the cloud risk assessment is understanding your\u00a0current<\/em>\u00a0security processes and how the tools you\u2019ve already invested in help manage risks\u00a0today<\/em>. Unfortunately, we see a lot of clients skip this step and move directly to design and build phases, which is a fatal mistake. Why? Because it inevitably leads to security teams rebuilding their on-prem security model in the cloud and completely misses the opportunity to transform their security program and \"shift left<\/a>\u201d their security, aka\u00a0DevSecOps<\/a>.<\/p>\n

When companies are planning an all-in approach to cloud, they typically focus on one of the three major players: Google, AWS or Azure. Each of these providers offer rock solid services with every major security and compliance certification to boot.<\/p>\n

Invariably several months into the cloud migration process a business unit will pop up (or security teams will discover) a new cloud requirement: \u201cProvider X just launched a new feature which directly addresses our business requirement--can we get access this week?\u201d The IT and security teams then scramble and try to figure out how anything they\u2019ve purpose built for their primary cloud can be utilized with the new provider.<\/p>\n

For security teams who are relying on legacy tools or only native security features of their primary cloud platform, this is a major challenge. How does AWS GuardDuty or AWS Config help you to secure Google or Azure clouds? Simple answer? They don\u2019t. So how should a security team proactively address the multi-cloud security challenge while not getting caught up in the morass of ever-changing individual cloud provider offerings?<\/p>\n

 <\/p>\n

Standards are the Precursor to Automation<\/strong><\/p>\n

Staying secure in a multi-cloud environment can be challenging given the radically divergent APIs between cloud providers. The best place to start is with a trusted security standard. Rather than trying to design a standard from scratch, we highly recommend starting with the\u00a0Center for Internet Security\u2019s Benchmarks<\/a>. The AWS benchmark has been around for several years and both benchmarks for Azure and Google Cloud were released in 2018. While standards may not be the most exciting part of security they do have the added benefit of being the precursor to automation. Put simply, you cannot automate what you have not standardized upon. Once you\u2019ve agreed upon a standard you can then begin to measure yourself against it over time and work to automate as your cloud security program matures.<\/p>\n

 <\/p>\n

Moving from Theory to Execution<\/strong><\/p>\n

Security leaders can design a strategy that effectively addresses new risks and threats\u00a0presented by public cloud. This can only be done with a deep understanding of the shared responsibility model and a sharp focus on dissecting the process by which development and business teams are utilizing public cloud. In my next post we\u2019ll dig deeper into how this can be done as well as how simplicity is key to your multi-cloud security strategy.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

How do security leaders design a strategy that effectively addresses the processes and tools required to manage the new risks and threats cloud presents?<\/p>\n","protected":false},"author":623,"featured_media":96978,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[6724,6768],"tags":[1166],"coauthors":[6679],"class_list":["post-97628","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-points-of-view","category-secure-the-cloud","tag-cloud-security"],"jetpack_featured_media_url":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-content\/uploads\/2019\/02\/corp-blog-cloud-600x300.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/97628","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/users\/623"}],"replies":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/comments?post=97628"}],"version-history":[{"count":4,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/97628\/revisions"}],"predecessor-version":[{"id":97630,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/97628\/revisions\/97630"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media\/96978"}],"wp:attachment":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media?parent=97628"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/categories?post=97628"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/tags?post=97628"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/coauthors?post=97628"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}