A Zero Trust Leadership Podcast

AI Doesn't Break Security. It Exposes It. | Jason Garbis
Jason Garbis, founder and CEO of Number Line Security and co-chair of the Zero Trust Working Group at CSA, joins to explore what Zero Trust looks like when threats evolve at machine speed.
Transcript
Raghu N 00:00
Hello, and welcome back to another episode of The Segment. I'm your host, Raghu Nandakumara. And today we're exploring why this AI era may be reinforcing some very old security lessons. As AI accelerates attacks and automation reshapes the threat landscape, many organizations are searching for the next big security breakthrough, but the reality is that most breaches still come down to the same core issues, visibility gaps, weak governance, overly permissive access, and a lack of segmentation. So, how do security leaders cut through the hype and focus on what actually improves resilience? And what does Zero Trust look like when threats are evolving at machine speed?
Today, it gives me great pleasure to be joined by Jason Garbis, founder and CEO of Numberline Security, a consulting firm helping enterprises define and execute effective Zero Trust strategies. Jason has authored several books, including Zero Trust Security: An Enterprise Guide, is a co-chair of the Zero Trust Working Group at the Cloud Security Alliance, and is a longtime leader across product management, engineering, consulting, and cybersecurity strategy. Jason, it's an honor to have you on The Segment. Welcome.
Jason Garbis 01:09
Great, thank you, Raghu. I'm looking forward to this discussion. There's a lot to talk about.
Raghu N 01:13
There is indeed a lot to talk about, but before we start talking about those things, why don't you give us a quick sort of background on essentially how you got into Zero Trust and ultimately leading the Zero Trust working group at the Cloud Security Alliance.
Jason Garbis 01:27
Well, how far back in time do you want to go? It's entirely up to you.
Raghu N 01:31
You could go day zero if you want.
Jason Garbis 01:33
So, I've worked in technology for my whole career, and until really until I started this business as a vendor independent consultant, I worked on the vendor side for over 30 years in a lot of different roles, software engineering, technical consulting, product management, and then leadership roles. Through that evolution, I really found myself working for middleware and integration vendors, and ultimately started about 15 years ago, vendors that were focused on network security, identity, and what ultimately became this area of Zero Trust. So, about 1011 years ago, I started working for a vendor that was coming out with an identity-centric network segmentation product, this space that today we call Zero Trust Network access. And as I got into that, I realized, hey, this - there's this group called the Cloud Security Alliance, and they have a software-defined perimeter working group, and that was the architecture that we were implementing in the product at the time. So I joined the group and started volunteering, and through that, number one, ended up taking on a leadership role for that, and number two, as we went through, we realized within the Cloud Security Alliance that there was a much bigger trend going on in the industry around what today we call Zero Trust, so we really rechartered that group, that working group, from in what was initially the software defined perimeter specification focus to now Zero Trust, and there's actually nine work streams going on inside of this group across all of the different pillars in a different set of functional areas, so I really enjoy that role, because I get the opportunity to interact in a very academic, in the best possible sense, right, theoretical conceptual thought leadership way, with a lot of great, smart people, as well as, you know, it really dovetails into the kind of work that I'm doing now, which is to provide enterprises with vendor-independent best practices guidance around how to take this concept, the strategy of Zero Trust, and apply it best to their environment.
Raghu N 03:26
Awesome. So you were kind of like in involved with SDP, right? And then that sort of evolved into this bigger focus around Zero Trust, Zero Trust. Like, what were the kind of the key indicators that you saw in the industry, whether it's from the vendor side or the practitioner side or kind of the regulator like side of things that sort of really indicate this shift, this movement was gathered in pace. What were the key indicators for you?
Jason Garbis 03:52
Well, for me it was really looking at beyond just okay, we have this technology that can enforce access controls, and the vendor I was working for, was really largely focused on the user to service side of things. Obviously, at Illumio, you're focused largely on the service to service, or east-west side of things, but the same, I would say, approach was really required, which was, we have this technology, fantastic, but the technology is only going to be good as the data that it can consume to actually start to utilize and enforce the policies. It's the okay, great. I can enforce who can I, who has access to what, but unless I know the who, the identity side, and the what, the resource side, my fantastic technology isn't going to provide any value to the business, and that really underscored, I think, a lot of what we'll end up talking about today, which is the need to have reliable, accurate, machine-readable data that describes what are your workloads, what are the policies around them, and what are the identities that should have access to them, which in turn means you've got to have governance processes, you've got to have a higher level of discipline in your organization around processes for deploying. Workloads for organizing users and identities, and for managing the lifecycle of those, or you're going to be in a world of pain.
Raghu N 05:07
So, just like, because you brought this point up now, so there's there's been a lot of over the last 10 years, right, with sort of Zero Trust approaches kind of very much sort of coming to the fore. It's kind of followed that that sort of that hype cycle curve, where now it seems to be very much on that sort of path towards mainstream adoption,
Jason Garbis 05:26
the plateau of plateau of product productivity,
Raghu N 05:29
productivity. Yeah, I didn't want to nod too much to Gartner, right, but, but hey, do you think that one of the things you said there is Zero Trust requires a certain amount of discipline and rigor, right, in how you manage your estate, manage your infrastructure, your, your assets, your CMDB, etc. Do you think that has been one of the challenges in terms of organizations adopting Zero Trust? Is there, is there, as there's just been too much of a barrier to entry, or maybe needing more discipline that they have
Jason Garbis 06:03
there. It's definitely a challenge in many organizations, and it's.. it's.. there's a very wide variety of organizations that have invested in this and prioritize this versus ones that are haven't have a lot less control and therefore a lot less visibility about what's going on in their environment. I wouldn't say that it's necessarily a prerequisite, because we work with organizations at all phases, others are trust journey, and some are very immature, and it's not that they haven't had a desire to do this, it's largely a factor of how much the overall enterprise values and therefore has invested in this, and how much they're willing to accommodate. I won't say user friction or hits on user productivity so much as changes to the user experience, changes to the way that work processes happen, in order to best align with what we know as best practices. Around, you've got to have control of your environment, we'll take a simple example of someone who's using one of the major cloud service providers, the infrastructure as a service environment. How centrally controlled is this? How much leeway do developers have to in their developer sandboxes? Who really cares, right? But as you moved closer to production, whether it's a test environment or truly in production, how much control does the organization have, and how much daylight is there between what you think is running, what should be running, and what actually is running in your environment? And the right answer is, there is, there shouldn't be any, because that environment is going to, is completely under your control, and it's a completely solvable problem for you to have the right level of very detailed visibility, and therefore you can build very correct and very well very effective access policies around that.
Raghu N 07:49
Yeah, absolutely. So, just in terms of like that adoption, right, what have you seen change over your time working on Zero Trust projects in terms of how organizations approach adopting Zero Trust strategy to their implementations, like what is what have been the significant shifts that you've seen.
Jason Garbis 08:08
I think that if we, if we reflect back over, let's say, five plus years, it's there's a definite, first of all, I would say a realization that Zero Trust is the right way to do things, right? Zero Trust is the way. If we're, if we're quoting The Mandalorian, and it really does encapsulate best practices, right? There's, you don't have people arguing against the principles of Zero Trust. No one's saying we need to have more implicit trust, we need to have flatter networks, etc. It's the challenge is really, okay, How do I do this? How do I, as a security leader in an enterprise. How do I do this in a way that isn't number one, maybe I'm really, my team is already overwhelmed from day-to-day operations. Number two, how do I do this when I have to ask it for people's time and to prioritize my work, my task over what they're already doing? How do I get people on who own line of business applications or line of business processes to make changes to what they're doing in a way that is going to improve security. I think that becomes a big challenge, and the right way to do this is to really - this is part of the best practices that we recommend when we work with enterprises - is to dive into what is driving the business, what are the things that allow the CSO to not just stand up there and say, hey, we prevent bad things from happening, but also we securely enable good things to happen, we understand what the business needs to do, and AI adoption is the best, most recent example of this, you know, obviously a gigantic trend where no CISO is in their right mind is going to go to the business and say no, you can't use AI, right? That's that's a career limiting position, right. Every every sane CISO is going to work with their team to say, okay, the business wants and needs to do this, this is how we can do this in a way that. Isn't going to sacrifice security or put the business at risk, because there's a lot of risk there if this stuff gets out of control.
Raghu N 10:06
Yeah, absolutely. So I think that's a, I mean, I think firstly that that approach and that change in approach, and the fact that everyone sort of acknowledges that there's no longer about is this the right thing to do, that acknowledgement, yes, this is the right thing to do, and it's a case of now, how do I bring everyone along for a ride, right? Because I think, and you kind of touched on this, because this is a Zero Trust program, is transformational across the organization. It's not just a, it's a security driven program, but it's an organization-wide sort of shift in thinking, right, and that's probably the challenging piece, is
Jason Garbis 10:46
can be
Raghu N 10:46
right, it
Jason Garbis 10:47
can be right as well. Let's challenge that a little bit. So I agree that ideally that is absolutely the case here. We love working with clients where that is because it's big and it's impactful and it's very broad in scope, but part of what we do up front is we have to have conversations with security leadership to really right size the Zero Trust initiative within the organization, and sometimes the right answer is no. This is going to be a smaller, narrowly focused program just within security, and there could be lots of reasons for that. Maybe the security isn't that important to the business, maybe security needs to build credibility. Maybe it's a very static business that there isn't a lot of business change. Maybe there's just budget issues. Whatever it is that a smaller and security only focused program, there's nothing wrong with that, right? Because you're going to be able to design it a way that improves your security, has minimal or less impact on business processes, and the user experience impacts can be and should be carefully designed to be very strictly additive. Hey, we're moving the password list. Hey, we can now enable you to get rid of the VPN and move to our more modern ZTNA, or in some cases it should simply be transparent, for example, the type of work that Illumio does, in terms of micro segmentation. It's yes, you're a sysadmin, you can still get to these production systems to close these tickets that you have, and you're going to get that transparently, because the fact that the business process of you getting a service desk ticket assigned to you is what opens a network connection, and when you're done and you close the ticket, that goes away. That's going to be a completely transparent type of operation, where it dramatically improves security, but there's no gigantic change to the workflow. So, those are things where, when you have organizations or CSOs, or whatever the dynamics are, where a smaller, more focused Zero Trust initiative makes sense, that's a way to design that, so the key is to align these things so that you're set up for success, and you're not pushing this out as some big giant business transformation initiative when the organization isn't ready for that.
Raghu N 12:53
I like how you said that, about sort of it's important to right size your Zero Trust project in order to make progress, in order to make gains, right. So, just like in your experience, like what have been some of the highlights about really well done zero across projects, but equally, like what have been some of the key learnings of where a project hasn't been executed, sort of let's say following best practice.
Jason Garbis 13:18
So, the we'll start with the good news, right? The good examples, you know, clearly in those organizations where they have support of leadership, and this could be for a variety of reasons. It could be a recognition that we're in the information processing business, right, whether it's a technology firm or financial services firm, etc. that, and they've seen peer firms have major security incidents, or maybe there's a regulatory change, or maybe there was an incident, and then some, or some sort of mandate for this, and they get this, this top-down support that number one is very helpful for the security team to have the political juice to push things through, but even when they do, that's not, you know, that's not the big stake that you want to pull out very often to beat people about the head and say no, no, you have to do this because I've got this this mandate in all cases. It's the best run organizations tie into what the business wants and needs to do, and that these changes that you're going to be making - technology changes, process changes, workflow changes - are going to be created and prioritized with a deep understanding of what's important to the business. This could be something such as, hey, the business has a big initiative to expand from just North America to the European region. Great, that's a gigantic investment by the business. Here's how we can use our Zero Trust initiative to support that, enable that, and make that easier. Or this company does a lot of mana, right, inbound M and A, or outbound divestiture. We're going to design things in a way to make that easier, or something that's, as perhaps, as let's say, tactical, as we're subject to compliance regulations, and every quarter this unit, this line of business, etc. has to go through the. Really painful compliance exercise that takes hours and hours of time, and we're going to make some changes to automate that. And if you approach it like that, and you say, "Hey, you know this thing that takes your team 40 hours every quarter, we're going to turn that into two hours, right? They're going to throw you a party. It doesn't matter that you're going to make them change the way they log in or do certain tasks. The benefit for them is going to be phenomenal. There, so really well-worn organizations look at what's going on in the business, and no matter how much of a mandate or a lack of a mandate they have, they still tie it to that type of benefit to the organization.
Raghu N 15:36
So, just to pause you there for a second, so I like sort of the way that was phrased, it's really, really around look at the way the businesses is transforming and what they're prioritizing, and use that as an opportunity, sort of to how can I plug my Zero Trust program to transform security into that existing kind of key initiative, so that it's like part of that versus a standalone thing that you're trying to drive in some other manner,
Jason Garbis 16:02
that's right, that's right, exactly. And we see many great examples of this today, where lots of enterprises are standing up AI initiative centers of excellence, or tiger teams, and in almost every instance, the CISO and their team is an active part of that to make sure that there's the golden pathway or design patterns, templates, et cetera, to give the business here are the sanction ways to do this. You can get access to these web-based chatbots, but not those. You can use these models in this way, but not those. You can't deploy some random MCP server and give it your logins, for example.
Raghu N 16:40
Yeah, yeah. Okay, so what about Zero Trust done? Not so well,
Jason Garbis 16:46
it's lots of ways for them to fail. I'm thinking of the.. I think it was the Tolstoy quote around.. anyway, we're not going to go there. There's lots of ways that Zero Trust programs can go wrong, and I think you know, certainly one failure mode is analysis paralysis, where we, as security professionals, we love architectures, and we love putting together things that on paper work really well. And I've seen organizations that spend far too much time doing this analysis and come up with a beautiful, well thought out 75 page architecture document, and it takes them a year and a half, and they've actually never delivered any value, because they haven't actually deployed additional capabilities in their environment. So, what we have to remember is, why does information security exist in enterprise? They exist to enable the business to securely access resources. Full stop. Most organizations, information security is a cost center, and you have to justify your investment in the budget. And our goal as security leaders is not just to improve security capabilities. Our goal is to use those new and improved capabilities to actually turn on and start enforcing access policies that make things better for users and better for the organization, and hopefully more operationally efficient. So, if you lose sight of that, organization security organizations can get really either stuck in the analysis paralysis, or they fall into, let's say, the traditional project management trap of, oh, you know, we need technology x, great, we know how to do that, we're going to put together requirements, we're going to do vendor POCs. We're going to deploy this. We're going to train people. We deployed vendor access solution for problem space Y. Great mission accomplished. And no, this is the tree falls in the forest, and no one's there to hear it, right? Doesn't make any noise. The world's best PAM solution, for example, doesn't do you any good until you actually have people that are using this, and that is a big part of this, right? You have to educate people, you have to build the workflow and the processes around this, and you have to have a way of incenting people, forcing slash incenting people to adopt this and change this, and this is hard sometimes. We work with one technology company, and they built out a basically a large technology platform. They were in the financial services space, and they had, you know, hundreds and hundreds of customers on this thing. This platform was pretty old, I mean, the parts of it were 20 plus years old, and there was a lot of security debt in it. And the security team recognized this, so they built out, they work with the developers, and they built out a whole new set of modules. Hey, get rid of this old authentication stack. We're going to use this new one. Get rid of this whole network security mechanism. Here's another model. Here, but they had very little uptake. They had built this out over a number of years, but they still only had about 15% adoption, and the reason was that every time they tried to push this, the developers were okay, but I got all these customer bugs to fix, I got to put these new features in to close this deal, so they were really struggling with the business to prioritize that adoption.
Raghu N 19:53
Yeah, that, that I can absolutely relate to, because in a previous life I had sort of done like. I done all that, built sort of this security capability that I thought it was fantastic, built all the self-service piece around it, and kind of just assumed it was like that, build it and they will come, right? Like people were queuing up, saying, yeah, I want to adopt this, but no, that's never the case, right? That, like, they have so many other things that are more important to them, that this doesn't, like, it's important to you, but it's not important to them, right? And it kind of just sort of, it becomes shelfer.
Jason Garbis 20:26
Yeah, exactly. And this, this is why in security organizations, there does need to be a proactive investment of getting people in the security team, you know, out from behind their keyboards and talking to their, the other stakeholders and the counterparts, and there's lots of opportunities to do that, whether it's, you know, today educating them on AI, or having brown bags, or things like that, but part of it is just listening, you know, which is, hey, let's sit down and have a cup of coffee, or a virtual cup of coffee, Raghu, tell me what's going on, you know, with your in your world, and what are you trying to accomplish, and you know, if we had the, the information security and it genie here, and he granted you three wishes. What would they be? It's a great way to, in a non-confrontational way, to hear, oh, you know, I hate this system, or this thing is a pain in the neck, or that process, you know, really slows my people down.
Raghu N 21:16
Yeah, maybe don't ask them what they hate, because that might be a long, not a long, it might be a long conversation. Yeah, but this is this is great advice, because this is exactly so now talking from an Illumio perspective. The when we're in conversations with prospects, like often the conversation is around, like, okay, well, how do I make this successful, right? How do I ensure, and, and it always, so much of this comes down to that the answer is it's not about the technology, right? It's about everything that you can wrap around from an engagement and an education perspective to ensure that once you have the technology in your hands, that everyone, or all the people who need to be in your organization, are educated, are engaged, are excited, and kind of see what's in it for them, so that they are ready to go, right? Otherwise, you're going to have to always be, you're kind of, you have the technology, and then you're doing the education, and that's always going to result in sort of slow down of the project.
Jason Garbis 22:15
That's right. That's right.
Raghu N 22:16
Okay, you've dropped the term AI in a few times, kind of teased it, like listeners will be saying, when's it, when's it going to happen, when did it happen. All right, let's talk about AI now. Where I would like to stop is, let's talk about Zero Trust, like securing AI systems first, right? So, being very specific, not about AI in the hands of the defender or AI and security tools, but very much around, and you kind of touched on it briefly about securing the adoption of AI, right, whether that's like access to models or whether that's agents in the environment, etc. So, what is kind of when we think about this in the context of Zero Trust, like what is relevant, what, what, what is new, what are the key considerations.
Jason Garbis 23:01
So the first thing that I think people have to recognize is to try to build a mental model or a taxonomy of the different types of AI systems that we have and that users can interact with, because there's a dramatic difference between I go to Claude, I go to the, you know, the free version of ChatGPT, and I type in a prompt, I upload a file, I paste some data, and it gives me some results back. There's a world of difference between that and I'm deploying an agent on my desktop or on my Mac Mini next to it, and running an agent on there and setting up an MCP server, so we can get to SharePoint and our customer databases and all my files, and a world difference between that and okay, our data scientists are building a custom fine-tuned model that does certain things for us, so those are very different problem spaces with very different technology spaces and very different sets of controls or capabilities that you need in order to get visibility and management around those, so the first thing to do is take stock and build this taxonomy, or find a fine taxonomy around this, and there's, you know, we have some work that's ongoing here at Numberline around blogging and putting together a framework to help people organize that, and for each of those, start to think about, okay, what might these things look like, what sort of capabilities might I need in the environment. What do I need to worry about in those different scenarios?
Raghu N 24:25
So, is it just new ways of thinking about essentially still the same problems, or is it introducing fundamentally new challenges?
Jason Garbis 24:34
I think it's both, and that sounds like a wishy-washy answer, right? I think that clearly AI is accelerating the speed of both vulnerability discovery and therefore the set of follow-up actions we have to take around patching, etc. as well as, of course, the speed and effectiveness of attacks that we're seeing. It is not fundamentally changing the foundation. National things that over the last 25 years we in information security have developed as, okay, this is how you do this stuff. We know you need this type of identity management program, we know you need this type of device management, workload management, network segmentation, et cetera. It's what I think it is doing is the speed and the volume of things that are stemming from AI is uncovering weaknesses in process and showing that organizations that haven't invested in these things are going to be a lot less resilient than organizations that have, right? If you don't know what's running your network, if it's a little bit of the wild west where you have developers deploying things, you know, you're already way behind here, and it's going to be very, very difficult for you to put some controls in place, versus if you're already doing that, and you have well-defined processes, then these new agentic systems become much, much more like just, you know, quote unquote, just another server. Now,
Raghu N 25:57
yeah,
Jason Garbis 25:57
there's some differences there, but there's a lot more similarities than differences.
Raghu N 26:00
I like the way you phrase that, right, is is that it's the capability, the speed, the potential autonomous nature of AI is going to expose flaws far more rapidly and potentially far more with far more catastrophic outcomes than we've been able to do to do thus far, right, so let's frame this in the context of essentially all the post mythos era, right, and of course, right, GPT 5.5 was announced recently that sort of showed similar capabilities. So when you saw that, what was your first reaction when you heard the mythos news?
Jason Garbis 26:38
So I wasn't, I immediately said, okay, well, this is going to result in a pat tsunami, right? This is a giant wave of updates to open-source libraries, commercial software, as an end major platform like operating systems that organizations are going to have to now all of a sudden very rapidly digest, and you know, perhaps even adjust to a new normal, much higher level of speed and volume of these things. Now we know there's a lot of debate over how much marketing hype was in the whole mythos announcement, etc. You know, my position here is that it doesn't matter, right? These models are not getting worse, they're getting better.
Raghu N 27:18
Yeah, and whether they get
Jason Garbis 27:20
better, you know, at a 45 degree angle or a 14 degree angle, doesn't matter. So we have to expect and get ready for that. And what that means is there's going to be more patches and updates to libraries. Period. They're going to come more quickly. We have to be prepared as enterprises, because if you think about Project Glass Wing, all these vendors are going to do a bunch of proactive analysis and come out with patches. Great, fantastic. As an enterprise, you know, you still have a good 50 plus percent of the work here. You actually have to now start to deploy these in your environment.
Raghu N 27:52
Yeah,
Jason Garbis 27:52
most, most enterprises are not great at keeping up with the volume, but patches that are coming out today, so if that gets multiplied by, you know, 2345, times, there's going to be a big backlog there, and probably some changes in the calculus of, okay, what are my internal SLAs around this? Maybe you know the level of criticality goes down or up in terms of the threshold for what I apply. When the, you know, the other couple other things to think about are for COTS software, this is probably going to, you're probably going to see a compressed tail of time periods by which, for which vendors are supporting older versions. So, working on the vendor space, right, for when we had customer-deployed software on premises, that was always a challenge. It was always hard to push customers to encourage or incent them to upgrade from old versions, and if every time there was security update, we had to make some internal debates around, okay, do we backport this to the old version, that's going to take this amount of time, there's a lot of work around that, so I think enterprises are going to have to expect probably a fewer old versions that are going to be supported, and they need to build into their process, the upgrades, and then third open source libraries are going to be, I think, a big pain point, because custom applications internally built ones, of course, I would say 97% of the time have a lot less rigor around packaging and updates versus commercial commercial software, so you have to expect as an enterprise that you're going to get a bunch of updates, that security updates that you need to apply to open source libraries, and therefore you need to have a repeatable and automated process, or at least semi-automated, for identifying these, for rebuilding your applications with updated libraries, going through QA and deploying them, that's a real problem, many cases, because you've got lots of custom software that probably hasn't been touched in two and a half years, maybe the person who wrote it left, or they changed roles, and all of a sudden there's a security update that's critical that you have to apply. Now someone who's unfamiliar with the system tries to build it, they do an analysis. Oh, well, we have to upgrade this. Library here, and the APIs have changed, so all of a sudden there's a huge amount of work that is 100 times bigger than they just need to recompile.
Raghu N 30:08
Yeah, absolutely. And I think actually just because, because of that, right? I think the risk here is less so about like what if an attacker got got access to a mythos class or better than methods class model, and they started scanning code repositories for vulnerabilities. I don't think that's the, I mean, that's potentially something they could do, but I think it's more a case of now, like these vulnerabilities are going to be announced, right, because that they have to be disclosed, because you have to say, yeah, and you need to go and patch, right, and I think that announcement of itself is enough to give, like, for the attackers to start thinking, okay, I don't need to go and find a vulnerability, I just need to not, I know that there's a vulnerability, I just need to build the exploit, because I know that an organization is, as you said, right, saying there's a vulnerability saying there's a patch is one thing, but then being able to get the patch out, validated, deployed, that's a problem that still exists, right? And that's the way there's so many ifs, buts, and maybes, because hey, does it work, is it backward compatible, does my application break, all of those things factor in, and I think that's actually the bigger opportunity for attackers versus trying to find a vulnerability.
Jason Garbis 31:26
Yeah, and I think there's going to be the, I guess we'll call them fast followers here, right, that do exactly what you say, and they're banking on the fact that there's going to be this long tail of enterprises who have this vulnerable, vulnerable version of Library X, and have not gone around to updating it yet, so the attacker can scam for this externally or internally, and then say great, and then take advantage of that, that vulnerability, which, of course, leads us to our, our favorite discussion of segmentation and micro segmentation, right.
Raghu N 32:01
Of course, of course. Hey, this is a thought leadership podcast. We don't deploy what Illumio does, right? But yes, yes, we do segmentation. So, and I think they're like what we're landing on there, right? Is is that, however, which way the attacker leverages the capability of these models, right? What is true is that the asymmetry is increasing between the attacker's ability to act at speed and scale and the defender's ability to adapt at speed and scale, right? Because I think I think like the defender still has all of those considerations that unfortunately we can't automate our way through, right, because it does require validation. It does require that human in the loop.
Jason Garbis 32:48
That's right. That's right. And I think there's really, there's two levels to that, right. There's kind of the operational side of things, which is okay. I have a bunch of systems that are running, I have log data that's going to a SIM, and I have a security operations center with some combination of human and machine analysts, and when things questionable things happen, there are almost every organization put does put deliberately puts humans in the loop for most, if not all, decisions. They use these tools to help perform analysis, and I think over time they will be more comfortable with having those machine systems do more automated elements, but they do certainly have humans in the loop, especially because no one wants to have a false positive and disrupt user interaction. Right, you're correct that you know the attackers are leveraging much more automation, and they don't have to worry so much about proceeding slowly.
Raghu N 33:45
Yeah, absolutely. So, which then brings us onto, and I think that one of the things that I've quoted so often over the last few weeks is this incredible bit of like research or recommendations that the Cloud Security Alliance have put together, building a methods ready security program, which is incredible in terms of the quality of it, like, of course, the community that came together to create it and get it out so quickly. I feel it's like the authoritative piece about how organizations should start thinking about their security programs. I mean, my first question is this, right? I've looked at who's on the list of contributors and authors, how did you get all of these people to work on this so quickly and get something out that is so usable, like it's amazing, so well done. And tell us, what was the magic?
Jason Garbis 34:33
You know, it's it's really leveraging the very vibrant community within the Cloud Security Alliance, and the connections that some of the leadership there has to really get everyone kind of in a, in a virtual tiger team, and say, okay, let's jump on this, this is something that's happening very quickly, and you know, how do we, how do we put together some guidance here and get all these people behind it?
Raghu N 34:56
Yeah, and by the way, for those of you who haven't yet seen it, we will put a. In the show notes, highly recommend going and checking it out, and sort of having that conversation with your, with your security leadership, because there's some incredible sort of and very practical guidance, but I think for me, more than more than anything, that I love it being repeated is an increased focus on the basics, right, and I'm just, just because I've got it here. I'll read it to you. That the basics remain valid and can be prioritized for risks that cannot otherwise be mitigated. Segmentation, yay, patching known vulnerabilities, identity and access management, and defense and depth breadth all increase the difficulty for attackers to lower latent risk. Expanding these efforts while there is time is prudent, and why I like that, because I'm kind of like a back-the-basics kind of guy, when it comes to cyber security, is that I think what it really focuses on is that as it's like as technology continues to evolve, ultimately sort of attackers, sort of tactics, techniques, and procedures continue to sort of relatively be the same, right, and so focusing on those basic controls is continues to be important, and probably more so than ever before,
Jason Garbis 36:08
for sure. For sure, it's it's the fundamentals that are not changing, and we should not expect them to change. Right, these AI systems, I mean, we're limited by what the software does, and you know the laws of computer science. Right, there's no gigantic new class of attack methods that we're not aware of. Right, we are, as an industry, well aware of those, and we know how to defend against, I would say, every single one of those. Some of those are harder than others, and some of them are more complex than others, but having in place good governance and well-defined processes around every element of an identity lifecycle, a device lifecycle, workload lifecycle, data, et cetera, having clear visibility and having multiple layers of defense. These are things that we know work, and you know it's not free, and it's not necessarily easy, but this stuff pays dividends, and when you do this, you know at least reasonably well. What you do is you're limiting the blast radius of an attack, and you're turning these things from what could be a major incident into an afternoon's problem, a small issue that you deal with, and you know no one likes it, but two, three hours later, like, okay, this, this is fine, versus some gigantic enterprise-wide thing that takes months and millions of dollars to deal with.
Raghu N 37:25
Yeah, absolutely. And one of the key things in there is also in the recommendation of the Cloud Security Alliance, is prioritizing a Zero Trust strategy. So, what does a Zero Trust strategy again in this post-Mythos world look like, or is it zero for strategy, and it's now more important than ever.
Jason Garbis 37:45
It's, I think, there's certain elements, and I, the, I do recommend that folks take a look at that, that CSA document, because there's some really good specific advice, advice in there. I think if we look at things through this, this post-mythos lens. Okay, now we have to anticipate more vulnerabilities that are going to be exploited and disclosed, you know, faster patching, etc. If it highlights both the need to be able to react to those in terms of having the patch processes and having a mechanism to do a faster set of triage and make some rapid decisions around which ones we're going to apply quickly and which ones we're going to apply slowly, but it also really, to my mind, highlights the need to put in place better segmentation on the network, which, of course, is based on getting visibility into who should or what identity should have access to what, because when you do that, you're immediately reducing the blast radius, we've seen this time and time and time again, so many vulnerabilities that anyone with network access to a system can send maliciously crafted packets, exploit it, and then they're off to the races, whereas if you put even let's say coarse-grained segmentation in place, okay, this is a finance system, this is the web UI to the finance system. Instead of putting on the flat enterprise network, where all 5000 users and devices can access, let's just restrict it to people in the finance group. Is that perfect? It's not. It's a really good step forward. And now immediately you've reduced it to the 200 people in the finance group as the entry point to the network, you still have to patch, but that's a significantly reduced issue there, and it allows you to now prioritize this down versus lower than other things.
Raghu N 39:31
Yeah, I often think about sort of adopting a Zero Trust approach and putting it into practice as very much about ultimately about reducing your problem size, right, is like to something that is far more manageable than it was before, and removing implicit trust, moving towards much more explicit trust, allows you to be very deterministic about, okay, like, if the attacker does get in, right, how far could they realistically. Go, I have a much better handle on what my likely exposure is going to be versus if I have a lot of implicit trust in the environment, I have a much lower, smaller handle on that.
Jason Garbis 40:10
That's right, that's right. And there's one of the things that I like to do is encourage people to think about getting to a point where security becomes a byproduct of operations, and the service test ticket giving an admin access is a good example of that, but even in terms of let's say software release deployment processes, it's another where you want to have something in place where someone can't deploy commercial software or an updated version of custom software, unless you would, you would raise the bar here unless there is a documented set of network connections that are going to be allowed and expected, both inbound and outbound, that gets put into a machine-readable system, and now it can get enforced in your environment. Now that takes work, right? There takes some discipline to do that, and what I recommend is that people put enterprises put in place processes where starting today all new systems are going to have to follow this process, so you know today we have zero systems that follow up, tomorrow we'll have one, next week we'll have three, and over time that number is going to grow. Second is to put a, you know, put a timeout or a timer on every other system in your environment where once a year, or once every 18 months, whatever the right number is, that system has to get refreshed. That does a number of things. It makes sure that for custom applications you can actually rebuild it. So many things they don't. It's a manual process. So making sure that you can do that in an automated or at least a semi-automated way is really good discipline when the next patch comes in. Second, is it spreads this work much more thinly across a 12 or 18 month time period, so that you're not giving all these teams some giant pile of work that's going to take them weeks to do, you're giving them this very thinly spread pile of work, if you will, that takes an extra hour a week or something like that. Yes, it's a workload, but it becomes much more manageable, and every time they do that, things get better in the environment.
Raghu N 42:06
Yeah, I love that sort of.. I think that's sort of great, great advice, and a great point to almost wrap up the conversation. So, before we wrap up, Jason, you are the latest in a long line of Zero Trust luminaries that we've had on the segment, and each of them has shared their favorite Zero Trust analogy that they've used to sort of communicate Zero Trust to whoever. What's your favorite Zero Trust analogy?
Jason Garbis 42:33
So this analogy is, I think, one that we've seen enterprises use to communicate to non-security, non-technical stakeholders, and you might want to close your ears, John, but not everyone likes the term Zero Trust. I would say, in about 30% of the enterprise, is they deliberately decide we're not going to call this initiative Zero Trust, we're going to call it something else - workforce transformation, modern identity, password list, whatever it is, because there's for non-technical, non-security users, right, there can be some negative connotations of those, those terms, so the analogy is we really like an automotive analogy where we look at this and you don't, you don't use the words Zero Trust, right, this is all about for us as as the enterprise, as the CSOs organization, we're providing for the enterprise, for the car, the brakes, the oil, and the seat belts. Right, so the brakes let you drive the car fast. You can go as fast as you want, but you, the driver, you got to apply the brakes, right. We're giving you these fantastic brakes, but you got to use them, so you don't crash the car. This is a way for let you drive fast. We got oil, the oil lets you run the machine, you know, hard and fast, and get a lot of power out of it. But you got to, once in a while, do some maintenance. We got to change the oil, right? You got to pause and update things. The third are the seat belts, right? That's on us. We're going to make sure these seat belts deploy and keep you safe every single day? All you got to do is put them on, so it's a really nice way of illustrating, first of all, a metaphor that everyone understands. Second, this combination of the shared responsibility - you've got to operate the brake safely. If you run and go straight into a wall, I can't really help you with that. You got to pause once in a while and do some work, some very basic maintenance work to keep things running smoothly. And then there's some stuff that we're going to take care of for you. And when the seat belt clicks in, when your machine gets quarantined because something bad is happening, this isn't a bad thing. This is actually a good thing. This is a system working as design, and maybe should.
Raghu N 44:40
I love that, by the way, and I think you should add to it, because we also know that you're sometimes you're going to forget to forget to tap the brakes, and sometimes you're going to forget to switch the oil, right, and that's why we've got the seat belts to make sure that the impact is less than it, that it could have been. Jason, it's been a pleasure to have you on. Here, thank you so much for your time, so much for your insights. I've loved this conversation, really appreciate it.
Jason Garbis 45:05
Thank you, Raghu.
Raghu N 45:07
Thanks, thanks for tuning in to this week's episode of The Segment. For even more information and Zero Trust resources, check out our website at illumio.com. You can also connect with us on LinkedIn and Twitter at Illumio, and if you liked today's conversation, you can find our other episodes wherever you get your podcasts. I'm your host, Raghu Nandakumara, and we'll be back soon.

