What we all can learn from Twilio's recent hack

Travis Good
August 11, 2022
Image generated with DALL•E

Twilio announced a massive data breach this week. This was a huge breach. It is going to cost Twilio a lot in direct dollars to fix and also going to cost it a lot in damage to its reputation.

Most of the news about the breach focuses on how Twilio employees were scammed using SMS-based phishing attacks, also called smishing. The inference, and the headlines, give the impression that the attack resulted from employees falling for a scam. Employees being scammed by smishing attacks contributed to the data breach; but, that’s only part of the story.

Here is what the text message attacks looked like:

Twilio also hadn’t implemented cybersecurity best practices in the form of a hardware multi-factor authentication (MFA). Forcing a hardware-based MFA would not have prevented Twilio employees from being scammed but it would have reduced the risk of a breach even when employees fall for phishing attacks. NIST removed SMS as a recommended form of MFA some years ago. Cloudflare, which was targeted by the very same attack, had MFA setup with hardware keys and this prevented attackers from gaining access to internal Cloudflare systems.

The Twilio data breach highlights the multifactorial world of data breaches. All too often security incidents and data breaches result from multiple factors, in this case human error and lack of a hardened MFA implementation.

But the response to data breaches usually ends up being a bit of a pissing contest. Responses fall into one of two camps:

  1. Better security training is needed to prevent employees from getting scammed; or
  2. Better security practices like MFA are needed to secure accounts.

Implicit in the above camps are a couple biases:

  1. Training can’t prevent employees from getting scammed; and
  2. Technology and automation is the only thing that prevents breaches.

That 👆👆👆👆 is absolutely the wrong way to think about cybersecurity. Protecting your company from cyberattacks, which ultimately comes down to risk mitigation, requires both defense in depth and defense in breadth.

Wait, Twilio? How? 🤯

Twilio is a tech darling. They are one of the major B2B SaaS success stories. Because of this, most people have the perception that Twilio has a tech-savvy workforce, a solid engineering organization, and quality cybersecurity practices. I don’t work at Twilio and never have but I bet all three of those are true, at least relative to most billion dollar companies.

So, how did this happen to a company like Twilio? It happened because attackers chose to target Twilio. Any company can be a victim of a data breach. It’s really that simple. Of note, both Slack and Twitter reported large scale security incidents this week.

Post Morten -> Better Afterwards ⚰️

At this point, while the reasons for the breach itself are important and should be fully explored, the most important thing for Twilio is how it responds internally and externally.

Don’t Shame 😔

From what’s been reported, it seems like the phishing messages were targeted but not overtly specific. Most people I’ve talked to have expressed anything from surprise to shock that engineers would fall for these attacks; the people I’ve talked to are in cybersecurity so you can take that with a grain of salt.

Hard truth, we all can fall victim to cyber scams.

👉 Scams are hard to spot. Attacks are getting better. They are more targeted. Often the only way to spot a phishing attack is by checking and noticing an obscure URL.

👉 We all have too many messages to triage. Slack, email, LinkedIn, social media — they all are essential inboxes that fill up every day. It’s overwhelming.

👉 The law of averages. Attacks are near constant today. We work from all over — phones, Airbnbs, coffee shops, home, trains — and this makes it easier and easier to “miss” an obscure URL or other tell on a phishing message.

Shaming people that fall victim to phishing scams won’t prevent them from happening in the future. It’ll just show the rest of your employees that you're an adversarial employer. It’s better to focus on what happened and how it can happen to anybody. There are things learn from the attack:

  • Does IT send SMS requests?
  • Always inspect URLs in any message.
  • Don’t hesitate to ask questions when you receive a request.

Twilio would know better what takeaways they want the company to have from this experience. The most important part of the story is not to shame those employees that were scammed.

Automation is Good 👍 

You can’t 100% automate away all risk with cybersecurity tools and best practices. However, you can mitigate risk with them. There’s no great excuse for not having MFA setup. Authentication apps and hardware keys are your best bet, but even email is better than not having any MFA in place at all. It’s usually a matter of oversight or lack of time to implement (this assumes some level of effort to implement MFA across all access points).

Risk Comes in Different Flavors 🍦

If this can happen to Twilio, it can happen to anybody. It’s never been easier to launch these kinds of attacks. 👇👇👇👇

👩‍💻 Software to launch attacks at scale is readily available, like low-code for cyber attackers.

🤦 Personal info is everywhere, making targeting easier than ever.

📲 Contact info, including phone numbers and emails, are easy to find.

We can’t prevent attacks from being launched, and we can never 100% prevent attacks from being successful. That’s why the goal is to mitigate as much of the risk as possible. In this Twilio example, and more broadly, you need to manage two key risks:

  • Risk 1 - Employee Actions: There’s risk from employee actions, in the case of Twilio the risk is getting scammed by a smishing attack.
  • Risk 2 - Compromised Accounts: There’s massive risk from compromised accounts. These can be used to gain additional access to systems and data. In this particular case, not having a better MFA system in place made it a lot easier to compromise user accounts.

Mitigating Risk is a Team Sport 👫

Cybersecurity, whether we acknowledge it or not, is a horizontal function, or should be. It spans multiple groups and can have multiple owners. That’s ok, as long as those owners work together as a team to manage risk. When a company experiences a breach, especially a public one that creates a lot of press, addressing the factors that caused the breach is essential. At the very least, I think Twilio would address both of the risks head on.

First, they’d implement some form of new security and / or phishing training. I don’t know what Twilio does today for this kind of training but objectively I think you can say a reboot or remix of that training is needed. According to Twilio’s own security documentation, this what they currently do for security awareness training:

The Twilio workforce is required to complete the Twilio Security Awareness Training annually and acknowledge our set of security policies and standards. 

We work with 100s of companies, smaller and larger than Twilio. Across the board we find that annual training is a very low bar for security awareness. Admittedly, It’s surprising to see this as their approach to security awareness training. There’s clearly room for improvement, both in policy as well as implementation.

Ideally the new training covers the importance of MFA with all services, mainline IT or shadow IT.

Second, authenticator or hardware-MFA should be enforced for all accounts. In the case of this attack, it appears hardware-based MFA, such as Yubikey, is the type of MFA required to block the attack. Using a centralized auth platform like Okta makes this a lot easier. Of note, Twilio acquired Authy, a 2FA platform, several years ago. According to Twilio, Multi-factor authentication (MFA) is required where possible.

This is a good policy but it does provide flexibility in how it is applied across the company. A small tweak to improve this policy would be to state that documented approval is required for any accounts or services where MFA is not implemented.

Just Do It 🏀

It sucks to have a public data breach be the trigger to do some of the things above. But, this could have happened to any company. All companies can learn from Twilio’s painful experience — look internally at risk, from all angles, and take a team approach to mitigating that risk.