Posted by Mike Pittenger on September 18, 2017
You’ve probably heard that personal information, including social security numbers, was stolen from Equifax. Here’s what you need to know.
If you’re reading this, you have no doubt heard that personal information, including social security numbers, was stolen from Equifax—one of the Big 3 credit reporting agencies. From an industry standpoint, here’s a quick takeaway.
For a lot of breaches, the impact on the public is minimized. Receiving a new credit or debit card in the mail along with the offer of free credit monitoring quietly became the new normal. The Equifax breach, however, is different. The information required for identify theft was stolen for over half of the adults in the United States (per the 2013 census). This is the civilian equivalent of the Office of Personnel Management breach of 2015.
The information is available for sale on the dark web already. You, and people you know, have a good chance of being adversely affected by this breach. In the best-case scenario, you need to closely monitor your credit (I spent $30 and placed a credit freeze on my report). In the worst-case scenario, someone is going to be opening bank accounts, taking out loans, or getting healthcare in your name.
There is plenty of blame to go around when a vulnerability is known to the public and an exploit has been published, yet the relatively simple update is ignored. We don’t know yet whether a patching policy for open source vulnerabilities was in place and wasn’t followed, or if monitoring for open source vulnerabilities was not part of Equifax’s standard security procedures.
In any case, blame needed to be placed. Equifax acted by removing the CIO and CSO from their positions. The fallout may continue, however. The Board of Directors needs to decide how best to show that they are taking security seriously, and replacing other top executives may be an option. Executive-level support of security programs is critical to their success, and the CEO will likely be asked by his Board how he prioritized and supported software security. The CEO will also be testifying to Congress about the breach, and the company may well be under investigation by the Federal Trade Commission.
Privacy violations are likely to garner more attention from legislatures as well. If security is not treated as a priority, and regulatory standards like PCI, HIPAA, and GDPR are not addressed with appropriate measures, I believe CIOs are placing their careers in jeopardy. The consequences of breaches, in terms of both finances and reputation, are simply too great to organizations. Like any other critical role, performance matters.
Rarely is the root cause of a breach disclosed publicly. Organizations don’t like publicizing their mistakes and giving adversaries clues as to other attack vectors that may prove successful. In this case, however, Equifax came clean. I doubt they will be the last victim of this vulnerability.
It makes sense that the longer a vulnerability goes unpatched, the greater likelihood of an attack. While Equifax was successfully attacked within a couple of months of the Struts vulnerability’s disclosure, we often give attackers far more time than that. On average, the open source vulnerabilities identified in the audited applications had been publicly known for more than four years.
There are over 3,000 vulnerabilities disclosed in open source each year. It’s long past the time when organizations could rely solely on vulnerability assessment tools for their custom code. Both Rapid7 and Tenable had rules for this issue, but that is the exception rather than the rule. Outside of Linux patches, only a handful of vulnerabilities in open source are covered by these tools. For all of the others, organizations assume responsibility for monitoring the National Vulnerability Database, other threat feeds, or project home pages for updates and announcements.
Remember that this is not an indictment of open source. Open source, like commercial code, is software. It’s going to have vulnerabilities. Like most vulnerabilities in open source, this one was disclosed responsibly, and a simple fix was published concurrent with the vulnerability disclosure. Equifax had plenty of time to remediate the issue prior to the attack.
This assumes, of course, that Equifax knew which components they were using. Synopsys research shows that this is not simple without automation. The average customer of our on-demand audits knew of less than half of the open source components they used. Obviously, if you don’t know you’re using a component, you’re not going to track it for vulnerabilities.
Get the latest Software Integrity news, thought leadership, and more.