Five Most Common Cloud Threats
Cloud threats are on the rise. At any point in time, sensitive data can move between 2,481 different cloud apps and services, making it a prime target for cybercriminals. A recent study by McAfee concluded that there’s been a 630% rise in cyberattacks on cloud services since January 2020. According to industry research, cloud breaches cost organizations $5 trillion over the past two years. From our experience, here are the five most common cloud threats.
S3 Buckets
Misconfigured AWS S3 buckets are among the most common causes of data breaches. Amazon Simple Storage Service (S3) provides the ability to store and access content organized in “buckets,” or logical containers, which are accessed by a static URL. Often, administrators allow public access to these buckets to store and share files between employees, and to host internet-facing services, thereby unintentionally exposing server backups, company documents and contracts. Magecart hackers exploited misconfigured AWS S3 buckets to hit 17,000 domains including 2,000 of the biggest sites in the world.
Unprotected Idle Assets
At the beginning of any cloud environment deployment project, the IT or DevOps team can create thousands of cloud assets. With the ability to add or remove cloud assets and the rapid pace of releases, it is easy to lose track and leave an unused asset unprotected. There are dozens of different asset types that need to be tracked, including compute engine virtual machines, cloud storage buckets, IAM policies and others. According to our internal research, on average, 11% of these assets go unused, many of them without security authorizations in place. Hackers can take over a company’s unused cloud assets undetected because security officials may not even know about these assets’ existence in the first place.
Overly Permissive DevOps Pipelines
Business units are under pressure to deliver new features, applications and fixes within tight and frequent deadlines, which can be as often as once a week. Traditionally, DevOps teams have a singular focus on building applications and delivering on release dates with little consideration to adding security layers to the pipeline. When it comes to the permissions of continuous integration, continuous development, and CI/CD servers, DevOps engineers are reluctant to deny access. After all, the wide access permissions are part of enabling the speed of innovation, and development teams are regularly – and often understandably – cautious about putting least privilege or other access rules into place. These wide access permissions increase the risk of sensitive data being leaked.
Developer Workstations
Developers typically have full administrative privileges to deploy new code. Developers need access to privileged credentials to access key developer tools like Kubernetes or Jenkins admin console. These credentials make developers’ workstations a high-value targets for hackers. If the station is compromised, the attacker can create a new admin asset, launch admin code and can gain control over the entire cloud environment. This vulnerability is typically a blind spot.
Authorization Misuse
There is no standard procedures for assigning authorizations between cloud services, which can result in mistakes due to a false assumption that user accounts are protected when they are, in fact, open to tampering. For example, AWS identity and access management (IAM) policies and evaluation logic do not work the same way as other authorization mechanisms that security engineers are more familiar with. This discrepancy can lead to a security engineer falsely believing that because access to a group is denied, individual members are protected as well.
Complex cloud environments, with their hundreds of assets, have become prime targets for hackers, but the good news is that today there are several defensive measures that can reduce the risk. It is recommended that security officers take a proactive approach and focus on defending valuable assets rather than reacting to wave after wave of alarms.
The context of cloud threats should be used to prioritize its severity to save valuable time and to make the best use of human resources. Remediation should be streamlined using automatic and guided scripts, and it’s better to scan and identify misconfigurations in the development phase before systems are put in production. Cloud security is more complicated, but if we are more diligent based on past experience, there is higher likelihood that we can prevent a cyberattack.
