3 ms·

I kind of want to challenge this "better SPOFs" idea. From what I understand of the ZTN concept, the SPOF is the factory line. If an adversary can compromise wh

I kind of want to challenge this "better SPOFs" idea. From what I understand of the ZTN concept, the SPOF is the factory line. If an adversary can compromise what's on the board, it's really hard to prevent that adversary from controlling what happens on that machine. I have had people tell me in meetings at work that they have pictures of people swapping out parts on an assembly line for unknown parts. If that's happening, unless the machines are verified by XRay, from my point of view, the ZT concept isn't worth a whole lot.

tptacek 5y ago
A pitfall of all these ZTN discussions is that they tend to propose a definition of "zero trust" as an axiom, and then use deduction to construct a whole system from those first principles. This is especially useful for security product vendors, who will pick the most congenial definition of "zero trust" in order to derive a mandate for their products. We don't so much have to get lost in abstractions here. There's a blueprint: all this ZTN stuff was inspired by Google's BeyondCorp paper (ZTN is the marketing-neutral name for BeyondCorp; the Kubernetes to BC's Borg). So: just go read the BeyondTrust paper; it's great: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-...
- distortedsignal 5y ago
  Thanks - my company is pushing a lot of ZTN stuff, and I wasn't totally sure where the principles are coming from. Having a root that I can anchor my debates in (which, as you can probably tell, is currently lacking) should be really helpful.
- staticassertion 5y ago
  The paper's definitely worth reading, although it's worth noting that: a) This is implementation heavy b) The implementation is tied to a specific company migrating to this approach incrementally I would say it's a great case study for moving to a ZTN, but if I were to explain ZTN I'd probably just propose a definition. I'm technically a vendor but the definition serves me in no way. 1. Requests are mutually authenticated and always encrypted (ex: mtls) 2. Requests are authorized; policy oriented, granular, and contextual authorization 3. Requests are monitored and audited The paper lists a bunch of ways to accomplish those goals. SSO, device inventories, an authorizing proxy, a monitor, etc. Of course, you're right. Vendors are horribly self serving and have already significantly degraded the term and confused people.
  - tptacek 5y ago
    This is the implementation that defined the movement. You can distill it down to principles, but if you're saying things that contradict it, you're talking about something other than ZTN.
    - staticassertion 5y ago
      Yeah, I'm totally with you on that. I was just trying to get across that distilling to principles is easy and effective, whereas the paper is going to describe a specific implementation. If someone is interested in ZTN they would be best presented with both imo
      - tptacek 5y ago
        People land in weird places when they try to carry around just the principles. Like, "network controls are evil and should never be used". That's not at all what BeyondCorp says.
        staticassertion 5y ago
        People gonna people
WalterBright 5y ago
The idea is not to guarantee the board is not compromised, because, as you stated, such is impossible. The idea is assume the board is compromised. Now what? Answering that question is the key to robustness.
- distortedsignal 5y ago
  Is there a "now what?" if the board is compromised? I have... difficulty... understanding what you could possibly do to prevent full distributed system compromise if one hardware node is compromised. You seem very certain that something can be done, and I trust you, so I can trust that something can be done, but perhaps the solutions in this space elude me. I'll keep watching this space, but my pessimism may leak through from time to time.
  - WalterBright 5y ago
    I can't answer it in detail because I don't know how those systems work. But if I did, I bet I could find a way. After all, it's clear to me how Fukushima and Deep Water Horizon both had an easily fixed single point of failure that doomed them, and I ain't no expert on nuclear reactors nor drilling rigs. When I got a job at Boeing, I thought it was impossible to design an airplane with full redundancy. They showed me how it was done.
    - WalterBright 5y ago
      BTW, in airplane avionics, faulty boards are detected by having more than one board, and comparing the results. Ideally the different boards are different designs, different CPUs, different code, etc.
  - toast0 5y ago
    In a 'well designed system', any given node has limited access to the other nodes and user data. If a node is compromised, that shouldn't turn into full access to everything. Specifics would vary depending on your application, but while most user facing servers might need to be able to validate a login token, few would need to be able to issue a login token or access billing details. If you compromise the node that has billing details or access to them, then you'll have them, but if you compromise a different node, you won't. That's better than compromise any host and get access to the 'private' network where there's no auth or encryption, which is kind of traditional.

tptacek 5y ago

A pitfall of all these ZTN discussions is that they tend to propose a definition of "zero trust" as an axiom, and then use deduction to construct a whole system from those first principles. This is especially useful for security product vendors, who will pick the most congenial definition of "zero trust" in order to derive a mandate for their products. We don't so much have to get lost in abstractions here. There's a blueprint: all this ZTN stuff was inspired by Google's BeyondCorp paper (ZTN is the marketing-neutral name for BeyondCorp; the Kubernetes to BC's Borg). So: just go read the BeyondTrust paper; it's great: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-...

distortedsignal 5y ago
Thanks - my company is pushing a lot of ZTN stuff, and I wasn't totally sure where the principles are coming from. Having a root that I can anchor my debates in (which, as you can probably tell, is currently lacking) should be really helpful.
staticassertion 5y ago
The paper's definitely worth reading, although it's worth noting that: a) This is implementation heavy b) The implementation is tied to a specific company migrating to this approach incrementally I would say it's a great case study for moving to a ZTN, but if I were to explain ZTN I'd probably just propose a definition. I'm technically a vendor but the definition serves me in no way. 1. Requests are mutually authenticated and always encrypted (ex: mtls) 2. Requests are authorized; policy oriented, granular, and contextual authorization 3. Requests are monitored and audited The paper lists a bunch of ways to accomplish those goals. SSO, device inventories, an authorizing proxy, a monitor, etc. Of course, you're right. Vendors are horribly self serving and have already significantly degraded the term and confused people.
- tptacek 5y ago
  This is the implementation that defined the movement. You can distill it down to principles, but if you're saying things that contradict it, you're talking about something other than ZTN.
  - staticassertion 5y ago
    Yeah, I'm totally with you on that. I was just trying to get across that distilling to principles is easy and effective, whereas the paper is going to describe a specific implementation. If someone is interested in ZTN they would be best presented with both imo
    - tptacek 5y ago
      People land in weird places when they try to carry around just the principles. Like, "network controls are evil and should never be used". That's not at all what BeyondCorp says.
      - staticassertion 5y ago
        People gonna people

WalterBright 5y ago

The idea is not to guarantee the board is not compromised, because, as you stated, such is impossible. The idea is assume the board is compromised. Now what? Answering that question is the key to robustness.

distortedsignal 5y ago
Is there a "now what?" if the board is compromised? I have... difficulty... understanding what you could possibly do to prevent full distributed system compromise if one hardware node is compromised. You seem very certain that something can be done, and I trust you, so I can trust that something can be done, but perhaps the solutions in this space elude me. I'll keep watching this space, but my pessimism may leak through from time to time.
- WalterBright 5y ago
  I can't answer it in detail because I don't know how those systems work. But if I did, I bet I could find a way. After all, it's clear to me how Fukushima and Deep Water Horizon both had an easily fixed single point of failure that doomed them, and I ain't no expert on nuclear reactors nor drilling rigs. When I got a job at Boeing, I thought it was impossible to design an airplane with full redundancy. They showed me how it was done.
  - WalterBright 5y ago
    BTW, in airplane avionics, faulty boards are detected by having more than one board, and comparing the results. Ideally the different boards are different designs, different CPUs, different code, etc.
- toast0 5y ago
  In a 'well designed system', any given node has limited access to the other nodes and user data. If a node is compromised, that shouldn't turn into full access to everything. Specifics would vary depending on your application, but while most user facing servers might need to be able to validate a login token, few would need to be able to issue a login token or access billing details. If you compromise the node that has billing details or access to them, then you'll have them, but if you compromise a different node, you won't. That's better than compromise any host and get access to the 'private' network where there's no auth or encryption, which is kind of traditional.