Cloud deployed software, including SaaS, is rewriting the rules for how software is developed and deployed. Yesterday's monolithic applications have given way to a multitude of microservices, each of which is upgraded several times a week, or in some organizations, multiple times a day.

The pace of innovation is astounding. Customers expect this rapid pace, and vendors view this as a key competitive differentiator. But change disrupts security. Coupled with the needs of modern cloud architecture of AWS, Azure or GCP, traditional security solutions are rendered unsuitable.

There is a need to rethink how to secure cloud workloads if software continues to be the engine of innovation. For the first time in the digital age, cloud software and SaaS enable the company that develops the software to also be the company that hosts the software for the consumption of its customers.

We no longer need to develop software in one company and ship it to hundreds of customers around the world so they can host it in their respective data centers. For the first time, we can protect software by understanding the specific needs of the software, as opposed to treating it as a black box and focusing exclusively on detecting threats.

Defense in depth of legacy security products is the current best practice of protecting enterprise software. This evolved out of a need to protect the applications a typical enterprise buys from several ISVs and deploys in its data center. This legacy security architecture is focused on detecting threats since the enterprises and the security vendors can't understand the specific security needs of applications because they don't have access to the source code.

Security efforts, therefore, continue to focus on the next best thing they can understand — the threat landscape. As a result, the key components of a defense in depth architecture include: antivirus (AV), intrusion detection systems, web application firewalls, application whitelisting and sandboxes.

The drawbacks of this threat-focused approach are well documented:

• Focusing on threats makes the architecture inherently reactive. Security vendors have to wait to see an unknown threat before they can write a signature (or algorithm) for it.
• The security products don't understand the application and rely on pattern matching to detect threats. As a result, they generate large amounts of false positives. The customer is left with the task of manually tuning the security tools to their environment.
• Several security products, such as WAFs, can auto tune themselves if given sufficient time to learn an application's behavior. But if the underlying application changes frequently, the tuning process can never keep up.
• It is inefficient in terms of capital and operations as it relies on multiple products generating thousands of false positives submitted into a security operations center (SOC) manned by several individuals who are tasked to identify signs of a true incident or attack.

Legacy security products fail to protect Cloud Software

The way applications are now developed and consumed is changing. Movement of software into the cloud and the consumption of Software as a Service (SaaS) create the following additional challenges for legacy security products:

• Ownership of Security: The responsibility of protecting the SaaS shifts to the independent software vendor (ISV) who owns the SaaS, as opposed to the customers deploying the software in their data center. Within the ISV, three important figures can play a key role in enhancing the security of the SaaS — developers, DevOps and security.
• Agile CI/CD: Monolithic applications of yesterday are being broken down into multiple microservices — hundreds, at times — each of which is upgraded several times a month or, in some organizations, multiple times a day. Legacy security tools cannot keep pace with this agility because they can't be manually tuned quickly enough nor can they learn and auto-tune themselves faster than the current pace of continuous integration/continuous deployment (CI/CD).
• Workload Distribution: Distribution of workloads across a single cloud provider, or across multiple cloud providers, doesn't provide a single control point where legacy security products can be deployed.
• Encryption and APIs: Inter-microservice communication often uses APIs and is encrypted, rendering traditional network security solutions blind. The problem of encryption can be solved by conducting man-in-the-middle decryption or re-encryption of traffic, but this can be prohibitively expensive. The usage of APIs defeats network security solutions unless they understand each API.
• Layered Infrastructure: Organizations are leveraging containers and virtual machines across one or more public and private clouds to scale their applications. Any security solution specific to one public cloud or to containers fails to meet the security requirements of a modern SaaS vendor. Moreover, as Infrastructure as a Service (IaaS) vendors are evolving to become Platform as a Service (PaaS) vendors, the focus of the ISVs should be to protect their applications. The IaaS vendors have done a great job providing infrastructure security, and as they evolve to become PaaS vendors, they will do an equally good job of protecting the operating environment — be it virtual machines, containers or uni-kernels.

Security that is merely threat focused is relegated to being reactive, and due to its pattern matching nature it generates a lot of false positives. What is needed is a new model for protecting software and limiting the attack surface proactively. A new approach is emerging that looks at and understands the security DNA of each new version of applications or micro-services.

The security DNA is the security-specific code intelligence extracted during build phase of an application. By doing this, code can be analyzed and security strengthened in the DevOps process. Looking at the actual DNA of any software app helps businesses increase the speed at which security issues can be identified and fixed.

This entirely new way to look at security doesn't impact the speed of CI/CD process. Going further, as the workload executes, the security DNA can be seamlessly utilized to protect the app against those unforeseen threats which may arise in production. Such real-time visibility of the application in production is targeted and hence reduces the false positives.

The time is now to rethink how we protect cloud software.