September 18, 2017 • RBS

Categories: Security News

As expected, the amount of news and commentary around the Equifax breach continues to pour in. We focus on some of the big points and include another roundup of news.

Running Timeline

As the events unfold, people are taking an increased interest in the amount of days that passed between two events. Typically after a breach, this centers around the time to patch for the organization to determine, at least in their minds, if the company was diligent in addressing the vulnerability. To help everyone with this, we’ll be maintaining a running timeline of the events with references.

201?-??-?? Apache notified of the vulnerability (RBS has contacted Apache asking)
2017-03-06Apache released upgrade to resolve vulnerability (ref)
2017-03-07Vulnerability published in VulnDB (ref)
2017-03-07Exploit published (ref)
2017-03-10MITRE opens up CVE ID with description and 7 references (ref)
2017-03-10NVD adds to their database via CVE. No updates since (ref)
2017-03-14CERT releases advisory on vulnerability (ref
2017-03-14Equifax aware of the vulnerability (ref)
2017-05-13Equifax breach occurred, continued until 2017-07-30 (ref)
2017-07-29Equifax detected breach (ref)
2017-07-30Equifax patched the vulnerability (ref)
2017-08-01Equifax CFO and President of US Information Solutions sold stock shares (ref)
2017-08-02Equifax President of Workforce Solutions sold stock shares (ref)
2017-08-02Equifax contacted Mandiant to help with incident response (ref)
2017-09-07Equifax notified public of breach (ref)

Based on the above, here are some numbers people are frequently asking about:

  • Equifax time to patch: 138 Days
  • Equifax time to notice compromise: 78 Days
  • Equifax time to notify public: 117 Days

Equifax International Victims?

Since Equifax is known as a U.S. company, gathering data on Americans for credit tracking purposes, many are surprised to hear that other countries are affected. We originally noted that some in the UK and Canada were impacted. Now, more information has become available about the UK victims. The National Cyber Security Centre, a part of GCHQ, has issued a statement saying that around 400,000 UK citizens were impacted by the breach. 

According to the BBC, Equifax blamed this due to a “process failure” and confirmed that the information spans from 2011 to 2016. Little is known as to how many Canadians have been impacted in the breach. The lack of transparency has prompted the Canadian Automobile Association (CAA) to take the unusual step of notifying 10,000 of their members their information may be at risk.

The reason? Between March 2015 and July of this year, CAA partnered with Equifax to provide an identity protection program to their members. CAA reached out to Equifax requesting clarification as to whether the members that participated in the program were impacted but has received little information from the company.

Patching is Hard

Perhaps the hottest debate among InfoSec, journalists, and other observers over the last few days is that of patching vulnerabilities. In the context of Equifax, some are saying that they were negligent in so many words, for not patching a critical remote code execution vulnerability for 138 days. Others jumped in saying that patching is not a simple task, that it takes time, resources, and money, especially in big organizations.

While this may seem like a simple debate, there are many other factors that must be considered. Those who work defense, known as Blue Teams, often say that if you haven’t worked a day in their shoes, you will never know the pains of patching. Those outside of Blue Teams may also level blame at all levels of the organization, ranging from the security teams to the Chief Information Officer (CIO).

Using the Apache Struts vulnerability as an example, Alyssa Feola points out that it isn’t a simple patch, as it requires updating and recompiling production code. Not everyone is sympathetic to Equifax’s security teams and management though. Daniel Franke reminds everyone that patch management is a huge job, but so is filing tax returns, and there is no excuse for failing to do so. 

Steve Tornio steps back and looks at it from a broader picture asking if patching Struts is more or less time intensive than 149 million people dealing with identity theft. Steve’s point, along with the difficulty of patching any technology, is a good reminder of what is known as technical debt. The time and costs associated with maintaining software must be considered long-term, not just the initial cost of installation and deployment. Many things factor into technical debt, including the history of vulnerabilities in the software, the average time to patch of the vendor, and more.

The Music (Gender?) Angle

On September 15th, Brett Arends published an opinion piece in MarketWatch calling out Equifax Chief Security Officer (CSO) Susan Mauldin for having a degree in music. The article firmly levels blame for the breach starting at the top with her, going so far as to put her title in quotes. This sparked a heated debate on Twitter about if such a degree is relevant. Many were quick to point out that Peiter Zatko, a.k.a. Mudge, one of the most respected security professionals in the world also has a degree in music. He was quick to point out that nothing is wrong with a music grad as a CSO, but he humbly suggested they also have a 20+ year track record.

This conversation quickly pivoted and became focused on gender. Paul Roberts wrote an opinion piece for Security Ledger that explicitly calls this point out, titled “when they say your major is a problem, what they mean is your gender is a problem”. In the article, Roberts points out several other successful C-level executives that don’t have degrees in computer science or security, while also noting that Arends does not have a degree in his chosen profession either. Daniel Miessler published a blog with a handy flow-chart on whether you should hire an infosec person with a music degree. Perhaps the most interesting result of this conversation is the #unqualifiedfortech hashtag on Twitter.

PCI Blowback?

A small portion of the data compromised in the Equifax breach included around 200,000 credit card numbers. As Brian Krebs notes, Visa updated an advisory about the stolen cards saying that the data likely included cardholder’s Social Security numbers and address. He says this ironically suggests that the data was stolen from people who were signing up for credit monitoring services through Equifax.

Even more interesting, Kim Zetter says the the credit card data was part of historical transaction data, meaning Equifax violated PCI security standardsShe goes on further pointing out the dates of the transactions go back to November 2016, which means unencrypted credit card information was available on their network for six months. This seems like a clear-cut violation of PCI security regulations and could be grounds for sanctions. However, Equifax is ironically a member of the PCI Security Standards Council (PCI SSC), making some wonder if they will even receive a slap on the corporate wrist for the violation.

Update Roundup

A week later, there is no sign of the news and commentary letting up. Rather than try to visit each item in detail, we’d like to share some of the updates and new developments in a more succinct manner:

  • According to Bloomberg, Equifax learned of the breach in March, not in July as they claimed, according to their sources. Perhaps mincing words, Equifax claims it was a ‘different breach’ involving the ‘same intruders’.
  • According to Sonatype, thousands of organizations may also be vulnerable to Apache Struts flaws. As always, we remind readers to take such claims with a grain of salt when they are based on downloads. There could be a big discrepancy between the number of downloads, number of installations, and more importantly, the number of vulnerable installations.
  • Kevin Beaumont noticed that Equifax had the results of one external audit performed by KPMG available on their public website. At the time of this blog, the 2012 “Report on Equifax’s Controls Placed in Operation and Tests of Operating Effectiveness” is still available (PDF). As Brian Krebs also points out, a different report from 2014 that has since been removed shows that KPMG found Equifax left private encryption keys on servers.
  • Equifax has announced that their Chief Information Officer (David Webb) and Chief Information Security Officer (Susan Mauldin) would be “retiring”, according to the Wall Street Journal.
  • The WSJ also reports that Equifax spent at least US $500,000 lobbying Congress for laxer regulations, including limiting liability for credit-reporting companies.
  • The Department of Justice announced they have launched a criminal probe into the timing of stock sales by senior Equifax officials.
  • The U.S. Department of Justice has opened a criminal investigation into three executives who sold stock days after learning about the breach, months before the public was informed.
  • U.S. Senator Elizabeth Warren, along with 11 colleagues, has introduced a bill that would prevent Equifax and the other credit bureaus from charging consumers to place a credit freeze on their account. Warren went on to Tweet that the idea of the bill is simple; “Equifax doesn’t pay you when they sell your data. You shouldn’t have to pay them to stop selling it.
  • Shortly after the breach, Equifax removed its mobile apps from the Apple and Google markets. After speculation, it appears that it may have been in response to a vulnerability found by Jerry Decime.
  • Looking for a real challenge in InfoSec? Equifax is apparently hiring around 40 people!

The story continues with Equifax Breach: Cyber Insurance To The Rescue?!

Our products
The Platform
Risk Based Intelligence
Learn more
Vulnerability Intelligence
Learn more
Cyber Risk Analytics
Threat Intelligence
Learn more
Risk Management
Learn more