Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I read the federal government’s Zero-Trust Memo so you don’t have to

bastionzero.com

Post reply on HN
Print view View original

121–130 of 369 posts

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#121

Post by gkop »

mooreds wrote: post #108
meepmorp wrote: post #17

Earlier quoted context omitted.

Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

To be fair, this was part of the NIST guidelines since Mar 2020. A whole appendix was added to justify it: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

Way earlier than that, even.

> Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets

Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too.

https://web.archive.org/web/20160624033024/https://pages.nis...

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#122

Post by mjg59 »

tptacek wrote: post #59
uncomputation wrote: post #5

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the impl…

It's not clear to me that a VPN endpoint is a meaningfully smaller attack surface than an authenticating proxy? The VPN approach has a couple of downsides:

* You don't have a central location to perform more granular access control. Per-service context aware access restrictions (device state, host location, that sort of thing) need to be punted down to the services rather than being centrally managed.

* Device state validation is either a one-shot event or, again, needs to be incorporated into the services rather than just living in one place.

I love Wireguard and there's a whole bunch of problems it solves, but I really don't see a need for a VPN for access to most corporate resources.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#123

Post by rodgerd »

uncomputation wrote: post #5

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

The thing is that over-focus on perimeter security is still a huge problem, and one reason that e.g. ransomware owns orgs with depressing regularity. There's nothing wrong with perimeter controls in and of themselves. But they become a substitute for actually security what's on the internal network, so once you've bypassed the perimeter, it's all too easy to roam at will.

The people over-relying on perimeter security are the folks buying a big sixties car and assuming that seatbelts and traction control are no substitute for chrome bumpers.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#124

Post by rodgerd »

KarlKemp wrote: post #22

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The sam…

"Zero assumption" would have been a better phrase, but that horse is not just out of the stable, he's met a nice lady horse and is raising a family of foals and grand-foals.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#125

Post by btbuilder »

shbooms wrote: post #101
tablespoon wrote: post #81

Earlier quoted context omitted.

>> 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. > I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaning…

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions.

They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#126

Post by tptacek »

mjg59 wrote: post #122
tptacek wrote: post #59

Earlier quoted context omitted.

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the impl…

It's not clear to me that a VPN endpoint is a meaningfully smaller attack surface than an authenticating proxy? The VPN approach has a couple of downsides: * You don't have a central location to perform more granular access control. Per-service context aware access restrictions (device state, host location, that sort of thing) need to be punted down to the services rather than being centrally managed. * Device state…

Sure: an authenticating proxy serves the same purpose. I agree that unless you have a pretty clever VPN configuration, you're losing the device context stuff, which matters a lot in some places.

I'd do:

* SSO integration on all internal apps.

* An authenticating proxy if the org that owned it was sharp and had total institutional buy-in both from developers and from ops.

* A WireGuard VPN otherwise.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#127

Post by codemac »

staticassertion wrote: post #2

This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edg…

Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#129

Post by alksjdalkj »

c0l0 wrote: post #31
staticassertion wrote: post #2

This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edg…

I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…

Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some point and figure out what they want to do about it.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#130

Post by count »

tptacek wrote: post #59
uncomputation wrote: post #5

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the impl…

If you can get the govt to drop FIPS or wireguard to change to ...different crypto, wireguard would take off like hotcakes.

I'd be flogging tailscale so hard!

Stupid policies.

Post reply on HN