The title talks about Zero Trust[1] and so I expected it to lack any kind of discussion about the threat model, the expectation of what an attacker starts with, what they’re trying to achieve, and how the security policy protects against this kind of attacker. I was not disappointed.
[1] TRUST is an acronym for Thinking Rationally or Understanding Security and Threats
Thanks for taking a look at the article. Sorry it didn’t provide a threat model for you to read. I think it’s hard to find the right amount of detail to pack into any single post. Too much detail scares people away, too little and some people leave feeling empty. I’m glad you weren’t disappointed about the lack of rigorous discussion.
You might find the 5 part, detailed series about bootstrapping trust published in the previous years to be more what you’re looking for. It’s a lot more to read, but maybe that’s what you’re after?
Thanks. I am deeply skeptical of anything that uses the term Zero Trust because 90% of the times I’ve seen it used have been by bullshit artists and snake-oil salesmen. Everything that I’ve seen that claims to be Zero Trust involves increasing the size of the TCB or the attack surface or both. I actually quite liked the original Google paper that introduced the term but the key messages in it seem to have been lost by everyone who picked up the buzzword.
From your article:
Zero Trust is a security model that requires strict identity authentication and access verification on every connection at all times
And that’s the problem. A good security policy doesn’t do this, it starts from a posture of ‘assume compromise’ and limits what an attacker can do if they compromise one component. A Zero Trust system builds a web out of single points of failure: you’re actually doing the opposite of what the original paper proposed by trusting things based on some authentication that you’ve done and giving an attacker who compromises one an easy springboard to elevate privilege.
Never Trust, Verify - the virtue of a connection should not grant access
Authenticate Before Connect - authentication should happen before resources are connected to
These are not new things, they have been security best practices for at least 20 years.
Least Privileged Access - access should only grant connectivity to the minimum number of resources
Finally, this point arrives (also security best practice for 20+ years), but the fact it’s listed last is telling because this is the one that actually gives you some security beyond ‘anyone with a network connection can do anything’ and is the one that most Zero Trust solutions fail to do: once you’re authenticated, you can do anything, so as long as no one finds a bug in the hundred million or so lines of C code that you have in the TCB for your endpoints, everything is fine.
And then you miss the second most important principle for designing secure systems: the principle of intentionality. Any operation that requires exercising privilege should require asserting that privilege intentionally. The vast majority of compromises that I’ve seen that were not the result of memory safety bugs were as a result of violating this: a principal in the system holds a set of rights and is tricked into exercising one when they think they are doing something that should not require it.
Again, most Zero Trust systems make this worse by saying ‘hurrah, I’ve identified that the enormous pile of insecure code that is running with far more privileges than it needs to has made some attestation about your device, go ahead and do whatever you want!’.
I now regard Zero Trust as a useful filter term: if someone uses it, I assume that they know absolutely nothing about security. I get very few false positives with this.
But back on topic:
If you are telling people ‘you should deploy this security thing’ you need to be able to say what the threat model is. That is the absolute minimum for any security system. Ideally, you’d also have a security analysis that tells you how well you are able to defend against that threat model. So, for this deployment, what is your threat model?
The title talks about Zero Trust[1] and so I expected it to lack any kind of discussion about the threat model, the expectation of what an attacker starts with, what they’re trying to achieve, and how the security policy protects against this kind of attacker. I was not disappointed.
[1] TRUST is an acronym for Thinking Rationally or Understanding Security and Threats
Thanks for taking a look at the article. Sorry it didn’t provide a threat model for you to read. I think it’s hard to find the right amount of detail to pack into any single post. Too much detail scares people away, too little and some people leave feeling empty. I’m glad you weren’t disappointed about the lack of rigorous discussion.
You might find the 5 part, detailed series about bootstrapping trust published in the previous years to be more what you’re looking for. It’s a lot more to read, but maybe that’s what you’re after?
You can find part 1 here if you’re interested and read all five: https://blog.openziti.io/bootstrapping-trust-part-1-encryption-everywhere
Thanks. I am deeply skeptical of anything that uses the term Zero Trust because 90% of the times I’ve seen it used have been by bullshit artists and snake-oil salesmen. Everything that I’ve seen that claims to be Zero Trust involves increasing the size of the TCB or the attack surface or both. I actually quite liked the original Google paper that introduced the term but the key messages in it seem to have been lost by everyone who picked up the buzzword.
From your article:
And that’s the problem. A good security policy doesn’t do this, it starts from a posture of ‘assume compromise’ and limits what an attacker can do if they compromise one component. A Zero Trust system builds a web out of single points of failure: you’re actually doing the opposite of what the original paper proposed by trusting things based on some authentication that you’ve done and giving an attacker who compromises one an easy springboard to elevate privilege.
These are not new things, they have been security best practices for at least 20 years.
Finally, this point arrives (also security best practice for 20+ years), but the fact it’s listed last is telling because this is the one that actually gives you some security beyond ‘anyone with a network connection can do anything’ and is the one that most Zero Trust solutions fail to do: once you’re authenticated, you can do anything, so as long as no one finds a bug in the hundred million or so lines of C code that you have in the TCB for your endpoints, everything is fine.
And then you miss the second most important principle for designing secure systems: the principle of intentionality. Any operation that requires exercising privilege should require asserting that privilege intentionally. The vast majority of compromises that I’ve seen that were not the result of memory safety bugs were as a result of violating this: a principal in the system holds a set of rights and is tricked into exercising one when they think they are doing something that should not require it.
Again, most Zero Trust systems make this worse by saying ‘hurrah, I’ve identified that the enormous pile of insecure code that is running with far more privileges than it needs to has made some attestation about your device, go ahead and do whatever you want!’.
I now regard Zero Trust as a useful filter term: if someone uses it, I assume that they know absolutely nothing about security. I get very few false positives with this.
But back on topic:
If you are telling people ‘you should deploy this security thing’ you need to be able to say what the threat model is. That is the absolute minimum for any security system. Ideally, you’d also have a security analysis that tells you how well you are able to defend against that threat model. So, for this deployment, what is your threat model?
Well said.
Not my article, but a colleague’s. I thought it was cool and full disclosure, we’re devs on the project.