11 ms·

The new White House memo on zero trust is a strong signal

205 points by CKMo 5y ago

aborsy 5y ago
VPNs are one of those items misunderstood (perhaps even by authors) in this memo. People claim they are deprecated. I don’t think VPNs, proxies and bastions will be deprecated. I don’t think we will access so many random applications directly over internet without segmentation.
killjoywashere 5y ago
This should be voted back to the top, because it's hugely important and everyone should have eyes on the bad actors inside government called authorizing officials who are going to abuse the shit out of this by attacking their users. Fuck Citrix, fuck Menlo Security, fuck F5. Fuck these motherfuckers.
treatmentteam 5y ago
I like that they're setting such a high bar, despite the potential difficulties of achieving that broadly. One question I have: I've yet to encounter an entity (including login.gov) that allows FIDO2/WebAuthn without also requiring a HOTP/TOTP or other 2nd-factor. So what's the point of allowing the security key option if an attacker has the option to attack the authentication code (which is often sent via SMS)?
- toomuchtodo 5y ago
  Login.gov has to serve a diverse customer base made up of every American resident/citizen, therefore its threat model and approach to securing identity is different than that of someone, say, storing cryptocurrency (where the risk of loss and lack of recourse is much higher than someone seeing your Social Security benefit statement). Consider an older citizen losing their hardware token, and unable to login to their Social Security or IRS account. The current model is to be expected until the government builds out its identity functions. Security is about trade offs and compromise. (no affiliation with login.gov or related federal agencies, just a fan of their work)
- MadVikingGod 5y ago
  I'm not sure about the public facing entities, but the Federal Government already has a VERY widespread PKI system in place that I'm sure they will leverage. Most federal departments already have a process for distributing a smartcard with a Federally signed key to all their employees and some contractors. I'm hoping that they can extend that to non-employees.
  - toomuchtodo 5y ago
    If DHS would issue Global Entry smart cards that were part of the CAC platform [1], that would be a convenient shim until national ID cards could be deployed. I picked up a TWIC card [2] thinking I'd be able to use it with Login.gov, but no such luck. [1] https://www.cac.mil/common-access-card/ https://www.cac.mil/common-access-card/ [2] https://www.tsa.gov/for-industry/twic https://www.tsa.gov/for-industry/twic
- acdha 5y ago
  login.gov does allow you to have FIDO2 setup without a phone number — my account currently only has hardware tokens — but I think you want to look backwards from the challenges of supporting a service like this. If you're serving the general public, people reliably lose their tokens and you can't require them in general since multiple $20 tokens is a complete non-starter so there's a lot of appeal to things like SMS which don't require additional purchases. The other question I'd ask is how bad SMS really is: it's definitely not great from a security perspective but for the average person it seems unlikely that they're worse off from having it. Maybe we can start phasing that out now that common clients have integrated WebAuthn support (e.g. Apple's FaceID/TouchID for the web) but if you have to support the general public you probably have a different threat model than a more targeted audience.
- brightball 5y ago
  I haven’t found a bank that will allow FIDO2 yet.
- tialaramex 5y ago
  "or other 2nd-factor" includes another WebAuthn factor. This is one of the things that bothered people about login.gov before, they're like "But I already have a Security Key, what other factor can I use?". Another security key is fine, they're each independent factors, it just wants to make you won't lose your only route in to the site. My login.gov has my two Security Keys plus my phone (a Pixel 2, via WebAuthn) as possible second factors. You can indeed choose TOTP, or use a Government ID (a few million people have Federal jobs with IDs) and if you must yes you can use SMS So if you need better security, just don't choose the weaker options. Suddenly that goes from "automated attack launched by a school kid on the far side of an ocean" to "Government black bag job", and it's enough that most people should sleep soundly. Also, the other benefit of Security Keys as an option is that we can teach users that their Security Key is safe, because it can't be phished. That exercise where you try to train users to check they're on the right domain and realistically you know adversaries will confuse or terrify them into skipping that step? No need with Security Keys, that's the Web Browser's job and the browser isn't confused or terrified, it's just calling memcmp() as it does many times every page load.
tptacek 5y ago
This memo is driving me nuts. It's not that the memo is bad; it's very competent, and while there are things in it I disagree with, it's far better than anything else the USG has published, and its authors should be happy. No, my problem is that every goddam security product company in the world is treating it like the white paper for their product, and so, if you pay attention to security stuff, you're besieged with takes about how this memo is going to change everything, hmmm, just coincidentally, in such a way that makes our product vital to the continued working of every company connected to the Internet. God help us if the federal government ever publishes a memo about geographically distributing app workloads. You thought I was a nightmare now. "[M]any overlook device identity but it’s one of the most important context sources". Yeesh.
- oldstrangers 5y ago
  Welcome to the wonderful world of inbound marketing.
  - bduerst 5y ago
    Yeah first party whitepapers are nothing, wait until you get sucked into content syndication networks that sell peoples' contact details.
    - dzhiurgis 5y ago
      I'm convinced half of silicon valley sales people are selling each other software to help them sell software
- staticassertion 5y ago
  Security vendors gonna security vendor.
  - blitzar 5y ago
    Vendors gonna vendor
  - 5y ago
visviva 5y ago
Previous HN discussion on this memo: https://news.ycombinator.com/item?id=30101411 https://news.ycombinator.com/item?id=30101411
- dang 5y ago
  Thanks! Macroexpanded: I read the federal government’s Zero-Trust Memo so you don’t have to - https://news.ycombinator.com/item?id=30101411 https://news.ycombinator.com/item?id=30101411 - Jan 2022 (352 comments)
MadVikingGod 5y ago
Does this mean that the decades of training on "Defense in Depth" is going to have to be rewritten and all the certs reacquired?
- bombcar 5y ago
  Which answer makes more money flow around? That's the one!
righttoolforjob 5y ago
They're also (intentionally?) misrepresenting the memo. > MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network). They comment with: > While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard. Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. I don't know or care who pomerium is or what they sell, but this sort of anti-advice severely diminishes their trustworthiness.
- noasaservice 5y ago
  > Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. Having done FedRAMP and also running Tor servers, I'm also at the conclusion that using IP in any sort of rules is a bad practice. You should be identifying/verifying/authorizing/logging the connection regardless how it came to you. Consistently doing that means you now can control user access at a chokepoint (usually an IdP or similar token passing credentialled login). If you have a malicious entry, you do not want lateral transfer to end up hitting less secure stuff on the network because of implicit network trust. Zero-Trust is about removing those implicit things. And if everything has service-level IdP token checks, not even replay attacks will work. As a malicious hacker, you're stuck there. Less scope of damage. Same with Tor. For anyone running a Tor client or operating a Onionserver, all connections are actually an IPv6 overlay with routers that only support TCP (not UDP/ICMP). And since those absolutely will be randomized every 10m on average, you absolutely must verify the connection AND NOT the source/destination.
- cdoxsey 5y ago
  First of all its not a misrepresentation of the memo. The memo states: > Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet. Second with regards to this statement: > Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. That's precisely what zero trust networking is. Ala Google's BeyondCorp: > Virtually every company today uses firewalls to enforce perimeter security. However, this security model is problematic because, when that perimeter is breached, an attacker has relatively easy access to a company’s privileged intranet. As companies adopt mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce. Google is taking a different approach to network security. We are removing the requirement for a privileged intranet and moving our corporate applications to the Internet. (https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-...) Maybe they're wrong about all this, but it's not anti-advice. It's a legitimate security model being pursued by many different companies.
WalterBright 5y ago
"The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted" It's about time. That's how airliners are designed. The guiding principle is "no single failure will bring the airplane down." What it is not is "guarantee critical components will not fail". The airline design principle is applicable to all kinds of things, like electrical grid design, security design, nuclear plant design, oil drilling platform design, ship design, and on and on. But I see it rarely applied, which is frustrating.
- hulitu 5y ago
  Tell that to Microsoft.
- pinephoneguy 5y ago
  How do you do shared secret authentication in this model? I know cert based auth is far better but today many apps rely on some kind of shared secret auth. Don't you by definition trust eg LDAP/IPA servers then? EDIT: In case it's not clear: I'm talking about employee facing software inside an organization where you might have some kind of single sign on system or a distributed account system (like IPA or LDAP.)
  - WalterBright 5y ago
    One method is "assume your system is penetrated, so do not put all your secrets on one system." For example, don't use the same password on your Etrade account that you use on your bank account.
  - daveevad 5y ago
    I don't know but have wondered about this sort of thing before. There is a Wikipedia article on 'Key ceremony'[0] that seems to indicate an in-real-life shared secret creation and or sharing event. (https://en.wikipedia.org/wiki/Key_ceremony)[0] https://en.wikipedia.org/wiki/Key_ceremony)[0]
  - noasaservice 5y ago
    Use SAML. The SP never sees the credentials. The SP only sees a token which includes the username (NameID) and other attributes passed from the IdP through the client. https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang... (Scroll down to the "Single sign-on using SAML in a Web browser" image for a good data flow depiction) Basically this seems to be a "SAML-IZE EVERYTHING".
noasaservice 5y ago
I'll believe it when I see it. I'm still waiting for feds to implement the guidance from https://pages.nist.gov/800-63-3/sp800-63-3.html https://pages.nist.gov/800-63-3/sp800-63-3.html from 2017 and 2020 about NOT rotating passwords arbitrarily, and NOT requiring undue amount of special symbols. Even when I've asked IT, I get crickets and more bullshit password rotation.
- earleybird 5y ago
  Microsoft followed on with that NIST recommendation and suggested discontinuing regular password changes in 2019 [0]. Where I work (MS infra & service) 90 password changes show no sign of going away. A pretty convincing argument that the folks involved are more into theatre than practice. [0] https://news.ycombinator.com/item?id=26863907 https://news.ycombinator.com/item?id=26863907
  - bombcar 5y ago
    For a long while you couldn't disable password rotation on Office 365 - you could only set it to some arbitrarily long time (and only via Powershell, if I recall correctly). Luckily that is starting to back off, but it has NOT trickled down everywhere by a long shot.
opportune 5y ago
This has restored my faith in the government wrt technology. I am sure there are some very passionate and smart people behind this initiative who are motivated by doing things right rather than intellectual laziness. I’m convinced that the “defense in depth” and “security permitter” models were pretty much entirely driven by laziness (define a perimeter and call it a day) and pork (defense in depth= we can pay for tons of different disjoint security software/vendors/contracting because it adds depth). Zero trust actually requires you to do the right thing and do it everywhere, and hopefully reduces the amount of waste thrown at vendors. It will create a lot of integration work but will hopefully consolidate the actual security software used.
- rank0 5y ago
  Defense in depth is just a design philosophy for security controls. It absolutely makes sense and doesn’t have to be implemented as “disjoint security software/vendors/contracting” It can be the justification for things like database controls, OS level controls, or seemingly trivial things like log forging. I heard a million different versions of “it’s not a big deal because an attacker would have to breach our network already”
tomohawk 5y ago
I just have to shake my head at this stuff. They still haven't fixed this after decades of effort: https://www.washingtonpost.com/sf/national/2014/03/22/sinkhole-of-bureaucracy/ https://www.washingtonpost.com/sf/national/2014/03/22/sinkho... It would be great if they could do something to prevent things like the OPM data breach, but check out this questioning of the principles involved in that debacle: https://www.youtube.com/watch?v=AK-zEGjxuAA https://www.youtube.com/watch?v=AK-zEGjxuAA Does this give anyone any hope that there is competence to deal with this? I know someone is going to say, "but we have to start somewhere". Sure. But, keep in mind there doesn't appear to be any pilot program where they've proven they can do this in even a single place. And now they're creating a blanket executive order to do something across the whole federal government?
actuator 5y ago
Is it inspired by Google's zero trust model, Beyond Corp?
oxplot 5y ago
Ah, I thought the name was familiar. They have a good zero trust reverse proxy that I deployed on k8s a few years back. https://www.pomerium.com/guides/kubernetes.html https://www.pomerium.com/guides/kubernetes.html
cett 5y ago
Any bets on how many years before PCI DSS catches up?

205 points by CKMo 5y ago

VPNs are one of those items misunderstood (perhaps even by authors) in this memo. People claim they are deprecated. I don’t think VPNs, proxies and bastions will be deprecated. I don’t think we will access so many random applications directly over internet without segmentation.

killjoywashere 5y ago

This should be voted back to the top, because it's hugely important and everyone should have eyes on the bad actors inside government called authorizing officials who are going to abuse the shit out of this by attacking their users. Fuck Citrix, fuck Menlo Security, fuck F5. Fuck these motherfuckers.

treatmentteam 5y ago

I like that they're setting such a high bar, despite the potential difficulties of achieving that broadly. One question I have: I've yet to encounter an entity (including login.gov) that allows FIDO2/WebAuthn without also requiring a HOTP/TOTP or other 2nd-factor. So what's the point of allowing the security key option if an attacker has the option to attack the authentication code (which is often sent via SMS)?

toomuchtodo 5y ago
Login.gov has to serve a diverse customer base made up of every American resident/citizen, therefore its threat model and approach to securing identity is different than that of someone, say, storing cryptocurrency (where the risk of loss and lack of recourse is much higher than someone seeing your Social Security benefit statement). Consider an older citizen losing their hardware token, and unable to login to their Social Security or IRS account. The current model is to be expected until the government builds out its identity functions. Security is about trade offs and compromise. (no affiliation with login.gov or related federal agencies, just a fan of their work)
MadVikingGod 5y ago
I'm not sure about the public facing entities, but the Federal Government already has a VERY widespread PKI system in place that I'm sure they will leverage. Most federal departments already have a process for distributing a smartcard with a Federally signed key to all their employees and some contractors. I'm hoping that they can extend that to non-employees.
- toomuchtodo 5y ago
  If DHS would issue Global Entry smart cards that were part of the CAC platform [1], that would be a convenient shim until national ID cards could be deployed. I picked up a TWIC card [2] thinking I'd be able to use it with Login.gov, but no such luck. [1] https://www.cac.mil/common-access-card/ https://www.cac.mil/common-access-card/ [2] https://www.tsa.gov/for-industry/twic https://www.tsa.gov/for-industry/twic
acdha 5y ago
login.gov does allow you to have FIDO2 setup without a phone number — my account currently only has hardware tokens — but I think you want to look backwards from the challenges of supporting a service like this. If you're serving the general public, people reliably lose their tokens and you can't require them in general since multiple $20 tokens is a complete non-starter so there's a lot of appeal to things like SMS which don't require additional purchases. The other question I'd ask is how bad SMS really is: it's definitely not great from a security perspective but for the average person it seems unlikely that they're worse off from having it. Maybe we can start phasing that out now that common clients have integrated WebAuthn support (e.g. Apple's FaceID/TouchID for the web) but if you have to support the general public you probably have a different threat model than a more targeted audience.
brightball 5y ago
I haven’t found a bank that will allow FIDO2 yet.
tialaramex 5y ago
"or other 2nd-factor" includes another WebAuthn factor. This is one of the things that bothered people about login.gov before, they're like "But I already have a Security Key, what other factor can I use?". Another security key is fine, they're each independent factors, it just wants to make you won't lose your only route in to the site. My login.gov has my two Security Keys plus my phone (a Pixel 2, via WebAuthn) as possible second factors. You can indeed choose TOTP, or use a Government ID (a few million people have Federal jobs with IDs) and if you must yes you can use SMS So if you need better security, just don't choose the weaker options. Suddenly that goes from "automated attack launched by a school kid on the far side of an ocean" to "Government black bag job", and it's enough that most people should sleep soundly. Also, the other benefit of Security Keys as an option is that we can teach users that their Security Key is safe, because it can't be phished. That exercise where you try to train users to check they're on the right domain and realistically you know adversaries will confuse or terrify them into skipping that step? No need with Security Keys, that's the Web Browser's job and the browser isn't confused or terrified, it's just calling memcmp() as it does many times every page load.

tptacek 5y ago

This memo is driving me nuts. It's not that the memo is bad; it's very competent, and while there are things in it I disagree with, it's far better than anything else the USG has published, and its authors should be happy. No, my problem is that every goddam security product company in the world is treating it like the white paper for their product, and so, if you pay attention to security stuff, you're besieged with takes about how this memo is going to change everything, hmmm, just coincidentally, in such a way that makes our product vital to the continued working of every company connected to the Internet. God help us if the federal government ever publishes a memo about geographically distributing app workloads. You thought I was a nightmare now. "[M]any overlook device identity but it’s one of the most important context sources". Yeesh.

oldstrangers 5y ago
Welcome to the wonderful world of inbound marketing.
- bduerst 5y ago
  Yeah first party whitepapers are nothing, wait until you get sucked into content syndication networks that sell peoples' contact details.
  - dzhiurgis 5y ago
    I'm convinced half of silicon valley sales people are selling each other software to help them sell software
staticassertion 5y ago
Security vendors gonna security vendor.
- blitzar 5y ago
  Vendors gonna vendor
- 5y ago

visviva 5y ago

Previous HN discussion on this memo: https://news.ycombinator.com/item?id=30101411 https://news.ycombinator.com/item?id=30101411

dang 5y ago
Thanks! Macroexpanded: I read the federal government’s Zero-Trust Memo so you don’t have to - https://news.ycombinator.com/item?id=30101411 https://news.ycombinator.com/item?id=30101411 - Jan 2022 (352 comments)

MadVikingGod 5y ago

Does this mean that the decades of training on "Defense in Depth" is going to have to be rewritten and all the certs reacquired?

bombcar 5y ago
Which answer makes more money flow around? That's the one!

righttoolforjob 5y ago

They're also (intentionally?) misrepresenting the memo. > MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network). They comment with: > While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard. Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. I don't know or care who pomerium is or what they sell, but this sort of anti-advice severely diminishes their trustworthiness.

noasaservice 5y ago
> Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. Having done FedRAMP and also running Tor servers, I'm also at the conclusion that using IP in any sort of rules is a bad practice. You should be identifying/verifying/authorizing/logging the connection regardless how it came to you. Consistently doing that means you now can control user access at a chokepoint (usually an IdP or similar token passing credentialled login). If you have a malicious entry, you do not want lateral transfer to end up hitting less secure stuff on the network because of implicit network trust. Zero-Trust is about removing those implicit things. And if everything has service-level IdP token checks, not even replay attacks will work. As a malicious hacker, you're stuck there. Less scope of damage. Same with Tor. For anyone running a Tor client or operating a Onionserver, all connections are actually an IPv6 overlay with routers that only support TCP (not UDP/ICMP). And since those absolutely will be randomized every 10m on average, you absolutely must verify the connection AND NOT the source/destination.
cdoxsey 5y ago
First of all its not a misrepresentation of the memo. The memo states: > Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet. Second with regards to this statement: > Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy. That's precisely what zero trust networking is. Ala Google's BeyondCorp: > Virtually every company today uses firewalls to enforce perimeter security. However, this security model is problematic because, when that perimeter is breached, an attacker has relatively easy access to a company’s privileged intranet. As companies adopt mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce. Google is taking a different approach to network security. We are removing the requirement for a privileged intranet and moving our corporate applications to the Internet. (https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-...) Maybe they're wrong about all this, but it's not anti-advice. It's a legitimate security model being pursued by many different companies.

WalterBright 5y ago

"The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted" It's about time. That's how airliners are designed. The guiding principle is "no single failure will bring the airplane down." What it is not is "guarantee critical components will not fail". The airline design principle is applicable to all kinds of things, like electrical grid design, security design, nuclear plant design, oil drilling platform design, ship design, and on and on. But I see it rarely applied, which is frustrating.

hulitu 5y ago
Tell that to Microsoft.
pinephoneguy 5y ago
How do you do shared secret authentication in this model? I know cert based auth is far better but today many apps rely on some kind of shared secret auth. Don't you by definition trust eg LDAP/IPA servers then? EDIT: In case it's not clear: I'm talking about employee facing software inside an organization where you might have some kind of single sign on system or a distributed account system (like IPA or LDAP.)
- WalterBright 5y ago
  One method is "assume your system is penetrated, so do not put all your secrets on one system." For example, don't use the same password on your Etrade account that you use on your bank account.
- daveevad 5y ago
  I don't know but have wondered about this sort of thing before. There is a Wikipedia article on 'Key ceremony'[0] that seems to indicate an in-real-life shared secret creation and or sharing event. (https://en.wikipedia.org/wiki/Key_ceremony)[0] https://en.wikipedia.org/wiki/Key_ceremony)[0]
- noasaservice 5y ago
  Use SAML. The SP never sees the credentials. The SP only sees a token which includes the username (NameID) and other attributes passed from the IdP through the client. https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang... (Scroll down to the "Single sign-on using SAML in a Web browser" image for a good data flow depiction) Basically this seems to be a "SAML-IZE EVERYTHING".

noasaservice 5y ago

I'll believe it when I see it. I'm still waiting for feds to implement the guidance from https://pages.nist.gov/800-63-3/sp800-63-3.html https://pages.nist.gov/800-63-3/sp800-63-3.html from 2017 and 2020 about NOT rotating passwords arbitrarily, and NOT requiring undue amount of special symbols. Even when I've asked IT, I get crickets and more bullshit password rotation.

earleybird 5y ago
Microsoft followed on with that NIST recommendation and suggested discontinuing regular password changes in 2019 [0]. Where I work (MS infra & service) 90 password changes show no sign of going away. A pretty convincing argument that the folks involved are more into theatre than practice. [0] https://news.ycombinator.com/item?id=26863907 https://news.ycombinator.com/item?id=26863907
- bombcar 5y ago
  For a long while you couldn't disable password rotation on Office 365 - you could only set it to some arbitrarily long time (and only via Powershell, if I recall correctly). Luckily that is starting to back off, but it has NOT trickled down everywhere by a long shot.

opportune 5y ago

This has restored my faith in the government wrt technology. I am sure there are some very passionate and smart people behind this initiative who are motivated by doing things right rather than intellectual laziness. I’m convinced that the “defense in depth” and “security permitter” models were pretty much entirely driven by laziness (define a perimeter and call it a day) and pork (defense in depth= we can pay for tons of different disjoint security software/vendors/contracting because it adds depth). Zero trust actually requires you to do the right thing and do it everywhere, and hopefully reduces the amount of waste thrown at vendors. It will create a lot of integration work but will hopefully consolidate the actual security software used.

rank0 5y ago
Defense in depth is just a design philosophy for security controls. It absolutely makes sense and doesn’t have to be implemented as “disjoint security software/vendors/contracting” It can be the justification for things like database controls, OS level controls, or seemingly trivial things like log forging. I heard a million different versions of “it’s not a big deal because an attacker would have to breach our network already”

tomohawk 5y ago

I just have to shake my head at this stuff. They still haven't fixed this after decades of effort: https://www.washingtonpost.com/sf/national/2014/03/22/sinkhole-of-bureaucracy/ https://www.washingtonpost.com/sf/national/2014/03/22/sinkho... It would be great if they could do something to prevent things like the OPM data breach, but check out this questioning of the principles involved in that debacle: https://www.youtube.com/watch?v=AK-zEGjxuAA https://www.youtube.com/watch?v=AK-zEGjxuAA Does this give anyone any hope that there is competence to deal with this? I know someone is going to say, "but we have to start somewhere". Sure. But, keep in mind there doesn't appear to be any pilot program where they've proven they can do this in even a single place. And now they're creating a blanket executive order to do something across the whole federal government?

actuator 5y ago

Is it inspired by Google's zero trust model, Beyond Corp?

oxplot 5y ago

Ah, I thought the name was familiar. They have a good zero trust reverse proxy that I deployed on k8s a few years back. https://www.pomerium.com/guides/kubernetes.html https://www.pomerium.com/guides/kubernetes.html

cett 5y ago

Any bets on how many years before PCI DSS catches up?