Disruptive data breaches
The recent Equifax data breach settlement 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.
There are 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 already know...that 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 such as dependencies, old links in documentation, a lack of time allotted to test newer versions, and the simple fear of change.
Why do data breaches happen?
Compatibility is a big factor we’ve noticed based on our experience. 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. In addition, they need to keep libraries or tech stacks current. Information security officers have been highlighting these CVEs to application development and the business. It’s a risky decision for businesses to determine where their development dollars are spent. Ultimately, the risk can easily be the downfall for 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.
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 webserver, 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!
Looking 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 the 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.
Currently, there are 74 known CVEs in Apache Struts technology which have been publicly acknowledged and patched. This tally does not include undocumented CVEs. The real number of exposures is, in all likelihood, significantly higher.
Is your application safe? That depends on what version is running. Is the version current? If it's not a Struts version 2.3.34 or 2.5.13, then the version is not up-to-date—you are vulnerable.
Companies can prevent future data breaches.
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:
Track of Common Vulnerabilities and Exposures (CVE) through a reputable source such as MITRE.
Keep a detailed list of all the software's dependencies, libraries, and components, by version and 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 another repository) as part of the continuous integration process, forcing currency into each build and release.
Ensure the 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.
If you suspect you have a problem or need help to quickly address a CVE situation, engage an experienced company.
At Devbridge, we’re equipped to assess your current application, its dependencies, libraries, code, and other open-source technologies in use to determine its level of technical debt. We can determine what resources are needed to bring a version current. Alternately, we can refactor into more current technologies like Java 8, Spring4, SpringMVC, and JavaScript front-end technology (Angular, React, etc.)
We 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.
