(Part One of a Three Part Series)
Unless you have been out of the country or otherwise shunning the news, you have likely heard that on September 7th and again on September 15th, Equifax reported that it suffered a security incident from May 13th through July 30th, 2017. This breach is broad reaching in its individual exposure and potential future impacts, having potentially exposed the personally identifiable information (PII) of roughly 143 million U.S. consumers, including names, Social Security numbers, birth dates and, in some instances, drivers’ license numbers. The company also reported losses related to consumer credit card data, PII on dispute documents and limited PII for certain U.K. and Canadian residents.
The event is proving to be painful for the company as well: the CEO has been summoned to testify before Congress, the CIO and CISO have “retired,” and there was a massive drop in shareholder value the day after the announcement.
The company’s investigation is continuing, and neither I nor my company are directly involved in the matter. However, as a cybersecurity assessment and advisory firm to over 1,400 enterprises, we are already able to see some lessons that every enterprise can learn from the Equifax incident. This blog is the first in a series of articles we will be publishing on the topic to help organizations prevent, prepare for, and respond to cyber incidents in their own environments.
Lesson #1: You May Not Be as Secure as You Think You Are
Equifax reported that attackers exploited a vulnerability in the open source web application Apache Struts. Recently, media outlets have reported that Equifax had the patch for this vulnerability, but failed to install it in a timely manner before the second attack in May – an oversight considering prompt action would have deterred this second event. Granted, for a company of Equifax’s size and scope, this was not a routine exercise – it would have been one of enormous size and scope, consuming considerable resources. But this incident emphasizes the importance of patching and the consequences of delay.
If you are looking to avoid this kind of pain, you might consider instituting a regimen of assessment and testing activities aligned with the NIST CSF, so that you have assurance that your controls are working effectively.
In this case, the company’s Asset Management processes (part of the “Identify” function) may have failed them, potentially by missing one or more applications that used the vulnerable software. Another likely control failure is related to Risk Assessment. Nobody can make completely accurate predictions, but security teams do need to provide management with estimates of the likelihood, probability and magnitude of potential losses. As information becomes available, it will be interesting to see how the company was funding and prioritizing its security program, and if those investments contemplated losses of this scale.
Over the coming weeks and months, we expect the company and the experts it hires to conduct a thorough analysis of the incident and release what it can to the public. We look forward that analysis, since such discussions help us learn and provide better cyber risk management to the enterprises we serve.
Lessons Learned: Protecting Confidential Data Blog Series
Part 1: You Might Not Be as Secure as You Think
Part 2: The Value of Governance in Minimizing Cybersecurity Incidents
Part 3: How You Respond Can Make All the Difference