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

51–60 of 369 posts

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

#51

Post by amluto »

ctime wrote: post #38

The real crux of the issue is the long-tail of applications which were never conceived with anything but network-based trust. I'm certain the DoD is absolutely packed with these, probably for nearly every workflow. The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable s…

Many workflows are proxyable using fine grained IP-level or TCP-level security. (I believe that Tailscale does more or less this.). This can’t support RBAC or per-user dynamic authentication particularly well, but it can at least avoid trusting an entire network.

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

#52

Post by shadowgovt »

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.…

> If only specific builds of software that are on a vendor-sanctioned allowlist

Yes, but for government software this is a bog-standard approach. Not even "the source code is publicly viewable to everyone" is sufficient scrutiny to pass government security muster; specific code is what gets cleared, and modifications to that code must also be cleared.

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

#53

Post by tptacek »

pitaj wrote: post #27
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…

What's wrong with TOTP?

It's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?"

It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious.

You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.

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

#54

Post by tptacek »

jaycroft wrote: post #32
pitaj wrote: post #27

Earlier quoted context omitted.

What's wrong with TOTP?

I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test. https://blog.trezor.io/why-you-should-never-use-google-authe... Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untru…

Yeah these are very dumb arguments against TOTP.

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

#55

Post by ketzo »

toomuchtodo wrote: post #33
thomascgalvin wrote: post #23

Earlier quoted context omitted.

I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.

Which is why you ignore them. No reason for a nation to be held back by this type of person. Same reason you don’t take cancer treatment advice from someone who suggests juicing.

That 30% of the population translates to about 45% of federal elected representatives. Not quite as easy as "ignoring them," sadly.

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

#56

Post by tptacek »

paganel wrote: post #24

> Do not give long-lived credentials to your users. This screams "we'll use more post-it notes for our passwords compared to before", or maybe the real world to which this memo is addressed is different compared to the real (work-related) world I know.

The general attitude among practitioners now is that "post-it notes with passwords on them" is superior to the more common practice of "shitty passwords shared across multiple services".

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

#57

Post by atuladhar »

meepmorp wrote: post #17
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…

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.

Somewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers.

(Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)

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

#58

Post by [deleted] »

ketzo wrote: post #55
toomuchtodo wrote: post #33

Earlier quoted context omitted.

Which is why you ignore them. No reason for a nation to be held back by this type of person. Same reason you don’t take cancer treatment advice from someone who suggests juicing.

That 30% of the population translates to about 45% of federal elected representatives. Not quite as easy as "ignoring them," sadly.

[deleted]

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

#59

Post by tptacek »

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 implementations of every other VPN protocol are pretty unsafe) with SSO integration, and to have the applications exposed by that VPN also integrate with your SSO. Your users are generally on the VPN all day, and they're logging in to individual applications or SSH servers via Okta or Google.

"RIP VPNs" is not a great take.

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

#60

Post by jollybean »

They should have given out free identify FOBs with vaccines.

I'm only half joking.

It's really just a matter of changing gears - you carry a physical key to your house, car, and your online life. You lose the key, you have to go through a bit of pain to get a new one.

But establishing that norm is beyond the purview of anyone it seems.

Perhaps one of those advanced Nordic countries will have the wherewithal, it seems Estonia is ahead of all of us but we don't pay attention.

But this doc looks good.

Post reply on HN