The recent Equifax data breach has reignited the national discussion on cybersecurity. Accusations and outrage abound, but how do companies prevent hacks like this from occurring in the future?
The answer is a bit less headline-grabbing—it’s all in the code. This article details what organizations can learn from the Equifax breach and how they can prevent future compromises.
In a previous article, I explored different approaches organizations can use to tackle technical debt before it’s too late. Technical debt occurs when organizations don’t keep applications up-to-date with the current patch or point level. This exposes organizations to common vulnerabilities and exposures, known as CVEs.
The Equifax breach, an Apache Struts exploit, reinforces what most corporations are already aware of: Companies are vulnerable because they fail to regularly patch their applications.
This raises an obvious question: why? There are a variety of reasons for the lack of regular patches: Dependencies, old links in documentation, a lack of time allotted to test newer versions, and the simple fear of change.
Why data breaches happen
Compatibility is also a big factor, as we’ve seen in our work over the years. Struts versions have unsupported or broken features, plugins, and prevent easy upgrades. These reasons are likely excuses as to why Equifax couldn't—or didn't—apply the engineering resources needed to upgrade to the latest patch level of Struts to protect their customer's data from the exploited hack.
In most companies, engineers are pressured to deliver functionality and business value over upgrading software components and keeping libraries or tech stacks current. Information security officers have been highlighting these CVEs to application development and the business. It’s a risk decision put to businesses to determine where their development dollars are spent. Ultimately, the risk can easily be the downfall of a company who chooses not to address CVEs promptly.
The Equifax breach illustrates the perils of using open-source technology that has been exploited—something many companies do, not just Equifax.
While most companies use perimeter security such as firewalls, DDOS, intrusion detection, and other measures, this exploit parallels SQL Injection attacks, where perimeter security doesn’t catch the hack. The exploit is injected into the web server, which allows hackers to spread throughout the organization. They can then access data that would otherwise be safe.
Even in the day of Agile development with DevOps, continuous integration, and continuous delivery, many of the application build processes use static references to the dependencies and libraries, which become part of the product in production. These static references in the build (e.g., POM file), or in a static repository such as Nexus or Artifactory, are part of the problem. The other extreme is to update libraries and dependencies with every build, using tools such as Gradle or Git. There’s a happy medium that needs to be governed by the overall scrum process to ensure all security and current versions are incorporated into builds and releases.
Keep your Apache Struts current!
If we look at the Struts example, there are many publicly available Struts versions incorporated into various companies’ web applications:
- 1.x: The original version of Struts had versions 1.0.x, 1.1.x, 1.2.x and 1.3.10
- 1.3.10: Most current version of Apache Struts 1.x supported but general end of life
- 2.x: The second version of Struts (Struts2) currently has versions 2.3.x and 2.5.x
- 2.3.34 and 2.5.13: Most current version of Apache Struts 2.x supported
All these Strut versions are available on Apache open-source downloads. All are used by various Fortune 1000 companies.
At the time of writing this article, there are 74 known CVEs in Apache Struts technology which have been publicly acknowledged and patched. This tally does not include undocumented CVEs, however—the real number of exposures is, in all likelihood, significantly higher.
Is your application safe? That depends on what version you’re running. Are you current? If you’re not at Struts version 2.3.34 or 2.5.13, then you are not up-to-date—you are vulnerable.
Ways companies can prevent future data breaches
What can you do? A simple upgrade of Struts may not be simple. It may require remediation of specific APIs contracts, source-code changes, or a refactoring into new technology stack components. In light of recent public exploits, we’ve had a stream of requests to engage in assessments of Struts-based applications. In a recent case, our team executed a high-level analysis and mapped out a path to replace Struts with other technologies, rather than trying to patch and repair the old Struts.
Some key lessons to incorporate before you’re exploited, too:
- Keep track of Common Vulnerabilities and Exposures (CVE) through a reputable source such as MITRE
- Keep a detailed list of all your software's dependencies, libraries, and components, by version. Keep these at the most current general release version
- Incorporate release dependency as part of the build process— download the current version from the internet, GitHub, or other repository to include in the continuous integration process, forcing currency into each build and release
- Ensure your business partners factor 20 percent of their quarterly release budget to keeping applications and their dependencies current.
- Break larger applications into smaller sub-components to manage these pieces independently and more quickly address CVE or current version issues.
We can bring the Lean and Agile process to bear and quickly turn your challenge into your next business value—even if it’s to reduce the risk of an exploit against your company’s data or systems.