Posted by Amit Sethi on September 13, 2017
In recent days, more details concerning the Equifax breach have come to light. There’s now speculation that attackers exploited a vulnerability in Apache Struts to steal data. There has also been plenty of speculation regarding the exact vulnerability that may have been exploited.
The Apache Struts Program Management Committee released a statement regarding the hack. It reaffirms the uncertainty as to the specific vulnerability. At this point, we don’t have any official confirmation whether the exploited vulnerability was in Apache Struts.
Assume that the vulnerability was in Apache Struts. If this is the case, how does it change our previous analysis? Let’s explore a few specific areas within the SDLC to examine security measures with open source software (OSS) and commercial off-the-shelf (COTS) software in mind:
Architectural and design controls can help to minimize the impact of many vulnerabilities in OSS and COTS software used by an application. While it isn’t possible to protect against every potential scenario, organizations must pay close attention to security during the earliest phases of software development.
Unfortunately, there is little that individual developers can do to protect against vulnerabilities in open source and COTS software within these SDLC phases.
Attackers may target any software within your production environment during the final SDLC phases. This includes OSS and COTS software. Operational controls must monitor applications and systems for any unusual behavior regardless of the exact exploitation.
We didn’t discuss this security method as the Equifax hack was unfolding. Some of the earliest assumptions were that the exploited vulnerability was in Equifax’s software. As new details are emerging, even though we still don’t know the definitive cause for the hack, it’s safe to say that organizations need to maintain an inventory of all open source and COTS software in use within their applications. Additionally, firms should ensure that old versions with known vulnerabilities are not in use.
Many attacks are the result of organizations not patching software with known vulnerabilities—or at least not patching soon enough. When a patch is released, attackers immediately get to work to figure out what vulnerability was patched (easy to do with open source software) and start exploiting it in unpatched systems.
There’s no easy solution here. Firms need to follow secure software development practices from the beginning. And it’s never too late to bring security into the process.