Have you read about the September 2022 Uber attack where the attacker was able to overcome MFA to prowl all over their intranet with privileged access?
How it happened?
If you dig deeper here’s the modus operandi:
Hackers get credentials for an Uber external contractor via the Dark Web
He successfully logs into Uber’s VPN using the stolen credentials but gets prompted for MFA
Hacker keeps annoying Uber external contractor with MFA prompts for an hour
He then reaches out to contractor on WhatsApp telling he is from Uber IT and he needs to accept those prompts
Contractor is now tired (we call it “MFA Fatigue” in the industry) and accepts the next MFA prompt
Hacker is in the Uber intranet and is free to roam around
Hacker scans for network shares and finds a PowerShell scripts with credentials to Thycotic Privileged Access Manager (PAM)
Hacker logs into Thycotic PAM and gets credentials for many other systems and it causes further damage
You can read more about it from Uber’s official posting on it here, including how the attacker reconfigured Uber’s OpenDNS to display a graphic image to employees on some internal sites: https://www.uber.com/newsroom/security-update/
From cybersecurity perspective, a few critical mistakes were made here:
MFA Prompts: MFA Fatigue is a real thing. You should disable prompts where possible, not just because of MFA Fatigue but MFA prompts are prone to phishing attacks.
Credentials in PowerShell Script: This one is a biggy and is a strict no-no. If you as an organization are not scanning all network shares, storage accounts, S3 buckets, code repositories etc. for cleartext credentials, you may be setting yourself up to be in the news for the wrong reasons.
Thycotic PAM Misconfiguration: Details on this are fuzzy but I can’t understand how API credentials were allowed to login from the UI and if so, why Thycotic PAM had no MFA in place for UI-based authentication. If Thycotic was accessed using the API, the credentials stolen should have been scoped to limit their access. I am suspecting the credentials in the PowerShell script were there to read ALL secrets / passwords in the system!
The Elephant in the Room - Allowing Users to Roam Free within your Intranet
The above issues are fixed by applying best practice configurations on tools and scanning for credentials in the usual places. However, the extent with which you are protected is still limited. To begin closing this security gap I would ask myself and the team the following questions:
Why was the hacker even able to network scan once in?
Why was the hacker able to login to Thycotic PAM?
And once those privileged credentials were compromised, why was the hacker able to login into other internal systems all over the place?
Where was Network Segmentation when you needed it?
The core issue that each of the above questions raise is how could our architecture be more identity based versus IP based. Because the core issue with the security architecture that allowed such damage was due to a fallacy that authentication equates authorization. Just because a user is authenticated on a network, does not make the user authorized on the network.
Network Authentication Does Not Equate to Network Authorization.
Transitioning an existing IP based infrastructure to one that is identity based does not have to be as onerous as it once was and when done within a SASE framework it can also bring some other additional benefits.
SASE (pronounced Sassy) integrates your cloud infrastructure with security to create an identity based Zero Trust Network Architecture (ZTNA) while allowing you to control your entire network via software. SASE combines Network and Security into one cloud-based service built on your Device, Application and User identities. All security services like NGFW, SWG, CASB, DLP etc. are included from the Security aspect and Cloud Optimization, Global Connectivity, and SD-WAN from the Network aspect.
A SASE implementation would have easily and quickly prevented all the above because it's Deny All by default, only what you allow (based on user identity and application) passes through your network. With a true SASE solution, you get complete control over your network everywhere, at a device, application and user level.
The Right Way to Migrate to SASE
Many security teams have the perception that moving to SASE will be an overwhelming amount of work to implement. But, it doesn't have to be that way..
Implementing SASE can involve a significant amount of planning, however you can and should follow a gradual approach to SASE migration. Here are four possible ways you can gradually migrate to the network of the future:
Migrate from MPLS to SD-WAN: SASE can support running MPLS alongside SD-WAN. In this scenario, enterprises leverage SASE’s SD-WAN functionalities, while turning off MPLS sites at their own schedule. This by itself enables product significant cost saving. Existing security and remote access solutions can remain in place.
Optimize Global Connectivity: SASE improves performance and resilience across global sites and WAN applications. Organizations can use SASE for global connectivity and keep MPLS connections for critical WAN applications.
Retire Edge Security Devices: SASE eliminates the need for edge security devices by including new technologies within the service itself. For example, NGFW, IPS, ZTNA, SWG and more.
Enable Secure Remote Access: SASE optimizes and secures remote traffic. By replacing VPNs with SASE, enterprises can ensure remote access to all edges through a secure global network. No more users roaming around in your network freely, remote or otherwise.
Overall, implementing SASE can be a complex process that requires careful planning and coordination. It may be helpful to work with a skilled IT professional or consulting firm to ensure.
A Journey of a Thousand Miles Begins With a Single Step
In conclusion, the September 2022 Uber hack teaches us that even if somehow hackers get into your networks, you cannot and should not allow them to roam freely. While breaches will happen (you should expect them - that’s the whole point of Zero Trust), you cannot give away the hall pass to these bad actors. If your network is tied to your identities, it is Deny All by default, and all network connections are explicitly allowed, you will limit the damage.
The key challenge for most of us is how to achieve our company’s security needs within the constant constraint of never enough highly skilled resources and limited budget. In other words, at the core of security is really a resource management issue. That is why beginning from an architecture that is focused around identity as opposed to IP addresses, you have started down a path where security is actually strengthened in a framework built upon fewer people and resources requirements.
That is where SASE comes into play. It's a great way to start your journey towards a more identity based secure network while making lesser demands on your budget and resources.
You just have to take the first step.