MFA and addressing password reuse is table stakes in 2021. Like this is literally the first item I would do as a CISO in any company.
MFA is among the core security items like running endpoint protection, updating your software or filtering spam. Bucketing it with things like CORS or auditing third party libraries is either disingenuous or extremely naive.
These types of arguments are so hard to have over HN, because people with actual experience across all sorts of organizations can't explicitly say what they have seen and where because of NDAs and we all have our own viewpoints and individual experience.
Bucketing MFA into one broad concept is as disingenuous as calling out security headers as being as benign as CORS. Does your org have MFA on SSH? On email? On the code repo? On the Slack login? On the VPN(s)? Etc. Etc.
I have yet to see a single org that had MFA on everything and blaming a lack of MFA on the VPN misses the point. If they'd had it there, the attackers would have hit elsewhere. Most developers install random software and browser toolbars that they'll never have time to check and connect directly to their companies servers, repos, and communication tools. Pretending like MFA on a VPN would have magically solved everything is a pipedream. There are too many ways in, and every time someone gets in the response from the software community is always "oh why didn't they do X" while ignoring the larger truth: There are too many threat vectors and getting them all right, at all times, is nigh on impossible.
There’s no silver bullet that magically stops all attacks so your position feels a bit extreme. MFA would have stopped this particular attack (so would have disabling inactive accounts or scanning for password existence on leak databases).
Expect future attacks to focus on unrevoked lost/stolen yubikeys.
If the Yubikey is serving as a FIDO Security Key (rather than in one of its other modes) then this is much trickier than it might look.
Suppose you find my Security Key in the street, or left behind on public transit. It has no idea who it belongs to! All it is capable of doing is proving that it's still the same Security Key as before, which it is. I use that Security Key to sign into Google, Facebook, GitHub, and a dozen more, but the Security Key itself has no memory of any of that, it's a blank slate. The Security Key works perfectly well, maybe you can eBay it, but you can't realistically break into accounts with it.
The alternative is stealing keys to order. But this involves connecting up two very different skill sets, one of which requires physical proximity. That's a tall order for everybody but nation state adversaries. If you're an Indian organised crime syndicate, hacking some IT systems in Texas is likely practical for you via the Internet, but flying a member out to Dallas to try to steal a physical object from the right person is both unduly risky (local cops might be bought off, but the cops in Dallas don't know you from Adam) and surprisingly expensive.
Also there’s a baked in assumption that the HW for these is secure. They’re probably pretty good but I don’t know how resistant they would be to a physical attack to figure out the domains.
I agree that these attacks will get more expensive but I it’s still too early in the adoption cycle for me to conclude this is an unmitigated hard stop against these kinds of attacks vs just a speed bump.
Another area of weakness one can expect is the use of automated system accounts. Those are still in the Wild West age in terms of being constructed Willy Nilly, having lots of privileged access to internal systems without real access nor auditing controls, no expiry, and sometimes even offer login access.
Did this feel like a fully-formed coherent thought when you wrote it down? Because that didn't come across. A Security Key has no idea about other accounts on this service, some other service, anything like that, it's intentionally oblivious.
> They’re probably pretty good but I don’t know how resistant they would be to a physical attack to figure out the domains.
I think you still don't get it. The Security Key has no idea what domains it has been used with. It isn't trying to hide them from you or from bad guys, they aren't secret, it literally doesn't know.
> Bucketing MFA into one broad concept is as disingenuous as calling out security headers as being as benign as CORS. Does your org have MFA on SSH? On email? On the code repo? On the Slack login? On the VPN(s)? Etc. Etc.
I have been doing security for 15+ years and your mindset of "omg its so hard, so we can't do anything" is the exact sort of thing that got the Colonial Pipeline into the situation they are in.
> I have yet to see a single org that had MFA on everything and blaming a lack of MFA on the VPN misses the point. If they'd had it there, the attackers would have hit elsewhere. Most developers install random software and browser toolbars that they'll never have time to check and connect directly to their companies servers, repos, and communication tools. Pretending like MFA on a VPN would have magically solved everything is a pipedream. There are too many ways in, and every time someone gets in the response from the software community is always "oh why didn't they do X" while ignoring the larger truth: There are too many threat vectors and getting them all right, at all times, is nigh on impossible.
Well, we should just give up and do nothing, right?
You probably need to see more organizations, I am really not trying to be a dick, but I truly hope you aren't in a position of authority or in charge of security for any sizable organization.
I have seen about 30-40 medium-large organizations breached by account takeovers (ATOs) over the last 5 years or so. At this point if you don't have SSO backed by MFA on everything (email, vpn, slack, git/vcs, salesforce, marketing sites, etc.) you are playing with fire. With things like Okta, Duo and Yubikey, there are just no excuses.
I explicitly said that MFA raises the stakes.
The point I was trying to make was that whatever the attack was, the thing that gets reported on, is so very rarely an attack that engineers side with the defender. It's almost always something like "oh why didn't they do X" where X could be thousands of things.
I know you say you're "not trying to be a dick" and all, but this is what I wrote in my original comment:
> the long tail of organizations just don't have the right staff, focus, or resources to do it.
If you reread my original comment you'll see what I'm trying to get software developers to understand. Securing these systems is nigh on impossible. Orgs lack incentives to do it to the fullest degree. If it weren't, 0days for iOS or Windows would cost billions.
I'm not excusing these large organizations—though actually working with the people involved gives me some perspective as to why they don't always have MFA on their VPNs—I'm trying to get the broader point across that we shouldn't trust such critical infrastructure to vulnerable computers. That there should be regulations and audits with fines.
And honestly, the way you worded your final paragraph is kinda confusing. You've seen a couple dozen orgs with account takeovers and your conclusion is that they're all playing with fire? Maybe what I said in my original comment on the article has some merit. Regardless, I've seen enough to know that "the problem" isn't a random VPN lacking MFA.
I amazed this isn't the norm across all industries.
I haven't seen video conferencing hardware at co-working spaces, it seems everyone there just plugs in their laptop if need be.
But I've long accepted that this is why you or I will never be CISO of an organisation like this. I've worked alongside such people, and they'd be horrified that thread isn't all about a logon disclaimer on that VPN.