Zero Trust in a Bot-Driven World: Securing the Internet’s Next Era

Brian Moody: Today's topic is really about demystifying Zero Trust, and we've been getting a lot of feedback, a lot of questions from our partners and customers coming in about this thing, Zero Trust. I've heard you speak on this topic more times. You don't really like this term, Zero Trust.

Shahin Pirooz: It's not that I don't like it. I think it's become so overused that it's become trite.

Brian Moody: Almost like XDR.

Shahin Pirooz: Yeah. It's to the point where it's not a new concept. It's a very old concept. It came rooted from this notion of moving away from an implicit trust model to an explicit trust model. And the way we wrapped marketing around it, as we do in our space, was we are gonna assume that there is no trust of anything. Therefore, Zero Trust.  

And so the concept, it's more of a methodology than it is a thing, but we tend to brand. And we're guilty of it. We have products that are Zero Trust Identity and Zero Trust Network Access, so those solutions that we're bringing to market specifically to deal with specific components of security, but really focused around this notion of just don't have implicit trust. Explicitly trust individuals.

Brian Moody: So let's kinda go back and start at the foundation, really of, we look at the beginning of the internet we look at the inventors of this thing. Talk a little bit about that trust model. I mean, when it started, you know, the internet was created for collaboration. So talk a little bit about that and what the foundation was.

Shahin Pirooz: Yeah, the internet fundamentally came from a system of computers that were connected together by the U.S. military apparatus. It was a network called DARPA. DARPANET was really a experiment to see if there could be secure communications between computers and if there was a way to communicate freely amongst defense administration.  

And the outcome of that was that it was a failed experiment. It wasn't secure enough. It was implicitly insecure, but it was designed as a distributed network specifically coming post this fear we were living in, basically the standoff between us and the Russian...

Brian Moody: The Cold War.

Shahin Pirooz: ...the Cold War, thank you. The Cold War threat loomed, and so there was this fear that we needed to not have control of communication and distribution of communication locked down in a single place so that it could be taken out by a nuke. So the internet was designed, that DARPANET was designed as a distributed network, so no node was 'the' node. They were all contributing equal nodes. And part of what that created was this openness.  

There was an implicit trust. If you were on the internet, you're supposed to be on the internet, or the DARPANET at the time. What ended up evolving was the universities came on and it became a side project called ARPANET, and ARPANET was effectively what evolved into what is today's internet, and it was really built around this concept of collaboration and interconnecting scientists and instructors to each other so that they can collaborate, so they can share information. And it was much more really thought about as an educational platform as opposed to a business platform which it has become today.

Brian Moody: And if you were on that, the idea was that you were supposed to see everything. You were supposed to...

Shahin Pirooz: Anybody, yeah.

Brian Moody: ...access to everything.

Shahin Pirooz: And, if you look back, if you read back any of the material from the early '80s, the idea was that network cables that connected systems together didn't have any layer of security embedded in them. There was no concept of firewalling. It was like, if you plug into the network, you're supposed to be on the network, and so you were implicitly trusted. And then computer programs were written that if I have a connection coming in from this network, so if there's a computer on this network, I'm gonna implicitly assume that every connection coming in from that network, that computer, is secure, because it should be here. So you created this notion of if everybody's supposed to be here and everybody's supposed to talk to each other, then anybody can jump on and do what they want, which is really what kind of evolved into today's hacker ecosystem.

Brian Moody: So you talk about, you know, even from the early days, Lawrence Livermore Lab and with DARPA, we saw some of the earliest signs of hacking. That, you know, all of a sudden, wait, we see this, in this... What is this?

Shahin Pirooz: Yeah, yeah.

Brian Moody: And so talk a little bit about that.

Shahin Pirooz: Yeah. Recently, Kirstin, our CMO, guided me to read this book called The Cuckoo's Egg, and this was a fun book. It was a really brilliant book. The author was the main character in this story, and it was really him articulating what his experience was through this process, and he worked for the Lawrence Berkeley Labs. And he was a physicist, but he was responsible for writing programs for telescopes and such, and they found 75 cents of computer time that they couldn't identify how it was used. It was unallocated, and it was an extra 75 cents that was consumed that they had no accounting for and no budgeting for.

Brian Moody: And this is breaking the you know, 75 cents, we're breaking the budget here.

Shahin Pirooz: So, the funny thing is, throughout the book, the FBI's like "When you get a million dollars of loss, call us, but don't call us before then."  

And the outcome of this was the same thing I just described. This actor was coming through an Emacs vulnerability that the world didn't really know about. Some people knew about it, and immediately he tried to communicate to everybody to shut it down, and people were like, "That's not my problem. Isn't that Emacs' problem?"  

And throughout the thing, he ended up writing a bunch of security tools and monitoring tools, because he was a budding software developer as well as a physicist. And watching his chase and his experience, and what feels like an evolution to the first SOC, effectively, is fascinating. So, I encourage everybody to go read the book. It's a fun read.  

But the same concepts were throughout that book. You plug a network into, you plug a system in, and it connects. This bad actor came in from Germany, and there was, at that point, it was dial-up was a big thing. So he was dialing up locally in Germany and connecting to an exchange that connected him to the United States. From that exchange, he jumped on MITRE's systems, and from MITRE's systems, he started hitting all the universities and military bases. And he was using MITRE's dial-in, and then from MITRE dialing out, so he was running thousands of dollars of dial-up fees for MITRE so that he can hide his tracks, so they didn't know where it was coming from. And it looked like initially he was coming from Berkeley. Then it looked like he was coming from Oakland. Then it looked like he was coming from New Jersey. Then it looked like he was coming from Pennsylvania. Then it looked like, wait, might be overseas. And so as they kept tracing and tracing, they found this guy.  

But ultimately, this guy used these networked computers over the MILNET, which was the military apparatus network, over the school network, over the proper ARPANET, if you will, and he was jumping into NASA, he was jumping in the Pentagon. Over 100 systems he broke into, took the password database on all these systems, and he was basically brute-forcing them on his own system. So, nobody saw the brute force attacks. There were definitely signs of activity, but nobody was catching it until this individual let them know.

Brian Moody: And this was a time where, I mean, cybersecurity didn't exist.

Shahin Pirooz: Yeah, we're talking '80s, early '80s.

Brian Moody: In infancy. So, the foundation, in a sense, if we look at modern cybersecurity and how we're protecting modern enterprise, I mean, the foundation was flawed from the start.

Shahin Pirooz: Well, it was not designed for security. It was designed for collaboration and resiliency. So, the biggest power in the internet is that there is no single node that is the managing node on the internet. And that creates a resilient network, so that if any node on the network breaks, it doesn't break the internet. It just finds its way around it. It's like, think of the electrons that are flowing on the internet as water, and the water finds a way. It's never gonna stop because there's so many pathways.

Brian Moody: So, if we think about the security tools that were developed up through that to address those things, if the foundation was flawed, talk a little bit about why, why are modern or even current traditional security strategies not enough?

Shahin Pirooz: So, I just mentioned MITRE, and if you think of the NSA's NSCS, the security computing, secure computing part of the NSA, they were part, throughout this book, this is the early '80s, they, as this poor individual physicist was calling them and saying, "These things are going on," everybody kept saying, "That's not my bailiwick. That's not my bailiwick."  

And today, we rely heavily on MITRE's attack matrix, and we rely heavily on the CVE database which MITRE manages. So, go back 40 years, and MITRE was like, "Not my problem."  

As you think about the evolution of things, it became very clear that we need to maintain databases of tactics and techniques. We need to maintain databases of vulnerabilities like the Emacs vulnerability. So, that was the starting point; let's figure out how to communicate what should be patched, because it was at that point still system-based security, where the system manager had to control the security of that device. You would patch holes. You would change configurations so that somebody can't log in.  

One of the key ways this individual was getting around was he was using the manufacturer's built-in accounts. When the machine shipped, it would ship with three accounts that had standard passwords, and the instructions were, change the passwords. Nobody did. So he was using System Manager or Service Agent. So he was basically really not doing any serious hacking. He was just using open doors that people had left, and you've said many times, like, if you leave your back door open but lock the front door, it's like, they're still coming in. And so that context in terms of just being able to walk into a network and then have elevated privileges, and then, with those elevated privileges, grab all the passwords and all of the phone numbers that that system uses to connect to other systems.  

Now this guy can build a map; here's the passwords for this system. I can use it to log in here. I can use the Emacs flaw to elevate privilege, and then I can use the phone numbers to call from this system to that system, and nobody will know who I am. So that was all a systems-based approach, and the evolution then went to, okay, we've got these networked computers. We should probably put a firewall, so people from the outside can't come in, and we can only allow traffic that we accept as good. So, this is moving towards an explicit trust model. So explicitly allow certain connections in, but not all connections.  

So the next step was firewalls. And then these bad actors realized that they need to get into the network, and the best way to do that was to deploy something on the systems that come in and out of the network. So malware, basically. So get malware on these systems, so antivirus evolved. And as we keep going forward, we find, okay, that malware now is coming in through email, so we need to put email security in place. And you can keep evolving to the now 4,000 security, 5,000 security companies that are out there trying to close all the little holes.  

And so the evolution of security started from this notion of we trust everybody implicitly to maybe we shouldn't. Maybe we should have some explicit controls about who can access our systems. Then we should say, okay, it's not just who has access to our systems, but did they do something that caused problems for them that they're now bringing into our network? And then it was, oh, now there's these bad guys trying to trick them through email. Then it was there's DNS links that are really bad, and so let's protect them from DNS. And it keeps evolving.

Brian Moody: Well, I think what's interesting is if you look at most security tools today, and I've been making this comment over the last many months, is that hackers are no longer breaking in, hackers are logging in. Because they are obtaining credentials. And if you look at most of our security tools today, if I log in with credential and I'm coming in with a valid credential, I am implicitly trusted. And there's not a security tool that's gonna catch me.

Shahin Pirooz: Nope. Well, I mean there's some...

Brian Moody: ...From a standpoint of me coming in with valid credentials.

Shahin Pirooz: The actual login won't be caught. But where you log in from and what system you log in from, we have tricks and techniques for identifying this person can't be logging in from Croatia when they were logging in from Oakland yesterday. So, there is correlation, and that's where the new defense mechanisms really come to play; we have to be able to correlate more than just the act of logging in, but where did that login happen from, and what operating system were they logging in from? Have they ever logged in from a Linux system before or has it always been a Windows machine, and now all of a sudden... Are they using Outlook to connect to Exchange or are they using a browser and they never use a browser, and a browser from Croatia?  

And so these factors all come into play, but this is where you've heard me say a SIEM without a SOC is like a guard tower without a guard. If you're not having somebody who's monitoring the results of those correlation rules and digging deeper to say something's fishy here, the tools themselves, no matter how many people tell you that AI SOC is here, AI SIEM is here, they really are just doing more better correlation rules. They're not solving the problem of finding out is this person supposed to be here? Is this entity doing what it should be doing?

Brian Moody: So you jumped my segue, which I thought would be a great segue from the point before to let's talk solutions.

Shahin Pirooz: Yes.

Brian Moody: Right? You made a comment that kinda set me back a bit. Everyone talks about Zero Trust, and you said, "Zero Trust is not a solution."  

"Zero Trust is a characteristic of your platform." So, talk a little about the solutions, and so people calling themselves... and as you said, we're guilty of it. You know, we call it Zero Trust Network Access. So, you know, we had put that tagline on products that WhiteDog offers.  

But talk a little bit about the characteristic of Zero Trust across the platform. And I think you've already started hitting on those notes, that it's about identifying process or behavior or there's other components of a platform that implement Zero Trust characteristics. But talk a little bit about that a little deeper for our partners. You know, where do we start, and where does Zero Trust play in a enterprise security platform?

Shahin Pirooz: Yeah. I think one of the best ways to talk about it is our ZTNA offering. And why did we call it ZTNA when we have this perspective? ZTNA stands for Zero Trust Network Access. So part of the reason we picked that naming convention is because the world calls the next generation VPN, ZTNA. The real problem is that the core distinction, the thinking, the way you gotta wrap your head around Zero Trust is you have to move away from an implicit trust model to an explicit trust model. So rather than just because this device VPNed into my network and they now have an IP address on my network, I implicitly trust them. They can do what they want. They can go where they want. They can touch anything they want.  

How about if we add a model where we said we don't do that? How about we say that they can't just come in and get an IP address on my network. They can only connect to the three servers they're allowed to connect to. And that's it. That would move into the explicit or Zero Trust world as opposed to a VPN displacement. And what I mean by that is most of the ZTNA solutions in the market today have really taken the VPN concentrator from your office or your data center and moved it into the cloud, and they call themselves a ZTNA player.  

All that did was move the same problem. There's a VPN concentrator somewhere, when you connect to it, there's a connection from that concentrator to the rest of your network. And you implicitly trust that device that's on your network. So now you're relying strictly on identity to protect your environment, and we just said bad actors no longer break in, they log in. Identity is the number one targeted, and when we talk about metrics around what types of attacks are successful, 100% of all attacks include an identity that's been captured.

Brian Moody: Well, I'm selfishly gonna ask you to kinda jump into what WhiteDog, because WhiteDog just recently around our DeltaDR platform, we've announced an enhancement around identity. Because, so, okay, I phish an individual, they make a connection, they put their credentials in. This is kind of a simple kill chain. I have your credentials. I log in, I come in via the corporate VPN, and so maybe I'm a lowly admin, or maybe I'm salesperson or what have you, but I've got your credential.  

Talk a little bit about that process. I mean, one, the hackers are relying on this implicit trust for dwell time, right? We talk about this all the time. If you look at most major attacks, dwell time is about six months, right? I mean, they're in. They know how to use this implicit trust to move around your network. They find your crown jewels.  

The key though is, talk a little bit about our ISPM, our identity security posture management, and our ISPM solution. Because the elevation of privileges around an account is critical, and again, we're looking at behavior. And that's the other aspect that I think is critical. So talk a little bit about that, 'cause I think it's a critical offering that we brought to market around our DeltaDR platform.

Shahin Pirooz: Yeah, so we've talked about DeltaDR before, but before I jump into that, let's distinguish that from XDR. There's a ton of solutions in the market that call themselves XDR, and I would argue that many of them are no better than EDR or maybe MDR. XDR should be more than just endpoint security. And we do have an XDR portfolio which is endpoint, email, and DNS protections. And what we decided is, you have to be able to go beyond even the basics of what an XDR solution does. There's a lot of gaps that remain when you just focus on those three avenues, and most of the XDR players will typically cover email and endpoint, at best, but usually it's just endpoint.  

And so, we initially added DNS to our XDR solution, and we decided we needed to go bigger and broader, so we added a full series of attack surface management capabilities. We added data security posture, identity security posture, we added DNS security posture, we added identity detection and response, and all of these things were really because there's five layers to any network security stack. And I say five layers, but I'm gonna say that there's technically another layer, and it's tied to the topic of today. The internet is now 51% bots versus humans. It is no longer made for us. It is made for bots. They've taken over the internet.

Brian Moody: There are good bots and there are bad bots.

Shahin Pirooz: They're just like good people and bad people. There are good bots and bad bots.  

So when you think about that most of the traffic on the internet is automated, we have to think about the next layer beyond the five I'm gonna describe. So the way we have looked at the world historically is email, DNS, identity, endpoint, and network. So those five layers of security are what we cover with our DeltaDR, and we called it DeltaDR because Delta closes the gaps that XDR doesn't. So it's the delta between XDR and proper security. And so when you take that into context, and now we're talking about this external attack surface from bots, now we've got, and we've heard a lot in the press about protecting your web applications and your APIs, and now that we've got 51% bots out there, we really need to consider that.  

But coming back to your question, identity posture is really about understanding what's going on in your Active Directory, in your Entra ID. So, one of the big components that the bad actor in this book that I was talking about was able to do, was he was able to take accounts that haven't been logged onto for months and change their password because he figured that individual isn't gonna come back and say, "My password's changed."  

So he was able to take stale accounts and rejuvenate them and be able to go up and operate. And it was really easy on Linux systems to change passwords. You would just blank out the password, and the next time you log in, it says, "What? Put in your password." So, it was super easy if you've got system manager-level credentials.  

So, going through that thought process for a second, bad actors are logging in, they're logging in with an individual account, they elevate system privileges and then they may create administrative rights for an account that hasn't been around for a long time. So what they're looking for is not to create a new account because we all monitor for new accounts. If there's a new account, creation alarms go off. So they don't wanna do that. What they do is they take an account that's stale, which means it has been sitting around and nobody's disabled it, and will run it.  

So part of ISPM is looking for stale and unused accounts, elevated privileges in accounts that shouldn't be, system manager accounts that haven't had their password changed in X period of time. It's a configuration management for your Active Directory to help to protect, and all of our attack surface portfolio is designed to identify what are the things that a bad actor could take advantage of and let's fix those. So when you think of attack surface, that attack surface is the same attack surface that the bad actor will take advantage of, so we actively test those attack surfaces in those five layers that I talked about.  So, that's the first part of it. That's the identity security posture management and configuration analysis.  

On the backend of it, in our largest feature set of DeltaDR, our DeltaDR Complete offering, we include identity detection and response for those that have Active Directory. And that is literally creating honeypots in your Active Directory. So we're creating fake accounts, we're creating fake domain controllers, we're basically making it so that when a bad actor comes in and they start touching these virtual devices and honeypots, we're able to identify nothing should have been touching this thing.  

So alarms go off much faster than digging through logs and relying on correlation rules. So, it's like the traditional honeypotting of networks, we do that within Active Directory, because identity is so core to protect, in order to prevent bad actors from logging in.

Brian Moody: So, we're really looking at behaviors. We're really beginning to understand how an environment... What's its normal, and what shouldn't be happening?

Shahin Pirooz: Yeah.

Brian Moody: Because even if I do come in with valid credentials, I may act in a way that I that account hasn't acted before or a user has now interacting with files they haven't interacted with before, and those things are things that we're now beginning... So, here's the human, the technology and human aspect of it, is that's where an analyst in a WhiteDog SOC begins to go, "Wait a minute." Right?

Shahin Pirooz: It's not just the analyst, it's also a tool set. If you think about UEBA, user and entity behavior analysis, that's been a terminology that we've heard. And people, when you go to have conversations, sales conversation, people say, "Do you do UEBA?" And almost everybody says yes to that, but nobody really digs past the "Do you do it?" It's a checkbox. And what we do with it, I think is distinctly different.  

We take and we're looking at traffic flow analysis, packet captures, logs, vulnerabilities, and we're correlating all that information together to say here's a user that logged in to Office 365. That user happens to be on this machine. This machine is connecting to 10 servers that it has never connected to before, and on three of them, its traffic pattern and flow looks like it's connecting to ports, which on those servers, have a vulnerability that that traffic pattern would take advantage of.  

There isn't anybody else in the industry doing that. We're literally monitoring the attack chain. We're checking to see has the behavior of an entity or a user changed, and if it changed, what has it changed to, and is there risk associated with that change? And we do that by embedding also vulnerability data into it. So having user and entity behavior data is important. Utilizing it and correlating it is even more important, and most people don't do that.

Brian Moody: So, you've been doing this a long time.

Shahin Pirooz: Yeah.

Brian Moody: So, we probably just spun the head off some folks that are listening, like, "Oh my God, what do you mean?" I mean, it sounds complex and it is, and it needs to be. You know, we mentioned Halloween and cybersecurity, both scary.  

Simplify this for our partners, I mean, where do they start? So we talked a little bit about some of the solutions, we talked kind of about that. So, I mean, where do they start to get down this path?

Shahin Pirooz: Part of the reason we're talking about the Zero Trust topic today is that there is this evolution that's happening. We're on the next generation of internet, if you will. You've heard Web3, you've heard Web1, Web2, Web3, where there's a lot of changes happening, but we're seeing more and more.  

If we back up, in a similar way that we talked about that evolution of the DARPANET to the ARPANET to the internet, we also saw business communications change. We went from VANs and EDI communication and modems to calling over the internet to do exchange of information, just in time shipping, ordering, processing. We had very specific message formats for doing that communication.  

To today, we are literally communicating over APIs business to business. So, there's no humans in that conversation. The behavior isn't really a behavior analysis of what people are doing, and the reason the internet is now 51% bots is because all of those business to business communications that were potentially done on private networks and all that are happening over the public internet, over secure connections via API to API interactions. So, if that's the case, if 51% of the traffic on the internet is API communications, who's protecting the APIs? And that's that sixth layer that is part of what we want to expose.  

We are actively developing our next evolution of what we're bringing in terms of attack surface management to the table. We're adding our application security posture management services to market. And ASPM is really threefold. It's this traditional dynamic and static application testing, security testing, which is going to statically monitor your libraries and repositories for your code for software that you're developing. There's the dynamic which you embed into custom code you developed that is monitoring the behavior of that application internally to see where potential compromises are, and then there's pen testing of the application from the outside, which is going to try to take advantage of vulnerabilities of that application's fingerprint and scan it.  

And it's important, similar to what we just said about those five layers, to identify, here is an attack we did, where did we see it in the dynamic stack, and where does that dynamic point to in the static actual code so that we can give a remediation recommendation about a code change that tells you where you gotta go fix this hole. That's something that the world isn't done yet. Those three solutions I just talked about are separate solutions that nobody integrates. You have your static, you have your dynamic, and you have your pen testing, and you monitor and manage each one of those just like you monitor and manage the 20 tools inside your network.

Brian Moody: Well, I'm gonna argue that most people don't monitor, manage those.  That's, you know, and again, as you run down the complexity of what you just talked about, I come back to what do partners, I mean, what do people do now to kind of start? Where's the beginning? And I think, and for me, selfishly so, I think WhiteDog simplifies this for so many people, with respect to our platform, and the complexity of the things you just talked about, and how we simplify the ability through our platform to address those things.

Shahin Pirooz: So the easiest way to think about that simplicity, and partners of ours know that we've done that for the standard security posture and management of email, DNS, endpoint, network, and identity. Where we're going with this, and with everything we do is, it's pre-configured. We're not coming in and building a custom solution for every organization. We're not trying to figure out how something fits.  

We've already evaluated if the technology is best-in-class. We do shootouts and evaluations, which all of us do in this space, and then we've taken the best-in-class technologies and used those as OEM engines behind the WhiteDog IP, and then we have WhiteDog IP behind that, that does the correlation of data. So front-ended with an interface that's multi-tenant and white-labeled, back-ended with data lakes that effectively allow us to correlate information in a way that none of these tool providers ever envisioned. You have AI integrated in each tool in those 20 tools in your stack. Those AIs don't talk to each other. We have AI on the backend that is doing the correlation across all the data, across all the tools.

Brian Moody: So you bring up, there's the AI word again, and last month we had a conversation about AI. So from a next component of a futuristic, what new threats and things do you see coming that Zero Trust can maybe help address, so in a sense, how would you tie new threats that are coming, the Zero Trust concept, what are things that our partners, customers should be concerned about?

Shahin Pirooz: Well, if you follow us on LinkedIn, we throw a tremendous amount of stuff out there about what the modern new threats are, and what's happening, and what large attacks are, and we try to break them down into the IOCs so that whether you're with us or not, you're able to take those IOCs and do something with them. So worst case scenario, follow us on LinkedIn. Best case scenario, sign up and get the advisories right from us directly.  

But ultimately, the attack approaches haven't changed. There's not that many new tactics and techniques that are happening. The speed of which those attacks are happening and the attack surface are changing. So the attack surface keeps broadening. I just talked about APIs, so it's no longer people are coming in through your web applications, they're going behind the web applications to APIs. And most people did not develop those APIs with a security mindset, 'cause they thought their application was gonna be the only thing talking to it. They thought there'd be a handful of partners that might wanna make their own web interface. So being able to, you know, big part of what this new application security offering that we're bringing to the table, will also include WAF functionality, so web application firewall, to prevent traffic that's going into these applications, both APIs and front end web applications, and being able to monitor bot behavior.  

So those web application firewalls that we're looking at are those that can give you visibility into what's going on, what bots are communicating to us. Are these good bots? Are they bad bots? Are we seeing the same bots come every week, or does behavior change on a bot, for example. So that's a factor that fingerprinting needs to happen on. So as I said, the attack surface has moved away from just the enterprise and interoperability of the systems of the enterprise, to now inter-business relationships and the security over the internet.

Brian Moody: Well, we're seeing a quick phenomenon around that with bots, and something that's in the news is, I saw the other day that when you apply for a job these companies are getting so many resumes that are coming in, again, bot resumes that are coming in to an organization, that they're literally talking about now that they need to add a fee.  

You know, universities now, there's so many AI-associated applications, the cost for these companies and universities, and just businesses in general, to process the amount of information that's coming in, you say 51% is bot-based or AI-based, it's a huge impact on their business and on their productivity. So now you're coming into all this fake stuff, is it human or is it a bot? You know, what fingerprint does it have? So I mean, this is a huge area that is just impacting business from a standpoint of how they understand even to some case what's real and what's not.

Shahin Pirooz: Just like the original inventors of the internet did not envision we would be using it for what we use it for today, the same thing happened when websites were created. They were not envisioned to be business-to-business interactions. They were supposed to be informational portals.

Brian Moody: Well, that's a lot. And I hope we helped a little bit with around Zero Trust and how it fits in. I mean, the net is, Zero Trust is not an endgame. This is not something that you... There's not one product that delivers Zero Trust. As I think Shahin eloquently said, it's a characteristic that you implement across your security platform.

Shahin Pirooz: It's something we strive for.  

Brian Moody: Yeah. So any any additional questions about that, we'd love to answer. Please reach out to us. We're happy to help and we appreciate you guys joining us today for a quick talk maybe about demystifying a little bit around Zero Trust.

Shahin Pirooz: Happy Halloween.

Brian Moody: So thanks again. Thanks for joining us and, yeah, happy Halloween.

‍