Congressional Report on the 2017 Equifax Data Breach

The US House of Representatives Committee on Oversight and Government Reform has just released a comprehensive report on the 2017 Equifax hack. It’s a great piece of writing, with a detailed timeline, root cause analysis, and lessons learned. Lance Spitzner also commented on this.

Here is my testimony before before the House Subcommittee on Digital Commerce and Consumer Protection last November.

Posted on December 19, 2018 at 6:00 AM20 Comments

Comments

jim December 19, 2018 9:58 AM

Thanks for pointing to this. It makes me spitting mad that this business model (and this is no different than the business of Facebook and others) is allowed to exist and this company in particular is still in business. Shame, in my opinion, that ordinary citizens can’t afford to purchase some congress critters to make it illegal.

Humdee December 19, 2018 11:16 AM

I clicked through to Lance Spitzner’s commentary and I not impressed by it. It is typical business thinking: people who always want the new employee to have none of the flaws of the old employee, while ignoring the fact that the new employee will have different flaws of their own. There is no business structure that can compensate for the human equation: that was the mistake the initial CEO made ten years ago when he siloed the CSO and CIO who didin’t get along, and they “fixed” the problem by making the same mistake in a 180 degree direction. Deck chairs on the Titanic.

vas pup December 19, 2018 12:25 PM

@Bruce: Read your testimony with pleasure: great logic based on facts not emotions, but the idea US Congress will follow good European model (kind of US GDPR)looks very distant. E.g. whole civilized world including UK and other countries adopted ISO measurements standard: meter, C0, kg – not foot, F0, pound, but only three left (US, Liberia and Burma – sorry,forgot proper spelling of current name of that country). That is why I am in doubt of reasonable changes you’ve suggested, and we do not need reinvent the wheel – there are good examples on State level even within US on privacy protection (e.g. California legislation).

Could you please clarify for me this part of your testimony: “Better is to reduce dependence on systems of identification and to create contextual identification where necessary.”, i.e. examples of contextual identification. Thank you.

Jeffrey Radice December 19, 2018 5:37 PM

Actually @Humdee, I was surprised at how apt Spitzner’s commentary is. Having the CISO report to the CEO is a much better arrangement for most organizations.

It’s possible in some organizations that is the functional equivalent of rearranging the deck chairs, but having the CISO report to the Chief Legal Officer is a surefire conflict of interest, because the CLO is first and foremost concerned with how to cover the organization’s ass not how to resolve security issues. I would argue that CISO reporting to CIO is also a conflict of interest. Unfortunately most boards, CEOs, and companies in general seem to want a weak “go along to get along” type CISO — who can be the fall guy if something does go wrong — instead of having a strong voice in that position loudly advocating for security and thus creating more work for everyone.

Clive Robinson December 19, 2018 9:01 PM

@ Thoughtfood,

What is described as “contextual identity” has been discussed here of and for quite some time as “role based identity”.

In general it’s easier for people to understand they have multiple roles in life rather than multiple contexts. That is contexts are too finely granular for many to get their head around, where as a role as “parent”, “sibling”, “employee”, “club member”, etc is just easier to get to grips with. More importantly roles are because they are easier to understand are also easier to manage.

Take the example of going to the theater, yes the context is theater but what role is the person in when taking the action of “going to the theater”? People naturaly see roles, contexts are seen as “actions” thus people would assume the context as an action would inherit the identity of the role the action is being carried out in.

Having an ID for every action a user takes such as “have breakfast” quickly becomes ludicrous the same applies to contexts.

Another issue is interaction of roles in normal life we are seen as “employee.’fred Smith'” not “‘Fred Smith’.employee” that is the role is actually dominant over the individual. Unfortunately bureaucrats see people not as role filling individuals but an individual with singular attributes which causes conflicts. Hence all sorts of problems arise when you have two jobs or two pensions and all manner of other things, that do not happen if the role is dominant and has the attributes. Which is the way people see the world, that is they have a work credit card and phone and seperatly a personal credit card and phone.

Jon (fD) December 20, 2018 3:20 AM

Like many others, I suspect, I’m still waiting for the Congressional Report that includes “and [these people] were imprisoned for X years and fined (personally – Not the company, but personally) $X million dollars for the betrayal of the public trust through either recklessness, incompetence, or deliberate malice…”

Not technically a crime, I believe, but there are so many laws about everything it’s impossible that it didn’t violate any of them. Not further that the punishments are that drastic either – compare the sentences for ‘selling out your country’ versus ‘selling $100 in crack cocaine’.

Sorry, “Early retirement” (with benefits?!?) is not much of a punishment.

Anyhow, it’s nice that Congress actually reported on it. I wonder how many Congressmen (and women) were affected by the data leak.

Jon (fD)

Ergo Sum December 20, 2018 6:20 AM

The report and the articles analyzing the report are somewhat misguided in my view. While certainly people/structure issue played a role in the Equifax breach, the IT and its CIO culpability should not be masked. If and when the CSO and CIO are not working together in keeping systems up to date with security patches, be that personal and/or organizational reasons, the CIO has to has to be responsible for IT security.

In that case, it is the IT department that is ultimately responsible for the keeping systems updated with patches, just like they did with all other patches prior to and after one Apache security update.

People responsible for administering systems are not just responsible for keeping systems running, adding UIDs, etc. They are also responsible for monitoring security vulnerabilities for systems under their control and based on the severity rating, file change control request, schedule the installation of the relevant patches.

Yes, it had been wrong separating the CSO from IT operation and tasking her with compliance reporting for the CLO, but that’s the job she had. But that does not mean the CIO, and by proxy members of his team, should not bear responsibility for this data breach.

vas pup December 20, 2018 9:16 AM

@Thoughtfood and @Clive:
That you very much for link and clarification provided.
As my humble understanding, all other data bases except Social Security Administration where particular person’s role is represented should not have SS# as unique identifier, but rather generate by their own algorithm (protected from snooping, stealing, replication, etc.) unique ID (no collision) which could utilize SS# just once as seed to generate such hush ID#. E.g. for driver license, insurance card, firearm ID.In that case without your authorization the only way to do xref of your personal data in multiple data bases is not by unique key (ID) across all of them (private and public), but by your Name (First, Last)which would be time consuming. For fast xref you need to know contextual (role) key for each DB.
In most cases for private data bases they should have generate own unique customer id only used within their contextual area.
Clive and Thoughtfood provide your grinding of my point so I did properly understand the concept. You can’t imagine how long it took to change health insurance cards (Medicare in particular)to provide unique id # nor equal SS# on them.

Chris December 20, 2018 9:45 PM

Thank you Bruce for pointing this out. This detailed and factual report is a must-read for IT security professionals.

A sad fact is the failure to detect the breach immediately because the exfiltration system had a stale SSL certificate. To renew a SSL certificate takes minutes and costs $10. This reminds me of the O-ring failure on the Challenger shuttle.

Denton Scratch December 21, 2018 5:04 AM

The report is confusing. Apparently the breach occurred in the Automated Consumer Interview System, a legacy system “developed in the 1970s” and that used Apache Struts.

Well, Apache Struts is written in Java. Java came into existence in about 1998. And in fact, as far as I can see Equifax was using Struts 2, which (according to Wikipedia) reached its first full release in 2007. That’s a 30-year error, which is a long time in IT.

Of cource, it’s possible that EquifaX were using Struts 2 for a security-sensitive project before it had been fully released. If that was the case, then that’s another security failure; but it doesn’t get a mention, at least not in the Executive Summary.

Large commercial information systems in the 1970s were mostly built using COBOL, a language wholly unsuited for writing secure multi-user network applications; but obviously that’s not what the original ACIS system was.

The current ACIS system is a public-facing web-based system; there was no world-wide web in the 1970s. Even by 1988, the internet was a mean thing, with only a few hundred nodes, none of which was commercial. People still used gopher. So this ACIS system that was violated must be unrelated to the legacy system that was developed in the 1970s. It is idiosyncratic in the extreme to refer to a system that can only have been developed since 2007 as a ‘legacy system’. That stuff about legacy systems is a red herring, and has no business appearing in the Executive Summary, where it is certain to be misunderstood.

I didn’t read past the Executive Summary; with mistakes like that in the first few paragraphs, I didn’t think it was worth the effort.

Denton Scratch December 21, 2018 6:11 AM

Hmm – upon reflection, perhaps the Struts system is just a web front-end for a legacy system written in the 1970s in COBOL. Maybe I should have been a bit more circumspect. But even if that’s so, I think the Executive Summary is confusing and misleading.

Clive Robinson December 21, 2018 6:48 AM

@ Denton Scratch,

Maybe I should have been a bit more circumspect. But even if that’s so, I think the Executive Summary is confusing and misleading.

What about the poor soul who had to write it, they probably had no clue as to what the words ment… Such is the nature of these types of enquiry,

Up on the hill they used to have a department of technological advisers but the GOP apparently decided they were a needless expense… Maybe they should reconsider… The report certainly reads like they need the input.

Thomas December 23, 2018 6:30 AM

Denton wrote, “So this ACIS system that was violated must be unrelated to the legacy system that was developed in the 1970s”

Back in the days those systems are full of backdoors and magic keystrings courteous of you know who, so I would not be surprised a bit if true.

Fritz Anderson January 15, 2019 8:31 AM

Dead link: https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf

New link: https://republicans-oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf

It appears the incoming majority has re-pointed the Committee’s archive searches to documents originating from its own party; the revised link points to the same document held in the records of the current minority.

(I’m not naming names because this is no more than the routine hardball of the House of Representatives. Majority reports are often skewed in favor of the majority party. The other party can’t be expected to sponsor what may be against its interests; whether one particular report is of continuing value is a judgment call it can’t be expected to pick through.)

Keith Moore January 16, 2019 2:31 PM

Just skimmed this and I do like how it covers chronology, root cause(s), and technical remediation. However I am really left wondering what legislative value it has. I see no evidence of significant legislative action nor is there anything represented in the recommendations that seems to embolden government representatives to protect consumers, restrict or limit exposure (or better yet, increase the COST risk for these CRAs). The references to the FCRA and GLBA are mostly in retrospect and do not seem to deliver any significant legislative action to enforce the existing acts or protect consumers via real penalties going forward. Am I wrong on this? Is there actually any real significant legislative action recommended? I see how the report partially punts to the State level. To me, the legal/monetary risk of being a CRA should be the first place to recommend change. It should be a risky business, not simply a lucrative one. The CRA business is a fundamentally risky business from a personal data exposure perspective. And, if we want to change the mindset of CRA corporations, we have to leverage that as a corporate mentality. Risk means expense (legal and insurance beyond just security). Expense means cost. By forcing monumental increases in the cost of being a CRA might be the single best way to express how the business trade-off is not worth it to most of these CRA companies to operate. Legislation and prosecution should be far more aggressive and punitively costly for CRAs in almost all cases. High risk insurance is expensive. I am here to tell you that this is a high risk business that needs high cost business mechanics that might not be viable in the greater business privacy exchange. Is that a possible way to break the CRA hold on consumer data and subsequent universal passive culpability for almost anything that happens to private data in the United States? I almost never write here, but this one hits my bones. It seems to me that this is a common problem where companies do not have incentives to evaluate their cost to the business risk cost:value ratio. This example is a textbook example where the risk cost impact should be increased in order to change a corporate behavior. But I see no evidence that this is what the legislative branch will glean from this report.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.