Top 5 Cloud Security Pitfalls & How to Avoid Them
Effectively securing enterprise cloud assets is a significant and crucial challenge for today’s security teams. Different security techniques, strategies and tools are necessary for the cloud and, therefore, your approach shouldn’t look anything like it did for traditional on-premises assets.
This blog looks at the top five cloud security mistakes and how to avoid them:
1: Lack of a Cloud Native Security Architecture
A cloud security mindset is completely different than the traditional approach used for on-prem security. Gone is the impenetrable, singular, secure perimeter protecting all your enterprise assets. With the cloud, you have as many perimeters as you have cloud environments: one perimeter for each cloud subscription or account, or you might even consider that each workload has its own small perimeter. In the cloud environment, the cloud workloads or applications are by their very nature short-lived: Provisioning a cloud instance might involve only the delivery of one workload before it’s deprovisioned. That means your hosting instances are disappearing faster than most of your existing monitoring systems or agents can be installed.
When you approach cloud security in a native way, you build the necessary security controls into those workloads even before provisioning them, rather than trying to later bolt on a patchwork of traditional security controls into your cloud environments. There are new options for detecting new cloud instances within your enterprise, API-based or even event-based discovery using native tools in the cloud platforms. For example, by hooking up to a cloud provider’s event source, you can discover there's now a new instance available and that's the very moment to trigger your scans and monitoring controls.
2: Cloud Credential Creep
Cloud credential creep is all about your collection of control plane and identity and access management (IAM) cloud credentials. Without proper management, you risk allowing a sprawl of overprovisioned user accounts, system principles or non-user identities. This is new compared to your existing access management systems for on-premises. It’s a daunting concern, as it’s exploitable by attackers in the wild through web portals, APIs and command line tools.
The control plane in the cloud is basically your list of any types of access given to your cloud environment or its APIs: create, read, update and delete. The IAM requirements within a single cloud environment can quickly span hundreds of different types of roles — technical roles that you need to start provisioning to your users with varying levels of granularity. Often, there are many cloud instances multiplying this security challenge.
You can mitigate credential creep by enforcing authentication using your centrally managed identity provider (IDP). You should apply role-based access controls (RBAC) with a focus on access scope. Embracing IAM as code for the cloud is advantageous whenever and wherever possible: policies as code, identities as code, application as code and infrastructure as code. You can even have all change requests done as code. All network infrastructure, all firewall rules are defined within the infrastructure as code to ensure consistency and to leverage time-saving automation.
3: Broken Data Plane Access Controls
Data plane access controls how you implement access to the data inside your cloud services. At the simplest level, your cloud storage bucket’s file structure contains tokens that grant specific access to create, read, update, delete or provide a connection string to a database. The cloud introduces a completely different world and ways of managing that access, and we’re even starting to see cloud providers implement attribute-based access controls.
Improper use of data plane access controls can break your centrally managed IAM system, as they’re not as universal or as capable in many cloud providers as the control plane access is, which leads to additional security challenges. For example, your development teams might be able to break your centralized identity model, create their own access tokens, potentially store them insecurely and fail to follow your enforced rotation intervals, which leads to attack vulnerabilities.
How do you secure the data plane? Ideally, you use a centralized identity management system and apply the same approach as you would have on that control plane access described in the prior section — using data plane RBAC roles and enforcing with storage bucket account setting policies. You enforce a secret or a key vault with programmatic rotation.
Quite often, development teams default to unnecessarily high privileges or use insecure key storage. Wherever possible, block developers from manually circumventing your centralized access controls to prevent them from regenerating their own keys, secrets or connection strings. Take away any legacy or key-based access control methods within your cloud provider’s settings and enforce that through policy as code. When you can’t enforce it for a specific provider or service, you can at least monitor against it to understand your exposure. Use data plane RBAC controls attached to the identity providers of your cloud provider.
4: Exposed Public Endpoints
Developers and security practitioners never intentionally plan to publicly expose their endpoints in the cloud. Yet, despite all best intentions, it’s become a kind of security whack-a-mole game to repeatedly find public endpoints and then fix them.
What happens when you open an endpoint on the cloud? In a matter of minutes or even seconds, you'll start seeing endpoint map scanning occur, which is someone knocking on the digital door to find out what's inside your web application. You are quickly noticed because the IP address ranges from all major cloud providers are public knowledge, available for download and accessible through an API.
Whenever you provision something, chances are malicious scanners will find your workloads before your own internal scanners built around concurrency do. How do you mitigate this? The answer is all about how you successfully communicate and enforce the importance of this vulnerability to every developer and everyone who works with the cloud. They must understand that whenever provisioning publicly accessible assets, every public IP is at risk and should be carefully reviewed.
It’s therefore vital to secure your infrastructure-as-a-service (IaaS) environments with native cloud networking services: network security groups (NSG), access control lists (ACL) and firewalls. Secure the platform-as-a-service (PaaS) data service with resource firewalls and enforce this with policies.
5: Cloud Misconfigurations
Did you know that data breaches are more likely to happen due to misconfiguration of cloud services rather than because of external attacks or application vulnerabilities? Year after year we keep hearing that cloud misconfigurations are the top reason for data breaches.
Cloud misconfigurations are failures to secure the cloud instance, either because you didn’t change the cloud provider’s defaults or because you didn’t use effective cloud security controls. While cloud provider defaults do provide an improvement in security in comparison to their on-premises counterparts, they’re far from perfect.
Your application teams have tremendous power over new cloud instances. Unless you ensure their success with appropriate guidance, controls and enforcement, they can accidentally introduce misconfigurations that adversely affect cloud security. The misconfigurations can be as simple as forgetting to enforce encryption in transit for your cloud storage services. Or they might extend into complex compound scenarios, where individual cloud services are set up correctly but introduce additional threats when chained together by an attacker.
The best way to avoid misconfigurations is to prevent their initial creation. You can empower your cloud application development teams to scan their infrastructure as code (IaC) deployment templates against known vulnerabilities. Another strategy is to integrate IaC static security scanning tools across the software development life cycle (SDLC) — as pre-deployment gates in your CI/CD, or even as extensions that provide security recommendations already in your developers’ integrated development environments (IDEs).
Another concern is the introduction of misconfigurations after the cloud instance’s deployment, even if you initially lock down your cloud landing zones and enforce your deployments to pass security scans. The answer is in cloud security policy enforcement and cloud security posture management (CSPM) tools. If your chosen policy framework or CSPM is cloud native, you can apply auto-remediation of identified misconfigurations in an event-driven manner.
Conclusion
The cloud has afforded businesses great speed, scalability and opened many new markets and product opportunities than ever before. However, the cloud also introduces a significantly different security challenge that necessitates adapting your security team to a true cloud native security approach. Start by ensuring you’re avoiding these most common mistakes.
