With application vulnerability correlation (AVC) platforms gradually gaining adoption across organizations, the concept of “automatic” correlation is still not being addressed holistically. Platforms available in the market today talk about the importance of vulnerability correlation and the value they add to the application security process, but not all of them truly correlate vulnerabilities automatically. In addition, these platforms are primarily dependent on one or more of certain immutable vulnerability definitions (for example, CWE IDs) provided by testing tools to perform correlation.
If an AVC still needs a security practitioner to manually merge vulnerabilities, then the purpose of using one is lost. The fundamental value proposition for organizations to use a correlation platform is that it saves time and effort (Find Early, Fix Early!) for security practitioners AND developers. Thus, if a platform’s default function is not “automatic” correlation, then the question that emerges is, what value does it add to the AppSec process?
Let’s dive a bit deeper into a present-day scenario in an organisation using an AVC-
Consider a sample application in a mid-sized organization- that has over 500 pages containing almost 10000 fuzzable parameters. Assuming an automated security iteration is executed by a toolchain comprising of the following tools:
- ZAP + 2 commercial DAST tools (ZAP’s everywhere ;))
- 1 SAST tool
- 1 SCA tool
Muting the calculations aside, let’s assume that at an average, 4000+ scan results are uncovered by these tools every iteration and SQL injection (CWE ID-89) is one of the bugs uncovered in the scan results.
This SQL injection will be cited across all the results multiple times for every affected instance.
In some instances, SQL injection will be termed differently - SQL injection is reported by tools under several different names; SQL injection, SQLi, Blind SQL Injection, Boolean Based SQL Injection, SQL injection Auth Bypass, Client-side SQL injection (reflected DOM-based), Out of Band SQL Injection, Stored Blind SQL Injections - but for practical purposes of remediation or categorisation, the overall classification of the bug remains the same nonetheless. Assuming one of the DAST tools does not provide a CWE score, the result set would be without a CWE score.
In the absence of autocorrelation by default, a security practitioner would have to correlate 4000+ scan results obtained from the tools manually, by examining every bug and grouping the similar ones under buckets. For SQL injection -
- The security engineer will explore each instance of SQL injection mentioned in all the 4000+ results and manually group them.
- Despite being the same, instances of SQL injection are NOT bucketed under a single category owing to discrepancies in naming conventions and absence of CWEs
- In cases where a CWE is not assigned to an SQL injection, the security engineer will be required to individually look at other instances of SQL injections and determine a CWE for the bug manually
One can only imagine the incredible amount of time and effort taken by security practitioners for correlating 4000+ scan results? Let’s follow through on the workflow in this testing process.
After the painstaking task of manually correlating scan results, the results are handed over to the development team for remediation. Remember, the results are still not correlated in the true sense.
- The developer delves into the uncategorised result set, only to take an unimaginable amount of time to remediate a single category of vulnerability.
- In addition to developing new features and products, the developer has to also go through a massive security report, prioritize the bugs based on their impact and remediate them in the application.
Wouldn’t remediation be a whole lot easier and faster if all vulnerabilities of a certain type were automatically categorised under a single bucket? And wouldn’t the application be secured faster if the bugs are visible to the developer with relevant vulnerability information and remediation inputs?
Before you catch your breath, this scenario is for a mid-sized organization developing and managing a single platform. Scale the problem, to a large enterprise managing hundreds of applications. The wasted time and effort spent in manual correlation and remediation would be astronomical.
A̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶ Automatic Vulnerability Correlation
Automatic vulnerability correlation platforms, like Orchestron, save significant bouts of effort otherwise spent manually on grouping/merging scan results. Orchestron works on automatic-correlation-by-default, thereby grouping vulnerabilities uncovered by tools that are not just commonly used but also custom built variants. Automatic correlation also eliminates the possibility of overlooking any critical vulnerabilities due to human error. All of these allow security teams more time to perform comprehensive application testing.
In cases involving a variation in vulnerability verbiage (same vulnerability, but termed differently) across tools, Orchestron normalizes vulnerability nomenclature across tools assisting developers in faster remediation. This gives them more time to focus on their primary role of developing applications on schedule.
The icing on the cake is Orchestron’s Risk Language Database (ORL) that is used to assign missing CWE IDs to a vulnerability, irrespective of the tool. This allows security teams to continue using their preferred tools and not spend additional time in manually assigning CWE IDs. Additionally, ORL provides detailed vulnerability information and remediation strategies augmented with language specific secure code examples. This acts as a guideline for developers allowing them to approach vulnerability remediation in a more structured manner.
Application vulnerabilities can be fixed faster and better by developers as they have a consolidated access to vulnerability data as part of their current defect tracking dashboard. Orchestron’s ability to integrate with commonly used defect trackers allowing security teams to raise vulnerabilities as defects. Facilitating faster remediation of vulnerabilities induces effective proactive coding secure practices, thereby bringing about a positive change in an engineering team’s perspective of application security.