The growth of Software-as-a-Service (SaaS) has fundamentally changed the security model. As applications shift from on-premise to the cloud, the burden of securing them also shifts: from customer to developer. The old security tools were network-centric and deployed locally by the customer: new security tools must be application-centric and built into the development life cycle.
Traditional enterprise security best practice dictated use of vulnerability scanners that leveraged public vulnerability databases, such as NVD/CVE. The identified vulnerabilities then drove patching priorities and policies of runtime protection tools such as (Next Generation Firewall), the IDS/IPS (Intrusion Detection/Prevention) and the WAF (Web Application Firewall) to protect the applications in line from the vulnerabilities.
If CVE/NVD didn’t have a vulnerability listed, the vulnerability scanners couldn’t help. And the runtime protection tools couldn’t write vulnerability based signatures, which were far more accurate than attack based signatures — and therein lies the problem.
Vulnerabilities in packaged software can be quickly added to databases of known vulnerabilities. This can happen in many ways - the ISV may mention that the current version contains a fix for a vulnerability existing in a previous version, cybersecurity experts may uncover a vulnerability during penetration testing, or customers may discover abnormal behavior in the application during usage.
The same remedies, however, are not available for SaaS applications. Since only the SaaS vendor has access to the code and hosts it as SaaS, there are no release notes mentioning vulnerabilities. Neither can the SaaS application be scanned for vulnerabilities except for the limited attack surface that can be scanned through ports 80/8080.
This case of disappearing vulnerabilities is evident from the data extracted from CVEDetails.com. With reference to the chart below, pay special attention to the number of vulnerabilities by vendor’s on-premises product versus the number of vulnerabilities identified for the same vendor's corresponding SaaS product.
Microsoft’s exchange server has 91 identified vulnerabilities; there are 423 vulnerabilities identified for Microsoft Office, but there is not a single entry for Microsoft Office 365. Similarly, Oracle Database Server has a total of 422 vulnerabilities, but there is no entry for Oracle Database Cloud Service. IBM DB2 has 122 vulnerabilities, but there is no entry for IBM DB2 hosted.
In case after case, vulnerabilities for the vendor’s cloud-hosted software are minimal or nonexistent, but vulnerabilities for the same vendor's shrink-wrapped products are abundant.
This data clearly shows that vulnerabilities for SaaS software will not be part of public databases of vulnerabilities. While the practice of identifying vulnerabilities existing within the app and correlating this with tools for runtime protection is basically sound, the SaaS vendor cannot rely on public databases of vulnerabilities.
Instead, the SaaS vendors have to conduct code analysis to identify vulnerabilities. Given their rapid CI/CD cycles, SaaS vendors need next-generation code analysis to identify vulnerabilities — code analysis that takes only seconds, identifies the usage of sensitive data and identifies vulnerabilities in all application components, including OSS and third-party libraries. The results of code analysis during development should also be available to protect the application at runtime.
However, instead of simply copying the legacy security strategy and correlating the results of code analysis with an off-the-shelf security solution (like NGFW, IDS/IPS, WAF), we can do better.
What the network-centric runtime security tools lack is application context because they weren’t conceived with access to source code. However, just as DNA varies among humans, applications have a security DNA stored in their source codes. Understanding this security DNA is the key to building application centric security for modern applications.
Security DNA defines an application’s attack surface. It’s not only understanding what open source libraries are used, but also which data is sensitive, where sensitive data goes and fundamentally what the software is supposed to do. Then multiply this across each microservice, each platform hosting the code and rapidly shortening of release cycles. Clearly application security processes that rely on manual intervention or tuning won’t scale in SaaS environments.
By extracting the security DNA from source code, automated policies can be created to protect every version of every application in runtime. This also eliminates the overhead of traditional network-centric solutions that encompass signatures for hundreds of apps, network elements and operating systems. Since the correlation between runtime protection and code weaknesses can be automated, no human intervention would be necessary. Only then can application security fulfill its true goals: agility, accuracy and performance.