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

261–270 of 369 posts

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

#261

Post by post_from_work »

warner25 wrote: post #183
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 o…

It took us NINE MONTHS to get a server installed in a data center a few years back. This was Marine-Corps fielded hardware running an ATO'd[1] software stack for real-world situational awareness, going into a Marine Corps data center. The people that run the data center have a glacial Change Management process, exacerbated by everyone in their organization not talking to each other, even though they are separated by cubical walls.

I too have no faith of seeing this stuff implemented anytime soon...

[1] (Authority to Operate, basically approval from the highest IT authorities to utilize something on a DoD network)

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

#262

Post by worthless-trash »

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…

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

This depends on how far down the rabbit hole you want to go, if it was secureboot, only signed processes can run, would that make you feel better ? If it doesn't.. what would ?

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

#263

Post by adreamingsoul »

mkohlmyr wrote: post #28
adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

We have that in Sweden too. As an expat it's a complete nightmare for me from day one. Getting my bank to successfully issue it was impossible. First, in the days before mobile bank-id, they sent windows-only hardware as I recall. Then came the days of letters/cards/hardware getting lost in the mail. I gave up on it in the end. I have multiple things (banking-wise) I no longer have online access to because of it. If…

(3 years ago I moved to Norway) It took me about a month to get into the system, but once I had my national ID it took about a week for my MFA dongle to arrive. After that It has been a great experience.

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

#264

Post by adreamingsoul »

paganel wrote: post #25
adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

What happens to the people who are not banked?

There are alternatives. For example, MiniID and BuypassID.

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

#265

Post by warner25 »

post_from_work wrote: post #261
warner25 wrote: post #183

Earlier quoted context omitted.

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

It took us NINE MONTHS to get a server installed in a data center a few years back. This was Marine-Corps fielded hardware running an ATO'd[1] software stack for real-world situational awareness, going into a Marine Corps data center. The people that run the data center have a glacial Change Management process, exacerbated by everyone in their organization not talking to each other, even though they are separated by…

Haha, yes, my day-to-day work for the past two years has been fighting exactly this same fight on the Army side.

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

#266

Post by iszomer »

seized wrote: post #256
kortilla wrote: post #244

Earlier quoted context omitted.

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

Not really. What's the use case there, everyone sharing a Google account? I travelled a lot for work, and never had issues with account access. Nor did my wife ever have issues related to accounts. We don't share Google accounts though. It sounds like that user has personal accounts being used by three people for business use... Which isn't "A seaman and his family".

It may be true about 10 years ago but I imagine the heuristics to have been improved since; I remember being locked out of my Google account while abroad for a month and all it took was to log back in within my "country of origin".

Or a more recent example: my father forgot to bring his Android phone back abroad which subsequently locked him out of his account/services; had to wipe it for him to get his access back.

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

#267

Post by mjg59 »

xyzzy_plugh wrote: post #249
tptacek wrote: post #126

Earlier quoted context omitted.

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…

Most SSO solutions don't verify device identity or state, so you're not ensuring that the connection is coming from a computer you trust running software you trust.

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

#268

Post by thinkmassive »

pabs3 wrote: post #189
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.…

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.

A remote cryptographically-signed attestation is not reproducible

https://developer.android.com/training/safetynet/attestation

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

#269

Post by AaronFriel »

solatic wrote: post #128

Meh. OMB also mandated moving to IPv6 more than a decade ago: https://www.cio.gov/assets/resources/internet-protocol-versi... Nobody cares. It just gets postponed forever.

The memo you're linking to was recently updated and did have force. The DOD, one of the largest federal agencies, issued its own memo with similar deadlines, and this & others have had the result of jumpstarting IPv6 / dual stack support for all of the major clouds & Kubernetes.

If FedRAMP qualification is tied to IPv6 support, you'll see every major contractor and cloud provider support it promptly.

If you look at the recent updates for cloud providers - AWS and GCP support for IPv6, Kubernetes going dual stack by default - you can see that this memo had a substantial impact.

Sometimes these things take time, but in this case, the recent memo you link to lit a fire under everyone.

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

#270

Post by raxxorrax »

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…

These are strong requirements, but I fear the government just wants more transparency of citizens. Remote-attestation of trusted platforms could lead to the worst surveillance attempts we have ever seen. And it would require you to trust your government. That is a bad idea from a security point of view.

edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So much so that I believe it is worthy to insert the problem into debates about anything relating to security. Because security often serves as the raison d'être for such ambitions.

Post reply on HN