September 25, 2017
The B2B Breach Trifecta: Equifax, SEC, and Deloitte
As rumors emerged this morning about a compromise of consulting firm Deloitte, this becomes the third breach announced in just a few short weeks of organizations that share a similar profile: Each one is primarily – or exclusively – a B2B organization. There are some questions worth asking and answering given each of these breaches:
Equifax took a beating in the headlines, but the SEC was barely a blip. Why?
Well, Equifax is primarily a B2B company, but the data stolen was consumer data. Couple that with one of the worst responses to a breach possible – from potential insider trading, giving inconsistent answers, asking users to sign up for its own products, the end user license agreement fiasco which drew attention from State Attorney’s General like Eric Schneiderman, discovery of a prior hack by the same group, and then routing users to a fake website put up by a security researcher, Equifax getting pummeled is not too surprising, or undeserved for that matter. The tepid response to the SEC breach can be boiled down to two factors:
- Business data was stolen from the SEC. While that isn’t a victimless crime by any stretch, individual consumers don’t have to scramble to place a freeze on their credit report because of what happened at the SEC. Most citizens will not need to alter their daily lives due to the SEC breach. No sitting on the phone with three different credit bureaus or website enrollments for credit monitoring.
- Hide your announcement in the shadows of a bigger breach. One of the not so secret secrets in the incident response, public relations, and crisis communications worlds is that sometimes you timing your announcement to coincide with a larger, more public, and more sensational breach can help minimize the attention it receives. Now, there is no information available that indicates that the SEC was even thinking along those lines when it announced its own breach, but Equifax’s continued missteps certainly didn’t hurt the SEC.
What do the hacks signal? Is this a trend? How does Deloitte fit?
It’s always tough to call hacking a trend after all, “hackers gonna hack.” However, it does continue to prove the oft-used Willie Sutton adage about robbing banks “because that’s where the money is” has not become irrelevant in the 21st century. Hackers have adapted to the digital transformation and data economy much like Enterprises have. Moreover, that means adjusting how and what they target.
- Deloitte has massive amounts of data. The days of consulting firms simply being a body shop or running through checklists in audits is long over. Deloitte is a global consulting firm that provides services across numerous business lines, which includes architecture, development, deployment, and ongoing services. Deloitte has scooped up digital agencies that design software, continues to perform Advisory services around taxes and accounting, and of course, consults on information security engagements.
- The data you steal from Deloitte makes every other attack easier. By sitting inside Deloitte as a threat actor, you gain valuable intelligence about the attack surface of hundreds of global enterprise companies. This data includes emails, email attachments, design documents, configuration details in spreadsheets, passwords emailed between engineers, etc. Your chances of success against other targets increase proportionately to the amount of information you harvest from Deloitte. Consulting firms and service providers are targets because they represent force multipliers for threat actors.
- You can make insider trades with this data as well. It isn’t just the information from the SEC that has value for a threat actor seeking to monetize information via stock market trades. Deloitte has an Advisory practice, and that means taxation and accounting audits for organizations. That information is the source of the data used in those very same SEC filings that may have been accessed by attackers in the SEC breach. Therefore, Deloitte – or any taxation and advisory firm – is a good target for the same reasons as the SEC.
Sure, but Deloitte sells security services, and the SEC is a regulatory body. Both should be better at this right?
It seems by 2017 we have – hopefully – moved past the “tar and feathers” approach when a breach comes to light. A smidge of public shaming, inevitable litigation, and 3rd party contractual issues should be sufficient in all but the most egregious scenarios.
- Deloitte’s consulting practice does not run Deloitte’s information security. With that in mind, its capability as an information security consulting firm does not necessarily reflect its ability to defend itself against hackers. The same is true for the SEC. They don’t share the same budgets, KPI’s, or organizational structure. However, it is right to ask whether Deloitte engaged in “dogfooding,” or perhaps as one of the Big 4, the preferred phrase to use is: “Drinking its own champagne”?
- Think stones and glass houses here. In Fight Club by Chuck Palahniuk the narrator states: “On a long enough time line, the survival rate for everyone drops to zero.” That advice seems to apply to cyber as well, since one mistake by a user, one prematurely closed event by the SOC, or one failure to apply a patch can result in disaster weeks, months, or years later. Learn lessons and develop takeaways as detail emerge, but remember that no one is immune to attack.
What should S&R pros do if they work with a breached service provider?
If you are the customer of any service provider that gets breached you should consider your organization more at risk. Here are some things to think about based on the nature of the Deloitte breach:
- How many: “This email is encrypted, the next email has the password” emails have you sent? Look, we all KNOW this happens. But it isn’t secure to send the encrypted item, then send the way to decrypt it across the same channel…and also mention the password is on the way. Think about defining a set of preshared passwords at project kickoff. For encrypted email attachments, text the password or share it by phone. Consider using a public/private PGP key pair at project kickoff if your team can handle the decryption.
- Is your old information laying on a file share or consultant laptop years later? If you email a consultant you worked with on a project two years ago and ask for information about the project, do you receive a proud “Found it!” response? If so, that might be cause for concern. If you no longer work with that consultant on an active project, why isn’t the data destroyed? Does your contract with the firm include data destruction and sanitization guidelines? If so, you uncovered a policy violation by at least one consultant.
- If you are included in the breach, was it only your information? One of your critical partners suffered a breach, which means your information might be out there. However, your customer’s information might be as well. S&R pros can’t just worry about first party enterprise information; you also need to find out whether you need to begin your own notification process. You have a vast ecosystem of customers, partners, and suppliers. You can bet that data from each one roams freely through your environments, which means it might make its way to a partner that suffers a breach.
- How much do attackers know about your environment now? If you’ve done substantial work with a service provider that suffered a breach, consider that they know everything about your environment. Diagrams, passwords, configurations, IP address assignments, administrative usernames, password formats, and more. This is a treasure trove of data for attackers to increase their likelihood of gaining access to your environment or remaining hidden in your environment. You should consider your own environment compromised and initiate threat hunting to determine if an attacker is present inside your environment, including looking for anomalies as this attacker may not have needed to use any malware to gain access to your organization given the information they started with usernames and passwords.