There have always been two fundamental pillars of cloud security. One is the visibility to detect issues. The other is the ability to remediate threats effectively – ideally, in a proactive manner, which means mitigating risks before they are actively exploited. Neither of these pillars has changed since companies began moving workloads into the cloud more than a decade ago.
What has dramatically evolved in recent years, however, are the tools and processes businesses need to enact cloud security. As organizations have shifted from basic cloud environments powered by VMs to distributed, microservices-based, cloud-native environments, the cloud security strategies that sufficed five or ten years ago are no longer enough to stay a step ahead of threat actors.
Today, it's critical to ensure cloud security evolves with your cloud strategy and architecture. This article explains what that means and which best practices businesses should be following to meet cloud-native security requirements.
From cloud security to cloud-native security
There is a big difference between traditional cloud computing environments and cloud-native computing environments. By extension, there is a big difference between traditional cloud security and cloud-native security.
In a traditional cloud environment, you secure workloads by setting up cloud firewalls and defining security groups. You achieved security visibility by loading agents onto VMs, which collected logs and metrics. You may have used your cloud provider's native security tools (like Amazon GuardDuty or Microsoft Defender) to interpret that data and detect threats. You might also have periodically audited your cloud IAM settings to detect potential misconfigurations. Perhaps you even outsourced some security operations to a Managed Security Service Provider (MSSP).
These types of tools and processes remain important in cloud-native environments. However, they are not enough on their own to meet the new and unique security challenges that arise in the context of cloud-native workloads. Traditional cloud security doesn’t address needs such as:
- Identifying risks beyond IaaS: Cloud-native attack surfaces extend beyond conventional infrastructure and applications. For example, Kubernetes RBAC configuration mistakes could create security risks, but monitoring just VMs or applications won’t alert you to them.
- Managing constantly changing configurations: A modern, cloud-native environment might include dozens of users and workloads, with thousands of access control rules defining who can do what – and the settings are constantly changing. Periodic audits aren’t enough for proactive threat detection in such a dynamic, fast-moving environment.
- Multi-cloud security needs: Cloud vendors’ native security tools don’t suffice when you need to secure workloads running across multiple clouds at once.
- Remediating root causes: Knowing that a risk exists is not always enough to fix it quickly in complex, cloud-native architectures. For instance, detecting a code injection vulnerability in an application doesn’t necessarily mean you can quickly trace the issue back to the particular microservice or code commit that triggered it.
So, while conventional cloud security remains part of the foundation for cloud-native security, it’s not a complete foundation on its own. To protect cloud-native workloads fully, you need to extend the security tools and processes you have in place to protect traditional cloud workloads.
Cloud-native security best practices
To achieve complete security for cloud-native workloads, strive to follow practices such as the following.
Bake security into your development pipeline
In a cloud-native world, you don't want to wait until after you've deployed an application to find risks. Instead, maximize your chances of finding and fixing issues pre-deployment by baking security tests into your CI/CD pipeline. Ideally, you'll perform a series of tests – starting with the testing of raw source code and proceeding to running tests against binaries in a pre-production environment.
Move beyond agents
While agent-based security may be enough for protecting simple cloud workloads like VMs, in some cases – such as when you are using serverless functions – you can’t deploy agents to achieve security visibility.
Instead, you'll need to instrument security visibility into your code itself by ensuring that your applications expose the data you need to detect threats without relying on agents to be your intermediary.
Implement layered security
Cloud-native environments include many layers – infrastructure, applications, orchestration, physical and virtual networks, and so on – and you need to secure each one. This means deploying tools and security analytics processes that are capable of detecting risks in, say, the way you configure your Kubernetes deployments or from inside container images, in addition to catching conventional cloud security risks like IAM misconfigurations.
Audit continuously and in real time
Again, periodic auditing or validation of cloud configurations is not enough to ensure you can detect and remediate threats in real time. You should instead deploy tools that can monitor all of your configurations continuously and alert you to risks immediately.
Where possible, you should also deploy automated remediation tools that can isolate or mitigate threats instantly, without requiring a human to be “in the loop.” Not only does this approach reduce the burden you place on your IT and security teams, but it also allows you to remediate threats as quickly and proactively as possible.
Tame the complexity of cloud-native security
All of the above is to say that, even if you feel confident in your ability to secure conventional cloud environments and workloads, you may face an uphill battle in handling cloud-native security risks. Solutions exist, but they require specialized expertise and a deep knowledge of new, fast-evolving cloud-native architectures and technologies.
Jeff Collins is Solutions Manager - Managed Cloud Services at 2nd Watch.