4 ms·

Summary of the USA federal government's zero-trust memo

49 points by fanf2 2y ago

zamalek 2y ago
> This seems very feasible in the context of a government agency, because each employee can receive her token as part of her onboarding when she is hired. However, this sort of thing is harder to do if you are a SaaS service It's not. Allow SMS to be disabled in favor of a more secure option (WebAuthn). Strongly suggest that users purchase a token.
- vlovich123 2y ago
  I find tokens to be incredibly hard to manage and if you lose them you’re completely screwed forever. And then there’s the problem where every employee gives you a security key do you don’t know which one has which credentials (yes you can add keys but managing all of that physical stuff has a cost). Although they’re not popular in security circled because technically they’re still vulnerable to phishing websites, I prefer TOTP apps like Google authenticator because it’s backed up to the cloud so even if I lose my phone I know I can get back the keys; it’s the best trade off for security vs usability.
  - tphyahoo 2y ago
    [dead]
  - alwa 2y ago
    I was confused on my first read through: this guidance seems to refer to federal enterprise applications, not necessarily customer-facing services. It seems reasonable to me to require employees to use a physical authenticator. Heck, how many of the people here use them and require employees to use them? Often to secure access to applications and resources less consequential than Official Acts Of The Federal Government. It would feel less reasonable (and a throwback to the ‘00s) to mail out hardware authenticators to customers/members of the public just to, say, buy stamps from the USPS or something. But the employee needs to be responsible enough not to lose it, they definitely need to not be able to back it up to god-knows-what consumer-grade provider (or to duplicate it at all). And when they lose it, IT needs to know to invalidate the lost one and issue them a new one. My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken?
    - Ylpertnodi 2y ago
      >needs to be responsible enough not to lose it.... needs to know to invalidate the lost one and issue them a new one. Ah, the never-ending circle of life.
    - 0xffff2 2y ago
      > My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken? I'm a Federal contractor. At least for my agency this is table stakes for any application period. I don't even have a password anymore. For the very small number of legacy applications that don't support smart card auth I have to log in to a different service to get a temporary password that expires after 24 hours.
  - zamalek 2y ago
    The main issue with TOTP is that it's still vulnerable to phishing, though it certainly is significantly better than SMS.
    - vlovich123 2y ago
      Yes but as I said, I’m personally less concerned about a successful phishing attack. I can see why you might be concerned as an employee to a multi billion dollar business but attacks on my personal safe are unlikely to be sophisticated enough to fool me / I’m not a target for sophisticated ones. UX vs threat model tradeoff.
      - tptacek 2y ago
        You should be very concerned about phishing. The push towards modern phishing-resistant authentication was spurred from large scale studies of phishing success against very smart targets (security teams at Google, for instance). It's probably drastically less expensive to put a "sophisticated" phishing attack together than it is to target you with a memory corruption exploit.
      - wglb 2y ago
        Phishing is the major vector for compromise. There is nobody that is unphishable. Very competent, careful, highly-skilled employees can be and have been phished.
  - deleted 2y ago
    [deleted]
- dochtman 2y ago
  Passkeys might provide a decent middle ground here, assuming current UX issues can be improved upon.
  - politelemon 2y ago
    I would certainly hope not, depending on the implementation it would be placing critical keys in the hands of an unknown/untrustworthy third party. The alternative is to manage the key infrastructure as a company which brings its own overheads, so the most obvious implementation goes back to WebAuthn.
  - freeone3000 2y ago
    Apple effectively fixed the UX issues, so we’re just waiting for the future to be evenly distributed.
joshmarinacci 2y ago
Surprisingly forward looking for the US government
dataflow 2y ago
A lot of good stuff in the recommendations, but I find this one questionable: > “Enterprise applications should be able to be used over the public internet.” This is straight up arguing against defense-in-depth, and getting rid of connection auditing and interception capability. Seems extremely dubious, unless by "be able to" they mean "it should be OK security-wise if you get rid of the VPN" and not "you should actually get rid of the VPN".
- brendoelfrendo 2y ago
  This is a fairly common recommendation for "zero trust." A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access. Google operates this way, if I recall correctly. It's how their "Beyond Corp" white-paper recommends setting up the environment. It's not exactly a "one size fits all" solution; I believe PCI requires VPN usage, for example, so a bank trying to implement zero trust practices would need to keep their VPN intact, but that's a regulatory concern, not so much a technical one.
  - dataflow 2y ago
    > A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access. Defense in depth is theoretically superfluous in a secure system, but it's still a good idea for... what I thought were obvious reasons. I don't see how this is any different. And, again, as I mentioned above this isn't even just about network trust, it's also about the ability to monitor, audit, and intercept potentially malicious connections when something does get compromised. "We assume our one layer of security will work perfectly" cannot be the starting assumption... > Google operates this way, if I recall correctly. Google also has 24/7 world-class security teams monitoring everything across the planet. They have a ton of power to monitor and mitigate damage across the entire internet. Just because something works for Google that doesn't mean it'll work for arbitrary organizations.
    - 2y ago
y-curious 2y ago
None of this is new to me, unfortunately. Going through getting FedRAMP High for my company and there are a lot of hoops to jump through. 80% of it is very reasonable e.g. DNSSEC, Hardware MFA. 20% of it is theater: You cannot, for example, allow AWS Govcloud to handle SSL termination for ECS. You have to manually verify S3 replication and cannot rely on their logging. Still, echoing other commenters' sentiments, it's nice to see the government being forward-thinking on this. Jury is still out for NIST to weigh in on post-quantum encryption.
- tptacek 2y ago
  DNSSEC isn't reasonable, and the OMB memo doesn't require it. CLOUD.GOV doesn't even support it. NIST has standardized a set of PQC constructions; I think the jury is in there.
  - y-curious 2y ago
    >NIST has standardized a set of PQC constructions; I think the jury is in there. Published 4 days ago, thanks for the heads up. I was curious if they would delay announcing the CRYSTALS-Kyber algorithm as their choice after a paper claimed that they were able to decrypt it without quantum. I just looked the paper up and they had a bug in their code, so their claim was dropped. https://eprint.iacr.org/2024/555 https://eprint.iacr.org/2024/555 >DNSSEC isn't reasonable Memo doesn't mention it, but please enlighten me as to why you feel this way. I think it's a low-effort way to prevent a (admittedly esoteric) attack.
    - tptacek 2y ago
      The NIST PQC standards were published very recently, but selected 2 years ago. If you use the search bar below and do "DNSSEC by:tptacek", I can spare this threat a recitation of an argument I've made many times before. I would say, with some pretty solid empirical backing, that DNSSEC is more or less a dead letter at this point, most especially in North America. Of course, "DNS encryption" (which is in the OMBZT memo) can mean a lot of things, and DoH is certainly not dead!
- 2y ago
tptacek 2y ago
We interviewed Eric Mill, one of the authors of the memo, a couple years back, getting into the details of what exactly the memo meant about VPNs, about encrypted email (it's not what you think it means) and about encrypted DNS: https://securitycryptographywhatever.com/2022/06/10/omb-zero-trust-memo-with-eric-mill/ https://securitycryptographywhatever.com/2022/06/10/omb-zero... I think for HN the most important thing you can keep in your head about the OMB ZT memo is that vendors jumped on it like the Bumpus hounds to the Parker family Christmas turkey, so there are a lot of ZT takes that more or less condense to "our product is now rated M for Mandatory".
deleted 2y ago
[deleted]
ProllyInfamous 2y ago
>No longer use phone/text codes for 2FA Hopefully my bank implements this recommendation ASAP... I haven't had access to online banking in the two years since they've required phone/text to log in, but are incompatible with my YubiKey (which is phish-resistant). I have complained for two years to them, visiting a physical teller every time I need an account inquiry.

49 points by fanf2 2y ago

> This seems very feasible in the context of a government agency, because each employee can receive her token as part of her onboarding when she is hired. However, this sort of thing is harder to do if you are a SaaS service It's not. Allow SMS to be disabled in favor of a more secure option (WebAuthn). Strongly suggest that users purchase a token.

vlovich123 2y ago
I find tokens to be incredibly hard to manage and if you lose them you’re completely screwed forever. And then there’s the problem where every employee gives you a security key do you don’t know which one has which credentials (yes you can add keys but managing all of that physical stuff has a cost). Although they’re not popular in security circled because technically they’re still vulnerable to phishing websites, I prefer TOTP apps like Google authenticator because it’s backed up to the cloud so even if I lose my phone I know I can get back the keys; it’s the best trade off for security vs usability.
- tphyahoo 2y ago
  [dead]
- alwa 2y ago
  I was confused on my first read through: this guidance seems to refer to federal enterprise applications, not necessarily customer-facing services. It seems reasonable to me to require employees to use a physical authenticator. Heck, how many of the people here use them and require employees to use them? Often to secure access to applications and resources less consequential than Official Acts Of The Federal Government. It would feel less reasonable (and a throwback to the ‘00s) to mail out hardware authenticators to customers/members of the public just to, say, buy stamps from the USPS or something. But the employee needs to be responsible enough not to lose it, they definitely need to not be able to back it up to god-knows-what consumer-grade provider (or to duplicate it at all). And when they lose it, IT needs to know to invalidate the lost one and issue them a new one. My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken?
  - Ylpertnodi 2y ago
    >needs to be responsible enough not to lose it.... needs to know to invalidate the lost one and issue them a new one. Ah, the never-ending circle of life.
  - 0xffff2 2y ago
    > My impression is that physical authenticators (often in the form of smart cards that double as employee ID) are pretty much table stakes in serious federal environments anyway, is that mistaken? I'm a Federal contractor. At least for my agency this is table stakes for any application period. I don't even have a password anymore. For the very small number of legacy applications that don't support smart card auth I have to log in to a different service to get a temporary password that expires after 24 hours.
- zamalek 2y ago
  The main issue with TOTP is that it's still vulnerable to phishing, though it certainly is significantly better than SMS.
  - vlovich123 2y ago
    Yes but as I said, I’m personally less concerned about a successful phishing attack. I can see why you might be concerned as an employee to a multi billion dollar business but attacks on my personal safe are unlikely to be sophisticated enough to fool me / I’m not a target for sophisticated ones. UX vs threat model tradeoff.
    - tptacek 2y ago
      You should be very concerned about phishing. The push towards modern phishing-resistant authentication was spurred from large scale studies of phishing success against very smart targets (security teams at Google, for instance). It's probably drastically less expensive to put a "sophisticated" phishing attack together than it is to target you with a memory corruption exploit.
    - wglb 2y ago
      Phishing is the major vector for compromise. There is nobody that is unphishable. Very competent, careful, highly-skilled employees can be and have been phished.
- deleted 2y ago
  [deleted]
dochtman 2y ago
Passkeys might provide a decent middle ground here, assuming current UX issues can be improved upon.
- politelemon 2y ago
  I would certainly hope not, depending on the implementation it would be placing critical keys in the hands of an unknown/untrustworthy third party. The alternative is to manage the key infrastructure as a company which brings its own overheads, so the most obvious implementation goes back to WebAuthn.
- freeone3000 2y ago
  Apple effectively fixed the UX issues, so we’re just waiting for the future to be evenly distributed.

joshmarinacci 2y ago

Surprisingly forward looking for the US government

dataflow 2y ago

A lot of good stuff in the recommendations, but I find this one questionable: > “Enterprise applications should be able to be used over the public internet.” This is straight up arguing against defense-in-depth, and getting rid of connection auditing and interception capability. Seems extremely dubious, unless by "be able to" they mean "it should be OK security-wise if you get rid of the VPN" and not "you should actually get rid of the VPN".

brendoelfrendo 2y ago
This is a fairly common recommendation for "zero trust." A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access. Google operates this way, if I recall correctly. It's how their "Beyond Corp" white-paper recommends setting up the environment. It's not exactly a "one size fits all" solution; I believe PCI requires VPN usage, for example, so a bank trying to implement zero trust practices would need to keep their VPN intact, but that's a regulatory concern, not so much a technical one.
- dataflow 2y ago
  > A VPN is theoretically superfluous in a zero trust environment, where you have no concept of a trusted network and your applications should be sufficiently hardened to prevent unauthorized access. Defense in depth is theoretically superfluous in a secure system, but it's still a good idea for... what I thought were obvious reasons. I don't see how this is any different. And, again, as I mentioned above this isn't even just about network trust, it's also about the ability to monitor, audit, and intercept potentially malicious connections when something does get compromised. "We assume our one layer of security will work perfectly" cannot be the starting assumption... > Google operates this way, if I recall correctly. Google also has 24/7 world-class security teams monitoring everything across the planet. They have a ton of power to monitor and mitigate damage across the entire internet. Just because something works for Google that doesn't mean it'll work for arbitrary organizations.
  - 2y ago

y-curious 2y ago

None of this is new to me, unfortunately. Going through getting FedRAMP High for my company and there are a lot of hoops to jump through. 80% of it is very reasonable e.g. DNSSEC, Hardware MFA. 20% of it is theater: You cannot, for example, allow AWS Govcloud to handle SSL termination for ECS. You have to manually verify S3 replication and cannot rely on their logging. Still, echoing other commenters' sentiments, it's nice to see the government being forward-thinking on this. Jury is still out for NIST to weigh in on post-quantum encryption.

tptacek 2y ago
DNSSEC isn't reasonable, and the OMB memo doesn't require it. CLOUD.GOV doesn't even support it. NIST has standardized a set of PQC constructions; I think the jury is in there.
- y-curious 2y ago
  >NIST has standardized a set of PQC constructions; I think the jury is in there. Published 4 days ago, thanks for the heads up. I was curious if they would delay announcing the CRYSTALS-Kyber algorithm as their choice after a paper claimed that they were able to decrypt it without quantum. I just looked the paper up and they had a bug in their code, so their claim was dropped. https://eprint.iacr.org/2024/555 https://eprint.iacr.org/2024/555 >DNSSEC isn't reasonable Memo doesn't mention it, but please enlighten me as to why you feel this way. I think it's a low-effort way to prevent a (admittedly esoteric) attack.
  - tptacek 2y ago
    The NIST PQC standards were published very recently, but selected 2 years ago. If you use the search bar below and do "DNSSEC by:tptacek", I can spare this threat a recitation of an argument I've made many times before. I would say, with some pretty solid empirical backing, that DNSSEC is more or less a dead letter at this point, most especially in North America. Of course, "DNS encryption" (which is in the OMBZT memo) can mean a lot of things, and DoH is certainly not dead!
2y ago

tptacek 2y ago

We interviewed Eric Mill, one of the authors of the memo, a couple years back, getting into the details of what exactly the memo meant about VPNs, about encrypted email (it's not what you think it means) and about encrypted DNS: https://securitycryptographywhatever.com/2022/06/10/omb-zero-trust-memo-with-eric-mill/ https://securitycryptographywhatever.com/2022/06/10/omb-zero... I think for HN the most important thing you can keep in your head about the OMB ZT memo is that vendors jumped on it like the Bumpus hounds to the Parker family Christmas turkey, so there are a lot of ZT takes that more or less condense to "our product is now rated M for Mandatory".

deleted 2y ago

[deleted]

ProllyInfamous 2y ago

>No longer use phone/text codes for 2FA Hopefully my bank implements this recommendation ASAP... I haven't had access to online banking in the two years since they've required phone/text to log in, but are incompatible with my YubiKey (which is phish-resistant). I have complained for two years to them, visiting a physical teller every time I need an account inquiry.