Top Cloud Security Threats
Cloud computing is now a mainstream technology, with the majority of enterprises using some form of cloud services across IaaS, PaaS and SaaS. Major makers of software such as Red Hat, Oracle, Salesforce , VMWare and Microsoft are pushing users towards cloud adoption and many enterprises that have grown to scale are cloud-first. Operating in the cloud offers better flexibility, agility and scalability. In theory, too, the cloud abstracts away many security risks at the hardware, operating system and software layers. In reality, while some risk is reduced, some aspects of security are more complex and harder to maintain.
By distributing applications and infrastructure more widely and shifting to API connections over physical cables, the cloud expands the total attack surface for just about everything. Not only is the attack surface expanded but it is now constantly changing, as new cloud servers and functions spin up and down. Access to critical infrastructure is now by default remote and location agnostic. For these reasons, the cloud also renders the old hardened perimeter security model obsolete. Based on this new reality, there has been a rapid increase in attacks aimed at potential weak links created by cloud computing. Here is a look at common and severe cybersecurity threats that expose and attack the cloud.
Cloud deployments are outside an organization’s security perimeter and, unless properly secured, directly accessible via the public Internet. The ease of access makes life better for employees, customers and partners. But attackers have recognized that cloud targets are easier to attack because they are public and accessible to probes, scans and other tactics that would not work as well with a legacy IT architecture. Some of this can be solved through implementing role-based access controls (RBACs) for key services but, despite these controls, overly permissive access to cloud storage services or databases has been the top cause for cloud breaches.
Many developers write code for cloud applications in local environments and then move that code into a version control system to file a pull request. Unfortunately, these developers sometimes forget to remove the “secrets” they wrote into the code for things like API or remote service access. Smart cybercriminal scan open or exposed repositories to look for secrets and use them to break into cloud infrastructure. Because secrets are needed for so many things in the cloud — passwords, MFA, API keys, etc — hunting for exposed secrets has become a favorite tactic of criminals.
As cloud storage has become insanely cheap and convenient, more and more enterprises are using public and private clouds to store a growing array of data. Cloud storage services such as Amazon’s S3 and Glacier offerings, generally rely on users to set up proper security settings and controls to protect storage buckets. Unfortunately, setting up storage buckets is so easy that almost any developer can do it and mistakes are often made. Attackers know this and scan S3 to look for open buckets to see if they can get lucky — and sometimes they do, accessing sensitive data.
Hackers frequently attempt to break out of containers or virtual machines (VMs) and horizontally traverse inside a cloud to access and compromise other containers and VMs — an attack of the highest severity. Once attackers can break out, they are often able to view exposed network traffic and gain privileged access without requiring credentials or MFA. Because these attacks are hard to detect, CSPs and security teams guarding cloud applications may not identify the Indicators of Compromise for extended periods.
More vandalism than mastermind cybercrime, DOS and its close cousin Distributed Denial of Service attacks (which use thousands or even millions of compromised clients, devices or cloud instances) existed before cloud. These attacks seek to drown a target in noisy junk traffic, blocking legitimate users and slowing down access to services and applications. The Cloud Era has made it easier to create web-scale DDOS, often with clever criminals weaving together fleets of free micro-instances or renting out botnets to perpetrate these assaults. Blocking these attacks when they target cloud applications and infrastructure requires proper configuration of security controls and working closely with CSPs, ISPs and others to shut off the faucet of DDOS quickly and comprehensively.
In the cloud, almost all applications use APIs for external communications with other cloud services. For cloud native apps, running in Kubernetes, APIs are used not only for north-south traffic (public-private) but also for east-west (internal service to internal service) communications. With so much more use of APIs and APIs being used for more critical communications tasks, it’s not surprising that misconfigured or poorly designed API defenses are a top cloud security risk. There is a long list of failures that could cause API insecurity including, misconfigured and unnecessary HTTP headers, unmetered and unlimited API input fields, revealing error messages that contain sensitive information about an application, and overly permissive resource sharing.
Kubernetes and cloud native have grown rapidly in popularity. While the container orchestration solution solves real problems, it also creates many new security risks, largely due to the complexity of its networking model and the default settings of very low or minimal security with no default access controls. For example, Kubernetes has a rich RBAC capability but users must enable it. Or, by default Kubernetes allows every pod to contact every other pod, potentially exposing workloads that are meant to be secret or secure. Observing constantly changing workloads in Kubernetes requires cloud native metric collection, using tools like Open Telemetry and Prometheus. The lack of familiarity and the different constructs of Kubernetes mean security teams need to learn new rules.
You can’t defend what you can’t see. For the most part, an enterprise’s cloud infrastructure resides outside of corporate networks and runs on infrastructure hosted in a cloud data center. Most enterprises today use more than one public compute cloud. Each cloud has its own observability tools and offers different ways to observe application performance and workload. Hybrid cloud architectures create observability challenges because pulling all the information from multiple clouds into a single monitoring solution is often complicated. This can hinder a security team's efforts to observe and monitor their cloud-based resources and guard them against attack.
With cloud, you developers are remotely accessing resources and services located elsewhere. This means constantly logging in and entering passwords to validate privilege. Smart attackers have recognized that weaker access controls, such as lack of MFA and lack of anomalous behavior detection, can make it easy to use brute force “password spraying” campaigns to takeover and hijack cloud accounts. Attackers also have become more sophisticated in using social engineering, pretexting and even “deep voice” AI-powered voice simulation of trusted parties to take over accounts. The far flung nature of cloud and the proliferation of services to be accessed make it harder to police the situation manually. Once an account takeover happens in the cloud, the adversary usually can leverage access to insert malware or malicious code and horizontally traverse across an organization's infrastructure to hunt for even more valuable targets. Account hijacking is often the first step in data loss and theft of PII.
The world of cloud is fundamentally different from the world of legacy IT deployments tied to physical locations. Putting applications and infrastructure in the cloud offers tremendous benefits. This new paradigm for computing, however, introduces plenty of risks that did not exist in the legacy world of physical servers living in data centers. Loosely coupled, distributed infrastructure that splits key functionality among multiple services running in a public cloud requires a heightened degree of vigilance and observability designed for the rapid change common to the cloud.
One thing that divides cloud safe and cloud risky organizations is the degree to which they run automated and programmatic security assessment tests against their cloud. In our experience, assuming that your infrastructure is flawed and compromised, and running attack simulations as frequently as possible, helps your engineers block unwanted attention and attacks without disrupting your business.
For best protection, proactively, continuously validate and optimize the effectiveness of your cloud security controls with breach and attack simulation tools from SafeBreach.