6 ms·

Going to have to hard disagree there. MFA and addressing password reuse is table stakes in 2021. Like this is literally the first item I would do as a CISO in

• 3pt14159 5y ago
  Look, MFA for access to code repositories or a cloud is one thing, but if you think that MFA is "table stakes" for a VPN I don't know what to tell you other than "then very few orgs are doing table stakes with their VPNs." 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.
  • vlovich123 5y ago
    Yup. Every major tech company I’ve seen uses MFA + SSO for everything (including VPN and ssh). Many are even abandoning VPN because it doesn’t really give you what you want for security (vs something like BeyondCorp which is rapidly becoming the “right way” to do these things). 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.
    • tialaramex 5y ago
      > 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.
      • vlovich123 5y ago
        You don’t think there’s a possibility of timing attacks that can be used (eg use the yubikey for an account under your control on the same service)? Might be hard for corporate keys obviously… m 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.
        • tialaramex 5y ago
          > You don’t think there’s a possibility of timing attacks that can be used (eg use the yubikey for an account under your control on the same service)? Might be hard for corporate keys obviously… 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.
  • ramphastidae 5y ago
    The standard setup I’ve seen is MFA on VPN, with critical systems available only via VPN (like SSH), then all other services (email, GitHub, Slack, etc) are available only through SSO with its own MFA.
    • Haemm0r 5y ago
      How do you handle Cisco Webex with SSO+MF and video conferencing systems/rooms? For regular useres SSO+MF is no prob, however the rooms users are.
      • er4hn 5y ago
        The room users, as in, of a meeting room? I think those are defined to be in the "meatspace private network", so you don't need SSO/MF so long as the device identifies itself as being a member of the room. I haven't seen video conferencing hardware at co-working spaces, it seems everyone there just plugs in their laptop if need be.
    • alistairSH 5y ago
      MFA for both VPN (code repos, servers) and MFA/SSO for web application access at my employer. My wife's employer is similar. I work in software; she's in finance. I amazed this isn't the norm across all industries.
  • genmud 5y ago
    Uhh... Yea. we do (and I wouldn't even bucket my organization as one that is good at engineering/systems). VPN, email, slack, ssh are all behind multifactor. > 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.
    • 3pt14159 5y ago
      No. I did not say we should do nothing. What I said was people keep focusing on the one thing that the attackers used to get in, but that one thing is besides the point. 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.
• technion 5y ago
  I agree with you in the sense that those are literally the first thing I would do as a CISO anywhere too. 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.