Hey everybody, we're going to give it a few minutes before we go ahead and get started. For those that just joined, we're just giving it a few minutes while we wait for everybody to get on the talk. I think we have a bit of a quorum now here. Join Mike. Yep. Probably kick it off. Yep. So we'll go ahead and get started. We'll start off with some quick introductions. My name is Michael Villar. I'm the Director of field Security Technology at Akamai and I'm relatively new to the organization. I spent actually most of my career working in the financial services industry and most recently I served as principal engineer for Wells Fargo. And as part of my role there I was responsible for micro segmentation strategy, globally. I also served on various different committees, centered around Zero Trust and Network, Security. Prior to joining that role in Wells Fargo I performed similar functions. I was doing Director for Network Security Architecture at ubs focusing on some of their programs, micro segmentation and network security architecture for Deutsche Bank. But I've been working with microsegment, technology, and various engineering roles, and leadership roles since about 2016, 2017. So I've had the opportunity to really get a good take on the direction these products are taking, different solutions that are out there and things that from a strategy perspective work for us and really haven't. I'm joined today with Jason Aguiad. He'll be, he's an sc. I'll go ahead and let you introduce yourself. Jason. Yep. So my name is Jason, I'm a principal solutions engineer. I have been a part of gardacorps since before the Akamai acquisition and primarily focusing on our financial services vertical and supporting those customers. But I have advised a number of different industry verticals around segmentation and their zero trust strategy. So look forward to kind of speaking to you all today and have a kind of Michael lead the conversation. If you have any questions, on the right hand side there is a question and answer bar. I will do my best to to try to answer those questions in there and then we can also raise them to Michael if we want at the end and and have his opinion around what he's seen in real world implementations. Great, thank you. Go ahead and pull up the slides to get started. Thanks again everybody for joining us. This is Endpoints to End Build. You'd micro Segmentation defense. Again, I'm Michael Villar. I want to talk a little bit about what micro segmentation is and why it matters.
So micro segmentation effectively allows you to enforce policies and rules either at the workload or very close to the workload. It's a granular control and it allows you to restrict east west communication, but it also can allow you to incorporate the north, south, communication just the same. You can specify rules for individual servers if you desire. The capabilities kind of exist to do that. Absolutely right. So you have a way of compartmentalizing your architecture, your state, your different environments depending on what makes sense for you, and placing those controls where you need them. To simplify the process, we would want to create compartments that are based off of logic, context, either environment or multiple different contextualized asset tags, things of that nature to help understand what we're trying to create boundaries around. So kind of like you would see in the image on the right, a ship, different decks, different kind of environments that you want to cordon off. These are all things that can sit behind a firewall. Right. So this is a much more localized area of control and it's not necessarily something that would replace your firewalls, but kind of close the gaps between them. Right. Kind of like the spray foam inside of some construction. So what we're doing is we're essentially making the control like the blast radius controlled. We're making the enforcement areas much more restricted but at a much closer area to our individual workloads. And it can replace or reduce the fire in some circumstances. Right. If you're using firewalls for east west, I mean that's a lot of overhead. This is something that's going to sit even closer to the workload and it's something that's scalable and can be orchestrated with.
To give you a better idea of what that kind of looks like in a traditional environment we have on the left, there's no lateral movement controls whatsoever. And in a ransomware situation that's one of the most common use cases for micro segmentation is the, is aiming to reduce that lateral movement. So even if you're behind a firewall and something was to get it get inside and propagate within that network segment, there's no way to restrict that without having some sort of micro segmentation control, something that's actually controlling things on the east to west on a workload to workload, kind of basis. Right. So ultimately some workloads should probably never talk to each other at all. Would want to restrict that. And the only place to really restrict that would be either, you know, directly in front of the workloads or at the workload itself. But we can be further restricted based on not just port and protocol, not your traditional network, oriented controls, but you can place restrictions on other kind of logic as well. Right, so ports and protocols, but what about processes and binaries? If I know that an application front end is only going to receive inbound traffic over HTTPs and maybe perhaps it's, you know, we're expecting to see something with you know, Java, or we're expecting to see, you know, specific web traffic, we can restrict specific web traffic, we can restrict that further. Right. So it's not just talking about lateral movement on important protocol basis, but also the basis of which the function exists for that, for that workload. Right. If you're not using Samba SMB, why should we have that enabled? Why should that, you know, be allow a method for propagation of ransomware? If you're not using Telnet, let's block it. If you're not using RDP or RDP is only done by the engineering team's jump boxes, let's block it.
So while preventing the spread of ransomware, that's a extremely common use case. There's a lot of other use cases that exist and you'll, we'll talk some more about that as we dig into it with some better examples. But the best way I can put it, and probably the best exercise that I've recommended to understand what these use cases are beyond the zero trust use cases, beyond the regulatory cases, beyond the regulatory compliance, you know, and the audit use cases and critical infrastructure identification and isolation and all the visibility and enforcement use cases, you know, environmental, you know, separate prod from non prod. If you look at your cmdb, right, And I'm not talking about understanding, the data quality there or trying to, you know, discern whether, you know, this is a good method, to use this data. Just look at the attributes you have in your cmdb. What kind of aspects do you use to qualify a, piece of infrastructure when you bring it into your organization? Do you measure and you track their environment? Do you track the lifecycle, do you track the location? All these different criteria, they have some sort of relevance to security. It's a decision that you make. And if you take all of those attributes that you have that you would typically require to input into your cmdb, when you bring something on board and just ask yourself the question does this attribute, does this value, does it have a meaning for security? Does this mean something? Do we want to make a decision, a security decision, to determine access based on this attribute? Does environment serve a purpose in that discussion? In most cases, yes. And that's an exercise that I recommend because when you find everything that your security team, can unilaterally agree on, these are things that are relevant for security. You've kind of defined your structure of your enforcement structure. This is what you're going to kind of contextualize your environments based on to understand where you want to put your controls. So if you want production to only talk to production, and you want App A to talk to App A, that's the basis of your policy so you can get a better understanding of what you want to build and structure your use cases around. It's not just a matter of, you know, picking an objective and trying to go at, at it directly. It's about getting a better understanding of, you know, what your organization perceives as risk and incorporating these types of things help understand, like where you might have some, areas that are weaker on the data side and areas that are stronger. And there's different methods that we use and can be used to help, bolster that. But that's probably the best exercise I've seen to really get a handle on what are we trying to mitigate from a risk perspective and what are we trying to decide on for traditional, micro segmentation use cases?
So there's a generalized structure, well, with how we go about and how most organizations should go about, implementing controls around ransomware, around micro segmentation. And this is kind of what we do at a high level. And fundamentally it starts with visibility and understanding your environment, how your environment communicates. And that's done with either orchestration, but primarily with the Gardacore agents. So software agent that's deployed on your workload that collects telemetry. And the telemetry isn't this heavy netflow, tons of overhead, that's a lot of unnecessary data and bandwidth. It's a lot of times it's not scalable. Right. The agent telemetry is really stripped down to the network data that's needed and then further enriched with the data that we have from the agent that the system is operating on. So something that's really well defined there. Furthermore, overlaying the context around this, either through, labeling, AI labeling or labeling from data that we're collecting from CMDB or just even manual labels, that helps Paint a better picture to understand how these things operate. Once you have that basis and you're able to visualize this and collect this data historically and understand what's changing, what's not changing, we can start defining rules, right? So if we know that every hundred days the we've collected all the telemetry for something that includes quarterly processing or any type of quarterly batch processing, month end processing, we have a really good understanding of the frameworks around this particular application. It's much easier for us to lock that down. The longer we collect data, the more accurate these policies can become because we can take into account some of the outliers and we can also see things that maybe perhaps we weren't anticipating as well. And that's when we start moving into the segmentation and the control aspects is defining those rules and how we want to govern them. And there's a lot of different ways that we allow you to do that. And it depends on your use cases, but it also depends on what your objective is. So if you want to go with a zero trust approach where we're looking at individual applications, we want to lock down any inbound traffic to that application or outbound, we want to lock down even in intra application traffic to make sure that, you know, your three tier use cases app, A database is not allowed to speak out to the web. It can only receive inbound communications from the application tier and then the web tier. That's the front end. Those are things that you can, you know, move towards but just as easily. You can also incorporate kind of guardrails and higher level frameworks just to reduce your risk. Right, reduce the attack surface. And that's done by defining things like you know, hey, we don't want to allow the propagation of SMB. We don't want things to propagate over that. We don't use telnet, let's block telnet. So there's a lot of ways to go about this. You certainly could do both at the same time, but that's when you really are starting to control, at a granular level, access to your different environments.
When you talk about doing this at scale and operationalizing this at scale, it's important. And we take a lot of care in making sure that the tooling is there to allow you to do this. If you're looking at every server in your environment and you're controlling it in a granular way, that's effectively turning every server into, into a firewall and at an enterprise that might have 100,000 workloads and, you know, 2,000 firewalls. You know, the team alone to manage all these firewalls is substantial. These are people that. You have an entire department that's dedicated to doing that. So what kind of department would you need to do that for 100,000 firewalls? That's. That's the question. That's why the orchestration piece and all the tooling is extremely important, the modeling design, to make sure that you can actually derive the outcomes that you're looking for at scale. You can collect all this data at scale. You have the capability to store all the data that you need to perform the logic for enforcement. You can collect that and store it historically. And you're not taking any shortcuts. You're not building a monument to compromise where you're only collecting portions of the data. And once you've established that and you have something that's foundational, that's able to be, you know, persistent, let's move into the detect and response thing. These are things like anomalous traffic. These are the outliers we want to not only take into account we've locked things down, but how do we further understand and respond to situations? If you're seeing a bunch of traffic that's trying to exit a server, we haven't seen that before, it's trying to use a protocol that hasn't been used. We're seeing it's being blocked. Why is that happening? Is it a misconfigured application? Is it something that's on the destination that's misconfigured? Or is this application somehow impacted, or, compromised? Trying to do something that's not supposed to do. And that's where we move into the final stages. More of the end state of the zero trust piece with the detect and respond aspect.
Michael, we had a question come in. In a mature zero trust architecture, where do you see micro, segmentation actually deliver the most bang for the buck? You're talking about east, west, you know, traffic isolation. You talked about telemetry. I know we've been a part of a bunch of projects where, you know, different organizations, you know, garner return differently. What would you see, as. As kind of the, the biggest bang for the buck when we look at microseg? Yeah, I mean, so it depends on your, your frame of time. Right. So, you know, if you're, if you're able to build out a really mature deployment and you're able to get things really granular and have correct automation, everything. I mean you can eliminate a lot of the east west controls, with firewalls, right? At that point it's more of like a rate limiting thing and fault domain but from a strict security aspect, you have granular level controls on things. If you automate things when the business is deploying something, they have control to be innovative. Right? So it's a mature deployment, allows more of a frictionless time to market with the business. And that's always been the biggest challenge is like how do I make the business you know, be innovative to be able to you know, be effective, make changes and you know, get their code deployed in a secure way without having them submit a firewall rule request that takes you know, two weeks, three weeks. How do I make sure that their time to markets improved? So I mean when you're really like looking at from a dollar perspective, we want them to be secure, we want them to be able to do this effectively and you have to kind of do that at a really low level. Right? You need to do that at a workload level to have that efficacy and you need to have the orchestration and the operational capabilities to to allow the business to execute on that. And when you tie it all in together, you're able to, to stitch that together and still deliver on the, you know, the business promise of, you know, generating revenue, doing whatever it is that your company has to do, but you're not compromising on the security of it as well. And I think that's the biggest impact that I've seen with micro segmentation is the ability to do that and answer the questions of, you know, how does my application function in a regulated environment? Our platform owners, they have to attest to these things. They have to responsible for it. They're taking, they take risk every time that they recertify their rules when they don't know what they are and that needs to stop. Right? It becomes a, it's a useless endeavor where you know, they're taking responsibility for things that they just don't have control over and they don't know about. And rather than, you know, continue to propagate that and not get any value of it, let's make it real, let's actually, you know, make these types of internal auditing aspects functional. And that actually provides some practical security to the organization. I'm a big proponent of moving controls closer to the endpoint regardless of whether it's micro segmentation or otherwise. Placing the controls closest to the Endpoint gives you the granularity to do that and it kind of has to start there.
Okay, and how would you. This leads into kind of another question here and then I'll let you continue on here. But how would you start that if you don't have any controls in place today? What would be kind of your approach to moving towards the micro segmentation in a production environment? Yeah, so I mean the visibility aspect, that's, you know, that move me into my next slide because we'll talk about discovery and things like that and I'm going to give you some examples of some use cases that I've encountered that might help. I've been part of programs where the expectation is that we're going to bring them to a zero trust micro segmentation enforcement state at some point. Right. Whether it's three years, five years, seven years, whatever the case is. As we went on this journey, my main focus is like, let me have as much telemetry and visibility as possible because I know what's going to come next. As soon as I'm able to understand and discover the communication patterns, questions will come up and people will bring me questions. So you'll have your base use cases like I don't want my non prod environment to talk to prod. Like that's this common, common use case that we see. It's a, it's, it, there's, there's requirements around that for regulated entities. But there was an organization I was part of where we're just, I'm building out security, our security policy structures and I have agents deployed, I'm collecting telemetry and I'm just digging around, just seeing what, you know, what kind of traffic. I'm categorizing things, seeing if anything sticks out. Just you, you know, normal daily, just working with the platform. And I see something that I didn't notice before. There's a huge amount of traffic that was going over DNS out to the Internet. I looked at the destination, the destination is going to a government address. That is the weirdest thing I've ever seen. I have no idea why this is happening. Has it happened historically? And I checked for a few weeks, nothing. I go back a few months. It happens at the end of every month, but it's over. DNS doesn't make any sense. Start looking at what the platform is. Reach out to the platform owner, find out he doesn't know. Reaches out to his engineer. As it turns out, that's a reporting server and they couldn't figure out or they couldn't get the firewall rules put in place for them to send the reporting data to the regulator in an appropriate way. And the engineer figured out a way where he was able to basically use the same techniques that you would use the same techniques that you would exfiltrate data over DNS to send reporting data to the regulator. And it blew my mind that we were actually doing this in a regulated entity. So at that point it's like, okay, there's so many questions that I had, that need to be addressed. But it tells me that first of all we have an operational issue with how we're handling these things and the firewalling aspect of it, the time to market with that, that's a problem. The fact that they were able to send this data out and it was somehow accepted in that way, that opened up even more questions. We needed to fix this and address it. And became its own, you know, its own project. The use cases, you'll discover them as you get the visibility and as you start looking at some of the circumstances. When you start trying to look at, you know, a cyber use case and try and contextualize it with the network traffic, you'll start discovering things traffic, you'll start discovering things like, you'll find your weak spots. You can start with the structure of like, I want to separate, you know, things based on application to application, or I want to just reduce my threat surface and just block high risk ports. Those are all viable ways. But as you start going through the process and start seeing the actual traffic, you'll start recognizing patterns that don't make sense, that indicate that we're doing something wrong as an organization that needs to be addressed. And we didn't recognize that until now. And I guess that's probably what, that's what usually happens. You start with the best intentions of what you want your end state to be, your North Star. And as you go through it, you have to have the flexibility to adapt because the data is going to tell you a different story. So I hope that kind of answers, like the getting started part, it really gets started with the telemetry and the visibility and with an idea of what a North Star is going to be as far as like placing the controls and but at a minimum I would start with, if you don't know where to start, start with at least you know, getting the data, getting telemetry and then let's just restrict things, restrict some high risk ports. Start with, you know, reducing the attack surface and figuring out what's going out to the Internet. And whether it should and is the volume expected or not. Right.
There, there's other use cases as well that these are all the things that came up that have nothing to do with micro segmentation enforcement. And I think that as an industry it gets overlooked way too much. But there was another organization I was part of and we were doing cloud migration. Right. And visibility during cloud migration, super helpful. Understanding the dependencies, that's extremely important for cyber resiliency and extremely important for cloud migration. They ended up moving a data warehouse over to the cloud and what they didn't know was there was tertiary dependency. And that resulted in a lot of that data having to get pulled back on prem. It spent a tremendous amount of time and effort to do this entire migration of this data warehouse to the cloud. And had they asked me, ended up asking me after the fact. But had they asked me in the beginning I would have been able to highlight that for them. We ended up having to move that data warehouse back on prem and this stuff cost us millions of dollars. It's just we're burning it, lighting it on fire essentially because. And we're wasting time, wasting operational resources and engineering resources. This is the kind of things that it's, you know, the visibility really, really matters. And it doesn't just matter for micro segmentation, but if you have the capabilities of understanding these things just to answer these questions, then you have the capabilities to do enforcement around them too. Right. To mitigate other types of things.
So this goes into some other circumstances when we talk about the understanding of these connections. And I do want to spend most of my time on the understanding part because I think that's the most important part of this platform. Micro segmentation is an outcome. It's an outcome. There's other outcomes that exist as well. They just don't make for good KPIs. That's the truth. And they're hard to come up with those KPIs when you don't have the visibility. It's basically chicken and egg thing. But at another company I was part of, we had a I got a phone call and subsequent email about something that we're blocking. Right. And it was our partner that handles our infrastructure management in our data centers and they were saying that they can no longer connect to our systems for patching. That was news to me because they were not allowed to do any patching on our production systems, period. They were not even, you know, that wasn't part of the agreement. It wasn't part of the contract. And quite honestly, I'm not sure they were even allowed to do that in some countries. So, that was news to me. Asked them what they're talking about and they gave me the name of the server. I dug into it. It's like this server was decommissioned. What do you mean you're using the server? They explained to me, well, actually, when you decommission a server, you know, if it's a good server. Instead of, you know, you know, repurposing it or whatever, we repurposed it for ourselves and we put it back on the network. And then we use that to kind of, serve software to your production payment applications across your entire production environment. And that blew my mind because there's so many rules that were just broken here and we didn't know that that was even happening. So what that meant for me was my structure for my policy changed. Instead of saying, you know, writing a policy says app A can talk to app B over this port and protocol. Using this process, it became App A when its life cycle is active. Can talk to App B when its life cycle is active. Just that one label incorporating that. That was a use case. That meant that I'm locking things down based on life cycle. And nobody talks about that because that's never really a consideration. But it really mattered because I didn't recognize that as an attack vector, somebody could repurpose something. I thought our controls were better around decommissioning. They were not, hafnium, when that, when that was attacking Exchange servers, you know, it's a, you know, fire drill zero day. We're going through that entire exercise and at the end of it, you know, Cyber reached out to me. They asked me, hey, we heard you have this platform. You get some visibility. Can you, help us understand if, we've patched, all of our systems. So, you know, we had Gardacorp. I did a query with Gardacorps insights. It's basically Osquery. It's going to be able to tell me what's been patched and what hasn't been patched. I cross reference their numbers because they're reporting this on an hourly basis to the c. So showing that we patch the systems or not. I said, your numbers don't match my number, so I don't know what the delta is here. And they're saying, well, one thing we notice is that we're patching, one system, but when we scan it to determine whether it's been patched or not, we're getting a response back and sometimes it says it's patched and sometimes it's saying it's not patched. And now I was like, that is the most. That's insane. What's going on with your scanners? And they gave me the IP address. I pull up a map in Gardacore, I'm looking at it, it's like, well, that IP address is not a server, that's a vip, right? That's a load balancer. And why are you scanning the load balancer and not the actual IP address of the endpoint? The workload that you're looking at, there's multiple exchange servers behind it. It's round robining the traffic and that's why you're seeing it. You only patch one of the servers. So they fixed that. We were able to get everything patched really quickly. But then it opened up the other conversation, why is our vulnerability scanners, why are they scanning vips? Why are we doing that? I mean, sure you can scan the vip, but you also have to scan everything behind it too. It became a whole nother initiative. Right? These are the questions that I was able to answer and really start figuring out the appropriate way of going about this thing. And there's not going to be a KPI, you know, nobody gave me, you know, a high five or a pat on the back or certainly not a bonus to, you know, that we demonstrated that capability. It's just the reality of when you start understanding, how your, you know, environment communicates that goes well beyond the micro segmentation out, but that one is micro segmentation outcome. Yeah, it's really important. I'm just saying that understanding your connections, you'll start understanding the use cases and those might result in different conversations that have nothing to do with what you kind of intended to start out with. And same thing with the cyber resiliency piece as well. That's going into topics around what are the dependencies on something. And there's, you know, banks have regulatory requirements for those things as well. If I were, unplug a server at random in your organization and it's critical, how long does it take for this to come back online and what are the dependencies, what else is impacted? Very easy to understand that if you know what, you know what's talking to what and you know, I saw millions of dollars getting pumped in building custom applications when, you know, on the network, in the microsecond program, we have this data right at Least for the vast majority of our estate. So the use cases, they'll, you can preempt them, you can adapt them, you can incorporate additional ones. But fundamentally speaking, it starts with visibility. And you have to have a mindset around flexibility when you start going to these programs because people will find out that you have this data and they're going to ask you questions and those questions may result in an entirely separate conversation, that you weren't anticipating.
So going into the actual control piece, the micro segmentation piece again, we can define rules based on those use cases, right? We can define rules. And for me, the way I like to look at it is the context that we provided. The labels that we use, those are use cases, Right. If I define a label that says environment, production and environment, lab, environment, non prod, that means I'm doing a use case for separation of environment. The more labels we add, whether the data quality is perfect or not, it'll work itself out because we're overlaying the telemetry with the data as we understand it. So you're taking the way your company actually communicates and you're overlaying it with the way you think everything is, identified and where you think it communicates. And when you look at that in a map, it exposes data quality issues quickly. And if you have to prune something out because it's not good enough data, you can, it doesn't have to be perfect, it just needs to be able to, you know, it needs to give you the visibility that you need to understand where you might have gaps. That's a more traditional approach, app based or inter app based communication restrictions. But at a high level we're talking about really reducing our attack service. So if you wanted to create guardrails, and this is something that I've done as well, let's block some high risk ports to start or let's just create an entire framework of what apps are allowed to do and what they absolutely cannot do. And we control the guardrails, the CISO organization will control, or network security will control the guardrails. At a granular level, we hand that over to the application owners and let them control what their application does and attest to it and be able to self service that. Right. That's an option too. Different structures around how you want to define and perform your policies for the organization. But it has to be kind of in concert with what you want to do from a governance perspective and an audit perspective. Right. What happens sometimes is you start out with the mechanisms for how you want to control traffic. When you get to the actual operationalization, you run into those roadblocks because you haven't considered what this is actually going to look like when you start doing it at scale. But going back into some of the control aspects, if you have the flexibility to do that with this platform, you're able to take different approaches with it. It doesn't mean that you're going to have a false start, right? You're not going to run into an area where we just can't do some sort of enforcement. So Gardacore has things like, you know, templates and things that allow you to get time to market with, you know, just general risk reduction like this. This is things that, you know, it's like general upkeep. We don't want to use Telnet, we don't want to use, we want to spring fence some of our, you know, critical infrastructure or core assets, active directory, things like that. So kind of get you better time to market with that. Locking things down where it matters most, where it has the most impact. You know, if you compare like a critical banking application or critical, your crown jewels, locking that down versus locking down, you know, 20 low risk apps, one may have more value than the other. If you look at, you know, how the organization generates, revenue or performs their critical functions and their, you know, core business functions, right? So sometimes there's a different direction you can take. But what matters is having the flexibility to do that and having the capability and the platform to let you make those kind of accommodations quickly.
And that leads into some of the topics around like continually adapting. So your organization is going to continue to change, right? And your enforcement models need to be in alignment with that. And you need to be able to kind of report, on that. You need to understand, like if your organization changes and you're seeing that your expectations around threat reduction are not there, that matters a lot, right? If we're seeing that somebody is, you know, trying to bypass something or things like that, we need to be able to accommodate that in the platform and be able to recognize it quickly and at a high level so that we can make adjustments accordingly. And that's kind of what, you know, what you want to look at when you're talking about like a mature implementation, especially if you're talking about a scenario where your enforcement's centered around just general risk, reduction, you know, just so you can kind of like attack surface reduction and spread, and I don't know if it's really easy to see on this slide or not, but when you look at protocols like RDP and things like that and so some of the, like the high risk things want to be able to measure the efficacy of the, of able to measure the efficacy of the, of the policy against those things. And you know, if there's changes in your organization, be able to recognize those and adapt quickly so that you're staying kind of in concert. So if your you know, environments are being migrated and things are being moved, new applications are being spun up, you know, measuring the efficacy of your policy and measuring the efficacy of the different enforcement capabilities, that's going to be absolutely critical to make sure that things are going to be sustainable and maintainable. Right. We don't want your policies and all the hard work that you put into just to kind of no longer be valid because maybe somebody left the organization, things like that. So having those capabilities incorporated in the platform and part of the planning as you go through it are going to be really important.
And at least in my experience at these banks, it felt like the enforcement and all the hard work that we put into locking things down really truthfully it's only as good as I can prove it, right? I can do a lot of different types of work to help reduce the risk to an organization but unless I can quantify it and really demonstrate that or provide those types of insights up the chain, it really didn't mean a whole lot. And so the reporting capabilities and being able to tie that back to the actual risk and findings and the different kind of like high level indicators in a way and in a format that I can present that up consistently. That's going to be really important. Especially if you have something that's driving micro segmentation for you that is you know, a board level initiative or an executive level initiative that you need to build a report on progress and demonstrate anything that's stands out really quickly. And that's going to be really key to the success as well. Otherwise it comes in, comes the conversation around, you know, are we getting value for what we're paying for? And you know, as I discussed earlier, sometimes it's hard to really quantify the value when you're answering those complicated questions. It's not a KPI, but if we needed KPIs and we want to understand things, at this level, you know, that capability is here, it's there and it's going to be important regardless of what direction you choose. You're going down that path of micro segmentation.
I'm going to go into some of these slides and I'm going to talk about not so much what we have, but why we have it. Right? Because otherwise it's just a pitchy proposition and I don't really appreciate going down that path with it. But. AI labeling, right? The reason why AI labeling was incorporated into Gardacore and Akamai is using this is because there's a tendency for companies to have false start, where they are just not able to get over that hurdle into enforcement. But because they have an issue with data quality. And there's a lot of things you can do to fix data quality, but fixing data quality prior to having to do enforcement, it's gonna be extremely time consuming. That's problematic. Right. So going back to, we've enriched with the data we have. We know that the data we have is not that good. But we see our telemetry, we see it contextualized, but our data just is not great. This is something that you can use to help with the data quality issues. This is something you can use to give you some real practical detail around what these individual workloads around what these individual workloads and what these applications are doing so that we can distinguish them better. Right. And we can make decisions on them better. This is a result in solving the problem of the false starts around data quality. That's what AI, labeling was there for. That's why it's created, because that happens. And it's a shame because you put all this effort into a program and you just can't get over that hurdle and demonstrate the enforcement mechanism.
The next piece is essential policy. This kind of builds off of that a little bit. Companies struggle with expediting their enforcement mechanism. Right. And this comes through. It could be governance issues, it could be policy structures. Changing a policy and a control at a bank could take a tremendous amount of time. So this is going to expedite that for you. This is going to create some baseline risk reduction, early enforcement. Let's reduce our attack surface easily, effectively. Broad strokes, right? So helping improve time to market, helping reduce risk without putting you in a situation where you're overwhelmed with operational overhead because your teams are not prepared to take this on yet. So whatever reason resulted in not being able to get time to market, this is going to help expedite that. And that's why this was built.
This is the final slide. And this is around the Hunt Service. Right. So the research That I did in this platform. Not every organization is going to have somebody that's going to be able to dig into this and look at the flows and be able to analyze things. This is a white glove service. This is an extension of the Akamai, Cyber Threat Intelligence team. Right. So kind of like hiring somebody to do a lot of that heavy lifting, to put together reports to understand exposure management, to help provide remediation recommendations. This is what, what that is an add on. You can add. If you don't have the internal capabilities in your organization, you don't want to take all of that on or you need somebody to help, you know, guide you as you go through it. That's it solves that problem. This is solving the problem of I didn't have enough resources to help with, with this, deployment or I want to derive some other type of value. And I want a turnkey. Right. So that's the micro segmentation strategies, the use cases, most of everything in a nutshell. And I'm gonna go ahead and finish the presentation there for the live attendees before we go in. Q and A for live attendees. We'll be reaching out to you, using the email you register with with details, about your gift card. And with that we'll go ahead and move to anything that's left in Q and A if there is anything.
So no questions actively in the chat. Let's let's give it another minute or so to see if anything pops up. Sure. Most of it seemed to center around how do you start a program, program that we, we addressed and then kind of where you're, where you're getting your return as it relates to zero trust and things like that. But ultimately, if I summarize kind of what I, what I think I heard you say today, Michael, the, the visibility is always kind of the, the kickoff point to help you get situational contextual awareness as to what's actually happening down to the workload level. Getting that user's identity to understand, you know, different services versus users versus of systems, how they're all communicating systems, how they're all communicating within, within the environment, but then also having the ability to enforce at that granularity. Yep, yep, 100%. That's exactly, that's exactly what it is. I mean you can build and determine your zero trust models based on that zero trust. It's not something that's going to just, you know, happen overnight. It's iterative approach and it's going to be different for every organization. So the approach that you mentioned want to take in your organization was going to be different than somebody else. So it really helps to have all the context there and then really help define your roadmap. But you can start with some ideas around it. Right. You know, what areas you want to lock down. And the best place, I think, to get those kind of ideas is looking at, you know, the cmdb. Like, what do we actually ask, to qualify our assets based off of, to qualify our assets based off of, and does that have relevance for security? Cool. I think that puts us at time. I want to thank everybody for joining us today. Michael, thank you for leading the conversation and, walking us through this. Great. Thank you so much. Appreciate it. Take care, everybody. Thanks, everyone. Take care. Bye. Bye.