Misconceptions around cloud-native security

Adoption rates for cloud native application architectures are rising quickly within enterprises, and for good reason. Portability, scalability and efficient resource utilisation are commonly cited benefits, but the greatest boon is the significantly reduced deployment times enabled through a cloud native approach. A cloud native approach gives organisations far more flexibility and control over the infrastructure they use, enabling faster workflows and deployment processes. This goes some way to explaining why the number of containers in production has jumped 300% since 2016. However, don’t let these numbers fool you. Although cloud native is gaining a foothold within businesses, there is still a lack of cloud native experience within many development teams, and a lot of common misconceptions, particularly regarding security.

Misconception #1 – We don’t need a specific cloud native security strategy

The separation of discrete computing components in containers, alongside concepts like immutability, provide the impression (at least at first glance) that cloud native applications are, by their very nature, secure. This is one of the most common misconceptions we see, and quite a dangerous one at that.

It is, of course, convenient to assume that containers ‘contain’ and are segregated from other containers and the OS they’re running on. But the truth is not so simple. If one runs a container with root privileges, that container could potentially access all the resources on the host, opening up the possibility for an attacker to take over that host. Privileged access must be controlled before the container is deployed and re-checked using cloud native runtime enforcement capabilities.

Embedding cloud native security into cloud native initiatives can make applications and infrastructure more secure, and microservices running in containers or as serverless functions, provide ways to limit exposure. However, a cloud native deployment without a security strategy does not necessarily enjoy full protection, and security teams must still set policies across the build, cloud infrastructure and running workloads.

Misconception #2 – Secure application code should be the primary focus

Application code should of course be error-free and technologies such as static application security testing (SAST) are of great importance whether you’re working with custom code written entirely by your own team, or as is likely the case today, with code assembled from multiple open-source libraries. However, there is much more to securing a cloud native application than just securing the source code.

The best, most secure code still won’t protect against a scenario where images, which should never change in production, begin executing commands in runtime that were not included in the base image. Nor will it prevent orchestrator misconfigurations or cloud account misconfigurations that can leave entire cloud services open to attack.

Developing secure images is an important element, but a broader focus on securing the overall pipeline from build to deployment, as well as the security posture of the infrastructure it will run on, can be even more critical.

Misconception #3 – Development issues will be fixed in production

One of cloud native’s most prominent benefits is immutability, which essentially means that workloads will not and should not change while running in production. In cloud native environments, if a container needs to be updated or configuration changes need to occur, a new version is created within the pipeline to completely replace the previous workload. Making fixes earlier in the pipeline, and then rolling-out new versions through automation results in reduced downtime for patching, which consequently impacts how security teams plan on fixing vulnerabilities.

Confusion arises when security teams are still under the impression that fixes will be made in runtime. When this happens, it puts them at a disadvantage when security issues are ‘shifted left’ to the DevOps teams, which builds and tests the app in the CI/CD workflow.

Essentially, although the security team must still be involved in protecting against exploits and vulnerabilities in the application itself, how and when they do so needs to change. A stronger partnership with the DevOps team must be forged, and any activity must happen earlier in the pipeline.

Fostering this new mindset within both the DevOps and security teams can have huge benefits. With a cloud-native deployment model, the time spent by operations teams deploying patches can be reduced by around 75% (according to a recent Forrester Total Impact study). With fixes made earlier, workloads can simply be re-deployed as new instances. Getting it wrong, however, can lead to security gaps.

Conclusion

If teams can get to grips with these common misconceptions, they can begin planning an effective cloud native security strategy. Only through a thorough understanding of the realities of the cloud native journey can teams really begin to plan out the responsibilities, resources, controls, and new interdisciplinary relationships that need to be forged.

The most crucial part of any cloud native journey is learning about cloud native security early on in the process. CISOs should be equipping themselves with knowledge and skills around cloud native as a matter of urgency because, if security is done right, it can accelerate adoption, improve efficiency, and make security the main pillar of cloud native.