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

181–190 of 369 posts

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

#181

Post by EthanHeilman »

wmf wrote: post #154
mikewarot wrote: post #104

Does any of this protect against a zero day exploit running in the client device?

No, but once the exploit is discovered they could use client posture information to prevent unpatched clients from logging on.

It reduces your window of exposure.

For instance the zero-trust system we are building at bastion-zero uses ephemeral ECDSA key pairs attested by tokens that expire.

+ When the user logs out these key pairs and tokens are deleted. Ideally tokens should be revoked as well. If an attacker installs an implant on the user's endhost and the user is not logged in the attacker doesn't get any access because there is no keys/tokens to steal. If the implant/attack is discovered prior to the user logging the device can be reset and the attacker doesn't get any access.

+ If the attacker installs an implant on the user's endhost and the user is logged in. The attacker gets the key pair and tokens. If the attacker attempts to exfil the key pair/tokens and use them from another host this may set off alarms. The attacker if they wish to be stealthy and maintain access must conduct the attack through that endhost (at least include they compromise additional systems). Once the tokens expire the attacker is locked out again.

+ If the attacker manages to watch the user login and generate the attestation to the key pair and good MFA is employed, e.g. U2F/FIDO. The attacker can not eternally get new key pairs since they can not read the secret from the MFA device.

+ As wmf suggests, monitoring helps a lot. Monitoring is extra powerful when can easily revoke the user's key pair without revoking the user. Say a user triggers an alarm, automatically revoke the key pair and see if they can reauth. If it is a stolen key pair the attacker might not be able get a new key pair issues if the actually user is offline. If you decide the device might be compromised you can disable access from that device and have user pick up a new laptop.

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

#182

Post by tata71 »

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.

This is the difference between

"Log in by tapping Yes on my phone"

and

actually using a FIDO2 USB key.

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

#183

Post by warner25 »

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…

"...fairly bleeding edge best practices..."

By the time we implement any of these things, if ever, they certainly won't be. I work on military networks and applications, and it's hard for me to believe that I'll see any of this within my career at the pace we move. This is the land of web applications that only work with Internet Explorer, ActiveX, Siverlight, Flash, and Java Applets, plus servers running Linux 2.6 or Windows Server 2012.

The idea of "Just-in-Time" access control where "a user is granted access to a resource only while she needs it, and that access is revoked when she is done" is terrifying when it takes weeks or months to get action on support tickets that I submit (where the action is simple, and I tee it up with a detailed description of whatever I need done).

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

#184

Post by zie »

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?

DNSSEC is security in the other direction( DNS server -> client ). All DNSSEC does is securely sign all the responses to DNS queries.

so DNSSEC is the answer to, can I trust this IP is valid for the name news.ycombinator.com.

DNS over TLS/HTTPS just says, nobody but the DNS server I use can see I'm wanting news.ycombinator.com's IP. It's mostly useless at the moment, since other gaps exist leaking essentially the same information(SNI, etc), but it should get more useful over time, as people are working on fixing those gaps.

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

#185

Post by dopamean »

golem14 wrote: post #116
wordsarelies wrote: post #45

Earlier quoted context omitted.

As if Gov't does their own IT infrastrucutre... This is a windfall for Gov't contractors.

Hey, at least they're 'our kind' of Gov't contractors. No $640 toilet seats here ;)

"This line of code will be $500 please"

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

#186

Post by quinnjh »

userbinator wrote: post #106
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.

No connection really but made me think of bidens tweet @POTUS 8h In 2021, we had the fastest economic growth since 1984. The Biden economic plan is working, folks.

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

#187

Post by zie »

tptacek wrote: post #120
unethical_ban wrote: post #113

TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life. TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker. The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general…

Yubikeys aren't the serious long-term alternative to TOTP; software keys embedded in phones are what we're going to end up with.

I want to disagree, but I can't, because you are right. Though perhaps as wearable tech grows(watches and what not), perhaps the keys will exist there also.

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

#188

Post by notatoad »

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 you can argue that remote attestation doesn't provide additional security, then i'd love to hear that argument. but it seems like a fairly clear-cut case that it does provide additional security, and i don't think it's reasonable to accept a lower level of security for the sake of allowing unverified builds of open-source software.

there are specific contexts where you want to distribute information as widely as possible, and in those contexts it makes sense to allow any software versions to access the information. but for contexts where security is important, that means verifying the client software isn't compromised.

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

#189

Post by pabs3 »

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

Identical source code when recompiled should produce identical binaries:

https://reproducible-builds.org/

Agreed that people should have the freedom to modify their software though.

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

#190

Post by gkop »

dragonwriter wrote: post #133
gkop wrote: post #121

Earlier quoted context omitted.

Way earlier than that, even. > Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too. https://web.archive.org/web/20160624033024/https://pages.nis...

SHOULD NOT and MUST NOT are very different from a compliance perspective. The former usually means something between nothing at all and “you can do it but you have to write paperwork that no one will actually read in detail, but someone will maybe check the existence of, if you do”. The latter means “do it and you are noncompliant”.

Thanks for pointing out the improvement over NIST, it wasn’t clear to me. But did you mean to reply to my parent? Both the draft and the current language say SHOULD NOT. I’d rather “must”, but will settle for “should”; the NIST docs have certainly made my work easier. Hopefully NIST improves, and perhaps this memo will help!

The essential purpose of my comment was only to correct my parent on the date.

Post reply on HN