Hmm so BeyondCorp for gov - BeyondGov? Or am I totally off
I read the federal government’s Zero-Trust Memo so you don’t have to
251–260 of 369 posts
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#252Earlier 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 supports identity proofing. It’s part of the flow when signing up for a Social Security account using Login.gov at ssa.gov (Login.gov recently became their primary identity provider a few months back).
Login.gov also supports WebAuthn.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#253This 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…
Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.
My company is built on GSuite. We use APP and CAA for everything.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#254This 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…
Maybe, but my hope is that this pushes external vendors that have government contracts to support these workflows.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#255Our 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?
There isn't a great reason. It's just that the people who set the policy wanted to prevent lateral attacker movement at all costs. The VMs and the enterprise applications are in the same building, but no longer have network connectivity because they don't routinely communicate (in the past, a VM would make an outbound TCP connection only after an SRE decided that a problem existed).
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#256Earlier 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.
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".
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#257Earlier quoted context omitted.
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.
That's not true at any big dev shop
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#258Earlier 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 don't you share a TOTP between all of you? Just take a screenshot of the authenticator QR code, or save it to a shared 1password secret.
Google's login protection mechanisms seem to be satisfied by TOTP usage, and you won't be locked out anymore (or at least much less likely to be).
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#259Earlier quoted context omitted.
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.
I thought I'd find you in here! Wishing you well friend.
-Mario
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#260Tangential remark to author if they’re reading: favoring “she” isn’t more inclusive for an unknown pronoun. You probably already use a non-gendered singular “they” in normal speech and you could use that where the gender/preference isn’t known. Just a suggestion from an NB who passes as male and thinks binary gender substitution doesn’t help, even though I appreciate the effort.