Security lessons from the House Oversight and Government Reform Committee

The U.S. House Committee on Oversight and Government Reform has more than a few things to say about responsible enterprise application security.

On Dec. 10, 2018, the House Oversight and Government Reform Committee released a staff report detailing the committee’s 14-month investigation into the 2017 Equifax data breach. The 96-page 35,000-word report is well worth reading in its entirety if you’re interested in how relatively small security missteps can cascade into a major data breach. But for the tl;dr crowd, here are the key lessons I took away from the report.

If you have an aggressive growth strategy, you must have a software security initiative to match

A company’s growth and accumulation of data can result in a complex—and, in some cases, antiquated—IT environment, making software security especially challenging. Even if you recognize the security risks of your legacy systems, moving too slowly to implement a comprehensive software security initiative (SSI) will leave your sensitive data exposed.

When a vulnerability is disclosed, you’re in a race with attackers

On March 7, 2017, a critical vulnerability in the Apache Struts software was publicly disclosed. Security researchers observed a high number of exploitation attempts almost immediately after disclosure. In fact, on the same day of disclosure, information about how to exploit the Apache Struts flaw was posted to several Chinese websites popular with hackers.

Thousands of organizations were affected, and even though many applied the patch to their systems immediately, the attacks kept coming. All it took to create the conditions for the breach was for one department at one firm to miss patching one custom-built internet-facing consumer dispute portal running a version of Struts containing the vulnerability.

Is open source inherently less secure?

Open source like Apache Struts is not less secure (or more secure) than commercial software, but there are characteristics of open source that make it attractive to attackers when vulnerabilities are disclosed. Unlike commercial software, open source usually does not include a support contract. That means that open source users are responsible for tracking updates for security or functionality. If you aren’t aware of vulnerabilities in the open source you use, you become an easy target for attackers.

Hackers know that many organizations do not properly track the open source they use, as we’ll see below.

You can’t patch what you don’t know about

It can be difficult to maintain adequate software asset management procedures. As the OGRC report describes, even if you have an ongoing initiative to develop a comprehensive inventory of your IT systems, including all components for each system, your inventory might not comprehensive at any given time.

No company is alone in finding it difficult to maintain an accurate list of all components used in their applications, especially when it comes to open source components. The 2018 Open Source Security and Risk Analysis (OSSRA) reported that Black Duck On-Demand audits of over 1,100 commercial codebases found open source components in 96% of the applications scanned, with an average 257 components per application.

Seventy-eight percent of the audited codebases contained at least one vulnerability, with an average 64 vulnerabilities per codebase. Eight percent of the audited codebases were found to contain Apache Struts, and of those, 33% still contained the Struts vulnerability nearly a year after that vulnerability’s disclosure, and months after the famous breach.

Another important data point found by the scans was that the average age of the vulnerabilities discovered is increasing. On average, vulnerabilities identified in the audits were disclosed nearly six years ago—versus the four years reported in the 2017 OSSRA report—suggesting that those responsible for remediation are taking longer to remediate, if they’re remediating at all, allowing a growing number of vulnerabilities to accumulate in codebases.

Your application security program needs to evolve to be effective

No one technique can find every vulnerability. Static analysis (SAST) is essential for detecting security bugs—SQL injection, cross-site scripting, buffer overflows—in proprietary code. Dynamic analysis (including DAST, IAST, and fuzz testing) is needed for detecting vulnerabilities stemming from application behavior and configuration issues in running applications.

But with the growth in open source use, organizations also need to ensure that software composition analysis (SCA) is in their application security toolbelts. With the addition of SCA, organizations can effectively detect vulnerabilities in open source components as they manage whatever license compliance their use of open source may require.

As the final line of the OGRC report states, “Private sector companies, especially those holding sensitive consumer data, … must prioritize investment in modernized tools and technologies.”

Learn more about SCA