Cloud Security: Citadel or Straw House, It’s Your Call
- by nlqip
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.
Source link
lol
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…
Recent Posts
- Security plugin flaw in millions of WordPress sites gives admin access
- Phishing emails increasingly use SVG attachments to evade detection
- Fake AI video generators infect Windows, macOS with infostealers
- T-Mobile confirms it was hacked in recent wave of telecom breaches
- GitHub projects targeted with malicious commits to frame researcher