Finding Your Path to Zero Trust

Welcome everyone to our KuppingerCole webinar, finding your path to zero trust. This webinar is supported by beyondtrust. And the speakers today are Morey Haber, who is CTO and CISO at BeyondTrust and me, Martin Kuppinger. I'm principal analyst at KuppingerCole. Before we start, I want to quickly give you some like our information about upcoming events on some housekeeping inflammation. Then we'll directly dive into our topic of today. So please have a look at all these various KC Live Events. We will run over the course of the next couple of weeks around a series of different topics, like the future of ham, like horror, cyber Xs, summit trembling for truant around cyber security and that entity. And it went to interest and more focused on the role of service knowledge and in servicenow and stuff like that. And that would be way more events, including our upcoming European identity conference. The first onsite event for quite a while we will do, which were run in September mid September in Munich again.
So in front of our do housekeeping. audio control, you don't need to care about that. We have everything under control, so to speak. We have you muted muted, and there's nothing you need to do. We are doing a recording of this webinar and we were provided the recording as well as slides used, which are very few today. I have to say for download shortly after the webinar, and last, at least we will have a Q and a session by the end of this webinar, hi, or feel free to enter questions at any time so that we either can pick them during the webinar or by the end of our Q and a session. And it was that let's have a look at the agenda. I'll please welcome Morey Haber of BeyondTrust. Hi, Maury and the agenda for today is a little different than most of our webinars are that we will not have one presentation with the panel slides for me and on a presentation for Marie, but we will have very few slides.
We will do it very interactively. So there'll be more a conversation between Morey and me about our perspective. So we have successful implementation of theory, trust strategies, and various aspects around what to do here. So it will be more open and that the goals that allow us to pick, maybe if there are a lot of questions for you from your audience during the webinar and that trust after it into Q and A's or box, we will end, or we intend to have a Q and a session by the end. Anyway, so with that again, welcome Marianna let's get started. And the first point we'd liked, or the first topic we'd like to talk about his goals. So the discussion about what is zero trust really about and to which schools can this strategy deliver. And so maybe more you, what, what is your perspective on, on zero trust? So, so you were arrived at this industry for quite a while. I'm around for a couple of years, we both have seen the zero trust concept evolving it's our care for more than 10 years right now. So, so if you, if you need to define theater trust and say what it's about, so what, what would be your, your, your, your perspective in a short enough putting up mine in a minute, then
The goal of zero trust, the definition is really evolved per vendor, per Analyst, per even regulatory authority or regulatory frameworks likeness. The whole point here is, is that you're not trusting anything implicitly based on access control lists, accounts that are present the network or anything else to provide authorization or authentication to a resource with that in mind, you're going to use attributes. You're going to use real-time decisions. You're going to make policy decisions based on everything about the environment, the connection, and the request to allow something to occur, whether it's just the start of a session or whether it's the implementation of an application, or whether it's even to extract data. But the key part here is, is that you're monitoring everything that is being done at the same time to ensure that nothing inappropriate happens that is out of scope for what they're allowed to do as well. So instead of having large quantities of persistent accounts and large quantities of Ackles and permission groups, these things are decided in real time, many times a femoral in order to provide that access or that connectivity to an application.
Pardon element of that? I fully agree. I think it probably goes even beyond that because the columns and controls are just part of the story side. When I look at zero trust as to like this don't trust verifies thing, that the point that we not just blindly trust a single entity, and I think just becomes very clear and I painted a small graphic. And I'd like to, to use that maybe as a frame for the discussion for the next few minutes, which is a little bit about the evolution of zero trust. And I think this is what is also important. When we look at Sera, trust them at the beginning, you'd walked into at Sierra cross. You also see zero trust networks. So it was something which was more limited on the networks, but came from this. I think I'm going to go back to the history to pine, to us.
We had a lot of scenarios where someone passed the firewall. And once you are in the network, you have a trusted your, I believed, okay, this is okay. And then the lateral movement happened from the attacker switch successfully passed the firewalls. Then over time, I think from my perspective, we have seen a quite interesting evolution to arts. It's not just network it's way more than that for us. So it's systems security devices, identity has a very central thing, and I'm a strong believer in that identity is your trust and software. And at the end, it's, it's saying ever saying so, so my perspective on Sierra trust tells us that this isn't about layered security or multi-layered security to say apple, a lot of points where I verified. I try to do it in many places and tomorrow I have protected the better I can do more. Sure. I should. I can be that this excess is acceptable. So how do you see that?
I see that as well from the early days of zero trust, we kept on hearing ziti and a zero trust network architectures and many vendors capitalized on that perspective where we're going to secure the network, we're going to remove those controls. But in the last two to three years, that evolution Martin has is exactly, as you said, really come to the application layer, really come to other types of controls that we have, and just even basic resources. The whole point about zero trust is that you can't trust anything in the supply chain. You can't trust any type of communications. You have to have that continuous verification. And the key part is the removal of those static credentials, those static secrets, those static tools that were used to provide trust before, like an actual, an access control list. You want those to not appear in your security model and be dynamic like having a separate system to secure, secure secrets, and when an application or a process, or even a CIC pipeline requests them, it's validated versus just here's the current key. And that premise builds at least the foundation for zero trust, but by no means is the complete picture. And I think that's a good part of our discussion today.
Yeah. And I think also very important is to kill number four in my graphic, which is software. I think doesn't the, the latest learning, I think the last 15 months or so during the pandemic has shown the network is probably not the best place to start to see or trust because if everyone has trust from one day to the other, working from home, the notion of the network is a totally different one than it has been. But you had a learning. I think we had starting law late last year was the solar winds incident and all the subsequent incidents we have seen since then all the cybersecurity or the software supply chain. So the cyber supply chain, cyber security supply chain risks. We see, I think the other thing is we have these I'm learning also that you must start to trust software, but also verify it that space. So it's getting even broader I'd know from my perspective. And we both had a short conversation about that aspect before maybe we would also like to bring in yourself that,
Yeah. So one of the conversations Martin and I were having as part of our pre-call, and this is generally, if you've ever done a webinar of seeing how these go, you generally banter a little bit before and just discuss ideas, you'll talk in a webinar. We actually crossed the topic about a supply chain of a breach where the actual tools used for publication were compromised. So anybody that use those tools then had their code modified as a part of their upload into cloud-based compilers. That's a whole nother way of attacking software, where when you look at your source code repository, and then the end result very difficult to determine that something was modified because it's compiled code. Yes, you could do things like black duck, et cetera, but they're not always going to find those extra pieces. So the attacks to the supply chain are not only occurring directly to you, but also the vendors, the tool, the security that you use, everything about that. And that makes it that much harder to secure one as anybody producing software, but to even more of a reason to go down the zero trust route, because you shouldn't just trust that tool to be able to run a command and do all these functions, it should be gated as well and controlled as well. So you are ensuring that it hasn't been tampered.
And then I think it's really, this thing is really changing in the way things are happening. And so, or have you look at these things. And I think it was interesting. I had a conversation just one or two days ago with clause about YPs. And I said, you know, the point is a lot of organizations I see still saying, oh, with all this work from all, we use a BPM and bring it back to our network. So it sounds off, or we have something we can trust. We trust the BPM that it's back in the network. And so I brought him, I said, you know, this is exactly not zero. Trust is the total opposite. When we say we use that to create trust again. Well, if he should do this, we should create verification of you should do the also secure every, we do security communication, secure.
Every traffic we have secure at reacts is have a lot of layers of security, but I think we need to re also be aware of when we do something that some of the things we have in mind might be the opposite of what we want to achieve, because we, if you don't say, okay, this, we have edited this, we of dress this latest, then we should say, okay, maybe that's exactly not what I had in mind to do if it's seen as an extra layer of security, different scene. But if it's seen as an entity, we can trust I'm a skeptical,
Well, that's a great point because when we think about VPN technology with people working from home or allowing a contractor or vendor in it, it almost sounds at first, like it's complimentary to zero trust, zero trust says, networks should not be my control layer. You should not be relying on firewalls and other things for zero trust architecture and a VPN extend your network outside. So it almost seems like it should be a part of it, but in many ways it's almost anti zero trust because now you're taking the network and bringing it to a location that you cannot control the rest of the environment nor even applies zero trust controls to the rest of the environment at home or in a hotel or wherever you may be. And we've also seen that recent rash of ransomware attacks coming through VPN because it does provide that network layer tunnel from one location to another, in addition to many VPN based vulnerabilities that then basically can compromise the security model that you're trying to achieve. So VPN is one of those areas that's kind of hard to define, but it also is not the best way to think about zero trust because that extension of a network brings in liabilities.
I, I don't think to leave her and saying, you know, let's have a perspective on starting pulling this. We can use, we can have a user internal or external whichever already wise, because we have control about some devices. We, but we never will have control about all the devices and that user accesses our services, which run somewhere. And when I look at this, then my control Pines, my best control points are at the entity and the service at the end of the data. This is where I can get a relatively good trip where I can implement a lot of controls, a lot of verifications, way better than I think the wise itself, which is an element, but which is harder to get a cripple and harder than at the network level. Because if you come in from your home, you have insecure home wifi, you have to public internet provider, you're, you're using us on and it's, it's not so easy. You can, yes, you can in group, then you have sold a lot of things. So I think we are pretty much and soon about what, what we understand as a or trust then. So when I go back to D the bus forward sitting at the beginning of that part of our conversation, that was goals. So maybe, maybe you can quickly sum up before we jump to the next point. What are the main goals silver cross can deliver to?
I believe that the main goals for zero trust are to remove the dependencies on the network, traditional firewalls, access controls, and perimeters to provide a better security model for authorization and authentication. Make sure you keep them separate for user experience and device access and even automated application access or workflows for let's say, agile development. The goal here is to find a better way and implement tools because there's no such thing as a zero trust product tools in a way that have an architecture that eliminate a lot of the traditional security controls, but implement them in a better way without all of those dependencies.
Okay. Yes. And I th I think I agreed to stop it later. Maybe let's talk first about the readers. So why doesn't everyone have a well-working zero trust, architecture and implementation place today, Marie, why
There's a lot of reasons and Martin, I think you and I are going to go back and forth on this one, and we may agree to disagree. One of the primary reasons that we see a barrier to zero trust is because we can't throw out everything we've already built for the last 50 years, we do have plenty of legacy systems. We have plenty of architectures and applications and designs that cross office buildings across geo locations that are very heavily dependent on security from the firewalls perimeters network segmentation, et cetera. There are a lot of zero trust philosophies, including what's in NIST 800, 207, that you could treat some of those as enclaves as bubbles, almost the segments are zones, but within that zone, the controls are not readily modifiable. The systems were never designed to be zero trust friendly. So one of the biggest barriers that organizations face is how do I adopt something new, like remote access or privileged access management or identity access management topics. We'll cover a little later on. That can be zero trust friendly, but how do I get it to legacy systems or existing systems that just were never architected with these concepts in mind? And personally, I see that when discussing with clients and other analysts, this is one of the biggest barriers.
Yeah, I think it is, it is one, maybe it's also sometimes the barrier, which is sort of artificially enlarged. And in some sense, sounds that because saying, oh, this is how we always did it, or this is what we have. We can't change it. And it calls it. Julie has a good w or is, is a brutal way to, to hinder change. And I think part of that is sometimes the people also want to keep things as they are winners, want to keep their technology up and running. And I are saying some so to some extent, it's true. To some extent it's also, I think sometimes a gap or a lack of, of being consequent in moving forward. So I think a simple example, if you take Microsoft on-premise active directory compat combined, this BitLocker was so good, modern MFA authentication versus x-ray D combined with BitLocker and the good multifactor authentication.
Now this is way easier to achieve was Azure ID, but I still see very large organizations, which aren't at that point in time investing into modernizing my creating Azure on-prem to on-prem Ady and on euphoric concept and stuff like that. So they are still investing into a, at the end legacy technology, instead of saying, I go consequently forward. And so I believe that there's a mix of, of course, with micro-segmentation you at least can reduce some of the challenges. If you don't come to a full zero trust architecture by trusting, I make smaller segments and stuff for a bigger segment that is more, more dealing with the suit though. So that feeling that fixing the cost, but I think you can do is still a couple of things really better, even. Why do you have certain parts of legacy? And you always, I believe should ask yourself which part of the legacy do I really want to keep and where it's trust time to make the next, the bigger step towards modernization.
I think you're right on that. And I think there's also some caveats that get people in trouble. Let's just take a PCI zone. Or if you have a PCI environment, if you look at the regulations and the controls, it is fully segmented, latest standards require multifactor authentication, but you're doing a lot of hardening based on his own itself. You're only allowing specific access gated. You're doing a lot of ankles to control communications from one location to another, et cetera, in order to get to that premise like using Azure ID, you have to deconstruct that workflow and basically be able to say, okay, my dependencies no longer are on those traditional traditional controls. I am now going to evolve my environment, but I still have to adhere to the PCI standards. So when I refer to legacy environments as a barrier or different types of implementations is a barrier PCI comes to mind first. Yes, it can absolutely be done with zero trust, but you really have to understand what you're doing and how you're going to deconstruct those traditional controls that were part of the older DSS standards in order to make them more friendly or adoptable to zero trust.
We could deconstructing things which have proven to have limits, but when it comes to security and a lot of older security technology has its limits. And a lot of older approaches we have implemented over the years just got out of control. So when you look at the PSU of security tools, you would find more of the legacy space. Then it's really hard to do it, right? Because you trust to have too much complexity. So deconstruction, and what am I saying? This might also be a good thing to say. It makes things simpler. And this also aligns was one of the things I always recommend when it comes to security in general, and to moving forward to a zero trust approach. And that is one of the first things you should do is really stepping back and doing a, some sort of a cybersecurity portfolio assessment, understand what you have and what delivers today into the future to really your risk mitigation and what you will learn.
So if you're, for instance, create a matrix of the cost of the total cost of ownership and the, the, the risk mitigation impact. And if you construct this, you will observe, there are some of the operate entrepreneurs have a relatively affordable TCO and deliver, but you also will find some of the lower left edge, which are pretty expansive, which are maybe there for quite awhile, but with relatively little risk mitigation impact at the end, you never have a 100% security. There's no 100% security. So you need to understand, we can, combination of tools helps you best. Lastly, this is an exercise you, everyone should make everyone should make now, because it's not only about trust. It's not only about adding more and more and more it's about understanding what is the best combination of our verifications of tools to bring in security?
Well, it brings up another one of the barriers exactly. To your point. If we look at solar winds, we had an application that is again, not in a zero trust model, a legacy application that used what is, what was called God-like account privileges. So single account administrative rights, full system access allow listed across many applications or environments allow listed from antivirus and an absolute gold mine for lateral movement once compromised taking a workflow or a resource like a network management system, and saying, I want to implement that in zero trust and not rely on the traditional controls of a single or multiple accounts with all of those privileges is another barrier because someone has to go back and think, okay, what tools do I have, where there are account credentials that have all of these successive privileges that I need to re-engineer rethink or redo. And that's another challenge.
Yeah. Well, I like to be provocative. Sometimes I do. I in talks, I bring up this. If you have shared administrative for Collins, then you did something wrong and design. So if you have these accounts, then something went wrong. Yes. At the edge, you can always argue, I need to let this five file. This last account, you to use an a, in a direction situation, if everything else failed. But I think in daily use, we should really go to individual accounts. Accounts was the, with the least privilege, and that can, could be done a lot more. And a lot of this is trust because we are used , which can do everything on this network device, on your Seattle admin account. We use it on data are rarely good. If you look up many offices, many of the network devices, okay. You can create accounts and groups, but there's no cranial access control concept behind that.
Usually it's still that a lot of things are really constructed that with a really security by design and so on. And that is also part of the problem. I think directly leads us to our next part, which is tools. And you already touched us before. So you, you talked about some tools you feel we need, all right. It's like I have all my perspectives, which was, I know from our previous conversations, look, this conversation does a lot of our perspectives overlap quite well on that. But also w where are the limits of the tools perspective on zero trust? I think you brought up already, this zero trust is not a tool.
It's not, it definitely isn't
You console single across single tool.
But when you think about tools or solutions or applications, you know, it, it becomes, how am I using it? A hammer is a tool is a hammer solution. No, but when you put it together with nails and wood and you build a house with it, you have a solution to build a wall. You have to think of the concept of what am I building. And one of the biggest barriers translates into tools, and that's always funding money. How are you going to pay for it? If any of the listeners are in the United States, maybe you have seen the white house executive order from last week. Part of it mandates, whereas recommending mandating that zero trust initiatives do take place to modernize. Many of the government systems and actually provides potential funding to do so. So now you have a tool like zero trust. You potentially have funding, and now you're going after the application so that you can think of the solution.
So the best way that I always like to think about zero trust is what is something that you're trying to solve. I need a new house. I needed a new wall. I need to change something in my car and all of the pieces and parts to get there. And if it's someone from like the U S government, you potentially have government funds available to actually help you get there. It's a part of them, American rescue fund relief package. But when you think about it, in that larger perspective, don't look for a vendor to say, I have a zero trust tool. They may have a zero trust architecture that their solutions can be deployed with, but think of the bigger picture and that'll help at least get you started down that tool.
Yeah, I think we'll never be a single vendor. So I might disagree slightly despite the way with your hammer and I'll achieve. So if you have a sledgehammer that mountain, not only the tool, but the solution for this deconstructing some walls in your house. So sometimes, but, but I think in general, it it's re executive pilot. It's a tool and zero trust from my perspective as a paradigm. And it's the foundation for an architecture, it's the frame where we can sort of pre in our thinking about how the architecture of cyber security could look like in our environment. And then we need to understand which tools deliver to that. And I think what also, when we go back to this there's software security there's identity, interest network, industry-wise et cetera, et cetera. Yeah. A lot of components already makes clear, and this is don't trust, verify, verify multiple places. So, and multi-layer security. That means we have to have multiple tools in place, which hold us to, to create a good perspective on is this access. It's about context of this axis, instead of risks, something we want to take or not. And that is always created or made up by the information we receive from various sources, because the ADA, the queen of the census, we don't want to cross one off of on-scene lofty sources. So we will need to have more than one for our decisions.
It's Kate, because we're going back to the hammer analogy. And it's the best one I can think of. When you think of a traditional hammer, you nail something. Remember back when you were younger, whoever showed you the first time that the back of a hammer could be used to pull out a nail, right? Intuitively you look at it and you have no clue that the two metal piece has bending off where it's can do that. So deconstruction is a key, but when you put the pieces together, zero trust is just that framework. And when you combine it with comp with technologies or processes like sassy or other types of initiatives, then you start to get the house looking like a house. So don't think of zero. Trust is the entire thing, thinking of it as the enabler and the key for getting there. And it is just that tool. One side hit one side pulls. It allows you to get going to where you want to be.
And it's, I think it goes a little back to something we touched already on our discussion. It also helps you to cross Crosstrek your architecture, your plans, everything, that's, it really deliver to Sierra trusted as an added level of verification, or do you do something because you see, okay, I can trust that thing and I don't care. I need to care about it anymore. So it's also sort of a verification is, is it really see your trust or not? So, so my, my perspective, this it's a key principle for model in cyber security approaches, but you should understand it as a concept supported by tools, not trust a tool, specifically, not a single two in any way. There are elements in where I believe they are assumptions like a lot of DRS by identity and access management risk and conduct space or adaptive falls indication.
For instance, this is a, is a key element, but also a lot of elements of network security. So if you have a segment in your network, your network, a firewall still is key sewer trust. That doesn't mean get rid of your firewalls. You need your firewall, the right place as power of the solution, but not as that. So you're speaking about these areas one, which was medicine, not surprisingly, the topic of today's conversation given the year from BeyondTrust is furnished access management. So my question to you is what, where, and why does critical access management or PAM come into play? And we tried to sort of speak to your risk group. So relationships between PAM and zero trust.
Well, this is an interesting factor when we think of zero trust as a whole, we think about normal everyday usage, everyday usage of an application, et cetera, privileged access management is focused on any administrator or power user account, or really any account that if abused could be a liability, risk, threat, leak, data, whatever the risk is to an environment. So when you consider a deploy zero trust deployment of anything from an application to down to the network, to something being used by the end-user, the privileged accounts used by administrators to set up configure, backup, perform maintenance, any of that are a special use case. Those privileged accounts, if abused, just like anything else with privileged access management could be a huge risk to the business. So now how do we take that concept of, I have now done zero trust and now how do I handle those administrative route and power user or special service accounts?
And Pam went applied to it also follows a zero trust model. You then can basically not trust the end-user. You can also deploy Pam tools in a zero trust architecture to service those applications as well. There are a lot of little nuances, but the key point here is don't fall back to your traditional security controls for administration, consider privileged access management, a way to service those administrative accounts. It can be deployed in zero in a zero trust architecture as well, and it can be used by the application itself or the end users as well. In addition, however you want to phrase it to provide proper zero trust security for that application, because if you only do half and you don't manage the privileges behind the scenes with a modern architecture, then that becomes your liability moving forward.
So there's a, so at the end, what you're saying is pretty attracts as management is essential because we must not only focus on the of standard account, but also the griddles act, the Halliburton faxes and all these types of acts we have. And we have, in fact, when you look at the Brasil where detoxes matter for the ethic, couple of new layers of control and verification, because you also can, can you analyze what is happening during a session? We can monitor our session. We can authenticate, we can use a femoral from our access, our chest and time privileges was where all the solutions are heading. So this is what you're saying. This is why it's essential to have privileged access management.
Exactly. So let's just say you embarked on a zero trust initiative to re, to do, redo, to implement, to do something with a critical work source workflow development in your environment. And that project is going along perfectly. You've now done zero trust per something that system still needs privileges for maintenance, it's installation and everything else. How are you going to control those privileged accounts? Are you going to fall back to your old models of having standard persistent, non ephemeral privileged accounts? You shouldn't, you should embrace the zero trust model for its administration as well. Therefore your pan solutions can be deployed with zero trust. And even that administration can use just-in-time time and admin and femoral accounts to do that work for the end users, the systems owners, or the solution owners to do the roles that they need to do. So the whole point here is don't stop halfway and implement zero trust for something, do it for all of the backend as well. And that's where this comes to,
Which is I think a very obvious thing to do at the analyst day. So if you do it, do it right and do it across I recently, and be more when it comes to privileged access, because as we all know, and have you heard, okay, I tech us are on one hand looking for the simplest things like ransomware attacks to certain desktops and spreading it on at that level. But I pick as always specifically, the targets attacks always are after the highly privileged to Collins. And so we need to take sort of extra measures even here to ensure that these are effected, or they are not as much as at risk as they did. They are. So if we mitigate some of the risk of this British your house, we still have. I think there's another element in, we talk about legacy earlier. And even while we'd like maybe to have a supermodel environment, most of us have to deal with several months. Some of us have to deal with a lot of legacy. And when we talk about legacy, then we also have all these old approaches of shared accounts, functional technical accounts that are used. We must surf that as well. So I didn't say the treasured plan part is this is this athlete's entry. That's then more modern, trusted time femoral part of family.
It is. And part of that ephemeral approaches once access is granted. And as we defined it in the beginning of the presentation, you need to be able to adapt in real time to the user's behavior, monitoring the commands, looking what they're clicking on, checking to make sure that there's no duality or additional connections occurring. Other things like that that could be indicators of compromise, or why did they try to spawn a PowerShell or another, or run a script that's not appropriate or from somewhere else? Those types of things in terms of behavior are key. And even with legacy systems, we don't necessarily know, did someone put a command in a script? Did they try to make a call out to a malicious update server? Was there a man in the middle of tech, you have to look for all of these behavioral changes all the way down through everything that they're doing.
And that's where the real time monitoring comes into play. Because if something is seen as suspicious, you do everything from locking the user to terminating them to blocking applications, to a wide variety of basically responses that might be a part of your source system or EDR system in conjunction to ensure that whatever was done wrong or potentially malicious is caught early enough. Now many times that can be used just for training exercises, right? Did you remediate the problem correctly, but oftentimes you can capture something before it starts to spread. And that's one of the key benefits of that behavioral piece to
Stop with the access goes beyond that. It's about what happens during the session and what has happened. And I think we need to take his perspective on the behavioral analytics and collecting data for various places, her correlating them, our trust. One more element and verification is what is happening really correct or not. It's another angle, another perspective. And the more we have at the end, if you do it right, the better it is, we don't need, it's not about having Potter sake of having a lot of tools, but if you use them the right way and another angle of security and not a layer, you have a better instead, let's spend a few minutes last, the least on beyond cross your employer. So, so maybe you can talk a little bit about what, what beyondtrust is delivering here. So two key capabilities, secure remote access and privilege, British password management, but also all the other elements. And how does it supports your trust strategies?
Thank you, Martin. While I got caught on mute earlier, my name is Morey Haber. I'm the CTO and CISO for BeyondTrust. I have a very interesting dual role as a CTO. I oversee the high level strategy for the organization. The conversation I'm having with Martin today, as the CSO, I'm in charge of my own internal security and the cloud security of our SAS based solutions. This allows me to drink my own champagne, eat my own dog food. Use the products we make in my own environment to ensure they work correctly. My chief product officer jokes on a regular basis, I'm his hardest customer because I use the products harder than anybody else would to prove that they work as designed now, from the beyondtrust perspective, we have three pillars of solutions. The first is password management to handle that traditional storage of passwords rotation.
Check in, check out and monitoring. The second is dedicated to DevOps secrets to provide that storage of secrets and the conditional release updates rotation of secrets used for automation. Our middle pillar is around endpoint protection management. That is the removal, the complete removal of admin rights, power users, route from Unix, Linux, windows, Mac, so that you're no longer giving out those administrative accounts to anyone to perform their tasks. We're doing this with patented technology that works from the cloud in a zero trust architecture so that when something needs elevation, the patents allow for the security token of the application to be swamped. The application runs, but the end user is never administrating. We're typing in admin credentials. We also have an active directory bridge in that solution set. It's a little outside of zero trust architectures, but allows Linux and Unix systems to basically join traditional Ady structures.
And then finally, remote access. This is a pure zero trust type of architectural deployment. Also hosted from the cloud, preferably that allows end users without any agent-based technology to connect, to administer and work on systems anywhere else. This basically does everything from the policy engine to the policy administration and the real-time monitoring for behavior as well to ensure that the connectivity is appropriate, that can be used for the help desk. So service desk type scenarios, as well as contractors vendors, and even remote employees to get into systems. The point here being is all of that backend work from these pillars can be administered with zero trust and deployed as zero trust architectures. So whether you're implementing new solutions using zero trust and want to make sure the backend is secure, or you want to do things like removal of admin rights and remote access, or even the storage of privileges using a zero trust architecture, the beyondtrust solution family can get there, keeping in mind that the most critical accounts that you have are those admins routes and power users that if abused, because the applications still need them to be set up are the ones that can cause the most damage to your business.
And that's how we can administrate them using the zero trust architecture. Okay.
Thank you. I think this was a very, very good summary was that I think we have through that conversation, we had it in mind and we can pick up some of the questions we've received already from the audience to all the attendees for free to add more questions, to answer more questions, you'll find the questions area. Usually the go to webinar control panel at the right side of your screen demo questions we have, the more likely to final part of our conversation will be in. I'd like to, to, to start with fun question a lot, which I believe we have, how, but there's an England, which we didn't touch that much. And I like to go a little deeper into that part of the question, which came as in zero trust, a more pros than a technology is legal. And I think we are already very clear about it's so tools at the end, you need them, but it doesn't start as tools, but maybe when you look at gross is what does it mean from a process perspective? What does it mean from an architecture perspective? How do these things relate? It might be, I think an interesting angle to look out and I think you probably have to look at also the process perspective. We'll see our trust.
It is, and you know what? I think there's almost a whole webinar we could do on the process perspective. I like that idea. One of the things with any security technology is when you hinder or add steps to the end user, you're inherently going to get pushback. You need solutions that make the work seamless for them to perform. Regardless if they're a standard end user or an administrator, you don't want to go to a vault and check out a password, copy it, write it down, paste it for every single session you'd need. That's a hindrance. One of the process improvements that you want to gain from zero trust is to eliminate those bottlenecks, eliminate the time the mouse clicks and the exposure of like copying a password out of a vault. You want to get rid of that. If you can use native tools, if you can use your puddy, you're already P whatever it may be.
And it knows how to extract via the API APIs, the credentials for the system, and does all of that zero trust evaluation first, and then just starts the session just like you were natively right in front of that machine. Then you've increased productivity, but you've also increased security and make the users happy because you don't have introduced all those steps. So I think the process of making things better for the end user, regardless of role administrator or root or standard user is a key goal of any stereo trust initiative. If you're introducing all the additional steps, you're probably not going to have a good user experience and probably get a lot of pushback.
Yeah. And I think there's user experience with spawn pod Jada is also have a good process in place to use what you get a data from all the various components, because if you're task collect data and they don't make anything out of the data. And at some point it is that humans need to look at certain incidents at certain types of data, then your best thumb halfway. So we have quite a number of additional questions here. So we probably need to speed up things a little. Okay. Second question here. RAICES existed as a design principle for very long. I think we can argue how long it exists to bring it back or to bring it to the center of attention. So, so maybe you start again. Maybe I add a, if I have some good thoughts about that. Sure.
Many times, good principles, good things exist forever. And until they get documented, refined, polished, and have common nomenclature, they kind of exist in the ether. Or they're just understood. I best analogy I can come up with is bread. Now, it sounds silly how long has have human beings been making bread forever, right? Kneeling the dough, letting rise, baking it, et cetera. But we, in the last 15 years invented home bread machines where we just pour everything in and in the morning we can wake up and have this fresh smell of bread. Sometimes it just takes that innovation, that refinement, that documentation so that everyone understands it. And you can get that fresh smelling loaf of bread in the morning. And I know the analogy is a little off, but that's what zero trust is. It was the documentation of an existing principal and ideas in a very coherent way that everyone could understand and implement.
Yeah. And I think the other thing which three driving of trust these days is two things. One is ever increasing cyber attacks, so we need to get better insecurity. And the other thing is when we go back zero across three peaked over the last 15 months, it lost because the way we work has changed. So with millions and millions of employees starting to work from home from one day to the other, the established security concepts came under pressure. There was a lot of evolution I had was cloud first strategies and other things, but the last 15 months, so I've increased pressure to innovate massively. I think this is the outer part of it, why it's important. So we got better. We learned a lot about it. We documented it. We made it to you, but it's also trust that everyone understood it is changing. It'd be nice to have concepts that allow us to work. Everyone working from everywhere together was all the district transformation stuff, dynamic path trips and all that. All. I think that combination really makes it up. Next question. So many questions here. If we, in case we are had unable to cover all the questions, we will set up some answers later on, but we try to, to answer all of them. So the next one I could answer very quickly. So how to start implementing as you're across, I would say best answer is ask me and my team. We help you. I have Martin. I don't have a perfect
Answer for that. I really do. Yeah.
I'd like to bring up another as a, my, my thought and point, I touched it already. So I don't want to repeat it much. This Lou, what you have power, your environment to look like and what you have in security and what is missing. And then start with talk about the cyber security portfolio assessment as a logical starting point, but maybe you have a better answer.
No, it's the same answer. I was going to say, talk to Martin, but go ahead.
From a practical perspective, I think it's really build a rough picture, but don't go over the top and painting the picture. Does understanding, understand where your infrastructury it is today and where it will be, or maybe, and then look at the gaps. And it's always the same and understand what is missing to retire, what to do it in a very structured, very, very structured manner.
So respectfully I would, I would add to that, don't change your roadmap in terms of the projects and policies that you're trying to do. You might adjust after a little bit, but take one of the ones that is in your current plans and say, I can do this better than just a rip and replace or an upgrade. Can I adapt it and get the benefits of zero trust while I go do this? And Joe, all joking aside, Martin, his team, they're the best resources to ask in terms of how, what, where, and when I, I definitely would refer you to them as an analyst and as a thought leader and an expert in the industry to help you for the larger pictures. But I would strongly recommend don't just say, okay, we're going to go do this. Cause it's zero trust, make it work for you and the initiatives that you currently have. Yeah.
Only if it helps you, it brings you a break, delivers value to you. Does that make sense? Next question are relatively long. Question was IOT industrial controls us from getting access into corporate network and with the Atlanta of five, three, have we thought about their role in zero trust? What gates tools controls have we thought about these systems? And I think this is an interesting question because one of my, my, my standard sentences is once you're connected, you're under attack. And with smart manufacturing, we do exactly this. We collect our formerly closed environment to the outer space. And I think just the last week has shown what can happen if you don't have flood control about it. So, Marie, what's your perspective,
I'm in a full agreement and I'll give you a real life case study. You're in many ways dependent on the vendor to that bantering Martin and I had before I recently moved and I put in any why IOT device in the house, and this is just a commercial device, but it actually held zero trust principles, plugged it and turn it on. After the initial configuration, I can no longer access it from my home. I couldn't. It made me go to the cloud to do the rest of the administration. And with that allowed me to harden it that if only came from my geo location in terms of commands and controls, would it accept changes if I needed to access it locally, I needed to do a local full system restart. Now while that's not perfect, zero trust, it did have a unique SSI ID. It did have a unique password.
It had a lot of additional controls that were very close to zero trust for a consumer piece of device, but that meant that anything I needed to do afterwards required internet connectivity. And I needed to go to that vendor with the onslaught of industrial IOT and control systems. Many of those types of approaches are appearing in environments that are not air gap. They becoming dependent on the vendor. So you have to look to see if they do things like once the initial configuration is set, does it allow local access to prevent lateral movement? Is it dependent on the cloud provider? The vendor itself, does the vendor secure that from you with two factor, et cetera, or multifactor, et cetera. So when you're thinking about these control systems in the environment, think of all your additional security layers and what they've already done versus just saying single role, single admin, single password, anybody can talk to it. No, Ackles no services. It's going to get you in trouble at some time. And we've already seen that with many of the botnets that have appeared in
The answer is to the same. Like you will do an it trust was more legacy
Agreed. And many of even the consumer devices and business devices are going down this route. So there is good progress in the United States. California has had a law for the last two years that no commercial devices can be sold with the same username and passwords. They must be unique per device and or require you to change it on the first implementation. So we're making progress, but many of the commercial systems don't have those feature sets yet, but it also enforces us or asks us to basically treat them the same way. Don't use the same password across all the devices, make sure we adhere to principles. And if the vendors are not giving us all of these of security controls upfront, try to implement some yourself or request that they do. So. And if they don't, maybe you gotta look at another vendor,
Maybe not a very interesting question. I'd like to do the first part of the answer. How do you see blockchain or distributed electric technologies being used since kugel for Sierra ? I think this is a question we could spend probably the next two hours easily online more. I think there's one very interesting current use case. And this is when we look at this entire software supply chain and the software, we ourselves create a cetera. Having hashes of every conflict file of every piece of code of everything we do in that space. Having these hassles on a lecture clearly would be a good starting point for increasing the sort of improving the verification we can do. And it's not about increasing the level of trust. It's about improving our ability to verify whether this is really the software we believe we've already using. So if it's training, we can identify there has changed something. We can then Drigo pros is we don't have much time. So very short answer from my end, but feel free to reach out to me on that as for any other questions, et cetera, Mario, your perspective on the DLT.
I, I believe blockchain does have a place. Let's make sure we separate cryptocurrency from blockchain in any answers because as of this meeting, cryptocurrency is in trouble, but blockchain itself, I think has a very strong role in the identity space for managing that identity or that persona for any of that, the type of access for zero trust. And again, much longer answer that I can provide, but in the interest of time, I'll defer back.
Okay. Two questions to go. The first one is more follow up to the auto question, which is where it was conferencing with trust them. So the question is, is the starting point for Cedar trust, endless followed by a little steps. So once after the other, I kind of hold oddly agreed because at the end, it's the Sierra crossing as an elephant as usual, you need to slice it into pieces. Otherwise you will not be able to succeed in your protractor. Alright.
I concur no additional with anything new, always start small, make sure it's compatible. Don't try to bite this off in one shot. Any large projects that you try to do in one shot, you generally know the answer of the outcome.
Okay. Then our final question for today is theory. Trust limited by the ability to implement technical controls whenever Doris, Ruth, Chris, for. So for instance, contractual terms, there's stress and therefore Theo trust does not seem feasible. So like cloud responsibility models. And I think it's an interesting question because to seem of risk transfer you trust versus technical controls is clearly an interesting thing. Your perspective enough.
I think there is a very interesting piece of that. It's not all technical controls. Many of those may be just risk avoidance. You may choose certain technology stacks. Okay? Yes. That is technology. That is a control that will be risk avoided risk avoidance to better implement zero trust. For example, you may not choose not to use windows or Mac iOS as your primary mobile desktop. You may choose a Chromebook, no AAV closed the lid, open it resets a simple enough, no local storage of anything. Everything is in the cloud, et cetera. And you've eliminated a lot of the risks with choosing a platform as risk avoidance as a part of your zero trust model. So while you could call that a technical control really it's a decision to streamline the process to get there. So it's probably a much longer answer, but think about it more of not changing a setting or making a policy, but the choices you make to get to that end goal.
No, this is a great closing for our entire conversation. Was that set. We are at the top of the hour. So thank you very much for everyone listening to this equipment on cold webinar. Thank you very much for, to be on trust for supporting us and specifically thank you very much to you, Marie, for all the insights you've delivered for this talk. Thank you. Thank you, Martin. Pleasure.