Looking at cloud breaches over the last few years, it’s easy to get the impression that most were easily avoidable events that occurred due to silly misconfigurations, ugly failure modes, or borderline negligent architectures. To put it bluntly, these cloud breaches look stupid. But the people and the organizations designing and running these systems—both the clouds themselves and the web applications running on them—are industry-leading architects, respected engineers, and experienced, senior security people. They’re not stupid. So, what does it mean when we see smart people involved in situations that seem really stupid? It means that there is more to cloud security than a lot of the public noise and marketing, whether positive or negative, would have us believe.
In the 2018 Application Protection Report, we published a survey of CISOs and other security leadership in which 43% of respondents listed migration to a cloud environment as one of the top three barriers to application security. At the same time, marketing materials and exuberant early adopters are quick to assure us that the cloud is, in fact, so inherently secure that earlier controls (and the people who cared for and fed them) are now obsolete. The dichotomy between these two views illustrates that the industry never truly harmonized the differences in mission and perspective between the traditional roles of solution provider and security provider. The juxtaposition between the silliness of the prominent cloud breaches and the talent (and, frankly, degree of funding) of the people involved shows that this disharmony is even less tenable now than it was before the advent of cloud technologies. The capabilities and practices that the cloud presents to us call for a new conceptualization of trust, impact, and interdependence that must inform the selection and design of controls in this new environment.
Put another way, the question of whether the cloud is good or bad for security is irrelevant, because businesses are going to the cloud either way. What is germane regarding the cloud is that security practices and controls are a muddle of both the persistently relevant and the obsolete. In other words, cloud environments simplify some security issues, complicate others, and in all cases demand a critical rethink not just of controls, but of control objectives and how security relates to the business. What matters is not what we built in the past, but why we built it. We will unpack this perspective, and present recommendations for minimizing risk and enabling your business to reap the benefits.
What About the Cloud is Making Security Worse?
First, let’s consider all the things we were already supposed to have been doing for security. You know, the “best practices.” In reality, organizations often skip many of these practices for expediency or lack of resources. Vulnerabilities go unpatched, user accounts aren’t locked down, and firewall access rules are relaxed. We’ve experienced our usual share of security failures, but as a whole, business on the Internet has rushed ahead undiminished.
Unfortunately, as organizations “lift and shift” their traditional architecture into a public cloud environment, they magnify some of these existing flaws and then put them in a single convenient place for the entire Internet to find. We also add to the problem of monoculture. What was once a patchwork of disparate and dissimilar infrastructures now looks and runs in the same way. It may not be readily apparent, but there is a significant security difference between a traditional user machine account and an intracloud role. There is also a widespread reliance on APIs in the cloud, which multiplies attackable entry points into applications and infrastructure. There are more moving parts, yet at the same time, this complexity is presented with more simplicity and abstraction, which can lull operators and defenders into false sense of security. Cloud systems are also designed to be elastic, that is, they can proliferate and migrate depending on triggers and loads without human intervention or oversight. Hybrid architectures that mix on-prem and different cloud providers can also amplify gaps as different “cloudified” applications can have differing security profiles depending on where they live. Naturally, all of this is invisible until the problems with security, reliability, and cost overhead began to crop up.
How we humans react to the cloud is a major factor in this confusion, as well. DevOps and the cloud are seen as “disrupters,” shattering the antiquated and stodgy ways we manage technology. However, implementors would be wise to remember the Pottery Barn Rule: you break it, you buy it. When people bypass traditional security and operations practices in their rush to the cloud, they need to remember that they are also inheriting the security responsibility. A significant number of cloud breaches and outages stem from test environments being used with live data or production systems. So far, many application owners don’t seem to realize that their failure to meet the obligation of cloud security is leading to large-scale security errors, which is what presents the appearance of either amateurism or negligence.
Changes in technology and methods of deployment have rendered many of our old ways of doing security ineffective in ways that compound and can be difficult to recognize. At the most basic level, the perimeter is gone. Access control is also a significant challenge, as many servers and systems are now non-local, which require all users to login remotely. Visibility was already a challenge in the traditional on-prem world and becomes even harder when large chunks of the app infrastructure are virtualized and mutable in a cloud environment. Simple security tools like intrusion detection, vulnerability scanning, and malware detection can also be weaker or more effective, depending on whether they are designed to be cloud-aware or not. In short, we can’t expect all of our traditional on-prem tools to work as effectively is in the cloud. For this very reason, many security professionals are blocking their organization’s migration to the cloud, which can lead to the shadow IT and insecure deployments mentioned earlier.
Defenders need to focus on control objectives, not controls.
How Can the Cloud Be Good for Security?
With the right skills, tools, and design, the transition to the cloud can represent a substantial leap forward in security, availability, and efficiency. It does mean moving away from some of the things that have worked in the past, and focusing on the higher level goals regarding security while taking into account the newer paradigms of the cloud.
Starting with security, defenders need to focus on control objectives, not controls. This means looking at ensuring only authorized users and processes can perform authorized actions without getting hung up on user accounts, passwords, and machine rights. Cloud systems are often woven together with APIs, ephemeral instantiations, and decoupled services. A ninety-day password policy is not going to be as useful as a tightening of inherited permissions and permissible contexts for a specific service role. Least privilege and permission review are more important than ever, account lockout for failed password attempt is not. Similarly, most cloud environments move responsibility up the stack, so application-aware security tools like web application firewalls and service event monitoring also become more imperative while infrastructure hardening and network monitoring are often left to the purview of the cloud provider. The beauty of virtual machines built from scripts is that their inventory and operational characteristics can be completely observable. Change control procedures around operator actions on a server can transform into looking for divergence between a running instances and their associated build procedures. For example: does this machine suddenly look different than how it was built? If so, it could be hacked, so let’s take it offline now and spawn a new one. This can be completely automated, rapidly shrinking exposure windows for breaches while also containing attacker’s access to your systems. High-value systems can be also be isolated and segregated with microservices and refreshed as needed from patched, hardened, and tested models. You don’t “fix” hacked or broken systems, you rebuild them anew from stronger, fresher, tested designs.
To realize these new capabilities, organizations will need to have appropriate expertise to design and operate in the cloud. This means not only retraining and leveraging external expertise, but also rethinking how applications are delivered. Part of that rethink means maintaining perspective of what security is trying to do, and why organizations go to the cloud in the first place. On the one hand, it is important to make sure the pursuit of confidentiality does not get in the way of application delivery. On the other, in the long run, security and availability need to function as two sides of the same delivery goal. A security incident will quickly erode any market advantages of five nines of uptime. Cloud security can be an obstacle or a boon. It’s up to you to make sure you properly think through and do things in an appropriate manner.
