<div dir="ltr"><div><a href="https://www.riskbasedsecurity.com/2017/09/equifax-breach-updated-timeline-phishing-regulation-and-a-roundup/">https://www.riskbasedsecurity.com/2017/09/equifax-breach-updated-timeline-phishing-regulation-and-a-roundup/</a> </div><div> </div>This is the eighth blog in the running series on the Equifax data breach. Equif*@#$d: Equifax Breach Response Off To A Rough Start Equifax Breach: Legal, Vulnerability Blame Game, and the Big Technical Debacle Equifax Breach: EULAs, Size Doesn’t Matter, and Where’s The Data? Equifax Breach: The Bigger Picture, Identity, Impact, and Advice Equifax Breach: Ambulance Chasing, FireEye, and a News Roundup Equifax Breach: Timeline, International, Patching, Gender, PCI, oh my! Equifax Breach: Cyber Insurance To The Rescue?! Equifax Breach: Updated Timeline, Phishing, Regulation, and a Roundup ________________________________ There continues to be fallout after the Equifax breach reported on September 7th. Here are some of the highlights and focused topics. Running Timeline (Updated) As the events continue to unfold, people are taking an increased interest in the amount of days that passed between two events, such as the days between when the vulnerability exploited by attackers was disclosed and the date the weakness was fixed. Known as the “time to patch”, this metric centers around how long it takes for the organization to determine, at least in their minds, 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. This is our first update to the timeline with additional dates and events. 2017-02-14 – Apache notified of the vulnerability (ref: email between RBS / Apache) 2017-02-18 – Apache assigns a CVE ID (ref: email between RBS / Apache) 2017-03-06 – Apache announced and released upgrade to resolve vulnerability (ref) 2017-03-07 – Vulnerability published in VulnDB (ref) 2017-03-07 – Exploit published (ref) 2017-03-10 – MITRE opens up CVE ID with description and 7 references (ref) 2017-03-10 – NVD adds to their database via CVE. No updates since (ref) 2017-03-10 – Alleged Equifax breach occurred according to recent reporting (ref) 2017-03-14 – CERT releases advisory on vulnerability (ref) 2017-03-14 – Equifax says they are aware of the vulnerability (ref) 2017-05-13 – Equifax breach occurred, per statement from the company (ref) 2017-07-29 – Equifax detected breach (ref) 2017-07-30 – Equifax patched the vulnerability (ref) 2017-08-01 – Equifax CFO and President of US Information Solutions sold stock shares (ref) 2017-08-02 – Equifax President of Workforce Solutions sold stock shares (ref) 2017-08-02 – Equifax contacted Mandiant to help with incident response (ref) 2017-08-10 – Equifax acquires ID Watchdog, an identity theft protection service provider (ref) 2017-09-07 – Equifax notified public of breach (ref) 2017-09-07 – First class-action lawsuit filed against Equifax (ref) 2017-09-15 – Equifax CSO & CIO ‘retire’ (ref) 2017-09-19 – Massachusetts AG files lawsuit against Equifax (ref) 2017-09-20 – Equifax names interim CSO & CIO (ref) Equifax Specific Metrics Equifax time to patch: 138 Days Equifax time to notice compromise: 78 Days Equifax time to notify public: 117 Days Apache Struts Software Vulnerability Metrics As more information become available about the Struts vulnerability we also continue to track detailed timelines in our VulnDB service. Risk Based Security created a framework called Vulnerability Timeline and Exposure Metrics (VTEM) that defines and provides guidance for vulnerability timeline tracking and metric calculations to assist in the evaluation of vendors and products to better understand an organization’s exposure. We know that that ‘Struts-Shock’ vulnerability had the following key metrics: Vendor Response Time – To demonstrate the vendor’s response time from being informed about an issue to responding to a researcher. This is only the initial response, but not an automated response. Unknown (Apache did not include that in the timeline they sent us.) Time to Patch – To demonstrate the vendors response time from being informed of a vulnerability until to having a working fix published for customers. 20 days Time to Exploit – To demonstrate the amount of time from when vendor provided the solution until an exploit became publicly available. 1 day Overall, we have tracked a total of 75 vulnerabilities in Apache Struts, with eight vulnerabilities not having a CVE ID assignment.   We looked at the overall VTEM Metrics for Struts and wanted to call attention to two specific metrics. The first is Vendor Response Time; while we don’t have the dates to calculate it for the Struts-Shock vulnerability, we can see that the Apache Foundation on the whole is very responsive to researchers that contact them. While the sample size is low, only seven vulnerabilities out of the 75 can we calculate a metric, we see that on average it takes them just one day to respond. That is great to see! We can also see that the Struts-Shock was fixed much quicker (20 days) than it typically takes since their average is 92 days. Equifax Breach Earlier Than Initially Stated? The Wall Street Journal published an article based on a leaked preliminary report by Mandiant, who was brought in to determine the scope and method of the Equifax breach. The report, summarized in the article, alleges several new aspects of the breach that are interesting: Mandiant says the first evidence of hacker “interaction” occurred on March 10th, considerably earlier than May 29thas Equifax originally stated. Between May 13th and late July, the intruders accessed sensitive information “stored in databases in an Equifax legacy environment”. The intruders also compromised two systems that support Equifax’s online dispute application. The attackers set up “about 30 web shells” (a method of keeping persistent access to a compromised host) that were accessed from around 35 “distinct public IP addresses”. According to Mandiant, the attackers methods and tools do not match any “threat actor group” it tracks, and does not “overlap with those seen in previous investigations by the firm”. It is difficult to say why there is such a large discrepancy between compromise dates given by Equifax and Mandiant. One possibility is that Equifax’s internal teams found evidence going back to May 29th, while Mandiant’s team who has more experience investigating breaches found evidence going back to March 10th. Another possibility is that the first intrusion into the system took place in March but the data itself was not compromised until May, prompting Equifax to report the date of data compromise instead of the first occurrence date. Regardless, with this type of compromise and presence of that many web shell backdoors, it is making more people wonder exactly what FireEye’s security products were supposed to protect them from if not 0-day vulnerabilities (Struts-Shock) and the web shells. Perhaps the most confusing part of this recent development is Equifax’s lack of clarity around the March event. They have been adamant in claiming that these were two separate breaches. Indeed, an Equifax subsidiary, Equifax Workforce Solutions also known as TALX, was breached earlier this year in March. The attackers were able to guess at – and reset – account administrators PINs, and by doing so gain access to W2 details on thousands of individuals. If in fact this is the March event Equifax is referring to, then there is reason to believe it is unrelated to the May intrusion.   However, According to Bloomberg, Equifax said the “March breach was not related to the hack that exposed the personal and financial data on 143 million U.S. consumers, but one of the people said the breaches involve the same intruders.” This statement simply does not make sense. Looking back at the timeline, they confirmed the method of compromise and the dates show that a single attacking group/person could have kept access and consistently gained access to more servers and information. If the March intrusion is not the TALX event, then nothing published so far explains how this would be “two separate breaches” and why that claim is justified if the same actor(s) were involved the entire time. Equifax Recommends Phishing Site to Victims On the day Equifax announced the breach, they set up a website (<a href="http://equifaxsecurity2017.com">equifaxsecurity2017.com</a>) to help inform customers of what happened and provide resources. As we mentioned in a previous blog, it is a given that criminals would set up similar domains to carry out phishing attacks and other scams (here’s a handy list). What no one expected is that Equifax, via its Twitter account, started directing people to one of the bogus sites (<a href="http://securityequifax2017.com">securityequifax2017.com</a>). Fortunately for Equifax, that particular scam site was set up by security researcher Nick Sweeting to help prove the point of using such websites after a breach. Even worse, Equifax has been directing people to the bogus site since September 11th and just removed those Tweets on the 19th. ArsTechnica wrote more about this dreadful mistake, as did CNN. Bob McMillan points out that the actual domain Equifax set up is hard to find. If you Google for a common term that an ordinary person might search for, that site doesn’t appear on the first page. Even as Equifax learns their lessons with the Tweets, they are still sending out emails with multiple domains which “continues to train people to fall for phishing scams” according to Brian Krebs. Data for Sale Again? Tracking the Alleged Criminals. The first claim from criminals purporting to sell stolen Equifax data turned out to be false. In recent days, a second claim has appeared on the Dark Web (equihxbdrjn5czx2.onion). Like the first, someone claims to have the Equifax data and will crowdsource the money they want to publicly release the data. Security researcher ‘Krypt3ia’ posted about this development along with his doubts (note: that link is safe despite Chrome’s warning). Steve Ragan also expressed his doubts, saying the sample data had been previously released, suggesting it came from a prior breach. Someone who goes by ‘AKM’, or @037 on Twitter, posted a blog titled “How Equifax got Hacked” which claims to give further information about the hack, supports the new claim of Equifax data being sold, and offers a variety of screenshots as evidence. This blog is based on their conversation with the alleged hackers, where AKM was able to ask questions and share the answers. However, Brian Krebs points out that the screenshots mentioned are likely from an Equifax partner, not Equifax itself. Zack Whittaker posted a thread on Twitter reminding everyone of accepting such claims without verification and more digging. Is Government Regulation the Answer? After a large computer breach a question that comes up with increasing frequency is that of government regulation. If companies operated under security regulations set forth by the government, would this prevent breaches? Security blogger Bruce Schneier wrote on this topic, concluding “if you want to prevent this kind of thing from happening again, your only solution is government regulation”. Over the entire blog however, he doesn’t offer any compelling argument supporting this statement other than the age-old “raise the cost” through fines. As mentioned in a previous blog of ours, the General Data Protection Regulation (GDPR) shows promise to put a financial burden on companies that may change their tolerance of breaches. With that going into effect in 2018, the talk of government regulation is a no-brainer, more so than the last decade it has been brought up. More interesting is that Anna Slomovic, the Equifax Chief Privacy Officer (CPO) for three years until January, 2014, agrees. In a blog post, she says “given the nature of credit reporting, only action by the Congress and diligent regulatory oversight will lead to a better balance for consumers in the long term.” This statement is more telling coming from an Equifax insider who had to face the fallout of their security practices for three years. Even the National Retail Federation says that a uniform data breach law must be enacted; while that would certainly be helpful, that only helps after a breach has happened as conforming to a unified law is considerably easier than adhering to more than 50 separate state laws. But note, in 2017, the U.S. government hasn’t even standardized breach notification, let alone put forth more strict regulations. That said, it is difficult for some of us at RBS to really understand this logic in the bigger picture. First, the security and payment card industry has tried to self-regulate via the Payment Card Industry Data Security Standard (PCI-DSS)standards which mandate a certain level of security. While many in the industry feel it is essentially the “no child left behind” of security standards, it is exactly the kind of regulations the U.S. government might put forth. Second, the industry is already drowning in security regulations, many put forth by the U.S. government. In addition to PCI-DSS, depending on your business and industry, you may fall under the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes Oxley Act (SOX), Federal Information Security Management Act of 2002 (FISMA), Electronic Fund Transfer Act Regulation E (EFTA), the Health Information Technology for Economic and Clinical Health Act (HITECH), and more. Have any of these regulations or standards, or a combination of them, truly made an organization safe? With so much government regulation already in place, it is difficult to understand how generic statements of “we need government regulation” have any merit without proposing something more specific. Third, and finally, how has government regulation worked for other industries? Specifically, think about big banks and Wall Street that routinely breaks laws or regulations, as the fines and ‘punishment’ they face are part of their bottom line and expected. Think about the energy industry and the massive oil spills that still do irrevocable harm to our environment and the ‘punishment’ they receive. Years after these companies flagrantly break rules and regulations, and sometimes the law, we see summaries like this; “None of the charges against individuals resulted in any prison time, and no charges were levied against upper level executives.” With the credit bureaus having incredible financial resources, does anyone think that they don’t already have an incredible lobby? We’ve previously covered Equifax spending upwards of $500,000 in a year lobbying Congress to change the law in their favor. If more regulations appear that would impact them, we can also expect to see them increase their lobbying budget. So, do we feel that government regulation would have prevented the Equifax breach, or most other breaches? Do we think that such regulation, if enacted, would stop breaches from happening? Update Roundup As in previous updates, we’d like to share some of the other bits and new developments in a more succinct manner: The New York Times published a piece saying that the Equifax hack will “lead to little, if any, punishment”. Based on historical incidents, it’s hard to argue this. Brian Krebs points out that Equifax still appears to be in the dark ages regarding user web browser requirements when visiting their site. They may want to consider that no modern user runs Netscape. Maura Healey, Massachusetts Attorney General, filed a lawsuit against Equifax for failing to “develop, implement, or maintain a [comprehensive information security program] that met the minimum requirements of the state’s Data Security Regulations”. After the Equifax CSO and CIO “retired” following the breach, the company has named an interim CIO (Mark Rohrwasser) and CSO (Russ Ayres). Following the now ‘retired’ CSO and CIO, Equifax’s CEO, Richard Smith, has also announced he is ‘retiring’ which some call an ‘appeasement’ for regulators. In the running theme of Equifax having poor security, researchers have pointed out that their servers have a variety of problems related to security headers. Additionally, their credit report monitoring website is also said to be vulnerable to hacking. In the irony department, The Reg dug up material produced by Equifax showing that a survey they conducted revealed 74% asked thinks that a breach notification should come within hours or the same day. For those impacted by the breach, many are reporting problems while trying to set up credit freezes.

</div>