• Adam Cohen

Part 2 of This is Not Your Father's Cloud

This is Not Your Father’s Cloud (Part Two)

In Part One of this article last month, we began a discussion designed to demystify the hesitations behind cloud security and analyzed the fast-growing transformation to a range of newer technical approaches with important consequences for legal practice. This month we continue the discussion by tackling the security and legal implications of the mass transformation of enterprise IT to cloud services from leading providers such as AWS and Azure.

In considering the 1-2 market dominance of AWS and Azure, an inescapable thought is that the unprecedented degree of aggregation of customer systems and data under these providers presents a potential target of proportions never before imagined. One might reasonably, and hopefully correctly, assume that AWS and Azure are at least among the most sophisticated organizations ever when it comes to cyber-security, and plainly they have and deploy awesome resources to maintain and test their defenses. They have every business incentive to do so. But ultimately, they are to an important (if diminishing) degree controlled by human beings, at least some of which may not be perfectly immune from mistakes or bad intent.

Given the trust enterprises of all types — including government agencies — are placing in these providers to safeguard their systems and data, it would be naive to believe that intelligence agencies are not cultivating provider personnel as “assets.” Moreover, intelligent and successful people do desperate or evil things every day for reasons having nothing to do with state-sponsored espionage, including money problems, social engineering, etc. There is simply no way to ensure that unauthorized access never occurs in a company with thousands of employees.

Even if the leading cloud service providers (CSPs) were fully controlled by benevolent and un-hackable robots, they are portals to thousands upon thousands of customers, not all of who practice the best information security hygiene, to put it mildly. Customers interacting with AWS and Azure have their own customers, likely retain data about these customers, and digitally contact other third parties such as vendors. The attack surface is endless; someday, we will be nostalgic for the “big” recent data breaches, which will seem quaint.

Sharing Responsibility for Security

As AWS and Azure explain and promote, their clouds operate on a “shared security” or “shared responsibility” model; the CSP and the customer each have allocated roles and responsibilities with respect to cybersecurity. AWS famously sums up its view with the mantra that the customer is responsible for security “in” the cloud, while the provider has responsibility for security “of” the cloud.

As a legal matter, the allocation is transposed to a contract; as a practical matter, the sharing is inherent in the integrated and interactive nature of the relationship. Nonetheless, misunderstanding about this sharing arrangement is rampant.

The Two Extremes

False beliefs about enterprise cloud information security emanate from opposite ends of the spectrum. The overly optimistic extreme is under the delusion that, because these tech giants are so obviously the very arbiters of technological sophistication, and have every incentive to be concerned about security from a business point of view, customer data in services provided by them is more secure. Even assuming the truth of the premises, the line in the shared security model must be carefully delineated. Using these services does not mean that the customer or a user cannot impact the security level of the stored data or other Information Assets. Moreover, what each party needs to do in terms of security varies depending on the particular service. In general, the massive provider may drive the bus, but a passenger can almost always find some way to interfere with the driver’s smooth, safe operation of the vehicle.

On the other side of the spectrum is the argument that “the cloud is less secure than my company’s data center.” Granted, it may take some work to overcome years of familiarity with the word “cloud” in connection with floating, fluffy, formless giant cotton-balls in the sky, to associate the word “cloud” with strong cybersecurity. However, in the absence of perfect information security, which is the state of reality, security is relative. The notion that traditional corporate IT infrastructure, complete with dedicated data center, is more secure or less vulnerable than AWS or Azure as a blanket matter is not supportable. As lawyers will appreciate, many criminal defendants have found out the hard way that representing themselves may not be wise and the same goes for enterprise IT.

Not surprisingly, there are a growing number of publicly reported incidents where data in one of the big services was compromised. The ability to draw conclusions from these reports is limited. We know that, like the wider universe of data breaches, public information about them represents only the tiniest tip of an unknowably large number of total breaches. As a rule, among those responding to a breach, “mum’s the word” for obvious reasons and there are many business, legal and security rationales, real or imagined, for withholding disclosure.

Given the global size and complexity of the major cloud infrastructures, maybe it’s better not to think about the number of security incidents the providers evaluate and instead, stick with the understatement that the number is higher than what is publicly reported. Enjoy blissful ignorance. After all, visibility, traditionally an information security imperative, is strictly limited when it comes to the iceberg’s infrastructure; only the service provider has a complete picture. Getting the biggest and best in tech to provide and manage IT infrastructure comes with a serious side effect — substantial blindness.

The Customers’ Burden

The providers understand that customers need monitoring capability and offer services that generate logs, such as CloudTrail and CloudWatch on AWS and Azure Monitor. But it may be up to the client to activate such logging, as well as enable log file validation — hackers alter log files to cover their tracks. Access to the logs themselves should be protected with measures like multi-factor authentication and attempts to access the logs should be logged. The logging should be coupled with notifications to personnel who can take appropriate action. In other words, while the tools are offered, the customer has to know where and how to use them. Clients need to meticulously ensure that appropriate oversight and decision-making over matters with potentially serious consequences penetrate to the level hands-on, implementation by mouse-click.

Regarding the increasing number of incidents, we may charitably correlate the rise with accelerating systems migration and the learning curve inherent in using the services properly. Time and again, reported breaches describe a similar, if not identical story or set of facts. They start with an act of seemingly monstrous gross negligence — a customer or consultant acting on their behalf mistakenly designates a cloud repository as public rather than restricting access as appropriate.

Then, it is a race against time. The period in which the company might realize the mistake and close the gates is rapidly shrinking; eventually, the growing wolf-pack monitoring the public cloud for such exposed instances swoops in, gathering a treasure trove of sensitive information to sell for a nice bitcoin profit. If only someone had closed the door.

To make matters worse for the victim’s self-esteem, AWS and Azure provide abundant guidance and tools for preventing such catastrophes, although a rising chorus argues they should be doing more to protect people from themselves. Security, even when presented as the default setting, is not fully automated — a human being can click to destroy their business. Unauthorized access is widely viewed as the biggest threat to cloud security. In the nerd version of Naughty By Nature, the problem is OPP — overly permissive permissions.


A thorough discussion of the information security assistance provided by the major services is for a later publication, as it is extensive. From network security, to resource management, secure virtual machine templates, encryption of data in transit and at rest, encryption key management, and much, much more, the protections are either in place or made available for use. This includes access to guidance and expertise from human beings. Finally, the major service providers have multiple certifications such as ISO 27001, FedRAMP, DoD CSM, PCI DSS, etc.

The customer is responsible for making sure they configure their services securely. The service providers offer many security tools, but if the customer either doesn’t turn them on, or turns them off even though they are the default option …. Customers are responsible for their own employees in terms of internal compliance.

This is part of the bargain when you sign up for the prevailing “shared security” or “shared responsibility” model such as propagated by AWS or Azure. Regardless of the market power imbalance enjoyed by the tech giants, more legal and technical analysis of the risk allocation and its implications for clients would be constructive. Lawyers and clients need to understand the security measures available for the specific enterprise IT cloud services they use and how to ensure that they are properly implemented the right way. Otherwise, the data in those services will be compromised, leading to pleading, from plaintiffs and regulators, citing the ample security measures offered by the provider for a click and maybe a few bucks. *****

3 views0 comments

Recent Posts

See All

DevOps and the Fate of Secure Software Development

Reconciling Technology Development, Security and the Lawyer’s Role (originally published in the Cybersecurity Law Report) No matter how much new law is written on the topic of cybersecurity or data pr