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

151–160 of 369 posts

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

#151

Post by pdonis »

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…

> Is that really a problem? In practice wouldn't it just mean you can only use employer-provided and certified devices?

That's fine for employees doing work for their employers. It's not fine for personal computing on personal devices that have to be able to communicate with a wide variety of other computers belonging to a wide variety of others, ranging from organizations like banks to other individuals.

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

#152

Post by Godel_unicode »

sodality2 wrote: post #112
Godel_unicode wrote: post #92

Earlier quoted context omitted.

All of this is really government we-don't-pick-winners speak for yubikeys.

My OpenSK chip begs to differ. https://github.com/google/OpenSK

The disclaimer on the linked page agrees with me.

"This project is proof-of-concept and a research platform. It is NOT meant for a daily usage. The cryptography implementations are not resistent against side-channel attacks."

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

#153

Post by wmf »

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.

Most likely GeoIP information is used as one of many inputs to a neural net that decides whether you can log on or not (see tons of "Google locked me out" examples).

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

#155

Post by wizzwizz4 »

jacobr1 wrote: post #109
InitialLastName wrote: post #79

Earlier quoted context omitted.

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

I'm uncomfortable letting organisations have control over the software that runs on my hardware. (Or, really, any hardware I'm compelled to use.)

Suppose the course I've been studying for the past three years now uses $VideoService, but $VideoService uses remote attestation and gates the videos behind a retinal scan, ten distinct fingerprints, the last year's GPS history and the entire contents of my hard drive?¹ If I could spoof the traffic to $VideoService, I could get the video anyway, but every request is signed by the secure enclave. (I can't get the video off somebody else, because it uses the webcam to identify when a camera-like object is pointed at the screen. They can't bypass that, because of the remote attestation.)

If I don't have ten fingers, and I'm required to scan ten fingerprints to continue, and I can't send fake data because my computer has betrayed me, what recourse is there?

¹: exaggeration; no real-world company has quite these requirements, to my knowledge

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

#156

Post by mnd999 »

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…

Bleeding edge or complete fantasy? This is going to be very very expensive and guess who’s going to be paying for it?

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

#157

Post by enriquto »

wyldfire wrote: post #105
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.…

> 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

The dystopia described in Stallman's "The right to read" is almost here... and we don't even get to colonize the solar system.

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

#158

Post by Godel_unicode »

count wrote: post #134
Godel_unicode wrote: post #92

Earlier quoted context omitted.

All of this is really government we-don't-pick-winners speak for yubikeys.

PIV/CAC Smartcards.

That's an interesting subject, since there has been a lot of government push for PIV but the internet has essentially decided that FIDO2/webauthn are the way forward and making them work with PIV is non-trivial.

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

#159

Post by chaxor »

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

Wow, the monero project looks like they have some great ideas. I like this reproducible build - may try to get my team to work towards that. It seems like monero has more of a focus on use as a real currency, so hopefully it isn't drawing in the speculative people and maintains it's real use.

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

#160

Post by freedomben »

hansvm wrote: post #137
Signez wrote: post #36

Earlier quoted context omitted.

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…

Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.

It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what it is. We've emailed you a code to the email account that you are also locked out of because something is a tiny bit different with you. Also we're putting a flag on your account so it raises holy hell the next 36 times you log in."
Post reply on HN