A new approach to cloud native application security

Twenty years ago, the idea that people would be able to work remotely from their laptop or mobile device, able to access all their files, and collaborate in real-time would have been unthinkable. It goes without saying that technology has advanced very quickly and continues to do so. While this is wonderful for users, it presents some challenges for those who run and secure the applications and infrastructure that make these advances possible.

This is especially true, in recent years, in the case of cloud native applications, as new technologies for building these applications, such as containers, Kubernetes, and serverless architectures, are reshaping the way enterprises build and deploy business applications. But they also introduce a new set of risks that can only be alleviated by embracing new approaches to application security rather than relying on old tactics. Indeed, while traditional application security constructs might work on some level, they often do not work well when using the container or serverless technologies that are gaining rapid momentum to build cloud native applications.

It is not simply the case that migrating applications to a cloud infrastructure from traditional data-centre IT systems will incur greater risk or somehow seem less secure. In fact, cloud providers can often maintain higher standards of security than that an enterprise would in their own data centres. The security issues occur when enterprises begin to configure and use cloud services and are often not well equipped to secure these applications properly. Enterprises that use containers or serverless technologies to build cloud native applications, such as IaaS (Infrastructure as a Service) and PaaS (Platform as a Service), need to rethink their approach to security and do-away with their traditional approach.

Make security integral, not an afterthought

The DevOps movement has revolutionised the development process from what was once a slow, step by step process, to the quick and agile model we see today. Security’s place in this process has also been changing.

In the past, security teams would be brought in towards the end of the process and would provide reviews and guidance as a final step. However, what this meant was that if security issues were identified then the whole process would be delayed as the required changes would have to be addressed by the development team before running through the defined release process. Whereas now, developers are expected to work with speed and agility, so this prohibitively slow cycle is no longer acceptable. Developers are now looking to rapidly build and ship applications, as well as frequently update applications, and the only way to achieve this is through automated processes. Introducing delays at the end of a project pipeline would entirely derail these aims.

To enable this agility, organisations are now deploying applications developed on containers and serverless functions straight into production. These are run on the cloud and managed with tools like Kubernetes. While this approach does increase productivity, it comes hand in hand with an increase in risk. Therefore, CISOs must establish a balance between speed and security. The way to approach this is to fully integrate and automate security into the software development cycle by working with the developers and operations team to understand and address cloud native security requirements.

Closing doors on attackers

The agile and rapid networking environment of containers often overwhelms the traditional security tools that many enterprises still use. This unsuitability is amplified by the addition of newer serverless functions. These provide a simple execution environment for applications and microservices by abstracting infrastructure further, but they can also open the door to cyber attackers. If these services are not secured or configured properly then they become ripe pickings for attackers who look for vulnerabilities in the serverless function code. Attackers also search for misconfigured cloud infrastructure permissions settings that they can exploit to gain access to sensitive information held on servers and networks.

Businesses that change their processes to include security at every stage of the DevOps process, as discussed above, will be able to detect security issues and these vulnerabilities sooner, without causing delays.

An issue that occurs when using containers is that, to further increase their speed, developers often use base images and components from internal and external repositories. The problem is that these images may contain vulnerabilities that can make applications susceptible to attacks, even if they have come from trusted sources.

To stop this, developers can limit access to the vulnerabilities attackers utilise by providing security teams with the tools they need to block malicious or non-compliant images. This is a successful initial barrier whereby security teams can scan images for malware and vulnerabilities early on (using both static and dynamic models) and get ahead of the risk by alerting the developers to any potential threats.

Share the responsibility

Security can no longer be considered the sole responsibility of the cloud provider or the security team, instead it needs to be shared by all the stakeholders. Businesses that use cloud platforms will need to manage some aspects of security themselves, while some will be managed by the cloud provider or in some cases by multiple cloud providers.

An example of this approach is Amazon’s Shared Responsibility Model whereby “Security of the Cloud” is AWS’ responsibility and “Security in the Cloud” is the customers’. This system means that AWS is in charge of the host operating system, the virtualisation layer, and the physical security of the facilities in which the service operates. In turn, the customer manages, and has responsibility for, the guest operating system and any associated application software. The customer is also responsible for configuring the various services provided by AWS, which can be a complex process. The specifics of this depend on which services the customer selects but the overall split is much the same.

Approaching cloud security with this shared responsibility mindset will enable the programme to run smoothly. It is important that businesses appreciate that they have their own role to play and do not simply rely on the provider, this will ensure that the applications are fully secure. Tools for ensuring that best practices and compliance guidelines are being followed can improve the security posture of the cloud infrastructure.

Businesses that do away with their old approaches to cloud native application security and embrace the new will best be able to harness the conveniences and other benefits that these platforms have to offer.