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

171–180 of 369 posts

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

#171

Post by MattPalmer1086 »

nybble41 wrote: post #44
MattPalmer1086 wrote: post #19

Earlier quoted context omitted.

It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?

"Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet . In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be…

Yes, good point.

I wonder if that applies to all infrastructure, or just enterprise applications.

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

#172

Post by madjam002 »

zrail wrote: post #66
amluto wrote: post #51

Earlier quoted context omitted.

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.

You can query the Tailscale API socket locally from your application to see who someone is (email address) based on the connecting IP. It would be nice if the API let you tap into their ACL system as well

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

#173

Post by pishpash »

dathinab wrote: post #135
btbuilder wrote: post #125

Earlier quoted context omitted.

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.

Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…

It does seem like a privilege escalation in the reverse direction, allowing banks to escalate a decision about security into one about devices. They should not have that power, and it's far from the only solution.

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

#174

Post by pishpash »

reilly3000 wrote: post #140
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.…

How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client. If you want to get a package that is in the Arch core/ repo, doesnt that require a form of attestation? I just don’t see a slippery slope towards dropping support for unofficial clients, we’re already at the bottom where they are generally and actively rejected for various…

Where we "already" are is not a state to be anchored on.

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

#175

Post by mindslight »

kelnos wrote: post #98
jandrewrogers wrote: post #76

Earlier quoted context omitted.

There is a large contingent of non-religious people who are against it on civil liberties grounds. The resistance to it truly crosses both parties, and it requires the cooperation of the States, which makes it politically non-viable as a practical matter.

The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification that are a pain in the ass for a regular citizen to have to deal with. And the REAL ID stuff essentially makes state IDs conform to a national ID specification anyway. And regardless, if you do want a national US ID, you just get a p…

> The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification

Yes, and this unreliable patchwork is already being heavily abused by surveillance companies (eg Equifax, Google, LexisNexis, Facebook, Retail Equation, etc) involuntarily storing our personal information - creating permanent records on us that we can only guess the contents and scope of, sorting us into prescriptive classes so that we can be better managed, and completely unaccountable to even their most egregious victims.

Social security numbers were promised to only be used for purposes of administering social security, and yet now they're required by many businesses for keying into that surveillance matrix. The main thing holding back more businesses from asking for identifiers is that people are hesitant to give them out.

Before there is any talk of strengthening identification, we need a US GDPR codifying a basic right to privacy. Until I'm able to fully control the surveillance industry's dossiers on me (inspection, selective deletion, prohibit future collection), I'll oppose anything that would further empower them.

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

#176

Post by nybble41 »

judge2020 wrote: post #111
fire wrote: post #80

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum tra…

Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.

Any kind of tunnel or VPN would also mess with the minimum travel time. This seems like a good way to cause more problems for regular people just trying to log in from slightly unusual network configurations than for any hypothetical man-in-the-middle.

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

#177

Post by lmeyerov »

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

Yep

I'd feel 100% differently about this stuff if the NSA or some other cybersecurity gov arm making these rules used their massive cybersecurity budgets to provide free MFA, TLS, encrypted DNS, etc., whether US gov hosted or via non-profit (?) partners like LetsEncrypt.

OSS & free software otherwise has a huge vendor tax to actually get used. As is, this feels like economic insecurity & anti-competition via continued centralization to a small number of megavendors. Rules like this should come with money, and not to primes & incumbents, but utility providers.

Sure, our team is internally investing in building out a lot of this stuff, but we have security devs & experience, while the long tail of software folks use doesn't. The gov sets aside so much $$$$ for the perpetual cyber war going on, but not for simple universal basics here :(

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

#178

Post by pishpash »

fire wrote: post #80

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum tra…

Wouldn't work for VPN and authorized delegation. Very bad idea.

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

#179

Post by nybble41 »

dsr_ wrote: post #103
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.

DoT and DoH only encrypt the connection to the recursive resolver, more for privacy than security. You still need DNSSEC to authenticate the results.

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

#180

Post by melony »

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…

Isn't 3 responsible for all those HN horror stories about being locked out of their Google accounts while traveling?
Post reply on HN