Identify security hotspots in your apps and STOP hackers from exploiting you

The story behind Equifax: one of their most exposed web application was using an unpatched version of Apache Struts 2. This lead to a critical security breach which was exploited by hackers who didn’t even need to be authenticated and stole millions of Equifax’s customer data. The breach made headlines and caused a myriad of issues for both Equifax and Apache. The most important lesson learned is we need to be more proactive and know our vulnerabilities before it’s too late. This article explains how CAST Highlight can help you detect and mitigate vulnerabilities before hackers find them, thanks to 2 important features: automated framework discovery feature and continuous CVE database lookup.

What is a CVE?

A CVE (Common Vulnerabilities & Enumerations) is “a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety)” (source: NIST).

In other words, a CVE is a known/documented issue or flaw in a specific version of a software component. Whether it is commercial or open source, your application is at risk from a security standpoint if it’s in your production environment.

Launched by the National Institute of Standards and Technology (NIST) and regularly updated by the MITRE, the National Vulnerability Database references around 100K vulnerabilities distributed across 2300 software products. Some of them are very famous like Linux Kernel with the highest number of vulnerabilities. Android with the highest number of CVEs found in 2017, others are less known by a larger audience but maybe used somewhere in your applications. For instance, Yassl had issues, it was embedded into some versions of the well-known MySQL database and exposed software to DoS attacks.

The amazing thing about this CVE database is that the information is structured the same way across all entries and allows us to categorize the vulnerabilities:

A unique CVE Idendifier and status – E.g. CVE-2017-5638
Product and Vendor – E.g. Apache / Struts
Version(s) where the issue is found – E.g. 2.3.5.*, 2.5.3.*
The kind of issue (mapping with CWE classification) – E.g. CWE-20 (Input Validation)
a CIA (confidentiality, integrity, availability) impact categorization – E.g. C:High, I:High, A:High
a characterization of what is needed to exploit the vulnerability – Eg: Attack Vector (Network), Complexity (Low), Privileges (None), User Interaction (None)
References to advisories, solutions and tools: E.g. Mitigation provided by Apache
The organization having referenced the CVE (e.g. US-CERT/NIST), date, last revision, etc.
A global score that helps InfoSec and development teams prioritize actions (e.g. 10 out of 10 / CRITICAL)

CVE detection and reporting in CAST Highlight

CAST Highlight detects hundreds of open source and third-party components and (most of the time) the version used in the application. The CVE feature in Highlight is all about crossing this information with the vulnerability database detailed above. Highlight queries the CVE database to verify if a detected component and version (e.g. apache.struts 1.3) has known security issues and helps the development teams to quantify and prioritize mitigations within a given application. The CVE count is distributed across four levels of severity: critical, high, medium and low. You’re just one click away of knowing which components you should quickly upgrade to close doors to black hats.

At the component level, users can also quickly see if CVEs have been found, the precise version number and the severity levels. A simple click reveals a quick overview of the issue. From here, you can learn more about the issue itself, impacted versions, communication from the vendor and/or security expert communities, and finally decide whether this issue is relevant or not in the context of your application. As seen for Equifax and their unpatched version of Apache Struts, most of the time a simple upgrade to a safe version would be enough to mitigate the risk and secure the application.

And because we absolutely want application insights the most reliable for your organization, users can also report a false positive if they consider our component search algorithm didn’t match with a CVE item. This request will be analyzed by the product team and considered to enrich the search algorithm.

How to use the feature: Put InfoSec insights and CVEs into your app portfolio context

Now you’re able to detect components’ vulnerabilities your applications may embed, that’s the perfect moment to take a step back and consider what probably most of InfoSec teams lack nowadays where they sometimes miss the point: what is the business context of the application? Is it important enough to the business to justify the additional and unexpected cost of a component migration? Is this specific application even exposed to attackers over the standard networks?

We don’t want Highlight to be a security pure player but it has nice arguments to catch the attention of your DevSecOps teams though. Highlight builds software analytics at the portfolio level and is able to conciliate both and technical worlds with organizational indicators like the Business Impact. This metric, which is derived from survey questions on the importance of an application in the business context (e.g. define the level of impact of an application failure on your company’s image: very high, high, medium, low), could definitely help you prioritize the most urgent upgrades you’ll have to perform. Highlight also gathers valuable information through surveys sent to application owners, to let IT managers arbitrate on the opportunity to fix all the leaks (you would be surprise by the number) or rationalize the effort.

Would you personally take the decision to upgrade (and re-test) an application which can be used only in your walls and without any sensitive data in it? InfoSec ayatollahs are not going to be pleased but the organization should be able to rationalize their security effort.

Security is a speed race!

Securing and protecting your software against hackers is a speed race and the only way you will avoid a malicious attack is to be aware of the possible breach at the earliest. That’s exactly where the planets align perfectly with the other features of CAST Highlight. In order to ensure your application is not exposed too long (or ideally not at all) to vulnerabilities, you need to frequently control your software at the first stages in the build chain – even before it’s shipped in production.

In the recent version of Highlight, we introduced our command line which enables code scan and result upload automation. In other words, it provides you the appropriate tooling to automatically verify the integrity of the software produced by your CI/CD chain, without any human effort. This way, you’ll be able to anticipate component patches and upgrades even before your application is publicly released (and exposed to hackers).

More importantly, CAST Highlight’s CVE insights look at the past (i.e. old CVEs your third-party libraries might still have) and are always up to date at the same time. Indeed, the feature check your application against issues from 2002 to today, and is refreshed with new (or newly updated known issues) every 24 hours.