As organizations continue to adopt multi-factor authentication, attackers are getting better at learning how to bypass it. Uber had deployed Duo, a push notification service from Cisco, to protect their VPN remote access service, which is great. The problem is that criminals have learned that if they repeatedly spam a target with alerts, more often than not the target may just relent and press Accept.
What can be done? Well, in a perfect world we would all be using FIDO2 authentication which requires a hardware token or smartphone that must be physically proximate to the device authenticating.
Not everyone is ready to adopt this technology though, so multi-factor services like Duo also offer a hybrid approach to push, where the application asking you to authenticate gives YOU the 6-digit code and, instead of tapping Accept on your device, you must enter the secret code. This would require the criminal to interact with the victim and convince them to enter the code on their behalf. Not impossible, but a much higher barrier than simply pressing the big, shiny, green button.
Given enough time, there is nearly always a way for an authorized user to gain privileges to an account they shouldn’t have access to. The key to defending against this type of attack is to make it take enough time that you can detect their footprints and evict them before they succeed.
The attacker alleges they found the administrator password for Uber’s Privileged Access Management solution in a PowerShell file on a user-accessible file share. This is clearly not ideal, but it does beg the question: How should that have been sufficient to wreak this much havoc?
Without yet knowing the specifics of Uber’s affected system, most of us would ask why multifactor authentication wasn’t in place. Turning the question around, do you require multifactor authentication to log on to internal systems? For functions as critical as privilege management, source code, HR, or financials you should be applying the same amount of caution you exercise when authenticating users for access to the network itself — and you should never assume that anyone on the network is authorized for access to sensitive systems just because they have authenticated to the network at large.
Just like conducting an external penetration test on a semi-annual basis, it is also a good practice to do an audit of your internal environment for just this type of thing. It might have been a temporary workaround or a legacy practice that had been forgotten, but these things crop up in almost any reasonably complex network.
The idea behind Zero Trust Network Access (ZTNA) is that you should only have access to precisely what you need, when you need it, and I should never trust that you are who you say you are. Authenticate each user’s permissions at time of access to be sure everything is in order, just like you would for an externally facing application.
In fact, one of the benefits of this approach is that you can, in fact, eliminate the perimeter entirely – or at least you can stop relying on VPN-type solutions, paring down the broad-brush protection layers for assets living behind the firewall and WAF. Your assets will, yes, be less swaddled in layers of “protection,” but strongly and carefully verifying that every access request is authenticated and authorized is, in fact, better asset stewardship – and it’s easier to spot trouble when it comes.
Your network should not resemble a candy bar with a hard outer shell and a soft gooey center. When the Uber news first aired publicly, the best-managed networks have an assumption of breach. Nothing dangerous should be laying around that, when in the hands of someone with malicious intent, could harm you.
I find it a good practice, whenever there are security news headlines, to try to take away some lessons and imagine how my own team might fare when faced with a similar adversary. Successful network defence is hard, but by using these lessons to sharpen your tools, it gets a little easier each time.
The purpose of our layers of defence shouldn’t be with the expectation that one of those layers is going to magically stop a determined attacker; rather, each should be viewed as one more opportunity to buy yourself time. That time allows the team that is monitoring your systems to take note of the anomaly and start investigating. The goal is to have those layers buy you enough time that you’re able to find the point of entry, close it, and evict the attackers before they reach their goals.
When the attacker’s goal is to plant malware, steal specific intellectual property, or even trigger a ransomware/extortion attack, it usually takes a few days and that should be enough to stop them in their tracks.
Unfortunately, as is the case with Uber, Rockstar and other victims of Lapsus$, the attacker is after anything and everything, simply to make headlines and cause embarrassment to the victims. This takes frighteningly little time on the attacker’s behalf and requires the network and monitoring to be in tip-top shape to prevent.
The pain from these incidents will be temporary, and I hope that in the end we can all benefit by using them to improve our own processes and architectures. Security is an evolving field and the best we can hope for is to work together, learn from our mistakes, and continue raising the bar for criminals.
We have the Zero Trust Network Access (ZTNA) because it is something that is demanded by the way that modern networks operate, so that you only get the access you actually need for the task in hand.
If you think about it, this doesn't just benefit the company that's dividing up its network. It's also good for users - it means they can't make unfortunate blunders even though they think they're trying to do the right thing.
CyberSecurity is a journey, not a destination. You have to revisit it continually to make sure that a) you correctly did what you intended, and b) what you planned to do yesterday is still a valid and useful defence today.
If you're not able to do that in-house, consider hiring it out, as you need eyes on this round the clock. The idea of having somebody to help you review what is happening, particularly when you think something bad has just happened, means that you don't end up with security incidents being major distractions to your regular IT and Security Operations team. Distractions, after all, could actually be deliberately seeded by the crooks to act as a distraction for the attack that they've got planned for later.
Also, make it a goal of turning everyone in your organisation into eyes and ears for your own security team. Set up a CyberSecurity hotline for your staff to report incidents, and trust them to help you out by reporting such incidents. A lot of people believe that people are the biggest problem - people are, in fact, one of the best ways you can notice things that you didn't expect. It's always the things that you didn't expect that will catch you out, because if you had expected them, you would probably have prevented them in the first place!
You can check out the data sheet for Sophos ZTNA here.
The Tech Geeks have a wealth of knowledge due to the qualifications we have diligently acquired over the years, and are well placed to help support you with your CyberSecurity, Wireless and Networking needs. Do reach out to us and let us know how we can help you keep yourself, your staff and your business secure and safe online.
ZTNA deployment couldn't be easier. After an incredibly successful early access program, the Sophos Network Security Team is pleased to announce that the integration between Sophos ZTNA and Sophos Firewall is generally available. Both Sophos Firewall v19.5 MR3 and the...
The Sophos XGS 107 Firewall Appliance is built upon a dual-processor architecture, combining a high-performance, multi-core CPU with a dedicated Xs...
View full detailsThe Sophos XGS 116 Firewall Appliance is built upon a dual-processor architecture, combining a high-performance, multi-core CPU with a dedicated Xs...
View full detailsThe Sophos XGS 87 Firewall Appliance is built upon a dual-processor architecture, combining a high-performance, multi-core CPU with a dedicated Xst...
View full detailsThe Sophos XGS 126 Firewall Appliance is built upon a dual-processor architecture, combining a high-performance, multi-core CPU with a dedicated Xs...
View full detailsThe Sophos XGS 136 Firewall Appliance is built upon a dual-processor architecture, combining a high-performance, multi-core CPU with a dedicated Xs...
View full details
