Zero Trust Means Zero Blind Spots

Hello, ladies and gentlemen, welcome to another KuppingerCole webinar. My name is Alexei Balaganski, lead analyst here at KuppingerCole. And our topic for today is "Zero Trust means zero blind spots", supported by Guardicore. And today I am joined by Ariel Zeitlin, the co-founder and CTO or article. But before we begin just a couple of minutes of some housekeeping and information, I would like to use this opportunity to remind you about our KClive online events. Next one will be taking place on July 21st, and we will be covering the topic of access management. It will be our free KClive event. Online only. You can just register online at any time. It won't cost you anything. And of course, in September, we are planning to have our flagship conference, the European identity and cloud conference, which we had unfortunately to skip last year. And this year it will return as a hybrid event, meaning that if you wish, or you can afford coming to Munich and see us live, you are welcome. If not, you can attend in the online mode as well. Housekeeping: you don't have to worry about all the controls. You're all muted centrally. Or if we control the future, we are recording the webinar. We will publish the recording probably tomorrow and everyone will get an email with a link to download the video or a slide decks. And finally, we will have a uni session and the end of this webinar, and you can submit your question at any time using the GoToWebinar control panel, which has the questions box.
So our agenda for today is traditional. It's split into three parts. I will put up with my theoretical introduction. If you will talking about zero trust to the concept, what it is, what it is not, what are the benefits and challenges. And then I will handle what to REO who will be covering more technical details. And talking about network segmentation is one of the ways to achieve zero trust and what benefits it brings minutes. And as I mentioned later, we will have a Q and a session. So please submit your questions at any time, right? So why, why are we talking about zero trust? Why is this topic so hot and interesting? Well, first of all, because we are facing numerous challenges in the moment COVID of course it's only the latest of one of our challenges, but basically the whole world, whole society, and whole it industry has been developing in a way which are means that there is no longer a safe perimeter behind which you could hide all your it assets and protect them with a single firewall.
Everyone is moving into the cloud or maybe multiple clouds. Everyone is moving outside with the local area network, the corporate network, because they have to work from home or remotely. Everyone is jumping on the bandwagon because it is for many companies, the only way to work productively during the work from home time, the COVID times. And of course, all of this new technologies, all of this new it landscapes bring a lot of challenges, the perimeter realization, malware, and somewhere, of course, all those whole political turmoil, the tension between the U S and China and Russia and other countries, elections intelligence agencies. So the, we are both the collision and the profoundly insecure world, which increasingly depends on cybersecurity to not just stay safe, but to be able to continue to function. And I list morosely drawn by myself. Of course, slide. I was trying to illustrate the idea that typical a corporate network is no longer limited to just the office.
Nowadays, you have cloud, you have multiple clubs, you have probably industrial locations or data centers. You have external employees, partners, contractors, devices are connected to vehicles. You name them. Each one brings its own technology, stack its own security model, its own set of risks and attack vectors. So basically we are all under attack constantly. We have this massively complex and disjointed hybrid it infrastructure. It's becoming increasingly ephemeral with all those containers and serverless functions and other stuff we just put up works for a few seconds or minutes and disappears again at a huge scale, which makes the traditional security tools simply unable to keep up even worse. Some of those tools, some of those infrastructures are now owned by somebody else, the cloud service provider, a managed service provider. And you basically give up your valuable control while still retaining full responsibility for actually protecting the data.
And this is where zero trust comes into the play. It's again, it's extremely hot and popular buzzwords nowadays, but I would really like to kind of step back for a second. Can we look at the history because they don't trust started much earlier than many people expect last century in 1994, a British researcher, Stephen Marsh is first introduced this term in a, in a research paper. Well, it was largely an academic theoretical talk back then nobody was thinking about louds or large networks. I mean the internet was in its infancy back then. I think any kind of there were already academics researchers talking about the need to design network security. And of course, again, even before the cloud in 2003 at the forum, which unfortunately I don't remember anymore, the concept of the parameterization wasn't reduced. That's exactly the trend I was talking about just a minute ago, or even before the cloud, even before the last year to budget networks, we already noticed this trend.
We are losing ground of our perimeter and there are many more holes and there are many more complicated and complex infrastructures in place. So we simply cannot control our security using perimeter based tools anymore. And then 2009, Google has introduced, if you will, beyond Corp, it was designed as our bonds to a massive security breach Google head back then. And it was the first practical implementation of what later was called zero trust architecture. And I'm surprised I'm in the same year, some time later, John kindergartner, who was back at the company, introduced these three principles of zero trust. And we'll talk about them in a minute. The whole point here, that's kind of, he did not invent the term. I would say that invited the principals just kind of close the fruit to summarize and popularize the idea. And of course the people who are extremely interested it's resonated because it was the right time to talk about trust.
And not surprisingly, there was a lot of concurrent parallel developments with COVID and different despots of zero trust. But since today we are talking about networking. I will just briefly mention that in the first practical implementation of a network architecture designed according to zero trust was apparently created in 2014 by a Swiss company. They patented it or thought that the inventor, I'm not sure whether my guest, our guest speaker today, I don't think would agree with that because his company actually started earlier. And then again, that's history for you. And finally, last year was a formalized by the Americans national Institute of standards in NIST with a publication number you can see on the screen, which is actually the first formalized approach towards writing down. What exactly is, you know, trust is in a way that government agencies, at least in the U S and companies and public sector organizations can actually start using them as a real useful reasonable guidelines implemented practical zero trust solution.
So one is, you've probably heard this say in many times trust, but verify section an old Russian saying popularized by American president, Ronald Reagan. Unfortunately this is absolutely not housing FastWorks. If anything, a multilateral trust would be never trust, always verify zero trust is an architectural concept. It's not a product. It's basically the set of rules, how to design and architecture and it organizational architecture together to make sure that they work according to some specific strict principles. I think what Jeff mentioned, it goes beyond just it, because you don't just have to redesign your physical network architecture. You actually have to adjust some of your business processes as well. Trust is built around three pillars, which are data identity and networking and any device on the network, any user using those devices. And of course, any resource meaning like an application or data store, we are all the primary actors and objects and zero trust architecture student base.
And finally, it's really important to emphasize the zero trust is not just theory. It brings very tangible, useful business benefits. First of all, it, if implemented properly, dramatically reduces your complexity because you no longer need a separate different it stacks. For example, on prem and cloud architectures, it eliminates later movements for hackers within your local area networks, simply because you no longer have a local area network and the zero trust. And of course it or productivity for your users because they can work the same way from home or from a Starbucks or from anywhere else.
Unfortunately, it's both worlds. It's brought a lot of unrealistic expectations among many potential customers. So some people would honestly believe they can just take out their credit card and buy a solution which would rip and replace the existing flat network and just magically make in zero compatible. Unless this is not how it works. Although unfortunately, some vendors use this strategy as well. They will tell you they can sell you a little trust. And then again, don't look at the label, look at the specific capabilities. Again, zero trust is not about eliminating trust. It's about minimizing implicit trust. You're only trapped down one or something which you have explicitly defined policy for. And this policy has to be able to dynamically. Anytime you want to access something sensitive. Again, it's not a mighty modernization project because you can adjust and install a piece of hardware or software, install something else and be zero trust compatible. You have to redesign all of your business processes. And finally there is more than one way to achieve zero trust. And he will probably need more all those ways, or at least definitely more than one within your company as well. Unless your company is like really tiny. It's only a few people working from home. You'll probably need more than one approach combined.
So on this slide, we have the basic tenants, basic principles of the draft. And then we'll just quickly reiterate that any decision, any excess decisions, regardless of which device you use, which user is meaning the device, which data source or application you're accessing, all decisions are made dynamically or able to resource separately or granted access to one resource. Won't give you an implicit access to anything else. That's the primary difference from any flat network architecture, all communications of security end to end again, as opposed to traditional networks, no implicit tasks, meaning that you only get as much access as you demand. So if you only need to change one file, you only get access to that file. Nothing else, everything is driven by policies. Those policies are evaluated to the real time. You're in a context which other tools can provide. For example, where are you located?
What's the status of your device with regards to malware? Haven't been paged to all the recent updates, like argue, probably accessing something. We should have not access before. If there's something wrong with your behavior patterns and so on and so forth. Everything that has to be continuously monitored, obviously, I mean, you cannot implement security without monitoring and visibility for multiple times, but this is again, one of the primary premises of zero trust indication, obviously passwords are unsafe. If you cannot ensure that your user is actually the identity they claim to be embracing, that was just crumbled down. Like what's the point of securing access to a database. If anyone can pretend they are the database admin behind all the context of metadata as much of the business and it related context, you have, you have, you should be able to involve in all within Emery exit decision. So if you have a SIEM solution already in place, if you have an EDR and point detection response tool deployed on your end point, your, if you have a cloud connector, collecting some security telemetry all over this matters, every little helps, right? As a British, every Titan says, so every bit of this context data helps to improve your overall security posture.
And on this slide, I just included a very high level logical architecture from the NIST publication on zero trust. This is what a zero trust building blocks are. According to nest, they are very high level. They only say that, yes, there is some kind of a policy decision point, like a piece of software or a service, which takes all that context of metadata, your identity, your device status, and decides, yes, this request can be allowed to no, it cannot be, it cannot continue. And then communicate this to one policy enforcement point, which somehow undetermined nature somehow allows or blocks that access to an enterprise resource does. I mentioned that it can be more than one way to implement this policy enforcement. And then we'll be talking about that in detail later. But again, I would like to highlight that all of your existing security tools are automatically considered core components of a zero trust architecture, whether it's a identity management or a seam or threat intelligence feeds or anything else, the compliance management framework, everything helps to make a decision more precise and more zero trustee.
If you will. As I mentioned earlier, there was more than one way to implement it. And on this slide, I've included again, a very high level example of the way beyond Corp solution works to put it really short. It's like a web access management, but it's extra steps, right? So we're back to this management meeting of that decades, old technology, where there is a proxy server, which decides which part of our web application you are allowed to access. Even if the application itself doesn't have this feature, then tool would kind of implement this fine grain. Excess control, basically beyond core architecture is designed on top of that. But every resource is protected by a separate identity and have proxy which are orchestrated with a centralized policy management solution. There is one single rule engine, which takes almost a context, Maria morphed into an account into account, and then give it, you went to a specific proxy to allow a block specific access.
It was actually, this is probably like the first, the most popular approach. Again, it was basically how was it started? Unfortunately, it doesn't really work that well for non traditional applications. But if you have like a data center is lots of different devices. So planning is different protocols and standards. What if you have an IOT solution, what if you have a legacy platform somewhere? Like how do you end data team and proxy to Emerick away? Probably it will be nearly impossible if anything. So for some scenarios you would have to look further than that. And of course, one of those alternative approaches is microbes. And again, a really rough representation of what it could look like. Basically you have a data center or you have assets, it's a groups like subnets or individual servers, for example. And each one is controlled by a firewall and this firewall, okay, whether a particular access is allowed or not, it's not as dynamic or as fine-grained as an identity and web proxy, for example, but perhaps you already have all those firewalls, or maybe you are just able to utilize the firewalls already installed on a platform like a built in windows or Linux firewalls.
The only thing which is missing is this orchestration layer of 10,000 firewalls within your data center, we'll have really no way to manage it manually or even automated sorts. I'm kind of a low level of scripting engine. Like any symbol. For example, you have to have some smart level of automation, which is able to translate business policies or the declarative security policies to low level firewall rules. And this is actually exactly what got the call. I don't know when we'll be talking about the implementation just now and my last message for you as an analyst today that you don't trust takes a strategy though trust is not just limited to networking. You have to think about all these aspects. You have to protect access to your data. You have to protect your applications, networks of devices and users, and only you can set the priorities. And of course, today we are aiming at companies for whom network security network isolation. That micro-segmentation is the highest priority. And with that, I would like to give the stage to REO titling stage of yours, please.
Hi everyone. So as Alexei mentioned, I'm a real title and I am CTO for guardian or guardian, or is a network segmentation micro-segmentation company. And for us zero for us is a major driver or major framework that would fit in. And this is our customers usually consume our product and this is the value that we bring. But before we get them to exactly what we do and how it works, I would like to start over visually represent the, what, what the risk of, of unsegmented network is sort of in numbers. So this is a real customer scenario from one of our deployments. This is one of the customer's critical applications, GDE, and there are all seeing if you have tens of servers in it, and this is the require communication paths of this application. So this is basically what the application needs to have access to in order to function and provide a service.
There are around 400 of those, but if there is no segmentation internally and everything can access everything, then in reality, this is what happens. There are around 570,000 of possible connections to all the different from all the different IVs that all the different boards that are exist on all the servers inside this application. So basically what it means that 19 more than 99% off, they allowed possible communication paths are needed and basically represent, present the risk. And this is not some engineered scenario I have rarely seen in all our deployments as scenario where it's less than 95%. Like this is the real impact of flood network. Most of the possible connections are just unneeded and the presenters.
So just to sort of a line on how Madison mutation relates to zero Thrace inside the segment, there is basically full process because nothing checks on the network side when the server drives to connect to a server in its subnet in its segment, because it doesn't go through any sort of networking device that can check a connection or let it in a letter, or don't let it in. So segments sort of represent trust component. So to go to zero trust basically means to go to the smallest possible segment size. But as I like to say, right, it's really mentioned it's, it's not, it's very hard to go to the zero thrust. It's basically going to as a, a small of a trust as you can. And I really, I really think it's, this is what happens in practice. And if you look at the industry definition of a zero trust and networks, basically there are two common concepts that usually Blake lawn is the zero thrust. And the pro access is basically monitoring the access from the users to the applications, usually tied to the user identity. So if I'm a member of the HR department, I only should be accessing a few of the applications and only on their standard web ports, I definitely to be access to the critical databases on administrative boards like SSH or RDP.
The second part is micro-segmentation, which basically means reducing the size of segments inside the network. So not talking about the users by basically talking about the service, which servers can access, which, which other servers, or which applications can access which applications. So this is sort of the east-west part of the zero trust and ethics. It's actually a good model to look at zero trust network access as in north south, and the micro-segmentation is the east-west. And just to give you an idea of what the practical network zero thrust project look like, this is a, I would say, represent a typical customer for, for us or anyone from our experience is they don't actually, most of them don't try and create the full micro-segmentation full BI of their network. It will be a lot of effort and not necessarily at the marginal value of doing it potentially can be a smaller, the usually focused on a few of their business critical applications, if you can, is a very dependent on that on the, on the actual organization.
But I would say rule of thumb off bandwidth, 2050 up to a hundred over the critical applications, and basically create the ring fence to them, basically say, what's inside application can talk to each other. Really. They they're it's okay that they trust each other, but anything going in and out of this application should be verify, chose to be only allowed if there is a need for this communication between two applications. So looking at the most business critical obligations and creating a ring fence around them, this is a very common part of the zero trust network. So not take all of your obligations, but just focus on what's the most critical to the business. Another thing that a lot of companies do is look at the, sort of the more riskier protocols or protocols that provide the more access to the attackers, which are administrative protocols like SSH, RDP, or protocols that they use to manage the, the infrastructure and the only allow dolls connections on those protocols to go through some sort of jumbles or a similar solution.
So basically restricting those very risky protocols to the servers only from John books where you can, you can check the identity, then implementing the sort of a zero trust network boxes as an example that they mentioned, making sure that specific applications or even all of the applications are accessed based on the access is provided based on the identity of the users. So HR can only access HR applications on specific ports, and it's usually based on the identity. So you're not trusting that HR group is always accessing from some southerners. You basically check their identity to make sure that the one who is accessing is actually belonging to this user group, especially relevant for working from home and sorry. So this is, I would say a typical practical network, zero trust project. So if you establish that really focused on where the biggest risk is and make as much effort as possible to reduce the free access there.
And when we look at the, even in this sort of a practical, not a very huge segmentation project, or actually it's actually really hard to do with traditional tools. So if you look at it or additional tools to do segmentation, which are basically today or firewalls, what we see is that it's, it's really hard. It's really hard to implement segmentation with firewalls. Basically the reason why a lot of organizations have relative left networks is not, they don't understand that segmentation is important, that it's because it's hard to do it with firewalls because it's actually very slow and very complex. There's not all the visibility. So you don't know the dependencies. Well, it slows down the whole project of separating applications. It requires downtime when you separate the applications, you need to move up applications in different villans. So this is how firewalls work and this creates downtown and they change an application. So basically a very, very complex project for the whole organization involve a lot of teams, networking application, people, firewall people and so on.
And the other thing was which challenges the traditional segmentation is that there is the environment changes a lot. And when you look at how the data centers look today, or infrastructure looks today, there's not just the traditional data center where we have your firewalls and which are hard to manage. Now you have a cloud where firewalls are, blanks is a hard to feed or even have containers, which can run in your data center in the cloud where the profit between two workloads are inside the same CPU inside the same operating system. So there is absolutely no way to put the firewall. So it's it, they are hard to implement. It's, it's hard to put those traditional segmentation tools where most of the profit is today and will be even more so tomorrow. And it's just not, it, it is very complex and it's very expensive to manage, as I mentioned, or need to have many themes and, and downtimes of production application, which costs a lot.
And, and this is, we believe from our experience. Most in many organizations stay was sort of a flat of LePage network. So what Guardicore is doing is actually redesigning the way firewalls work. So you can be able to create those zero trust in a manageable way. So this is the traditional model was firewalls joke points inside the network. What we say is we basically break down the firewall into small pieces that touch the firewall as a sulfur to the workload itself, and now manage the access policy over this work of this workload, but also provide a lot of context and all of the visibility and allow it to work across your burritos, your virtualized servers, cloud containers, and so on.
So this is the Guardicore approach to segmentation. This software approach provides more flexibility, much more data, more context, and you don't need to change on networks or change your applications or have any downtime. So the whole thing becomes much faster. This is a very typical for us, 50 applications in, in a few weeks versus doing the same project in more than a year without zero time, zero downtime, and much, much less people involved. It's much easier to create tighter segments because you can actually create segment around the specific server where we firewalls will require basically to put each server in different Vilan, which doesn't scale. So it can reduce much more risk and it costs much less. And you will see that, sorry, you will see that I'll provide you how an actual calculation. It, it costs much, much less to do segmentation with, with a software tool. So if we take the same typical sort of echo the practical network, zero trust project over those obligations restrict death needs protocols. And there's three factors from users would take an organization that have 3000 users and maybe 2000 servers. This is a very typical project for us. It's who a full-time employee is working over six months and that's it. And there is no downtime, no spend on hardware, no change in the network. This is all it takes. And the security posture of this organization before and after is very, very different.
So just to give you a, an example of a case study, so we'll see how it actually looks into the need for more numbers. There are, this is a of ours that had to secure 50, oh, it's good to go obligations for this. You needed to have the visibility into the profit. It was really hard for them to understand the dependency of those applications. And, and they have a very sort of a hybrid infrastructure. They have virtual servers, they have bare metal servers and they have syrup. Are these accessing their applications to provide support? So this was the project. They plan to do it with legacy tools and the internal calculation for the price tag, including license, but mostly the work they will need to put in place and downtime people involved in this very complex project of actually creating 50 segments internally was over immediate and dollar and two year time.
And quite a few people involved. It's hard to actually found how many, but they, they estimated whenever it's three people working on this all the time and was Guardicore, the whole scene was Jessica tolerated. The hall, the 50 applications were ring fenced in less than two months, 45 days. There was no downtime. And there was no errors in the policy because they have great visibility into the application. So applying to zero thrust was very easy because they knew what they should trust. And when the guy called it, the total cost of ownership, it was significantly cheaper. And this is a very common scenario for us. So it is possible to get to a very practical zero trust implementation in your environment, whereas a fraction of cost of what you're used to pay for additional tools.
We also offer some of some free assessment tools for you. If you're interested, we can help you create sort of an internal attack surface report. So look at your environment and let you understand for a great report visualize and was numbers the exposure of your internal network. And so we can understand if you will implement segmentation, how big the impact would be. You're welcome to reach this link or to record directly. And we will help you create this report at no cost. And it will be based on your network notes, some questionnaire, if you feel, and you actually run through in your network and provide you the full information. There is also a pretty cool tool called infection monkey, which is sort of a open source breach and attack simulation tool, very popular. I'd say four networks. It has a brand of its own and infection monkey has a zero thrust component in it. So it provides a zero thrust report and you are able to see how well you fit or where are your gaps as opposed to the zero press framework. That's it. Thank you so much for, for listening.
So yes, please submit your questions using the questions box and you already have a couple ready liquid, just read them aloud and be decided like who, or maybe we answer them both. So we have some time left. That was the first one. The policy decision point in that zero trust diagram is now in you attack target. How should it be protected? And let me tell you, like, this is like, if I could give for that person asking the question in metal over the internet, I would do it immediately because this is like the most important and the most often overlooked question regards to zero trust. Yes. Because even if you are kind of trying to reduce the overall complexity of your security infrastructure, and that's the whole reason for you to embrace zero trust, you're still adding new components and you still have to protect them as well for like who watches the Watchers, the Watchmen.
So here absolutely specifically, I mean, REO, you could probably talk about your platform in particular, but what we just say that in theory, the whole idea of that, like those two components, the policy enforcement and policy decision points are decoupled as much as possible. And when the policy is enforced somewhere close to resolve your protection, but the actual policy decision point is somewhere else in a secure enclave, absolutely protected by my beer. It's all micro-segmentation implementation, right? Don't yes. That's the whole idea of zero trust does absolutely not invalidate the whole idea of layered defense in depth. That's my view on this question.
Yeah, I agree. And the thing that you should expect from the tool that from this policy management to be implemented zero trust internally. So, so don't let anyone connect to it and manage the policy. You should manage the who can do what in this policy and tune based on his identity and his role. And you should provide the access to this sort of policy management platform based on who actually needs to access and, and verifying this, these identity and, and that access when, where he counts. I also think that it is better to have one policy management tool and actually be able to manage a good policy while protecting the access to it. Then I think tons of different other unrelated bulleted tools where you will be basically not implementing any segmentation effectively or any zero trust effectively. So this for sure means you're exposed. So yes, of course you need, it needs to be managed, but manage and secure well, but it is critical to have one or this critical to reduce the complexity of your environment for one management console color. Otherwise you will be not doing this thing at all.
Yeah, yeah, absolutely. So if there would be like one single takeaway from this webinars that, yeah, this is a good clue. The first question, which will be asked to any vendor promises to sell you zero trust solution. Right. Okay. Next question. That's a very practical one, which areas of zero trust are especially effective against ransomware.
Yeah. I can start. Maybe I think that, I would say almost, almost everything. It's not, it sounds, things are quite unique to, so you definitely, you know, a lot of our aunts, our accounts starts with the user download something and there is a first food hall and then the ransomware propagates to inside the network to gain enough foothold in the network. So it can actually leverage the its propagation to ask for ransom. If you only control one laptop, nobody will be a lot of money. So you definitely to make sure that if you, as an, if an attacker has access to the laptop, you can't move too much internally. He's stuck with his laptop. So all the principles of multifactor and dedication identity-based access to the internal obligations apply freaky well to stopping ransomware. Some of the other aspects of, of, from our experience of specifically protecting in France or some of the critical crown jewels or critic obligations, where we suggest focusing the effort in segmentation pretty unique because Becca was to become the critical applications. This is what you need to protect, not specially your, not the, you're not the only your business critical application. Well, I know it's steers, but also backups. Those are critical for, or a grid to go for your ability not to pay ransomware and empower quickly. So those are some of the challenges, but I think in general and somewhere is just at the end of the day, is when he way off all the old school APDs. So was born with those in mind and run somewhere is not very different.
Right. Right. Well, I absolutely agree with all your, just from my perspective, as an analyst, I would say also try to look at it from the other end. Like the whole point of ransomware is to access your data and destroy it or steal it and hold you ransom that's hands-on. So here are, as I mentioned earlier in the presentation for the zero trust, it's not just about networking, it's about data protection as well. And there is more than one way to access your data. Networking was just one area and you absolutely can start with them because it's, it's a quick win for most companies, but you have to think again, you have to think in terms of layered protection. So zero trust absolutely applies to databases, applications, API, APIs, all those interfaces, which can expose your data and figure that kind of for in some way. It's not just about encrypting your files. When somewhere, for example, can connect to your like office 365 mail server and encrypt all your mails, how would you protect that? Like, there must be some kind of identity aware of the zero trust component, and ideally you should talk the same policy language as the rest of your health components. So there must be some kind of hybrid of your own trust architecture, if you will. And this is probably like the trickiest part creating lists or strategy and high level architecture.
Okay, great. Next question. Okay. Wait, does it have to be so tiny? Could you please go into the process on how to transform a legacy network to a ZT micro-segment network? What steps needs to be done?
Yeah, I can try and take this. I think that basically, I think first step is define the goal. The, what, what what's the end result is if then, and for most of our, our experience engaging with customers is during fencing sound critical applications, maybe separating business units, or, you know, controlling some as me knocks it. So it will be fine while your end result think any segmentation project requires understanding your environment. This is a lot of organizations lack this understanding because for you to start creating walls inside of your environment, you need to make sure it don't break anything. So anything that should be trusted to be allowed. So make sure you have a great visibility to all the allows lousy, easily, understand your environment, understand your obligations. And don't assume that you can go to an application owner and ask him what it's application dependencies.
They rarely know they're early, know everything. So having a great assistant tool can save months or in many cases, just frustration and failure or per project. So have a great mapping tool to understand your network and understand where walls should come and what would be allowed for those walls. It will help if the tool can translate this visual into a suggested policy easily. So we don't need to take data from one tool to another. So map your understanding, your end goal, map your environment and understand what are the dependencies, what would be allowed to be not. And then create the walls. I saying, I really believe in, in distributed model where the firewall actually is in the workloads, but even if you're doing this traditional way with firewalls, it's, it's, the next step is actually enforcing this policy. So this, those, those artists' stats and then maintaining it of course, or making sure that, you know, when an application change and your requirements come up, just like you will do it with your, for additional rule sets in your firewall, even them update that and make sure that they keep being tight.
Right? Yeah. I can only add one small thing to that. You mentioned the first step is to set a goal. That's crucial as it should. The goal should never be, I want to become zero trust. The goals would be a meaningful business achievement, right? It might something compliance related. Like I want to become GDPR compliant, maybe something business process, but I want some kind of security control, but you should not do this for the zero trust sake, because trust is not the goal just to means to actually let it go. Otherwise, I totally agree with your plan. Okay. Next question. What about zero trust for modern cloud states? For example, Kubernetes applications will be, will you approach work there as well?
Yeah, I think it's not different. It's it's just workloads workloads instead of running on its own, the operating system that are running in an eighth space. So it's not different. And the logical meaning of the workloads, which business you need to be launched, which business function and the implements show this Oracle log running now is Linux namespace be able to access other workloads and which boards this doesn't change. It's the same. It's the same concept. The implementation does is different because now you need to enforce the, those two workloads can be on the same operating system. Those two pods and need to infer the policy between them. Yes, are our tools support that in the way, the same way it will support those rituals, you know, bare metals. And I think it's when you choose it to all, it is important to make sure that it supports your all Solaris AIX service, which a lot of companies have where your windows and Linux servers through the managed Kubernetes applications in the cloud, that the segmentation needs to be maintained. The underlying implementation of are actually the packet is dropped or allowed should be completely decouple from managing this policy for you.
All right. Well, it's not that I disagree with your statement. I just kind of would like to remind that there are still some things which you have to keep in mind. And I I'm sure that for you or for your platform, it's probably like self-explanatory, but fortunately not for every solution containers are ephemeral, right? So when they pop up, they disappear without a trace. There might be like multiple copies of the same container. There might be like suddenly thousands or tens of thousands containers in an application because of the spike and the Lord thought your solution has to be able to take into account. So it's like if you have to design a policy and then to assign it manually to Emory container will never scale. It has to be solved, sort of some different types of maybe automation, maybe just some kind of tagging or labeling and stuff like that.
Absolutely agree. It, we cannot now keep setting policies or ideas. They mean nothing. You need to set policies through some robust abstracts that keep up with the business without through the changes that the underlying in the restructure though. So you want to say this workload belonging to this application, whether they are virtual or physical containerized containers, the cloud cannot or cannot access workloads on this application. And this is the policy you want to say, whatever goes in between, it's not your business, the donation falls and needs to take care of this, but I absolutely agree that it needs to be managing that on our more robust obstructs bag. The labels. Yeah.
Okay. While we are waiting for the next question from the audience, actually have one from myself. You mentioned earlier that you have this like a legacy firewall replacement project where you were able to like reduce the effort many, many times and costs, but what happened to those legacy firewalls? I mean, can you sell them on eBay or can you incorporate them into your platform as well?
So I think that if I, if I look at their organizations today, will they have the agreement, their firewall, and they have sound firewalls in the data center. I think sound firewalls and still belong there. I think a good pyramid, their firewall that does more than firewalling. It does a lot of things. It does DDoS. It does your own filtering. That's a WAF. There's a lot of things that are backed into this box. And it's a good practice to keep those. Maybe they can be as a box on your checkpoint and during your organization, or maybe they can be sort of a cloud delivered such as sassy solution. There is a good practice to have a choke point wherever it goes and being inspected, internalizing, but firewalls completely don't belong is just too denomic. And to creating villains just doesn't belong school, modern data center.
And this is so the way I see this organizations who keep, keep this checkpoint firewall can be cloud delivered. Doesn't have to be actual books and, and, and have a sort of a software software segmentation, the practicality of this, that people don't usually that fuss throw their firewalls away. It takes time because firewalls actually sometimes are also wrong with those. So again, just taking them out. So th there, they stopped managing the policy there, or the policy now managed for the software solution, but they sort of fade them out in their own pace. So this is all of those projects usually go, usually go, you're building a new data center or building the data center in the cloud. I wouldn't suggest buying a plane says for the internal product, use a software solution or the choke point yes. Go for an appliance or software appliance or cloud delivery points.
Okay. Okay, great. Thanks. But I think we have our final question for today because we only have like a couple minutes left. So if a company already has many tools which might help with zero tasks, where is the most common gap, which area is the most commonly underdeveloped?
Hmm. I think I, I, I wouldn't be super objective here. I think that maybe because that's what we do, that's what we see. I do seeing that because the technology to Sigma networks is complex. We see that a lot of companies actually have 3d flat networks. So for, and I believe this is super important to reduce that flatness. So I think when we look at a lot of organizations, this is the most screening gap, but if you are lacking a multifactor dedication, I would actually recommend you start from there. This is super important. And just seeing that it's a lot love organization already have it. So from our experience and internal network is actually a good place to start because you're probably left there and probably is a little bit under invested then the other areas. But maybe Alex, you will have a better, more objective point of view.
Normally. I mean, again, from technology perspective, you're absolutely right. I would just like to kind of again, think about from, from the other end. I believe that kind of the biggest thing companies are lacking is just a strategy. They have many tools because they were trying to solve cyber security as well. Tools like throwing money at cybersecurity. It's in over here, let's install a firewall somewhere over there. Let's install an EDR. They are not connected to each other. And whether your network is still flat or whether you are building a zero trust network, if you cannot connect all those disjointed tools back into the central policy engine, they won't help. And if you want to ensure that they are all connected, you have to start with a strategy that's going to basically from my site. And also I see that we have no for the questions and we just reached the top of the hour. It only remains to me to say, thank you very much for all the attendees. And of course thank you area for being with us today. Stay healthy and have a nice rest of the day. Bye-bye thank you. Bye-bye.