16 ms·

Implementing a Zero Trust Architecture

230 points by justinludwig 4y ago

tptacek 4y ago
Shameless plug: we had Eric Mill on to talk about what OMB was going for with this. https://securitycryptographywhatever.buzzsprout.com/1822302/10767220-omb-zero-trust-memo-with-eric-mill https://securitycryptographywhatever.buzzsprout.com/1822302/...
- er4hn 4y ago
  This was a really great episode. I'm glad you took the time to get someone from the gov to talk about this on the podcast.
- Phiwise_ 4y ago
  Thanks for getting such a great interview guest!
  - tptacek 4y ago
    Landing Eric was 100% Deirde and David and 0% me. :)
gz5 4y ago
I have previously read most of these docs, and NIST has done some excellent work in what can be tough territory, even if 'zero trust' is now* a misleading term (the question is more like who/what do you trust under which circumstances and how do you implement that in a simple, scalable, extensible way...so I prefer something closer to 'authorize everything'). * The term was more applicable when originally coined - the context back then was don't trust an endpoint just because it is on your network.
- alexott 4y ago
  I met customers who put anything under that umbrella. And they want to use PaaS/SaaS products - like, you need to encrypt table names, or some unrelated data… Some companies just use that to protect their …
- eikenberry 4y ago
  I'm not sure I see the difference between zero trust networking and authorize everything. Seems like they are saying pretty much the same thing, differing in positive vs negative assertions.
  - gz5 4y ago
    If you are to provide access to an app or network, you need to trust (something) under some circumstances.
    - nightpool 4y ago
      > provide access to a network That's your first mistake. You should be providing access to software, not networks. The idea of a "trusted" network that applications or users can communicate on is the fundamental idea that zero-trust architecture aims to get rid of.
      - gz5 4y ago
        absolutely. can even completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions. * requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
      - cassianoleal 4y ago
        > You should be providing access to software, not networks. You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access. One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.
        judge2020 4y ago
        I think they meant that software is 'what the identity should gain access to', and you 'should not grant that identity access to networks'; it is worded a bit confusingly.
- philjohn 4y ago
  Although "authorize everything" can also be confusing - so, what, you just let anything query your system?
  - gz5 4y ago
    Agree, not a perfect term. You certainly make a good point and in fact the strongest zero trust approaches don't even let you on the network (even at layer 3) until after you are authorized.
    - happyopossum 4y ago
      Err, no - the strongest zero trust approaches never let you “on the network” - authorized or not. They are designed to connect you to an application, you should never see the network.
      - gz5 4y ago
        yeah, agree, 'on the network' is a bad phrase. long form: completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions (strong auth - not IP-address based auth). * requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
  - jeffbee 4y ago
    That seems appropriate in many contexts. The originator of the "beyond corp" meme has all their critical systems just hanging out there on port 443. You could just download all their source code, if you were authorized. The point is if you want the extra layer of security, the belt of physical or VPN access to go along with the "authorize everything" suspenders, you can just put it on top. But you don't assume that the network security actually works, you don't allow its existence to degrade the rest of your security story.
    - 4y ago
- doliveira 4y ago
  > the context back then was don't trust an endpoint just because it is on your network. The majority of the world is still in this context...
- pyuser583 4y ago
  What was its original coining? PC Booting?
- TeeMassive 4y ago
  > the context back then was don't trust an endpoint just because it is on your network. I remember working for a major tech company that had contracts for big critical industries (think oil, aviation, trains, etc.). All the R&D department pretty much rested on one Brent, because they made no efforts to upgrade their systems for 15 years+. tl;dr: I asked him: hey maybe we shouldn't trust devs computers just because they are "on the network", he just shrugged and said: "if we're compromised we'll have other things to worry about anyway". While zero trust as a goal is impossible, it still is the guiding principle that everyone should follow; especially if you have a Brent.
historynops 4y ago
The problem with "implementing a zero trust architecture" is that it's framing an ongoing process as an end state. You'll see the same disappointment that people saw when they decided "we're going to do DevOps". I thought that "Shift Left" was going to be the new DevOps buzzword for security groups, but I liked that because it implied an ongoing process, not a "we're going to become perfect and fix this once and for all". Google's BeyondCorp - the precursor to zero trust architecture - said you need to secure three things: users, devices, and application policies. Your security teams are probably already aware of many of good tools available to secure the users and apps, but the device security piece has very weak tooling even today. You may have heard of MDM software. No one wants to use it.
- deleted 4y ago
  [deleted]
- 0xbadcafebee 4y ago
  I just like that there will eventually be a big shiny C-level-friendly website that I can show my bosses, that they can show their bosses, so we might actually get funding to start working on Zero Trust. Nobody cared about BeyondCorp but they might care about NIST.
  - aaaaaaaaata 4y ago
    Is your PowerPoint™ broken, son?
- tptacek 4y ago
  People get into all sorts of trouble trying to reason axiomatically about "Zero Trust". It's definitely a problem with the term, and a strength of "BeyondCorp"; BeyondCorp can only mean the one set of things, because it's meaningless outside of Google's branding. But everyone feels like they can work out what "Zero Trust" should mean. So the first thing you have to do is, you have to rewire your brain to read "Zero Trust" as the marketing term of art that it is. The OMB ZT stuff is a reaction to USG breaches, and I think in particular the OMB hack. There's a "before" state and a desired "after" state. In the "before" state, you're one of the 2.1 million federal employees, and you start your day by inserting a PIV card into a reader, and with that, you're given access to an intranet that in turn gives you access to a bananas number of different things that nobody can keep track of or secure. In the "after" state, each service is responsible for establishing its own tight trust boundaries, and instead of providing a network dial tone that people mistakenly assume is a proxy for trust, the USG infrastructure provides you with end-to-end authentication for requests regardless of the network you're using. As far as OMB and NIST talking about ZT goes, the major problem you're trying to solve is that there are a zillion federal agencies --- way more than you think there are, like you know that there's a Department of the Interior, but also under Interior there's a Susquehannah River Basin Commission with 100 employees, and there are other agencies that have like 4-5 employees. And what you're trying to do is provide a security strategy and a toolbox and a set of best/worst practices that you can apply across all of these organizations, to replace what I understand to be the status quo ante strategy of "stick it on the VPN, pretend we've kept it off the Internet, and call it a day". The other important subtext to all of this is that there's a huge give and take between USG and industry, where USG tends to take its lead from what's happening in industry, but it also participates in the industry in that it is one of the largest customers for technology products, so the industry is intensely interested in what it does. So when USG decides to demand "Zero Trust" for its agencies, and sets out a standard set of requirements for ZT, industry goes nuts making sure their products are responsive to that standard. The good thing here is that the OMB memo is smart, and ZT as construed by the current administration's IT people is a pretty good baseline security strategy, so in this one instance the USG is being a force for good, in that it's aligning a lot of industry work around a strategy that people should be seriously considering adopting anyways. And I think there's pretty broad recognition/agreement about that in the "security community" (hate that term), so when USG (here: NIST) does some big new thing about ZT, it gets a lot of positive attention. ... is how I understand all of this.
tjstebbing 4y ago
- pvg 4y ago
  Avoid unrelated controversies, generic tangents, and internet tropes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - denton-scratch 4y ago
    Well, parent has actually expressed my reaction. The article seems to be a puff site, with no details about what they mean by "Zero Trust". I didn't follow any of the links (I don't think I should have to). If NIST has something to tell me, then they need to tell it me straight, not cloaked in partner sites and snazzy graphics.
    - pvg 4y ago
      You can write a comment about things you don't like in the thing posted but not a reflexive trope response that can appear unchanged in anything with 'NIST' in it, which is what the guideline is about.
      - denton-scratch 4y ago
        Agreed, GP violated the guideline.
    - tptacek 4y ago
      You're a Google search away from the entire industry explaining to you what they think "Zero Trust" is --- the term predates the OMB memo. Your best first read is the Google BeyondCorp paper.
    - tomrod 4y ago
      https://csrc.nist.gov/publications/detail/sp/800-207/final https://csrc.nist.gov/publications/detail/sp/800-207/final https://csrc.nist.gov/publications/detail/white-paper/2022/05/06/planning-for-a-zero-trust-architecture/final https://csrc.nist.gov/publications/detail/white-paper/2022/0... https://csrc.nist.gov/publications/detail/sp/1800-35/draft https://csrc.nist.gov/publications/detail/sp/1800-35/draft
deleted 4y ago
[deleted]
thayne 4y ago
I'm a little surprised not to see cloudflare, tailscale, zerotier, or hashicorp on the list of collaborators.
motohagiography 4y ago
The list of partner vendors have a lot of smart people and influence, but there are key players who are absent from it, but are some of the most important players in IAA/IAM. To me the notable ones who have more customer traction than some of them on the list are companies like Apple, Hashicorp, Forgerock, Tanium, and any of the emerging self sovereign identity and blockchain identity vendors who all still have non-linear growth in front of them. I have worked on and partnered with some of the largest public sector digital identity schemes in the world, and almost none of the players who actually have traction in those organizations are represented. Microsoft has their B2B service, which is the inferior product you choose when you don't have expertise, and even though I think Okta is an excellent product and Duo (via Cisco) are fantastic, most of the parties represented aren't what developers, architects, and the people who actually build and use these techs would select. I realize these are IAA/IAM products, but ZTA has a bootstrapping problem without a foundation in identity. (Though I was glad to see Oracle wasn't on the list, even though they are the identity elephant in the room.) I like Zero Trust as a concept, but it's going to take more organic growth and integration with IAM and with the traction of companies like those missing vendors to make it viable. The players on the list right now are all enterprise vendors, but it's startups who are the ones growing and adopting standards - and using those missing organic-demand vendors whose customers actually want their tech instead of having it imposed. The growth companies hold the real influence on standards implementation because they are the adopters. Enterprise customers aren't going to change anytime soon, and having enterprise (slow linear to flat growth) vendors as your partner channel seems risky. I agree ZTA will be a thing, but without exposure to non-linear growth, they may just be inventing another SAML.
- tptacek 4y ago
  There is maybe no less promising blockchain application than identity. It solves none of the real problems, and introduces its own.
  - motohagiography 4y ago
    Arguably, identity is the only application for which blockchains are the most suitable for the reason that identity itself is the artifact of a consensus. I'll share the argument here in case you haven't read this particular driver for it yet, and it needs scrutiny. The reasoning goes that in govt, you have licenses and birth certificates, SINs and ID cards, and depending on the legal regime, there are limitations for the legal uses of each of those. Banks could theoretically offer ID because they have more information about you, but then they take on risk and liability in its usages. Second, each transaction that requires identity only needs a certain level of assurance, and what these orgs have agreed to is they will contribute their user identity attributes to a blockchain to support an identifying consensus without holding any risk or having any responsibility for the usage, while providing a high degree of institutional assurance that their contribution is verified and supported by KYC, pattern of life, anti-fraud etc. In this case, identity is an epiphenomenal artifact of the consensus. Where I might agree is that I don't think strong identity itself is valuable, it in fact destroys value, and the consensus just implements the impunity and social anti-pattern of a one-way committee decision - and I think it's an imposition that doesn't help anyone except make them more exposed to remote enforcement of fines and petty policies. e.g. Yay, now you can get parking tickets in foreign countries, and all the use cases are variations of that. However, if you want recourse and sanctions of individuals that are portable without integrating with central national identity schemes, a blockchain is the way to do that. That's the most succinct version I think there is. The irony may be that civil liberties may be the strongest argument against blockchains because they are the cryptological implementation of a committee or star chamber when their consensus represents a monopoly or "radical monopoly."
technion 4y ago
I've got multiple vendors that have been selling largely the same VPN appliances for a decade, that are suddenly rebranding as Zero Trust vendors. People have commented on the naming but I don't know if it's clear that it's not just a nitpick. It's breeding a situation where devices we moved away from years ago are becoming a topic people are suddenly asking us about for largely no reason.
trashtester 4y ago
Slightly off topic: In my ideal world, IT security should be available as a service, complete with insurance built in in case of a breach. A company that employs both IT Security experts and Actuaries would be in a perfect position to balance up-front investments in security against risk of payments in case of incidents, and would have this as their primary business purpose, instead of seeing security as a cost center with no revenue.
- alufers 4y ago
  Well you have insurances for ransomware, and it leads to the bad guys specifically targeting companies with such insurance, because they are more likely to pay the ransom.
  - headsoup 4y ago
    And you end up with companies having wide security gaps because the Sec and Actuary teams won't agree about anything to actually get on with implementation...
    - trashtester 4y ago
      Those insurance companies would then go out of business quickly, and be replaced by organizations that were able to handle this. This is a benefit of having actual security be core business for such a company. While for many companies, security is a small part of their business, and not critical for their long term performance, a dedicated insurance/security company would HAVE to be good at both to stay competitive.
  - trashtester 4y ago
    Exactly. By making the insurance company responsible for both the security and the payout, this would turn into a direct war between the insurance companies and the attackers. The incentives would now be on the insurance company to take the measures necessary to protect against the ransomware in the first place. Now, if society feels that too many ransoms are being paid (due to externalities, such as loss of confidential information, service quality, etc) , this might also make it easier to implement additional countermeasures. In particular, I think it would make sense to demand a fine or tax any time a company pays such a ransom. Lets say, if the government would demand a tax equal to the size of each ransom paid, the insurance/security company would either have an increased incentive to protect against ransomware, or alternatively, the attackers would understand that the break-even size of the ransom, where it would be preferable for the target to not pay, would be not much higher than half as high.
zktrust 4y ago
a hard or impossible problem? a while ago when prepping for my APs, I came across the paper "Reflections on Trusting 'Trustlessness' in the Era of Crypto/Blockchains" (Georgiadis,E.) available here: https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf and found some parts very illuminating. It makes reference to a paper by Kuhn called Backdoor Engineering and advances that point to a concept the author calls conceptual corruption. Under this light, zero trust architectures are impossible. My fellow classmate a CS nerd made an additional point about the paper reflections on trust. it was beyond me.

230 points by justinludwig 4y ago

Shameless plug: we had Eric Mill on to talk about what OMB was going for with this. https://securitycryptographywhatever.buzzsprout.com/1822302/10767220-omb-zero-trust-memo-with-eric-mill https://securitycryptographywhatever.buzzsprout.com/1822302/...

er4hn 4y ago
This was a really great episode. I'm glad you took the time to get someone from the gov to talk about this on the podcast.
Phiwise_ 4y ago
Thanks for getting such a great interview guest!
- tptacek 4y ago
  Landing Eric was 100% Deirde and David and 0% me. :)

gz5 4y ago

I have previously read most of these docs, and NIST has done some excellent work in what can be tough territory, even if 'zero trust' is now* a misleading term (the question is more like who/what do you trust under which circumstances and how do you implement that in a simple, scalable, extensible way...so I prefer something closer to 'authorize everything'). * The term was more applicable when originally coined - the context back then was don't trust an endpoint just because it is on your network.

alexott 4y ago
I met customers who put anything under that umbrella. And they want to use PaaS/SaaS products - like, you need to encrypt table names, or some unrelated data… Some companies just use that to protect their …
eikenberry 4y ago
I'm not sure I see the difference between zero trust networking and authorize everything. Seems like they are saying pretty much the same thing, differing in positive vs negative assertions.
- gz5 4y ago
  If you are to provide access to an app or network, you need to trust (something) under some circumstances.
  - nightpool 4y ago
    > provide access to a network That's your first mistake. You should be providing access to software, not networks. The idea of a "trusted" network that applications or users can communicate on is the fundamental idea that zero-trust architecture aims to get rid of.
    - gz5 4y ago
      absolutely. can even completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions. * requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
    - cassianoleal 4y ago
      > You should be providing access to software, not networks. You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access. One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.
      - judge2020 4y ago
        I think they meant that software is 'what the identity should gain access to', and you 'should not grant that identity access to networks'; it is worded a bit confusingly.
philjohn 4y ago
Although "authorize everything" can also be confusing - so, what, you just let anything query your system?
- gz5 4y ago
  Agree, not a perfect term. You certainly make a good point and in fact the strongest zero trust approaches don't even let you on the network (even at layer 3) until after you are authorized.
  - happyopossum 4y ago
    Err, no - the strongest zero trust approaches never let you “on the network” - authorized or not. They are designed to connect you to an application, you should never see the network.
    - gz5 4y ago
      yeah, agree, 'on the network' is a bad phrase. long form: completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions (strong auth - not IP-address based auth). * requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side
- jeffbee 4y ago
  That seems appropriate in many contexts. The originator of the "beyond corp" meme has all their critical systems just hanging out there on port 443. You could just download all their source code, if you were authorized. The point is if you want the extra layer of security, the belt of physical or VPN access to go along with the "authorize everything" suspenders, you can just put it on top. But you don't assume that the network security actually works, you don't allow its existence to degrade the rest of your security story.
  - 4y ago
doliveira 4y ago
> the context back then was don't trust an endpoint just because it is on your network. The majority of the world is still in this context...
pyuser583 4y ago
What was its original coining? PC Booting?
TeeMassive 4y ago
> the context back then was don't trust an endpoint just because it is on your network. I remember working for a major tech company that had contracts for big critical industries (think oil, aviation, trains, etc.). All the R&D department pretty much rested on one Brent, because they made no efforts to upgrade their systems for 15 years+. tl;dr: I asked him: hey maybe we shouldn't trust devs computers just because they are "on the network", he just shrugged and said: "if we're compromised we'll have other things to worry about anyway". While zero trust as a goal is impossible, it still is the guiding principle that everyone should follow; especially if you have a Brent.

historynops 4y ago

The problem with "implementing a zero trust architecture" is that it's framing an ongoing process as an end state. You'll see the same disappointment that people saw when they decided "we're going to do DevOps". I thought that "Shift Left" was going to be the new DevOps buzzword for security groups, but I liked that because it implied an ongoing process, not a "we're going to become perfect and fix this once and for all". Google's BeyondCorp - the precursor to zero trust architecture - said you need to secure three things: users, devices, and application policies. Your security teams are probably already aware of many of good tools available to secure the users and apps, but the device security piece has very weak tooling even today. You may have heard of MDM software. No one wants to use it.

deleted 4y ago
[deleted]
0xbadcafebee 4y ago
I just like that there will eventually be a big shiny C-level-friendly website that I can show my bosses, that they can show their bosses, so we might actually get funding to start working on Zero Trust. Nobody cared about BeyondCorp but they might care about NIST.
- aaaaaaaaata 4y ago
  Is your PowerPoint™ broken, son?
tptacek 4y ago
People get into all sorts of trouble trying to reason axiomatically about "Zero Trust". It's definitely a problem with the term, and a strength of "BeyondCorp"; BeyondCorp can only mean the one set of things, because it's meaningless outside of Google's branding. But everyone feels like they can work out what "Zero Trust" should mean. So the first thing you have to do is, you have to rewire your brain to read "Zero Trust" as the marketing term of art that it is. The OMB ZT stuff is a reaction to USG breaches, and I think in particular the OMB hack. There's a "before" state and a desired "after" state. In the "before" state, you're one of the 2.1 million federal employees, and you start your day by inserting a PIV card into a reader, and with that, you're given access to an intranet that in turn gives you access to a bananas number of different things that nobody can keep track of or secure. In the "after" state, each service is responsible for establishing its own tight trust boundaries, and instead of providing a network dial tone that people mistakenly assume is a proxy for trust, the USG infrastructure provides you with end-to-end authentication for requests regardless of the network you're using. As far as OMB and NIST talking about ZT goes, the major problem you're trying to solve is that there are a zillion federal agencies --- way more than you think there are, like you know that there's a Department of the Interior, but also under Interior there's a Susquehannah River Basin Commission with 100 employees, and there are other agencies that have like 4-5 employees. And what you're trying to do is provide a security strategy and a toolbox and a set of best/worst practices that you can apply across all of these organizations, to replace what I understand to be the status quo ante strategy of "stick it on the VPN, pretend we've kept it off the Internet, and call it a day". The other important subtext to all of this is that there's a huge give and take between USG and industry, where USG tends to take its lead from what's happening in industry, but it also participates in the industry in that it is one of the largest customers for technology products, so the industry is intensely interested in what it does. So when USG decides to demand "Zero Trust" for its agencies, and sets out a standard set of requirements for ZT, industry goes nuts making sure their products are responsive to that standard. The good thing here is that the OMB memo is smart, and ZT as construed by the current administration's IT people is a pretty good baseline security strategy, so in this one instance the USG is being a force for good, in that it's aligning a lot of industry work around a strategy that people should be seriously considering adopting anyways. And I think there's pretty broad recognition/agreement about that in the "security community" (hate that term), so when USG (here: NIST) does some big new thing about ZT, it gets a lot of positive attention. ... is how I understand all of this.

tjstebbing 4y ago

pvg 4y ago
Avoid unrelated controversies, generic tangents, and internet tropes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- denton-scratch 4y ago
  Well, parent has actually expressed my reaction. The article seems to be a puff site, with no details about what they mean by "Zero Trust". I didn't follow any of the links (I don't think I should have to). If NIST has something to tell me, then they need to tell it me straight, not cloaked in partner sites and snazzy graphics.
  - pvg 4y ago
    You can write a comment about things you don't like in the thing posted but not a reflexive trope response that can appear unchanged in anything with 'NIST' in it, which is what the guideline is about.
    - denton-scratch 4y ago
      Agreed, GP violated the guideline.
  - tptacek 4y ago
    You're a Google search away from the entire industry explaining to you what they think "Zero Trust" is --- the term predates the OMB memo. Your best first read is the Google BeyondCorp paper.
  - tomrod 4y ago
    https://csrc.nist.gov/publications/detail/sp/800-207/final https://csrc.nist.gov/publications/detail/sp/800-207/final https://csrc.nist.gov/publications/detail/white-paper/2022/05/06/planning-for-a-zero-trust-architecture/final https://csrc.nist.gov/publications/detail/white-paper/2022/0... https://csrc.nist.gov/publications/detail/sp/1800-35/draft https://csrc.nist.gov/publications/detail/sp/1800-35/draft

deleted 4y ago

[deleted]

thayne 4y ago

I'm a little surprised not to see cloudflare, tailscale, zerotier, or hashicorp on the list of collaborators.

motohagiography 4y ago

The list of partner vendors have a lot of smart people and influence, but there are key players who are absent from it, but are some of the most important players in IAA/IAM. To me the notable ones who have more customer traction than some of them on the list are companies like Apple, Hashicorp, Forgerock, Tanium, and any of the emerging self sovereign identity and blockchain identity vendors who all still have non-linear growth in front of them. I have worked on and partnered with some of the largest public sector digital identity schemes in the world, and almost none of the players who actually have traction in those organizations are represented. Microsoft has their B2B service, which is the inferior product you choose when you don't have expertise, and even though I think Okta is an excellent product and Duo (via Cisco) are fantastic, most of the parties represented aren't what developers, architects, and the people who actually build and use these techs would select. I realize these are IAA/IAM products, but ZTA has a bootstrapping problem without a foundation in identity. (Though I was glad to see Oracle wasn't on the list, even though they are the identity elephant in the room.) I like Zero Trust as a concept, but it's going to take more organic growth and integration with IAM and with the traction of companies like those missing vendors to make it viable. The players on the list right now are all enterprise vendors, but it's startups who are the ones growing and adopting standards - and using those missing organic-demand vendors whose customers actually want their tech instead of having it imposed. The growth companies hold the real influence on standards implementation because they are the adopters. Enterprise customers aren't going to change anytime soon, and having enterprise (slow linear to flat growth) vendors as your partner channel seems risky. I agree ZTA will be a thing, but without exposure to non-linear growth, they may just be inventing another SAML.

tptacek 4y ago
There is maybe no less promising blockchain application than identity. It solves none of the real problems, and introduces its own.
- motohagiography 4y ago
  Arguably, identity is the only application for which blockchains are the most suitable for the reason that identity itself is the artifact of a consensus. I'll share the argument here in case you haven't read this particular driver for it yet, and it needs scrutiny. The reasoning goes that in govt, you have licenses and birth certificates, SINs and ID cards, and depending on the legal regime, there are limitations for the legal uses of each of those. Banks could theoretically offer ID because they have more information about you, but then they take on risk and liability in its usages. Second, each transaction that requires identity only needs a certain level of assurance, and what these orgs have agreed to is they will contribute their user identity attributes to a blockchain to support an identifying consensus without holding any risk or having any responsibility for the usage, while providing a high degree of institutional assurance that their contribution is verified and supported by KYC, pattern of life, anti-fraud etc. In this case, identity is an epiphenomenal artifact of the consensus. Where I might agree is that I don't think strong identity itself is valuable, it in fact destroys value, and the consensus just implements the impunity and social anti-pattern of a one-way committee decision - and I think it's an imposition that doesn't help anyone except make them more exposed to remote enforcement of fines and petty policies. e.g. Yay, now you can get parking tickets in foreign countries, and all the use cases are variations of that. However, if you want recourse and sanctions of individuals that are portable without integrating with central national identity schemes, a blockchain is the way to do that. That's the most succinct version I think there is. The irony may be that civil liberties may be the strongest argument against blockchains because they are the cryptological implementation of a committee or star chamber when their consensus represents a monopoly or "radical monopoly."

technion 4y ago

I've got multiple vendors that have been selling largely the same VPN appliances for a decade, that are suddenly rebranding as Zero Trust vendors. People have commented on the naming but I don't know if it's clear that it's not just a nitpick. It's breeding a situation where devices we moved away from years ago are becoming a topic people are suddenly asking us about for largely no reason.

trashtester 4y ago

Slightly off topic: In my ideal world, IT security should be available as a service, complete with insurance built in in case of a breach. A company that employs both IT Security experts and Actuaries would be in a perfect position to balance up-front investments in security against risk of payments in case of incidents, and would have this as their primary business purpose, instead of seeing security as a cost center with no revenue.

alufers 4y ago
Well you have insurances for ransomware, and it leads to the bad guys specifically targeting companies with such insurance, because they are more likely to pay the ransom.
- headsoup 4y ago
  And you end up with companies having wide security gaps because the Sec and Actuary teams won't agree about anything to actually get on with implementation...
  - trashtester 4y ago
    Those insurance companies would then go out of business quickly, and be replaced by organizations that were able to handle this. This is a benefit of having actual security be core business for such a company. While for many companies, security is a small part of their business, and not critical for their long term performance, a dedicated insurance/security company would HAVE to be good at both to stay competitive.
- trashtester 4y ago
  Exactly. By making the insurance company responsible for both the security and the payout, this would turn into a direct war between the insurance companies and the attackers. The incentives would now be on the insurance company to take the measures necessary to protect against the ransomware in the first place. Now, if society feels that too many ransoms are being paid (due to externalities, such as loss of confidential information, service quality, etc) , this might also make it easier to implement additional countermeasures. In particular, I think it would make sense to demand a fine or tax any time a company pays such a ransom. Lets say, if the government would demand a tax equal to the size of each ransom paid, the insurance/security company would either have an increased incentive to protect against ransomware, or alternatively, the attackers would understand that the break-even size of the ransom, where it would be preferable for the target to not pay, would be not much higher than half as high.

zktrust 4y ago

a hard or impossible problem? a while ago when prepping for my APs, I came across the paper "Reflections on Trusting 'Trustlessness' in the Era of Crypto/Blockchains" (Georgiadis,E.) available here: https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf and found some parts very illuminating. It makes reference to a paper by Kuhn called Backdoor Engineering and advances that point to a concept the author calls conceptual corruption. Under this light, zero trust architectures are impossible. My fellow classmate a CS nerd made an additional point about the paper reflections on trust. it was beyond me.