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

61–70 of 369 posts

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

#61

Post by tbirdz »

atuladhar wrote: post #57
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.

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, un…

Just saying in this in case it will help you. For treasurydirect, you can use inspect element and change the value="" field on the password element, and paste in your password from your password manager. It's not as convenient as autofill from your password manager, but it sure beats using the graphical keyboard.

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

#62

Post by [deleted] »

Signez wrote: post #36
c0l0 wrote: post #31

Earlier quoted context omitted.

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

Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement. Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation…

[deleted]

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

#63

Post by jollybean »

adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

That's all good except for the 'bank' part.

It was expedient but banks are not the orgs. that should be running that.

Every nation needs to turn their Drivers ID and Passport authorities into 'Ministry of Identity' and issue fobs, passwords that can be used on the basis of some standard. Or something like that, maybe quasi distributed.

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

#64

Post by tptacek »

joshgachnang wrote: post #14
enriquto wrote: post #7

Earlier quoted context omitted.

As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. It is a good practice to securize everything even if visible only internally. The "perimeter defense" given by a VPN can be a plus, but never the only line of defense.

The memo does say each agency needs to pick one system that is not internet accessible and make it accessible in the next year. The way I read this memo is pushing that VPNs don't add much in the way of security (if you follow the rest of the memo) and should be removed.

The other way to read that part of the memo is that the exercise of exposing an application on the public Internet is a forcing function that will require agencies to build application security skills necessary whether or not they use VPNs. Note that the memo demands agencies find a single FISMA-Moderate service to expose.

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

#65

Post by dc-programmer »

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…

For anyone interested in 3, Google’s BeyondCorp whitepapers are an excellent starting point

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

#66

Post by zrail »

amluto wrote: post #51
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.

Yeah, a thing that I wish Tailscale could do is hand off an attestation of some sort that says a TCP connection is being used by user X who is authorized by rule Y. Maybe "magic TLS client certs" is a thing coming on the horizon.

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

#67

Post by c0l0 »

seibelj wrote: post #34
c0l0 wrote: post #31

Earlier quoted context omitted.

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

Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero

Let me elaborate on the problem I do have with remote attestation, no matter if I can verify that the signed binary is identical with something I can build on my own.

I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setting the clock, etc. All other "high-level" services that I am aware of, like Mail, Calendaring, Contacts, Phone, Instant Messaging, etc., are either provided by other parties that I feel more comfortable with, or that I actually host myself.

Now let's assume that I would want or have to do online/mobile banking on my phone - that will generally only work with the proprietary app my bank provides me with. Even if I choose to install their unmodified APK, (any lack of) SafetyNet will not attest my LineageOS-powered phone as "kosher" (or "safe and secure", or "healthy", or whatever Google prefers calling it these days), and might refuse to work. As a consequence, I'm effectively unable to interact via the remote service provided by my bank, because they believe they've got to protect me from the OS/firmware build that I personally chose to use.

Sure, "just access their website via the browser, and do your banking on their website instead!", you might say, and you'd be right for now. But with remote attestation broadly available, what prevents anyone from also using that for the browser app on my phone, esp. since browser security is deemed so critical these days? I happen to use Firefox from F-Droid, and I doubt any hypothetical future SafetyNet attestation routine will have it pass with the same flying colors that Google's own Chrome from the Play Store would. I'm also certain that "Honest c0l0's Own Build of Firefox for Android" wouldn't get the SafetyNet seal of approval either, and with that I'd be effectively shut off from interacting with my bank account from my mobile phone altogether. The only option I'd have is to revert back to a "trusted", "healthy" phone with a manufacturer-provided bootloader, firmware image, and the mandatory selection of factory-installed, non-removable crapware that I am never going to use and/or (personally) trust that's probably exfiltrating my personal data to some unknown third parties, sanctified by some few hundreds of pages of EULA and "Privacy" Policy.

With app stores on all mainstream and commercially successful desktop OSes, the recent Windows 11 "security and safety"-related "advances" Microsoft introduced by (as of today, apparently still mildly) requiring TPM support, and supplying manufacturers with "secure enclave"-style add-on chips of their own design ("Pluton", see https://www.techradar.com/news/microsofts-new-security-chip-...), I can see this happening to desktop computing as well. Then I can probably still compile all the software I want on my admittedly fringe GNU/Linux system (or let the Debian project compile it for me), but it won't matter much - because any interaction with the "real" part of the world online that isn't made by and for software freedom enthusiasts/zealots will refuse to interact with the non-allowlisted software builds on my machine.

It's going to be the future NoTCPA et al. used to combat in the early 00s, and I really do dread it.

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

#68

Post by [deleted] »

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…

[deleted]

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

#69

Post by vmception »

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…

Force banks to do this, immediately. They can levy it on any organization with a banking license or wants access to FEDWire or the ACH system. Force it for SWIFT access too, if the bank has an online banking system for users.

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

#70

Post by SecurityLagoon »

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…

Thanks for saying this. This was exactly my take. Saying goodbye to VPNs just completely ignores the risk of RCE vulnerabilities on your services. You can have a VPN that still brings you into a zero trust network.
Post reply on HN