From equanimity to Equifax

What the Equifax breach should show CIOs and CISOs about open-source software quality

Hidden cloud migration gotchas
Hans (CC0)

Here we go again. Another terrifying breach of data, of trust, and more concretely, of a mission-critical application that manages sensitive data. Attorneys general, Congress, the FBI, the Associated Press, the intergalactic cyber task force, and everyone else are now investigating what went wrong at Equifax. Almost certainly, the board of every company that deals with sensitive data held their emergency meeting last week to get a sense of their own security posture and issue an urgent action plan to find and remediate any security gaps that may bear a resemblance to this exploit.

Many boards these days have a member who is a cyber expert. Most cyber experts are former CISOs, and most CISOs are former network security specialists. That’s because investment in network and perimeter security has outstripped application security by a factor of 23:1 taken cumulatively from the inception of the cybersecurity profession. Boards and many CISOs don’t understand software design, architecture, or construction. It’s a black box that should be tested, patched and monitored. Managing the composition and construction of software remains a job for developers and vendors.

It’s common pablum these days to say that software powers everything we do. But do the majority of us really understand what that means? Very few in IT organizations have a software risk scorecard, and most board members don’t even know to ask for one. We here at CAST have been tilting at this particular windmill for the better part of 10 years now. Mostly falling on deaf ears. “We just hire good developers to make sure we have good, secure code.” Or, “we hired XYZ vendor because they have a strong SDLC process.” Or, my all-time favorite these days, “we have an automated unit test environment in our DevOps toolchain.” Uh-huh. But, do you know if this application uses Struts? And does it use the Struts framework correctly?

For all you non-techies out there, it’s still important to understand what Struts is. It’s a framework that developers commonly use for web applications so they don’t have to rebuild or rewrite code from scratch every time. It’s one of the approximately 130 open source frameworks that are commonly used by developers around the world, and there’s a long tail of hundreds of other framework varietals out there. That doesn’t account for the fact that Struts has about 10 versions in wide use, and most other frameworks have multiple versions as well. So, for example, in the case of Equifax, the vulnerability was CVE-2017-9805, which occurred in Struts 2.3.x and 2.5.x. Yet, Struts 1.2 through 1.3.10 do not have that vulnerability.

Using frameworks is considered best practice among developers and architects. It’s more productive, and you have less chance of introducing errors. The only problem is that most of them are open source, and thus can be studied closely by the “black hats.” If there are weaknesses in that code, they can figure out how to exploit them. Some of these weaknesses have to do with composition—which version do you have and does that version have an exploitable flaw inside. Some have to do with construction—how is the framework integrated into the rest of the application that’s coded around it. Both of these factors could be exploited by a black hat who’s studied the source code of a framework.

Aside from open source frameworks, there are many well-known software weaknesses that, even in the absence of open source components, can cause software to become unstable, inefficient, easy to hack into, and even hard to maintain.

So, I have to ask business executives who rely on custom software the age-old question: “Do you feel lucky, punk?” Because if you aren’t feeling particularly inclined to rely on chance alone, it may be wise to get a software risk scorecard going. Something that uses standards, like the CISQ standards for security, reliability, performance efficiency, and maintainability, which are based on the well-defined canon of commonly known weaknesses and vulnerabilities (CWEs and CVEs). Something that covers construction and composition. Something that fills that blind spot that almost all boards, business executives, and IT managers have: understanding the level of security risk within the software that powers their company.

Until your organization has a software risk scorecard, it would certainly be smart to do a software portfolio risk audit. Quickly scan your software portfolio, find out your exposure to known vulnerabilities from open source frameworks and your structural risk hot spots, and get cracking to fix the most egregious problems in your most critical systems.

This article is published as part of the IDG Contributor Network. Want to Join?