Eyal Arazi, of Radware, discusses the major security threats with migrating workloads to public cloud environments.
Migrating workloads to public cloud environments opens up organizations to a slate of new, cloud-native attack vectors which did not exist in the world of premise-based data centers.
In this new environment, workload security is defined by which users have access to a business’s cloud environment and what permissions they have. As a result, protecting against excessive permissions, and quickly responding when those permissions are abused, becomes the number one priority for security administrators.
Traditionally, computing workloads resided within the organization’s data centers, where they were protected against insider threats. Application protection was focused primarily on perimeter protection, through mechanisms such as firewalls, IPS/IDS, WAF and DDoS protection, secure gateways, etc.
However, moving workloads to the cloud has led to organizations (and IT admins) to lose direct physical control over their workloads and relinquish many aspects of security through the shared responsibility model.
As a result, the insider of the old, premise-based world is suddenly an outsider in the new world of publicly hosted cloud workloads.
IT administrators and hackers now have identical access to publicly hosted workloads, using standard connection methods, protocols and public APIs. As a result, the whole world becomes an insider threat.
Workload security, therefore, is defined by the people who can access those workloads, and the permissions they have.
One of the primary reasons for migrating to the cloud is speeding up time-to-market and business processes. As a result, cloud environments make it very easy to spin up new resources and grant wide-ranging permissions, and very difficult to keep track of who has them, and what permissions they actually use.
All too frequently there is a gap between granted permissions and used permissions. In other words, many users have too many permissions, which they never use. Such permissions are frequently exploited by hackers, who take advantage of unnecessary permissions for malicious purposes.
As a result, cloud workloads are vulnerable to data breaches (i.e theft of data from cloud accounts), service violation (i.e completely taking over cloud resources) and resource exploitation (such as cryptomining). Such promiscuous permissions are frequently mis-characterised as ‘misconfigurations’ but are actually the result of permission misuse or abuse by people who shouldn’t have them.
Therefore, protecting against those promiscuous permissions becomes the number one priority for protecting publicly-hosted cloud workloads.
Piecemeal solutions
The problem, however, is that existing solutions provide incomplete protection against the threat of excessive permissions.
• The built-in mechanisms of public clouds usually provide fairly basic protection, and mostly focused security on the overall computing environment, they are blind to activity within individual workloads. Moreover, since many companies run multi-cloud and hybrid cloud environments, the built-in protections offered by cloud vendors will not protect assets outside of their network.
• Compliance and governance tools usually use static lists of best practices to analyze permissions usage. However, they will not detect (and alert to) excessive permissions and are usually blind to activity within workloads themselves.
• Agent-based solutions require deploying (and managing) agents on cloud-based servers and will protect only servers on which they are installed. However, they are blind to overall cloud user activity and account context, and usually cannot protect non-server resources such as services, containers, serverless functions, etc.
• Cloud access security brokers (CASB) tools focus on protecting Software-as-a-Service (SaaS) applications, but do not protect Infrastructure-as-a-Service (IaaS) or Platform- as-a-Service (PaaS) environments.
New approach
Modern protection of publicly-hosted cloud environments requires a new approach.
• Assume that an organization’s credentials are compromised: Hackers acquire stolen credentials in a plethora of ways, and even the largest companies are not immune to credential theft, phishing, accidental exposure or other threats. Therefore, defenses cannot rely solely on protection of passwords and credentials.
• Detect excessive permissions: Since excessive permissions are so frequently exploited for malicious purposes, identifying and alerting against such permissions becomes paramount. This cannot be done just by measuring against static lists of best practices but must be based on analyzing the gap between the permissions a user has defined, and the permission they actually use.
• Harden security posture: The best way of stopping a data breach is preventing it before it ever occurs. Therefore, hardening your cloud security posture and eliminating excessive permissions and misconfigurations guarantees that even if a user’s credentials become compromised, then attackers will not be able to do much with those permissions.
• Look for anomalous activities: A data breach is not one thing going wrong, but a whole list of things going wrong. Most data breaches follow a typical progression, which can be detected and stopped in time – if IT know what they’re looking for. Monitoring for suspicious activity in a cloud account (for example, such as anomalous usage of permissions) will help identify malicious activity in time and stop it before user data is exposed.
• Automate response: Time is money and even more so when it comes to preventing exposure of sensitive user data. Automated response mechanisms allow you to respond faster to security incidents and block-off attacks within seconds of detection.
Advanced vendors are offering comprehensive protection. These can include a line of cloud-based security services that provide an agentless, cloud-native solution for comprehensive protection of workloads hosted on AWS. Such solutions protect both the overall security posture of an AWS cloud account, as well as individual cloud workloads, protecting against cloud-native attack vectors.
