Cloud-Native Security 101

This blog was originally published by Intezer.

The arrival of the cloud has changed the application development process. Agile cloud-native applications have replaced traditional monolithic application architectures, and components are no longer bundled into a single server. This transformation has forced developers to rethink security.

Traditional perimeter-based security approaches fall short for cloud-native applications. The deployment and delivery processes have become more decentralized and agile, but security strategies need to be revamped to keep up with development. As those strategies change and enterprises shift to cloud-native applications, what are the do’s and don’ts of security?

Cloud-Native vs. Non-Native Cloud Architecture

Cloud non-native monolithic architectures are clumsy.

With all components bundled together on a single server or two, touching the stack to make any change is a recipe for disaster. Upgrades are dreaded events leading to many sleepless nights for entire IT departments until the process is over. If you plan to add a small feature to an application built on a monolithic architecture, the entire application has to be redeployed.

Scaling applications to meet increased customer demand is a project in itself, often involving significant application updates to leverage the increased compute and storage capacity—not to mention the complexity of adding the additional capacity in the first place.

As new technologies evolve in the cloud, there are rarely plug and play interfaces for the cloud non-native applications to leverage them. Either you refactor the application, which could take significant time and effort, or resign yourself to using old technologies. Considering the complexity of the former, most organizations choose the latter.

Things couldn’t be more different with cloud-native applications, where the components have independent lifecycles, and your servers are no longer pets, but cattle. Applications are scaled on the fly to meet changing customer needs. They are designed from day one to integrate new technologies without refactoring or rewriting the code, and everything is in service of efficiency and agility. Serverless architecture and containers have made it possible for infrastructure to be abstracted to a couple of lines of code in a repository.

Along with all facets of the application, security strategies have also gone through a makeover to suit the changing paradigms of cloud-native applications. With threat vectors in the cloud changing by the day, this change is more organic than forced.

How to Approach Cloud-Native Security

Cloud-native applications need a new breed of security controls, unlike the traditional on-premises security strategies. Let’s explore different security controls suited for cloud-native deployments and how to adopt them.

The “Cattle, Not Pets” Approach

Dynamically scalable environments drive agility in the cloud, where environments are created and destroyed as needed. This means that security should be integrated with the deployment process through security as code to keep up with the speed of development. In short, security should be integrated into design from day one, not as an afterthought.

As workloads move to the cloud, deployments get automated through infrastructure as code (IaC). If you integrate security best practices into IaC, the resources will be protected when you deploy for the first time, reducing the attack surface. Deploying resources first and securing them later leaves your application vulnerable to attack.

IaC integration helps to ensure security during dynamic scaling as well. No matter how many additional instances you deploy, they will all have the security baseline integrated in them.

Focus on Runtime Protection

When compared to cloud non-native deployments, the focus shifts from perimeter security to runtime security in the cloud. While minimizing attack surface is important, it is also crucial to ensure comprehensive runtime security.

When there is a large code base to protect, protecting all the code is not practically feasible. Runtime protection acts as the last line of defense, detecting attacks that execute unauthorized code in real time.

Cloud Workload Protection Platforms (CWPP) are designed to protect your workloads regardless of their environment. CWPP solutions help prevent in-memory exploitation, which could otherwise go undetected in static disk-based vulnerability scanning. Alternatively, attackers can gain control over your resources by using legitimate software to inject malicious code. This would generally go unnoticed by security tools, as observed in the cyber attack by TeamTNT that utilized Weave Scope.

Undetected Threats in Linux

Statistics show that Linux dominates cloud computing and leading cloud service providers have openly admitted and embraced that fact.

Linux is traditionally considered secure, as it has features like SELinux and restricted user access, which is reinforced with cloud firewalls and access control mechanisms. However, recent trends show that Linux is increasingly becoming a preferred target for attackers.

Traditional Windows endpoint threat detection and response mechanisms could fall short here since it is an entirely different platform. You should consider tools that are specialized in providing advanced threat detection and security management capabilities for your cloud-native Linux workloads.

Cloud-Native Microservices

Microservice-based architectures have found their home in the cloud with a number of options, including managed container and container orchestration services, as well as serverless deployments. Managed K8s services are popular, as the control plane of the clusters are maintained by the cloud service provider.

However, keep in mind that the cloud follows a shared responsibility model, where ownership of workload security is still with the customer. Defense-in-depth security practices for cloud-native microservices should include guardrails at all layers, such as the cluster, containers and code security.

The different options for cluster security include implementation of RBAC, pod security, network security, and comprehensive application secrets management.

Moving one layer deeper to containers, where the workloads are deployed, it is recommended to implement image scanning to identify compromised images. Enabling the principle of least privilege (PoLP) for users will help to protect against unauthorized access to containers. You should also avoid security anti-patterns, such as disabling SELinux, host root access, and privilege elevation. Any configuration change should be enabled only through CI/CD pipelines, and deviations should be strictly monitored and reported.

In addition to cluster and container security, you should also ensure code security through static code analysis, third-party library scanning for vulnerabilities, use of automated tools to protect from known attacks, port restriction, and other means.

Conclusion

Cloud-native security strategy implementation is often a U-turn from what many organizations are accustomed to in traditional cloud non-native environments. While migrating to the cloud, cloud-native apps and services—and their associated security practices—should take precedence, with integration of best practices right into the code from the design phase.

The cloud demands greater vigilance. No matter how secure your deployments are, vulnerable third-party software, LotL attacks, and other threats mean it’s a constant battle to protect your runtime environment. This is why CWPPs are so important. Runtime protection, Linux threat detection, end-to-end visibility, and prevention of breaches using specialized CWPP solutions should all be factored into your security strategy for comprehensive protection of your application stack.