Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole analysts. My guest today is John Tolbert. He's lead analyst and works with KuppingerCole analysts from Seattle. Hi, John. Great to have you today. You suggested a topic and I've seen that in a blog post that you already written today. We want to talk about NIST SP 800-207, or to be more precise about the NIST special publication, about zero trust architecture. And as I've mentioned, you've written a blog post about that. You have provided already your impressions of this document. How are your impressions of this document?
You know, I think it's a, I think it's a really good start at zero trust architecture. You know, I, and I think the IOT and it security community in general definitely welcomes this because we've been hearing about as zero trust for years, you know, the idea has been around for awhile. It certainly has become kind of a big buzz word in cybersecurity industry. You can back, you know, when we were at conferences, you'd see lots of vendors talking about zero trust and how their products fit into the zero trust networking model. But you know what I like about one of the things that I like about what NIST has done is to begin to try to put it all together. And it's more than just a zero trust networking. It's, it's gotta be an architecture. So this document that they just published has a really good introduction to zero trust if, if you need that. But then it also has what I think is some pretty practical considerations about how to deploy it. And, and I also, especially like the sections on possible threats to that architecture and they call out the need for standardization about parts of the architecture as well. So I think those are, you know, really good points. It's a document that I think everybody in the cyber security world should take a look at and, and begin to think about.
I, I fully agree because as you said, we have been talking about zero trust for a few years. I did presentations. I looked it up three years ago about that topic. And nevertheless, you've mentioned standardization as it is not a, a product, something that you just can, this is really a kind of concept that you need to implement. And so what they are doing in the document is really a combine, some core security principles together to get a bigger picture on zero trust architecture. And that includes the least privilege principle and the principle of defense in depth, of course, zero trust is something every vendor talks about and it's really a marketing term. And by that, it also weakens a bit. And I think there are towns to have a document by this that describes the fundamentals of this concept. And these fundamentals include the foundation for cybersecurity. And for that is close to my heart, of course, identity management architectures. So if you combine these two aspects, relying on strong identities and creating a new way of cybersecurity architecture, I think that is a great thing. So I fully agree with what you said.
Yeah, yeah. You know, I think one of the best things about zero trust architecture is that it does provide us a way with thinking, you know, how to conceptualize and how to actualize those two security principles, least privilege and defense and depth. It brings them together in a way that I think is much more palatable for security practitioners to think about it and then begin to work on it. And, and yeah, you know, the, the NIST publication addresses the fact that zero trust architecture is more than just zero trust networking. It has to bring in identity and access management. I am really the core of a zero trust architecture is authenticating and authorizing every session in your environment that involves users, devices, networks, applications, and even the data. So you have to protect things at the network layer, but you also have to bring in the concepts of identity so that you know, who is doing this and the, who is bigger than just even the user who is also the device that a request originates from. And this is where we can get into topics like access controls, attribute based access controls, policy based access controls and fine-grained authorization. So yeah, this is, this is a perfect way to combine I am with cybersecurity and networks,
Right? So I'm a bit hesitant to welcome the terms zero trust, even for the NIST document, because as you just described, zero trust does not mean that you do not trust somebody. You do trust somebody, you have to trust strong identities as the foundation, just as you described. I really do not like the term zero trust. Although I love the concept behind that so that you can communicate safely and securely even in a potentially hostile environment. So zero trust is by this much more than just a network modernization or another type of VPN. You've mentioned that I've mentioned that already as well, network vendors have been promoting their solutions already for quite some time and branded it with the zero trust term. And of course, with the only thing that you can trust are the identities of all the individual types of identities that you mentioned. Some IAM vendors are already starting to move into that market and to promote this with that terms zero trust.
Yeah, yeah, definitely a good place for IAM and cyber security to meet, you know, going back to what you were just saying about not liking the term zero trust. I have to agree with that. You know, I find that it's kind of a misnomer because it has presupposes that there are no ways to trust anyone, but really what is implicitly trusted in any of these processes is the processes themselves. And they're probably in many cases founded on things like PKI. So there are definitely ways to represent these very, very fundamental level of trust upon which you can build other trust relationships that then you go forward and authenticate, authorize verify in a continuous manner. So yeah, I'm not, can't really say that I like to terms or a trust, but it certainly does get everyone's attention and it lets people focus on the least privileged defense and depth part.
Right? So at the core, as you've mentioned, it's really connecting two disciplines that are usually looked at individually. This is cybersecurity. And I am, although we at KuppingerCole consider, I am clearly to be a part of cybersecurity as it is an infrastructure here really can show its strengths. But nevertheless, you've mentioned that the chapter about the deployment of zero trust architectures was especially interesting. Well, what can you say about that? And what does mishap to say about that?
Well, you know, there's a place where I agree with the content from NIST entirely, you know, as part of zero trust architecture, they say, it's not something that you can solve with a single product or a service, or even an entire platform. It's not something you can buy a shrink wrapped off the shelf or buy as a service today. I mean, you get bits and pieces of it. But I think the reason for calling an architecture is that it is something that you have to sort of be on the lookout for modern products that allow you to do that, you know, per session level authentication authorization. If you're looking to get the security benefits, it's going to take a while to really do that because you may wind up having to update or even replace in some cases, bits of your security architecture and put in things that facilitate the zero trust, architectural approach. So yeah, I think most organizations, if they set out to do this today will probably take a while to actually complete that. And it has to be a guiding objective, you know, throughout various RFP processes for companies to be selecting a zero trust architecture.
Right. You mentioned the security benefits. Can you describe the security benefits that come through such a zero trust architecture? Yeah.
You know, I think that's pretty straight forward. I wouldn't say it's evaluating every interaction. So let's say a log in or a session that involves users, whatever devices they're coming from, whether that'd be mobile, mobile phones or desktops or laptops, or even IOT devices, the networks that they're on, the applications that they're using, and then the data that they're creating accessing or storing, which may or may not be on the device that they're using, or, you know, maybe under the control of an application. I think once we put together a holistic framework that allows us to authenticate and authorize every interaction between those components, we can get to a state where we're reducing the risk of fraud, data leakage, and even sabotage.
That sounds really great. And that also is the reason why zero trust has this notion within the customers, within the vendors, that it really is a next generation security platform, but you've mentioned, and I have not heard much about that topic before that NIS document also talks about threats to the zero trust architecture. So the threats to this next big things, cybersecurity platform, what do these threats look like? Can you describe some of those?
Yeah, yeah. You know, again, that's, that was something that I thought was really interesting and pretty novel meltedness is that it looks at these possible threats. Probably the most enlightening I thought was think about the possibilities of some sort of denial of, or distributed denial of service against the PDPs policy decision points. So the 800 dash 2 0 7 references, the exact mole architecture where you've got policy enforcement points that referred decisions to policy decision points, which then return a verdict to the policy enforcement points. So if let's say at some point in the future, we've all moved to zero trust architecture, we've got policy enforcement points, making thousands or millions of calls a day to various policy decision points. I think what the nest document is saying, think about what happens when those PDPs get overloaded. That may be a possible vector of attack. One of the other things they, they bring up as the weaknesses in API APIs.
I mean, most of this is predicated upon the use of API APIs. I mean, we've been talking about API APIs and microservices for a couple of years here, but again, you know, API security is a paramount concern. Even outside of the realm of zero trust architecture, you know, 800, 2 0 7 also talks about using a non person entities within zero trust architectural administration. And by this there, they're talking about machine language detection models. I think, I mean, it's, it's a bit vague, but what I read into this was that, you know, many security tools today, including, you know, very forward thinking forward looking access control products, we'll use machine language algorithms to help speed up the process of deciding who should get access and who shouldn't. We know that ML detection, models and algorithms like that can be manipulated or gamed to, to force things like false positives or false negatives. And, and those things, those results then can, could be exploited by malicious actors. Now these sound like very sophisticated kind of attacks. And I think that they are, but we, we know in some cases in the cybersecurity world that these kinds of things have happened before where bad actors have intentionally gained machine learning algorithms to obtain the result that they want. So it is sophisticated, but I think this is an area that definitely needs to be explored by cyber security and identity vendors. Take that into consideration when doing your threat modeling and build products
Accordingly. I also fully agree when it's what you mentioned first, the single point of failure. Would you have one policy decision point or only a few policy decision points? I think the same is also true when we are talking about identity at that part, both the PDP and the IAM system need to be made available in a highly scalable manner, in a highly stable manner and resilient manner so that all these many identities can be handled adequately on the IAM side. And that the requests for an access decision can be handled by the PDP at the required volume. You've mentioned standardization before I fully agree. And I'm a great fan of standards knowing that there are also many failed standards around, but I think standardization makes perfect sense for creating a heterogeneous architecture like zero trust at what specific areas does NIST suppose that standardization should take place.
You know, one of the things they call out is, you know, the proprietary nature of API APIs. Again, you know, everybody's kind of moving to an API first strategy, which we believe is a good thing. As long as those API APIs are secured, but at the same time, everybody having a slightly different API can be problematic. It makes it a little bit harder for solution providers and then the companies or organizations that operate all these different products with APIs to be able to integrate them. So having open API APIs that are also secured and standardized, I think are really important. I mean, you know, rest API APIs have been around for a long time. That's pretty straightforward. And, you know, there are lots of products out there and services that could help you secure a rest API APIs. But, you know, there are some products that use things like RPC and soap, and, you know, you may need a different set of security principles, models, and tools to deal with that. And now we also have web hooks, web sockets, and even W3C is new or newer web often, which came by way of Fido. Those things are out there to be used and to promote a more open and interoperable security architecture. But again, I think standardization wherever possible is probably a good thing. And there are major standards development organizations that, that are working on bits and pieces of this today. And we think that this is a good thing, and it probably has a role to play in the further in. So even zero trust architecture.
And again, I, I fully agree. I, with many of the API APIs around also being, being proprietary, being something where you cannot have a look at what's behind the API calls, or there might be issues with that API implementation and you just cannot see it because it's closed source. I think when there are standards around for implementing and creating and designing an architecture for zero trust that might also lead to readily available reference implementations, hopefully even as open source so that there is a better way to look into the solutions and to, to verify what's going on even behind the front door of an API call. Okay. Thank you very much, John, for, for giving that insight into that just really recently published document. Of course, you've mentioned the blog post and I highly recommend our audience to read it because it goes into more detail than we could cover here in this short podcast episode, when organizations are looking into going CRO trust for some of their use cases for some of their network segments. I know we have research in place. What does that cover?
Well, we, we help with various kinds of tools, choice, both around cyber security and identity management. And we are very familiar with the underlying principles under zero trust likelys privilege and defense in depth. We have research covering these. So we've got comparative reports, our leadership conferences, and then many different executive view reports on individual products out there that that could be useful for companies that are looking to do tools, choice replacements, or defining zero trust is the criteria for replacing a product. Right.
And I would like to add that with the identity fabric concept that we use for analyzing and updating and creating identity and access architectures, that would be one side of the metal when it comes to combining IAM and cyber security and our colleague Christopher just recently put out together with all our colleagues, the concept for a cyber security fabric, and that would be the other side of the metal. So if any organization is interested in doing that step and going that step, please let us know. Please get in touch, find some documentation, find some research and maybe talk to we hope the experts that we are and that we can support your in bed. Thanks again, John, for joining me today, any final thoughts you want to add? No,
Just this is a good document from nest. Thanks for them producing it. And we look forward to discussing not only zero trust architecture, but cybersecurity and I am in general with anyone who's interested. So thanks again for having me and have a good day.
Thank you for being here and looking forward to having you back soon. Bye. Bye
