You share responsibility for securing your data in the cloud. What does that mean? More than anything else, that you understand where the layers of protection from your cloud provider ends, and your responsibility begins.  

A storm awaits many companies as they move infrastructure, applications, and entire portfolios to cloud services.  Yet, the pace of digital transformation demands that businesses make the transition.  We all receive the emails: “Deploy with scalability”, “leverage provider security”, “make your operational model more efficient”, and “manage less of the complexity” in your services!  These promises can certainly be realized – on the back of the billions of dollars in cloud investment from Amazon Web Services, Microsoft Azure, and others. To do so without risking the security of your data, however, requires careful planning along the way.

Most companies have become aware of which services they continue to “own” in the basic cloud provider models.


While the “who” of service block ownership has cleared, the question of security responsibility is a bit more complex. Amazon and Microsoft are spending billions (with a “b”) of dollars investing in the technology, people, and governance to protect public cloud services. The recent introduction of services like Amazon’s Macie shows for example, how the stock set of firewall and identity rules are quickly being complemented by deeper levels of data protection.

You, however, still retain something that Amazon and Microsoft simply don’t have: you know how your business works!  You know your people.  You know your data.  Amazon and Microsoft depend on your team, your understanding of what “good” and “bad” look like, and your willingness and ability to put reasonable security controls in place.  Often, those controls require advanced capabilities and visibility that complement the investments of the public provider, allowing you to mitigate your unique risks.



Take a simple communications scenario in Amazon Web Services.  A virtual machine in your cloud deployment makes a request to an S3 bucket to list the contents, which it receives, and then begins to request objects from the bucket.  In the transaction, Amazon’s various protective layers are  hard at work ensuring that DDoS and other external threats are not immediately involved.  The investment Amazon has made in the identity and access management (IAM) system, including the tools for policy generation and monitoring, are activated to check the policies which apply to establish a basic authorization context.

Yet, your enterprise still has outstanding risk in even this basic scenario.  Do you need to know why the list action occurred?  What application called it?  Has the VM been recently seen to engage in other unknown traffic streams?  What type of environment is the VM a part of?  What is the hygiene status / policy compliance of that VM?  Once the list is returned, is the VM allowed to access all of the things in the bucket, or should some of them be restricted?

Your enterprise remains responsible for critical aspects of the risk management of your deployment, including the ability to recognize and detect mis-configurations and/or respond to undesired access events.  In these kinds of scenarios, the cloud provider has applied their formidable assets in your defense – but as far as your IAM and bucket configuration have stated, the provider can only understand the events to be permitted.

Recent data leaks at a partner of VerizonDow Jonesand elsewhere from misconfigured cloud resources have underscored that this is not mere conjecture, confirming that “but, I’m on Amazon” is not a defense for breached data.  Your enterprise should have strong governance, ready discovery tools, the same (or better) identification and investigation tools you had on-premises, and the instrumentation to better assess the risk of individual data access and transmissions to your business.

In today’s cloud services, “we are running DevOps”, “it’s cloud”, and “but I’m on [provider]” cannot be our line of defense.  Your enterprise can safely realize the business cases of cloud deployment, remembering the lessons of the last generation of incrementally controlling first the perimeter and then north-south and east-west traffic for risks.  Today, data probably would not transit(hybrid or private cloud) without policy check, inspection, and data loss consideration.  Why would your operations on a cloud service be protected any less?

For more information on cloud security, follow @McAfee_Business.