Lessons from Uber’s September Breach, Consumers to Corporations

By Bill Bernard, VP, Security & Content Strategy

Estimated Reading Time: 7 minutes

The world is awaiting details in the latest intrusion into Uber’s systems, looking to understand if customer records were taken, corporate data looted, or any systems were interrupted. But even as we wait for this information there are some lessons we can already learn from this incident. But before we jump in let me just say that any company can be breached by an individual employee making a poor security choice, and security departments need to be ready for this reality. We should all strive to learn from this experience and improve our own security programs because of it.

The Quick Synopsis

Based on what has already been widely reported, the intruder was able to use social engineering to bypass an MFA solution that relied on sending push alerts to a user’s device (likely phone). The intruder already had the user’s password, and was able to convince him to authorize the MFA prompt over the course of an hour or so of deluging the employee with MFA authorization requests. Once in, the intruder seemed to be “past” any serious security barriers, and had broad access to sensitive information, including scripts with hard-coded credentials that had elevated access to key systems – a key management system in fact that seems to have given the intruder the literal digital keys to the metaphorical kingdom.

Side note: I’m not mentioning the name of the employee whose login was compromised. We don’t need to give this person for making a mistake the Bartman Treatment (die-hard Cubs fans know what I’m talking about) because it is a mistake any of us might make. What we need to do is learn to adjust our MFA solutions to make this mistake less likely to happen. OK, back to it then.

From there the intruder chose to make their presence known both to Uber employees and to the world in general.

Different Lessons For Different People

There are a plethora of lessons for everyone involved in this event – from Uber customers to Corporate Leadership and Security Leaders – even with just this small bit of information.


This sort of breach will happen again. The Cylons have a belief that all of this has happened before, and will happen again. They’re right. Your data may have been breached this time, and perhaps not. But assuming it was it is a good opportunity to go back over some timeless advice for weathering such storms:

  • Use a unique password for every website you authenticate to. You wouldn’t want your Uber login info giving this intruder the data they need to get into your online dating site, bank, or healthcare app would you? A password manager is a great way to do this easily.
  • Enable multi-factor authentication on every website and app that allows you to do so. As shown in this situation, MFA isn’t fool-proof, but it is better than just a password by a long shot.
  • Be frugal with what information you share online. Just because the website/app asks for a selfie, or 16 different ways to contact you, doesn’t mean you should provide all of them. If it isn’t required, maybe don’t provide it. The first rule about losing data is that a company can’t lose your data if they don’t have it in the first place.

Corporate Leadership

Board members and the C-suite should be paying careful attention to this event as well. It can be difficult to see how a security program is aligned to the goals of the business. Security tends to get a reputation as the “department of ‘NO,’” or as a cost center with some of the most expensive “toys” in the company. There is also a ton of pressure on security departments to prevent all of these events, and I’m here to tell you that preventing all intrusions is just not realistic. There will always be an employee who makes a mistake, an undisclosed vulnerability that can be exploited, and an insider who has decided that your competitor needs this data more than you do.

If your company has 5000 or more employees, you probably already have more than 70 security tools in place. And I bet if you did the math that’s somewhere between 4-8 tools per security team employee. Each of those tools should be monitored 24×7, not just the 8×5 that most of your staff works. Have you enabled your security leadership to hire enough talent to do that, or have you merely begrudgingly approved the budget for buying the tool? Have you helped them spread the message that security is everyone’s responsibility, the same way you have with HR policies and accounting policies? Have you set the example for your employees, or have you gotten the security team to carve out exceptions for you? Have you demanded that your business leaders accept the responsibility for risk after they’ve gone against the recommendations of your security team’s documented policies and requirements, or have you simply told your security team that they’re still responsible?

Security Leaders

The lesson from Uber, Colonial Pipeline, and countless other breaches that we must take is that we will never stop all attacks before they breach our defenses. Many of the attack vectors are outside of your direct control, and every employee can be compromised whether by ignorance, accident, or willful action. And if we wanted to drive ourselves to drinking there’s supply chain issues, unpatched vulnerabilities, and IT misconfigurations going untested and uncaught.

While that doesn’t mean we should give up on protection capabilities, there’s a reason the NIST CSF doesn’t stop at “identify and protect.” Detect, respond, and recover are key and critical to a successful security program. 

Of course, where we can do a lot to protect our environments with a high ratio of tools to employees; detect, respond, and recover generally skew the other way, with entire teams of people using a handful of tools to look for and then mitigate security incidents – hopefully before they become newsworthy events. This can be extremely difficult in today’s uncertain economy, and with the shortage of trained security professionals available in the hiring pool, but it has to be done.

Jumpstarting Detect, Respond, and Recover

Fortunately, Deepwatch was built for just this purpose: providing our customers with the detection to alerting, alerting to response, and response to recovery capabilities their existing security program may be lacking. Deepwatch takes a people first approach so we don’t overload your team with another technology they don’t have the time to learn, but we bring a fantastic technology platform to ensure our team can get the job done for yours. Finally, with an eye on continuous improvement and maturity, we’ll never stop improving our own service and guiding you as you improve your security operations program.

How Deepwatch Can Help

Deepwatch partners with its customers to speed detection and response, providing SOC capabilities and 24/7/365 protection. The Deepwatch SecOps platform leverages security telemetry across data sources to detect complex threats and provide complete real-time response – programmatically, customized to the customer’s environment. Deepwatch security experts work in partnership with the customer’s security team to identify and prioritize which response processes to automate, alleviating the short-term burden of automation in order to achieve the long-term benefit.

As a partner and extension of internal security teams, Deepwatch offers peace of mind and assurance that threats are rapidly and holistically addressed, unlocking a new level of security that supports business outcomes.To learn more about choosing the right managed detection and response capabilities for your organization, check out our free ebook here: https://go.deepwatch.com/mdr-buyers-guide-deepwatch.


Bill Bernard, VP, Security & Content Strategy

Bill Bernard is a seasoned security expert with 20+ years of experience collaborating with customers to select and deploy the right security solutions for their business. Bill has held various solutions architecture roles throughout his career and holds a variety of security certifications including CISSP, CIPP-E and CIPM.

Read Posts


LinkedIn Twitter YouTube

Subscribe to the Deepwatch Insights Blog