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

101–110 of 369 posts

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

#101

Post by shbooms »

tablespoon wrote: post #81
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.…

>> 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 your employer forces you to, say, only use a certain version of Windows as your OS in order to do your job, that's generally acceptable to most people.

But if your TV streaming provider tells you have to use a certain version of Windows to consume their product, that's not considered acceptable to a good deal of people.

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

#102

Post by emptysongglass »

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…

I don't like VPNs. I think there's better ways of protecting our infrastructure without them. AWS offers a lot of technologies for doing just that.

A VPN is another failure layer that when it goes down all of your remote workers are hosed. The productivity losses are immense. I've seen it first-hand. The same for bastion hosts. Some tiny misconfiguration that sneaks in and everybody is fubared.

Bastion hosts and VPNs: we have better ways of protecting our valuables that's also a huge win for worker mobility and security.

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

#103

Post by dsr_ »

scarmig wrote: post #100

This sounds really beautiful, and I am saving the link for future reference. I'm curious about the DNS encryption recommendation. My impression was that DNSSEC was kind of frowned upon as doing nothing that provides real security, at least according to the folks I try to pay attention to. Are these due to differing perspectives in conflict, or am I missing something?

DNS over TLS and DNS over HTTP/TLS.

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

#105

Post by wyldfire »

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

> I think 3. is very harmful for actual, real-world use of Free Software.

It has been a long, slow but steady march in this direction for a while [1]. Eventually we will also bind all network traffic to the individual human(s) responsible. 'Unlicensed' computers will be relics of the past.

[1] https://boingboing.net/2012/01/10/lockdown.html

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

#106

Post by userbinator »

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…

nor would that be a society you’d want to live in.

100% agreed. My first thought upon seeing the title of the article was "and we trust that you did read it?"

The term "zero trust" certainly has a very dystopian connotation to me. It reminds me of things like 1984.

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

#107

Post by tptacek »

emptysongglass wrote: post #102
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…

I don't like VPNs. I think there's better ways of protecting our infrastructure without them. AWS offers a lot of technologies for doing just that. A VPN is another failure layer that when it goes down all of your remote workers are hosed. The productivity losses are immense. I've seen it first-hand. The same for bastion hosts. Some tiny misconfiguration that sneaks in and everybody is fubared. Bastion hosts and VPNs…

That's true of legacy VPNs like OpenVPN, and less true of modern VPNs. But either way: a VPN is a meaningful attack surface reduction for all internal apps that don't require individual apps to opt-in or stage changes for, and doesn't require point-by-point auditing of every app. Most organizations I've worked with would be hard-pressed to even generate an inventory of all their internal apps, let alone an assurance that they're properly employing web application security techniques to ensure that they're safe to expose on the Internet.

We're just going to disagree about this.

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

#108

Post by mooreds »

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.

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

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

#109

Post by jacobr1 »

InitialLastName wrote: post #79
nybble41 wrote: post #49

Earlier quoted context omitted.

Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot…

> no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services. It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.

Or we could better adopt secure/confidential computing enclaves. This would allow the organization to have control over the silo'd apps and validate some degree of security (code tampering, memory encryption, etc) but not need to trust that other apps on the device or even the OS weren't compromised.

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

#110

Post by criddell »

vmception wrote: post #69
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.

I asked my bank about their 16 character limit on password length because it suggests they are saving the password rather than some kind of hash. Their response - don't worry about it, you aren't responsible for fraud.

Banks aren't going to want to implement any changes that cost more (in system changes and customer support) than the fraud they prevent.

Post reply on HN