'Strutting' Past the Equifax Breach: Lessons Learned

The industry is still feeling the lingering effects of the Equifax breach, and, according to Sonatype, some things still haven't changed. I recently came across a Fortune article that takes a retrospective look at the Equifax breach and examines Sonatype research data on the vulnerable Apache Struts component that caused the breach. The research data used to analyze the usage and consumption of the vulnerable Apache Struts component suggest that people in organizations are still downloading it and could possibly be using the vulnerable component in production systems.

For an example, the article points out that as many as 10,801 organizations — including 57% of the Fortune Global 100 — have downloaded "known-to-be" vulnerable versions of Apache Struts. It further points out that as many as 3,049 organizations have downloaded the exact same vulnerabilities that hackers exploited to break into Equifax — that is, the same holes contained in Struts version 2.2.3 to 2.2.3.1 and 2.5 to 2.5.10 (CVE-2017-5638).

Over the last year or so, my views about vulnerable components have changed, and they've been strongly influenced by the growing reliance and consumption of open source software (OSS) in modern software development. The Apache Struts consumption rate cited in the Fortune article is part of a growing realization to me that developers may have taken the position (or have surrendered to the idea) that all software is vulnerable (or at least the most popular and frequently used OSS components) and have "known" vulnerabilities. I refuse to believe that developers are that careless, reckless, and have zero regard for the potential risks in using insecure software. When time is of the essence, people tend to sacrifice optimal for suboptimal, especially when choices and selections are slim. Organizations are in a dash to beat their competitors to market with new features and functionality for competitive advantage, which often means they take shortcuts to get there.

As a dad with two boys that play sports that involve travel, we are always on the road going from one game or tournament to another, and we tend to eat more fast food during the travel seasons. At times, I feel like I'm sacrificing good eating habits because my choices are slim, and often we are pressed for time. There are other options like packing my own lunch … or for developers, building your own software components. Jim Routh, chief security officer at Aetna indicated on my podcast that based on Build Security-In Maturity Model (BSIMM) research data, the mentality of many companies on the West Coast is to build their own software (they are the supply chain) rather than buy it. I'm sure there is some OSS consumption, but the point is that there is less reliance on third party suppliers, which may ultimately help reduce risks and improve software security.

Mission Impossible: Vulnerability-Free Software
Let's assume that developers don't subscribe to my theory. In that case, I still don't believe that software can be "free" from vulnerabilities. Today's software is too complex, organizations are taking far too many shortcuts to get to market faster, there is a lack of core fundamentals of software engineering being taught in academia, tools that are designed to find weaknesses and vulnerabilities in software don't perform well, developers don't understand the consequences of their coding practices and refactoring activities on software design ... the list goes on and on. All these things become detrimental to the hygiene of software. However, that doesn't mean we should give up ... or not exercise proper due care and due diligence when scouring the software supply chain looking for software components to consume for software development projects. It simply means that we need to adjust our expectations and approaches to software supply chain risks and modern software development, especially as the adoption of DevOps increases. 

So, what does all that have to do with the Equifax breach? The Equifax breach, in my opinion, dispels the notion that "speed" is the new security. The notion behind speed with respect to security is based on the concept that the environment is constantly changing, and that change can be effective in disrupting potential adversarial activity. Ideally, that's a great posture to be in for better cyber resiliency, but I don't think we are there yet or even have figured out how to incorporate that level of resiliency into continuous integration and delivery of software. A recent study from the DevOps Report concludes that only 27% of organizations surveyed have adopted DevOps practices.

People resist change. Consequently, people become the Achilles' heel in the software engineering process. Patching, for example, is one of those hygiene activities that is essential to preventing security breaches. Still, many organizations struggle to patch timely and consistently even in a DevOps environment for fear of the "unknown." Part of the unknown and resistance to change is rooted in the accumulation of technical debt that can grow to the point it become very expensive to pay it down. At some point, owing too much technical debt will impede an organization from doing essential things (like patching). But also, things like vulnerability coordination and disclosure across different suppliers and with key stakeholders can be challenging and time consuming. As a result, the window of exposure widens, and a breach is likely to happen.

All software has known and unknown attack surface areas (minus the zero day vulnerabilities) that are exploitable. The "known" attack surface areas are typically associated with things you can find in the National Vulnerability Database (NVD), and the "unknown" attack surface areas are typically associated with software weaknesses (also known as Common Weakness Enumerations — CWE) that could expose vulnerabilities in software. I tend to think of it as attack proneness and defect proneness. In modern software development, vulnerable software has a lot to do with what Brian Knapp, a software developer calls "software gravity. " He defines software gravity as the force that pulls features, complexity, and resources toward a software system over time.

The Equifax breach reminds me of the importance of making good design decisions, especially as it relates to component hygiene. Poor design decisions increase complexity and make it difficult to patch, and also introduce considerable amounts of technical debt. As indicated in the referenced Fortune article, third-party software like Apache Struts can be challenging to maintain and patch for several reasons: Struts libraries are bundled with disparate Web applications; fixing the issues requires, among other things, knowing which applications use the components (vulnerability prevalence); updating so-called build scripts so they fetch the latest versions of the software; and rebuilding the application and running quality assurance tests to make sure the mended application work as intended.

I would argue that the decision to use Apache Struts had just as much to do with the breach as failing to patch in a timely fashion. But both of these forces together are a recipe for disaster.

Author's Note: My affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed in this column.

Related Content: