3 new rules of cloud-native application security

Just when the CISO and IT security team think they've locked down the network perimeter, they discover that it has shifted again. Two decades ago, mobile workforces punched holes in it when employees began demanding the ability to connect their laptops and phones to the corporate network while working remotely.

These days, the advent of SaaS applications has accelerated the pace of business and introduced a host of new cybersecurity concerns. New technologies for building cloud applications—such as containers, Kubernetes, and serverless architectures—are reshaping the way enterprises build and deploy business applications.

They have also introduced a new set of risks that you can't mitigate by applying traditional approaches to application security. So how do you ensure the security of your cloud-native applications? 

1. Do security throughout the development lifecycle

Before the rise of DevOps, security teams provided late-stage reviews and guidance before applications moved from development into systems running in production. Security was often engaged only toward the end of the development process, creating significant delays if issues arose that required changes to the application.

This is no longer acceptable in today's more agile development models, where speed and automation rule.

Developers are under pressure to build and ship applications faster than ever, and to update applications frequently through automated processes. To achieve these goals, organizations are now deploying applications developed on containers and functions straight into production, managing them with orchestration tools such as Kubernetes, and running them in the cloud.

As a result, productivity increases, but so does the risk.

Striking a balance between speed and security requires CISOs to implement a strategy to proactively address cloud-native security requirements with developers and the operations team to ensure security is fully integrated into the software development lifecycle.

This allows an organization to detect security issues earlier in the development lifecycle without slowing down the whole works.  

2. Install guardrails, not perimeter controls 

Many enterprises still rely on traditional security tools that cannot handle the velocity, scale, and dynamic networking environment of containers. The addition of newer serverless functions exacerbates the problem by abstracting infrastructure further to provide a simple execution environment for applications and microservices. 

Cyber attackers hunt for vulnerabilities in the serverless function code, as well as for misconfigured cloud infrastructure permissions settings to reach services or networks containing sensitive information.

Organizations can use CI/CD tools such as Jenkins, Azure DevOps, or Bamboo to continually develop, test, and ship applications. When using containers to deploy their cloud-native applications, developers can leverage base images and components from internal and external repositories to further accelerate their efforts.

However, even container images from trusted repositories may contain vulnerabilities that can make applications susceptible to attack.

The solution is to replace gates with guardrails. Providing security teams with the tools to block noncompliant images within the CI/CD pipeline is the best first line of defense.

Scanning images for vulnerabilities, secrets, and malware during the development stage allows security teams to enforce the organization's image assurance policies, block noncompliant images, and alert the developers to potential threats.

3. 'We,' not 'us vs. them'

The call for internal stakeholders to work together should also extend to your organization's relationship with its cloud platform providers. The security mantra should be "We share the responsibility," not "It's all on our cloud provider's shoulders."

This requires accepting the new reality that certain aspects of security will need to be managed by the cloud provider, and others will remain with the customer. For instance, Amazon has invested heavily in its Shared Responsibility Model. Among other things, it assigns security of the cloud to AWS, and charges the customer with security in the cloud.

According to Amazon, AWS "operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates."

Specifics can change depending on which AWS cloud services are being used, but generally "the customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall."

Understanding the shared responsibility model and its gray areas is essential to any cloud security program. Enterprises should understand that the security measures undertaken by the provider do not absolve them from their own responsibilities.

Shared responsibility is key

The first step when evaluating how your organization can apply these three new rules for cloud-native security is to embrace the shared responsibility model with your cloud platform provider.

Then, to hold up your end of the security bargain, look for tools that will help you gain full visibility and control over your cloud-native infrastructure and application workloads across all your cloud environments.