The security status quo falls short with born-in-the-cloud software

Born-in-the-cloud software, pioneered by companies like Salesforce, are beginning to dominate the computing landscape. According to Gartner, by 2020, the cloud shift will affect more than $1 trillion in IT spending, and cloud computing will be one of the most disruptive forces since the early days of the digital age.

We all realize the opportunities abound. Gartner’s Ed Anderson says, “the cloud shift is not just about cloud. As organizations pursue a new IT architecture and operating philosophy, they become prepared for new opportunities.” He goes on to state, “organizations embracing dynamic, cloud-based operating models position themselves better for cost optimization and increased competitiveness.”

But, do we really understand the critical nature of born-in-the-cloud software’s greatest challenge – security?

Security solution landscape

To realize the security challenge, it’s critical to size up current solutions to see if we have what we need to protect cloud-based software. It’s equally important to identify the key characteristics of born-in-the-cloud software to know what constitutes a good solution.

These characteristics are:

• Modern continuous integration and deployment (CI/CD) has enabled faster speed of software development (more features faster)
• Monolithic applications of yesterday have given way to microservices, each of which can scale independently
• The microservices are developed by small independent teams causing the environment to be polyglot – multiple programming languages are in use depending on the purpose of the microservice
• Diversity in deployment methods means the microservices are deployed in different IaaS environments (AWS, Azure, etc.) and in different operating environments: virtual machines, containers, and perhaps tomorrow unikernels.

With this backdrop of how born-in-the-cloud software is significantly different let’s assess some of the key categories of security solutions.

Code analysis

These tools identify vulnerabilities in software so that they can be fixed before they become problems. The challenge is that they are slow and inaccurate. Above all, the developers are measured for speed and feature delivery, not on the security of their code. Consequently, code analysis is not used often. A 2017 Jet Brain poll of more than 5,000 developers showed that the majority of developers don’t use code analysis.

There is a fundamental disconnect between the promise of code analysis tools and the nature of cloud software, which if nothing else, is more agile.

Web Application Firewall (WAF)

A web application firewall (WAF) for HTTP applications applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as cross-site scripting (XSS) and Structured Query Language (SQL) injections.

WAFs greatest limitation is that it is threat focused – matching the customer traffic to possible attacks, which causes the WAFs to be reactive and generate false positives. WAFs additionally apply the same set of signatures to any and all web applications. Some WAFs come with a learning mode that takes 2-3 days to understand the application to provide more targeted protection. In a CI/CD environment, this is too slow as the microservices environment could change multiple times a day.

Runtime Application Self Protection (RASP)

RASP is built into an application and can detect and prevent real-time application attacks. RASP improves on WAF by instrumenting the application in pre-determined key points of interest but the logic of detecting attacks is still the same, i.e., focusing on threats.

RASP offers some key advantages but has fallen short of its promise. Its adoption has been slow because it changes the application causing accountability issues (who caused the bug in the application – the application or the RASP agent?). Its effectiveness is limited to attacks such as XSS and SQL injection, and impacts the performance of the application.

Container security

Software containers are lightweight virtual machines with much leaner system requirements. Containers offer advantages to DevOps and are an essential tool in creating and protecting software applications.

Security for containers is surely desirable. But, I would argue that Amazon, Microsoft, and Google will (over time) protect the container’s attack surface, leaving security of cloud-born-software protection to us. Let’s not forget that we also need to protect software deployed on virtual machines!

Cloud compliance

When organizations move their software to the cloud with services such as Amazon Web Services (AWS), they take on unknown risks because of the IaaS. Cloud services like AWS provide Application Protocol Interfaces (APIs) to inform DevOps of what the software is doing in the cloud environment to minimize risk. Cloud compliance monitoring companies provide risk assessment analysis of born-in-the-cloud software via such APIs. It is a much-needed capability.

But, given that APIs are platform (e.g., AWS) specific as opposed to application specific, they can only inform of the symptoms of some attacks as opposed to the attacks themselves. AWS aptly recommends customers to be responsible for the security of their applications.

Thinking differently

While there is a lot of innovation happening in cybersecurity, the solutions available seem piece-meal, fragmented, and above else threat-focused. Today’s defense-in-depth approach is not designed for born-in-the-cloud software. It’s too heavy, capital and operationally inefficient, and is always reactive (in a world where we are seeing more than 100,000 pieces of new malware every day).

We need to think differently about securing software deployed in the cloud and fundamentally change our approach. As software proliferates and born-in-the-cloud software becomes the norm, the attack surface and exposure increases.

Even if cloud providers offer infrastructure protection, our key responsibility is to protect the software that we are hosting in the cloud. But, today’s software built and deployed in the cloud is like a living organism with continuously evolving components (microservices) – each with its own unique DNA. Each of these components needs to be protected.

We need to stop being reactionary and seek an approach that makes it possible to understand each piece of software, what makes it unique, and offer bespoke security that is tailored to the very needs of the software. Personalized medicine promises to do the same for healthcare leveraging one’s DNA – could we similarly extract the DNA of each piece of software and protect it?