This memo is driving me nuts. It's not that the memo is bad; it's very competent, and while there are things in it I disagree with, it's far better than anything else the USG has published, and its authors should be happy.<p>No, my problem is that every goddam security product company in the world is treating it like the white paper for their product, and so, if you pay attention to security stuff, you're besieged with takes about how this memo is going to change everything, hmmm, just coincidentally, in such a way that makes our product vital to the continued working of every company connected to the Internet.<p>God help us if the federal government ever publishes a memo about geographically distributing app workloads. You thought I was a nightmare now.<p>"[M]any overlook device identity but it’s one of the most important context sources". Yeesh.
"The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted"<p>It's about time. That's how airliners are designed. The guiding principle is "no single failure will bring the airplane down."<p>What it is <i>not</i> is "guarantee critical components will not fail".<p>The airline design principle is applicable to all kinds of things, like electrical grid design, security design, nuclear plant design, oil drilling platform design, ship design, and on and on. But I see it rarely applied, which is frustrating.
This has restored my faith in the government wrt technology. I am sure there are some very passionate and smart people behind this initiative who are motivated by doing things right rather than intellectual laziness.<p>I’m convinced that the “defense in depth” and “security permitter” models were pretty much entirely driven by laziness (define a perimeter and call it a day) and pork (defense in depth= we can pay for tons of different disjoint security software/vendors/contracting because it adds depth). Zero trust actually requires you to do the right thing and do it everywhere, and hopefully reduces the amount of waste thrown at vendors. It will create a lot of integration work but will hopefully consolidate the actual security software used.
I like that they're setting such a high bar, despite the potential difficulties of achieving that broadly. One question I have: I've yet to encounter an entity (including login.gov) that allows FIDO2/WebAuthn without also requiring a HOTP/TOTP or other 2nd-factor. So what's the point of allowing the security key option if an attacker has the option to attack the authentication code (which is often sent via SMS)?
I'll believe it when I see it.<p>I'm still waiting for feds to implement the guidance from <a href="https://pages.nist.gov/800-63-3/sp800-63-3.html" rel="nofollow">https://pages.nist.gov/800-63-3/sp800-63-3.html</a> from 2017 and 2020 about NOT rotating passwords arbitrarily, and NOT requiring undue amount of special symbols.<p>Even when I've asked IT, I get crickets and more bullshit password rotation.
I just have to shake my head at this stuff.<p>They still haven't fixed <i>this</i> after decades of effort:<p><a href="https://www.washingtonpost.com/sf/national/2014/03/22/sinkhole-of-bureaucracy/" rel="nofollow">https://www.washingtonpost.com/sf/national/2014/03/22/sinkho...</a><p>It would be great if they could do something to prevent things like the OPM data breach, but check out this questioning of the principles involved in that debacle:<p><a href="https://www.youtube.com/watch?v=AK-zEGjxuAA" rel="nofollow">https://www.youtube.com/watch?v=AK-zEGjxuAA</a><p>Does this give anyone any hope that there is competence to deal with this?<p>I know someone is going to say, "but we have to start somewhere". Sure. But, keep in mind there doesn't appear to be any pilot program where they've proven they can do this in even a single place. And now they're creating a blanket executive order to <i>do something</i> across the whole federal government?
Previous HN discussion on this memo: <a href="https://news.ycombinator.com/item?id=30101411" rel="nofollow">https://news.ycombinator.com/item?id=30101411</a>
Ah, I thought the name was familiar. They have a good zero trust reverse proxy that I deployed on k8s a few years back.<p><a href="https://www.pomerium.com/guides/kubernetes.html" rel="nofollow">https://www.pomerium.com/guides/kubernetes.html</a>
They're also (intentionally?) misrepresenting the memo.<p>> MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network).<p>They comment with:<p>> While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard.<p>Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.<p>I don't know or care who pomerium is or what they sell, but this sort of anti-advice severely diminishes their trustworthiness.
This should be voted back to the top, because it's hugely important and everyone should have eyes on the bad actors inside government called authorizing officials who are going to abuse the shit out of this by attacking their users. Fuck Citrix, fuck Menlo Security, fuck F5. Fuck these motherfuckers.
VPNs are one of those items misunderstood (perhaps even by authors) in this memo.<p>People claim they are deprecated. I don’t think VPNs, proxies and bastions will be deprecated. I don’t think we will access so many random applications directly over internet without segmentation.