Tracie Berardi, Program Manager, CISQ
The Equifax data breach in 2017 was the result of attackers exploiting an unpatched vulnerability in Equifax software. The vulnerability – Apache Struts: CVE-2017-9805: Possible Remote Code Execution as titled in the NIST National Vulnerability Database – was a flaw discovered in Apache Struts web application software. Equifax was employing the open source code from Apache. The patch became available in March. The breach of Equifax occurred two months later in May. Outrage, lawsuits, and Federal investigations ensued…
A couple of key takeaways from the breach –
- Developers commonly use third-party components, both open source and commercial-off-the-shelf, in their code and products. It is critical for the development team to maintain an inventory of its third party components to manage the component’s source, versions, and patches. SAFECode has published an excellent guide on the subject. Read: Managing Security Risks Inherent in the Use of Third-party Components. In the case of Equifax, action came too late.
- Basic security prevention can help to protect against CVEs and future zero-day vulnerabilities. A subset of CVEs are issued with a mapping to relevant CWEs. The CWEs represent the vulnerability’s root causes and source vectors for exploitation. The Equifax CVE, for example, was mapped to CWE-20 (improper input validation) and OWASP A4 (broken access control) in the OWASP Top 10 2017.
The security weaknesses underlying the Equifax breach are highlighted in two major industry resources – the Top 25 CWEs maintained by MITRE Corp and OWASP Top 10 maintained by the Open Web Application Security Project (OWASP). As part of a secure development process, developers should continuously review their code for CWE-identified weaknesses. Many security tools automate detection of CWEs for this purpose. The CISQ Security measure is based on the Top 25 CWEs that can be detected through static code analysis. By mitigating CWEs early and often, a team can prevent future exploits and creation of future vulnerabilities.
As concluded in a recent CISQ board call, “Zero-day vulnerabilities really represent CWEs that were already there that somebody else was more committed to finding in your software than you were.” – Joe Jarzombek, Global Manager of Synopsys Software Integrity Group
There are a number of resources and stakeholders involved in helping the industry get further ahead on the zero-day CWE problem. In future posts we’ll explore what current mechanisms work and what the industry can do better to proactively address this issue.