On September 8, 2017, Equifax revealed that they suffered a massive data breach, with approximately 143 million records compromised, including social security numbers, first and last names, birth dates, addresses, and more in some cases.
The unfortunate fact is that the breach was just one of many examples of incidents caused by software security practices and culture within large organizations that will take major work to fix.
There have been lots of opinions as to how the breach was caused by negligence. One of the most common criticisms is that Equifax failed to apply a three-month-old patch—or software update—from open source provider Apache. The logic goes that basic patch management practices should have caught this oversight.
The issue with this line of thinking is that basic patch management—which has existed for years—tends to apply to technology infrastructure, such as operating systems, server software, databases and networks. The software at issue in this breach was part of a software library (Struts 2) that isn’t within the scope of many network-centric patching processes. The danger posed by this blind spot in patch management was highlighted in recent years by well-known security incidents and vulnerabilities, most notably HeartBleed.
A category of tools does exist to shore up software libraries. Dubbed software composition analysis (SCA), they are increasingly becoming part of the standard offer of static analysis vendors. Gartner estimates that 20-50% of the target market uses software composition analysis (SCA), which means that 50-80% of the market doesn’t yet use such tools. Wider use throughout the industry could be a significant step preventing similar breaches in the future on a technical level.
Yet even if a company uses SCA tools, applying a pivotal patch to a software framework is often not a trivial task. Even a minor change in a framework can impact every part of application functionality. In our experience, a framework upgrade is often considered a major undertaking for an enterprise web application development team. This increases the incentive to resist patching.
In this respect, the process of upgrading a framework is not particularly different from patching a custom web application vulnerability. According to WhiteHat Security, only 48% of such vulnerabilities in the financial services industry are ever patched at all. Even when they are fixed, it takes 160 days on average to apply such a fix. While tools and procedures exist to address this problem, the organizational burden often prevents them from getting fixed.
Beyond this, the vulnerability that was exploited for the breach can be attributed to an even more important root issue. There was a technical vulnerability in the Struts library itself, and it wasn’t the first-of-its-kind. The pattern of finding a certain kind of software flaw and then having it crop up in software again and again for years is commonly accepted in software development processes, and this needs to stop. Software development organizations following industry standard best practices have no obligation to introduce a feedback loop that prevents a class of vulnerability from reoccurring.
Several frameworks exist to build more robust secure software development processes, including (but not limited to) ISO 27034, Open SAMM, and BSIMM, which do introduce the need for such feedback loops.
There also exists a class of tools called Application Security Requirements and Threat Management (ASRTM) that facilitate adopting these frameworks. Yet a recent study by LinkedIn and (ISC)2 revealed that only 6% of companies say their application security teams are advanced enough to use such a framework. It is much more common to pay little attention to secure software development, even for independent software vendors.
A major contributing factor for this stems from the lack of emphasis on software security at the cybersecurity policy and framework level. When a company starts to build their cybersecurity program, they select a broad framework like the NIST Cybersecurity framework or the ISO 27002 as the basis.
Within these frameworks and most compliance standards, there is dangerously little mention of software security. When a CISO looks at the often insurmountable problem of securing an enterprise, they need to ruthlessly prioritize. Limiting the scope of the program to only those areas highlighted by an industry accepted framework is a good starting point. This might help explain why CISOs rate secure development as tied for 13th out of 17 priorities, according to SANS.
Another contributing factor is the bounds of authority of the security organization. Generally, the CISO has authority to perform testing and make changes to infrastructure, but is unable to exert mandates over software development teams. The person accountable for software development and acquisition—often the CIO—must take charge to force these changes. Yet the CIO is accountable for business results to other members of the C-suite, and is often focused here rather than security.
The board of directors—ultimately accountable for risk management—can play a role to force secure software to be a priority, but, unfortunately, there is little discussion of software security at the board level because it is often seen as too low level and technical. The recently released NACD Director's Handbook on Cyber-Risk Oversight doesn’t mention software security.
Anyone looking to identify a fixable vulnerability or single out a culprit inside of Equifax to explain this breach is missing the bigger picture. Until these dynamic changes in software security practices and organizational structure take place, we are doomed to see breaches like this recur.