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

231–240 of 369 posts

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

#231

Post by ensan »

themacguffinman wrote: post #214
0xedd wrote: post #210

Earlier quoted context omitted.

Wrong. 80% of attacks are social engineering ones. In which an employee is convinced to make a bank transfer, open some document, install some program. From there, often times it's exploiting wide spread software commonly found in large organizations. Everything you said cannot be further from the truth.

Hence the pre-approved software restrictions. In a locked down system, even the most gullible employee won't have the authorization to "install some program". I'd also hope that businesses care about more than 80% of attacks, preferably they should care about 100% of attacks. Hence, pre-approved software restrictions.

Wrong again.

The computers in any sizable business already have the pre-approved restrictions set on the OS level. Employers can’t just install any software.

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

#232

Post by thaeli »

kelnos wrote: post #99
jollybean wrote: post #63

Earlier quoted context omitted.

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.

I hear people say all the time that, in the US, the Postal Service would be great for this, and I can't help but agree. Sure, they'd have to develop in-house expertise around these sorts of security systems (just as any new federal government agency put in charge of this would have to do), which could be difficult. But they have the ability to distribute forms, documentation, and tokens to pretty much everyone in the…

So does the Social Security Administration, and they already administer the closest thing to a national ID number we have..

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

#233

Post by LilBytes »

ineedasername wrote: post #221
0xffff2 wrote: post #165

Earlier quoted context omitted.

NIST has made this recommendation for years. Sadly, I work for another branch of the Federal government and despite the NIST guidance I still have to rotate my password every 60 days. (Actually, the starts sending me daily emails warning me 15 days out, and the date is based on last change, so practically it's more like 45 days.)

I know, it's been a while since rotation was considered a best practice. Yet the security team where I work will pick a random shiny new security practice and impose it on users. (I don't mind the imposition of good security, the hassle is worth it). Just one example where I work is a prohibition against emailing certain types of documents or data to others in the company (which is mostly Word & Excel docs) Which see…

This is why security teams get a bad wrap :(

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

#234

Post by reilly3000 »

pishpash wrote: post #174
reilly3000 wrote: post #140

Earlier quoted context omitted.

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.

That’s fair. Its just to say there is a lot of context for client verification in software. Competitive multiplayer gaming has become an arms races of exploits and invasive anti-cheat measures; there is no concept of bring-your-own-client when there is money on the line.

Valve has taken a less heavy-handed approach and let users have more freedom over their client and UI, but they also have a massive bot problem in titles like TF2.

I can’t connect to my work network from a random client, and it will throw flags and eventually block me if I connect with an out-of-date OS version.

I can’t present any piece of paper with my banking data and a signature on it and expect other parties to accept it. I have to present it on an authorized document.

I guess money may be the common denominator here.

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

#236

Post by tptacek »

philosopher1234 wrote: post #142
imrejonk wrote: post #138

> Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption. This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Neth…

Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.

No, DANE is very bad. But it's a dead-letter standard, so I don't worry about much.

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

#237

Post by parkerhiggins »

tialaramex wrote: post #219
dmd wrote: post #206

Earlier quoted context omitted.

They even HAVE this already, at https://login.gov/ !

I have a login.gov account. Needless to say I'm not a US citizen, and the IRS should not cut me a refund check. ID.me supports WebAuthn (or maybe U2F? In this context it doesn't matter) but importantly it does identity verification so it can determine whether I am a US citizen, whether I'm a tax payer, and if so which one. Now, perhaps the US Federal Government should own the capability to do that instead of a privat…

A private company shouldn’t own this capability. Especially as ID.me CEO lied about maintaining a database of every face “1-to-many” that uses their verification system. They’re right up there with Clearview AI.

https://www.theverge.com/2022/1/26/22903437/id-me-facial-rec...

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

#238

Post by 0xdeadb00f »

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?

Whatever happened to Dnscrypt?

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

#239

Post by agar »

KarlKemp wrote: post #78
kstrauser wrote: post #37

Earlier quoted context omitted.

The "trust" here largely refers to identity. Do you trust that everyone in your house is your relative, by virtue of the fact that they're in your house? That falls down when you have a burglar. Similarly, is it good to trust that everyone on your corporate network is an employee, and therefore should have employee-level access to all the resources on that network? I wouldn't recommend it.

No, but I trust the people I regularly interact with and therefore allow them to be in my home. Nobody trusts people just because they happen to be in their home. To the extend that trust can go to “zero”, my fear is it will harm the (existing) first form of trust, which is vital, and have little impact on the stupid latter definition of trust. I know tech operates on different definitions/circumstances here. That’s…

I see this as the exact point of the Zero Trust terminology.

People extend your exact trust assertions to their networks, and bad actors exploit it to effect a compromise. A corporate network cannot be like your home. Zero Trust says that you should assume anything, and anyone, can be exploited - so secure appropriately.

Per your analogy, what would you do if your invited houseguests, unbeknownst even to themselves, wore a camera for reconnaissance by a 3rd party? What would you do if these cameras were so easy to hide that anyone, at any time, might be wearing one and you couldn't know?

You would have to assume that anyone that entered your home had a camera on them. You would give them no more access than the bare minimum needed to do whatever they were there to do (whether eat dinner or fix your sink). You'd identify them, track their movement, and keep records.

Your term, "Zero misplaced trust," assumes that you can identify where to place trust. Did you trust that system you had validated and scanned for 5 years...until Log4shell was discovered? Did you trust the 20-year veteran researcher before they plugged in a USB without knowing their kid borrowed it and infected it?

Zero Trust is a response to the failure of "trust but verify."

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

#240

Post by nijave »

notatoad wrote: post #188
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.…

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

It can go pretty terribly sideways just like antivirus with poorly coded, proprietary, privileged agents running on end user devices collecting data.

I worked at a place that only allowed "verified" software before and it's an ongoing battle to keep that list updated. Things like digital signatures can be pretty reliable but if you're version pinning you can make it extremely difficult to quickly adopt patched versions when a vulnerability comes out.

Post reply on HN