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

241–250 of 369 posts

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

#241

Post by agar »

mikewarot wrote: post #104

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

In a true Zero Trust model, every client device would have the minimum number of network permissions necessary to do its job - as would every other device. Every device could only connect to known good/known necessary endpoints over specific ports and protocols. All else would be blocked.[1]

If the client device were compromised with a zero day exploit, the blast radius would be substantially smaller, the difficulty of an attacker mapping a network for later exploit would be exponentially larger, and time to response would dramatically shrink.

[1] (This is particularly relevant for fixed-function IoT and Operational Technology devices. General computing devices need broader controls, but again - the minimum necessary for that user, in that business context, to do their job.)

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

#242

Post by nijave »

kelnos wrote: post #88
reginaldo wrote: post #39

Earlier quoted context omitted.

It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.

It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.

For something like LineageOS, ironically, the solution is to root your device to adjust build properties so it looks signed.

My vanilla LineageOS install fails but I can root with Magisk, enable Zygisk to inject code into Android, edit build properties, add SafetyNet fix and now my device is good to go?

It's crazy to think the workaround is "enable arbitrary code injection" (Zygisk)

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

#243

Post by konklone »

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…

Login.gov does support identity verification. Not all uses of Login.gov require it, so many accounts are just used for email with MFA.

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

#244

Post by kortilla »

sciurus wrote: post #201
freedomben wrote: post #160

Earlier quoted context omitted.

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…

Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

This is the problem with this kind of thing. It just perfectly captures the privilege/shelter of the programmers who come up with these heuristics of “obviously unusual”.

You just described the usage pattern of a pilot with a family, a truck driver, a seaman, etc.

It’s only unusual if your definition of usual is “relatively rich, computer power user”.

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

#245

Post by nijave »

lupire wrote: post #146
alksjdalkj wrote: post #129

Earlier quoted context omitted.

Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some po…

Free software doesn't really work in a networked untrusted world.

Linux and BSD beg to differ

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

#246

Post by throwaway48375 »

freedomben wrote: post #205
sciurus wrote: post #201

Earlier quoted context omitted.

Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

The frustrating thing to me is that as a user they don't give us any tools to help ourselves. I would gladly make it a "team" account and login individually if we could. I would gladly do a shared TOTP, or whitelist login locations, or anything like that. Or at least give us the option to accept the risk and disable whatever anomaly detection they are applying. But no, that's not how the software world works anymore.…

Why do you need to all access the same account though? Can't you grant access to whatever resource you need to multiple accounts?

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

#247

Post by YokoZar »

pledess wrote: post #228

Our corporate IT folks have a Zero Trust Manifesto in which there are enrolled devices (laptops that remote SREs can carry around), there are enterprise applications, and there's connectivity between these (e.g., tunnel pairs). SREs often need to write scripts that operate on sensitive production data from the enterprise applications, but must do this work directly on an enrolled device. Pre-Zero-Trust days seemed sa…

Why not combine the two and require using the secure VMs only from enrolled devices?

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

#248

Post by konklone »

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…

The document distinguishes between enterprise-facing and public-facing systems. For enterprise-facing (government employees, contractors, etc.), it's talking about discontinuing use of TOTP. For public-facing systems, it doesn't impose any restrictions, since (as you're saying) the general public really needs options.

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

#249

Post by xyzzy_plugh »

tptacek wrote: post #126
mjg59 wrote: post #122

Earlier quoted context omitted.

It's not clear to me that a VPN endpoint is a meaningfully smaller attack surface than an authenticating proxy? The VPN approach has a couple of downsides: * You don't have a central location to perform more granular access control. Per-service context aware access restrictions (device state, host location, that sort of thing) need to be punted down to the services rather than being centrally managed. * Device state…

Sure: an authenticating proxy serves the same purpose. I agree that unless you have a pretty clever VPN configuration, you're losing the device context stuff, which matters a lot in some places. I'd do: * SSO integration on all internal apps. * An authenticating proxy if the org that owned it was sharp and had total institutional buy-in both from developers and from ops. * A WireGuard VPN otherwise.

> * SSO integration on all internal apps.

> * An authenticating proxy

I'm having trouble understanding what the fundamental difference is between these. Is it just a matter of a single, centralized proxy at the perimeter of your service network versus in-service SSO? Is there a functional difference between being in the same process space versus a sidecar on the same host versus a service on another host?

Ultimately it boils down to trusting the authority, whether that's a function (code review), a shared library (BOM), an RPC (TLS), a sidecar (kernel), or a foreign service (mTLS). There are different strengths and weaknesses for each of these, but it's not clear to me that the options you would prefer are distinctly more or less secure -- maybe there is an argument for defense in depth, but I'm not certain that's what you're pitching.

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

#250

Post by pagnol »

freedomben wrote: post #160
hansvm wrote: post #137

Earlier quoted context omitted.

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…

Have you considered using the same Proxy or VPN? I work remotely and sometimes access services through a VPN based in the country my coworkers are at specifically to avoid this kind of annoyance.
Post reply on HN