KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Optimize your decision-making process with the most comprehensive and up-to-date market data available.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Configure your individual requirements to discover the ideal solution for your business.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
As workers become more mobile and workloads move into the cloud, the traditional model of enforcing security at the network perimeter becomes ineffective. A Zero Trust model of strict access control for every user or device protects your organization from advanced security threats enabling you to stay connected, productive and secure.
As workers become more mobile and workloads move into the cloud, the traditional model of enforcing security at the network perimeter becomes ineffective. A Zero Trust model of strict access control for every user or device protects your organization from advanced security threats enabling you to stay connected, productive and secure.
Hello and welcome to our webinar today. I'm John Tolbert, lead analyst here at KuppingerCole, and the topic today is "Zero Trust through dynamic authorization and policy-driven access". I'm joined today by Dr. Chase Cunningham from Ericom as well as Dr. Srijith Nair and Jim Barkdoll from Axiomatics. So with that, let us begin.
Before we begin, let's have a word about our upcoming European identity and cloud conference will be held in Munich Monday, September 13th, through Thursday, September 16th, we've got 200 speakers lined up over a thousand attendees are expected, 50 exhibitors, 180 sessions and lots and lots of social events and unlimited networking opportunities. It will be both hybrid so online and in person options are available. If you haven't registered, please do so. So a bit about the webinar controls: everyone's muted, there's no need to mute or unmute yourself. We'll handle that.
We do have a couple of polls and you can interact with those throughout and we'll discuss the results of the polls. At the end, we will be taking questions and doing the answers at the end. There's a blank in the control panel for go to webinar that you can enter your questions in at any time. And then we will get in take those at TM and we're recording the webinar and both the recording and the slides should be available on online within a day or two. So let's start with a poll.
Do you already feel familiar with terms such as zero trust, dynamic authorization management, remote browser isolation, and zero trust network access? The polls should appear. So feel free to go ahead and say yes or no to the poll. We'll wait a few seconds. Okay.
So yeah, we'll, we'll take a look at the results of that and another poll at the end. Thank you. So I'm going to start off and talk about a little history of identity and access management, how zero trust fits into that and dynamic authorization management as a key part of a zero trust strategy. And then I will turn it over to the others. Then we'll take questions at the end. So a little bit about the history of I am, you know, this reminds me of the old ancient Greek philosopher. Hereclitis who said you can't step into the same river twice.
I am as certainly been changing rapidly over its existence. You know, in the early days, we'll say back in the eighties and nineties, there was traditional.
I am, it was almost always about on premises servers and it was highly centralized monolithic. You'd run your identity management system on a server or a server farm. And it had all the functions that you needed for identity, including authentication and authorization and auditing all that wrapped into one program.
And the, the primary use case was just business to employee. So authentic, getting your employees in the early two thousands, we saw the beginnings of Federation, you know, as a result of, you know, needing things like web single sign on and being able to apply that to different domains. These business to business drivers arose and Federation hubs were established generally based on things like Sam.
Well, I think they became a standard like 2003, you know, security search and markup language. It was assigned to assertion that would say, okay, this person authenticated in this domain, trust us, let them into your domain.
And again, required identity mapping between different domains. You'd have to have an account, you know, wherever you went and Federation would essentially link those accounts. Then later came its identity as a service, as things became, you know, SAS oriented software as a service identity seemed to be a natural fit for that as well. Mostly cloud-based being able to offer a company's identity as a service was a, you know, a novel, but now very accepted thing. It's predicated on Federation, really to be able to authenticate users and pass tokens on between different domains.
That's what helps make it a seamless experience and can handle automated user provisioning. We saw other standards like as PML and skim evolved to handle that.
And then I guess is really what has enabled not only the growth of BTE and B2B use cases, but B to C the business to consumer side as well, which leads us to consumer identity and access management that started off in some cases with an on-prem component, but largely became driven by the cloud information is available in CRM systems that can assist companies with things like marketing, but it really takes, you know, sophisticated AI and deep data analytics to be able to take advantage of that.
So much information it's also changed the way consumers and now even employees want to do authentication. You know, looking at mobile applications, mobile devices is that Gator IOT could be contextual authentication.
See, I am also required, you know, the development of connectors for social networks, where individuals might want to use their social network credentials to get in this. It makes it easier for onboarding, but that kind of launched the whole wave of privacy regulations around the world too, was there was lots of informations that users might not necessarily want to share. So GDPR CCPA and you know, many other us states and many other countries have privacy regulations today that govern how CIM should collect information and requiring consent for it.
And then PSD two in banking regulation requiring strong customer authentication in the EU. And these, these are both business to business and business to consumer kinds of use cases that this addresses lastly, and currently we see identity API APIs, as you know, a very important trend here. This applies to hybrid environments, both on-prem and cloud private cloud. Multi-cloud many large organizations today have applications that are running and multiple ILS providers. They're doing both CIM and IDs for employees.
A big shift has been the developer centric focus that identity API APIs, both enable and then contribute to, you know, passing on other benefits, you know, being able to extend identity to applications and use identity in new and innovative ways. Workflows have become very important in the identity services world. Think of workflows in terms of, you know, orchestration provisioning, adding entitlements, doing access reconciliations, deep provisioning and the automation thereof.
And again, identity API is, is equally important for business to employee business, to business and business to consumer use cases. So let's look at three components.
You know, what a structured architecture requires for identity services these days. So by a service, you know, this can be a discreet service like authentication services, authorization services provisioning, you need an identity API platform backend. Then you need an identity API layer that can then provide these services out to applications. The applications call the identity API layer, which then interfaces with the backend. There's obviously a need for consistency within the API platform to make sure that these services are easy for developers to address.
There's also a need to develop service tiers and reuse components as much as possible between tiers. Generally, these identity API APIs are instantiated as microservices living inside containers. This kind of goes along with the agile development methodology that we've been using for many years, and now the DevSecOps delivery methodology. This means avoiding those monolithic architectures.
Don't not, not placing all your identity services on a server and or even a server farm. This is breaking each service up and treating it as an important service that can then be distributed across a number of different environments, you know, in, in container form. And this has a lot of advantages too. I think for that, even organizations are going to deploy entirely on-premise. If it's all using a modern cloud-based container architecture, I think that makes it much easier to deploy and maintain orchestrate even in an on-prem only situation, identity apps and data.
So we need logical boundaries between all three of these identity should be separate and it should be the vector by which users get legitimate access to data, excuse me, but applications themselves should not be responsible for storing and maintaining the data. It's good to separate applications and data, and then do a user attribute based access control to get access to that data. And at this point, I think it's time to think about going beyond mere app identities, mere user identities, and think about APEC attribute based access control.
And this is more than group membership, more than role-based access control. We'll dive under that here in just a minute. So we see several big trends that are affecting. I am. I think one of the more important ones is, you know, this growing ecosystem of identities, it's easy to think of users as the primary driver of identity and, you know, user identities themselves have been come more complex with more and different kinds of attributes and different authoritative attribute providers for those attributes.
But now we also have to consider the sources of where requests come from, say, computers, you know, what's the health of a device. Can you write policies that restrict access based on, you know, source device, then mobile devices, you know, phones and tablets increasingly being used for not only for access, but maybe as an authenticator themselves, same for IOT devices. There's contextual authentication that can include, you know, various IOT or smart home devices in a consumer setting, and then applications themselves have identities and attributes.
And all of these things need to be evaluated in runtime, access control decisions enter zero trust. So zero trust has now become a requirement for most every organization. It needs to be able to support different kinds of authentication mechanisms because as consumers become more familiar with easier to use authenticators, they want that in an BDE setting as well.
And, and there are ways that these more consumer focused authenticators can actually increase security because if most of your users are carrying mobile phones, they're used to things like mobile push notifications, mobile apps for authentication that can get you two factor second factor in, in a much more efficient way than perhaps, you know, doing a big roll out of some sort of card or key based authenticators. And this can help zero trust in general, eliminate the potential for lateral movement, data exfiltration and fraud again on API microservices.
This is this I was going to say, it's the way of the future, but it's the way it is now. Most of the identity services are being offered, you know, via API and then stained shaded as microservices. These are good standards and, you know, we've discussed the benefits of why that's even good for internal only deployments.
It's, it's a good manageable way of deploying these services. Lastly, here, AI, what's the impact of AI on identity and access management?
Well, there's an awful lot of information that's generated by users interacting with, you know, different digital resources. You can do user behavioral analysis. You can do device intelligence, things like that to make better risk decisions at runtime, but it really requires machine learning or deep learning algorithms to be able to go through all the data that is generated and come up with a, you know, a good, reliable risk score.
So, you know, this can be an information add on for user authentication and authorization. This is a way of improving your risk scores and getting a better outcomes. So zero trust zero trust means trust only with verification. And this is not something that can be found in any single product. Zero trust is a conceptual and an architectural model. It combines processes and technology.
And, you know, in the early days, people usually would refer to it as zero trust networking. But now we have come to think of zero trust as being really about identity, making sure each access attempt is properly authenticated and authorized on the network or in the cloud or wherever the target resources are. And this starts with a process, but it continues.
You have to identify the assets, the users, the data, and assume that there are threats out there assume that there's a strong risk of being compromised along the way, define your access control policies in accordance with that restricted, then verify how that's working monitor, make changes as needed and put this into a continuous loop, always tuning, making sure that users have the right level of access. So what does I am required to be zero trust? One of the things I like best about zero trust is I see it as a good implementation of the principle of least privilege.
And again, this is about properly authenticating every user and authorizing every user and every device, every target resource, that entire matrix of things that need to be considered for each given access control requests, then just giving them enough privilege to get the job done and then revoking. But it also requires centralization.
You know, if you're an organization and you've got, let's say just a hundred different applications, you don't want to write access control policies that that need to be changed a little bit for each underlying application. You want to be able to write a policy. That's an importance of what your business requirements are, and then have that flow down to every application and understood by every application so that you've got not only efficient, but consistent access controls.
So you may have lots of different applications running in different kinds of environments, different programming languages and operating systems, cloud platforms, but really you want ideally to have to be able to express policy one way and have that apply everywhere. These things have to be dynamic. Access control decisions have to be made in real time.
You know, you can't really pre decide something that's going to last for a long, long time. Every access control decision ideally would be evaluated at the time. The request is made, taking into account as much relevant information as possible, and then yielding a decision. And this can require lots of individual attributes about the user, the device, the application, the resource, and the context. And it shouldn't be adaptive. And by this, we mean, you know, first of all, reacting to environmental changes, let's say there's a change to the threat level. You've been breached.
You want to sort of up the, the requirement for both authentication and authorization, maybe for a short period of time, but it also means you need to be able to scale for, you know, huge loads against your authentication and authorization services. And then before looking so that you can support new authentication methods. We see of development, lots of new kinds of authenticators coming out and being able to plug those into your authentication service without having to rearchitect everything. It's definitely an advantage.
So dynamic authorization, taking a quick look here at our KuppingerCole. I am reference architecture. We see four stacks, administration audit and analytics authentication and authorization. The things in the dark blue or black are core.
I am functions and happy to see dynamic authorization management here and authorization, but it really is sort of the pinnacle of what zero trust should be leading to because it encompasses all of these other areas, the proper administration doing audit and analytics authentication as a precursor, but it's that runtime authorization that really makes zero trust possible. So dynamic authorization management is a real key part of zero trust architecture. We see six major kinds or six major patterns for dynamic authorization.
There's API access using OAuth two, coming at the API gateway with a, an OAuth two token federated WebEx as this like, you know, coming in from a web access management system, maybe a single sign on token or cookie getting access to other domains, data, access filters, maybe you're, front-ending a large set of databases with an intermediate database. You authenticate the intermediate database and application then transforms the query somewhat or filters the results coming back from others. So that you're only presented with information that each individual should be able to see.
There's an enterprise applications using policy information points. You know, this they'll go pick up that commonly defined policy, but each application is then responsible for enforcing it. API gateways.
This, this could be an instantiation of a, you know, a policy decision point. So applications go to the API gateway, get a determination about access, an externalized authorization manager. This is using, let's say plugins for different applications to essentially serve as their own policy enforcement point characteristics of dynamic access policies. Then I'm hinting at this all along, but it really includes all the different attributes about the subject more than just the user identity, more than just group membership.
There are other kinds of attributes that are important to consider and data quality is important there too. That's why, you know, excess governance, something that needs to be done continuously. What are the actions that are requested? Is it read right?
Modify, transfer, different policies can govern whether or not individuals can do certain actions, resources, themselves have metadata in many cases that describe the sensitivity or categorization or classification of the data object that has to be considered. And then the overall context, where is the request coming from geolocation, you know, device wise, IP addresses, date and time. So all of those environmental factors can be considered in dynamic access management decisions as well.
Here, we see our KuppingerCole trend compass about dynamic access management. You know, this started a long time ago, late nineties, and it was hyped up through the early two thousands, you know, and by 2010, it was on its way to becoming an established technology.
And, and it continues to grow as a technology that I think more and more see as absolutely essential for zero trust architectures, looking at the overall market direction, writing policies has gotten easier. It needs to get even easier. It has to be business friendly.
You know, you can't right. It's difficult to write policies directly in exact will. You have to be able to write policies in ways that make sense to the business owners, the data owners, and it has gotten easier. Cloud native environments are expected. Cloud architectures are great for not only the cloud, but private cloud and on-prem situations too, but this means you need standard authorization interfaces.
You know, this Dockers Kubernetes, things like that for actually containing services. And then automation will be key to going forward for supporting zero trust. This means everything from automatic discovery of applications to the orchestration and responses that may need to be taken there too. So with that, I'd like to turn it over to Dr. Chase Cunningham from Ericom. All right.
So, so recent survey data super useful in the context of zero trust and getting people to understand kind of how zero trust fits into the space. There are clear business benefits, and this is, this is useful for the context of a focus folks, understanding we're not just talking about some nebulous thing anymore. Like there are reasons to do this that are not just cybersecurity specific they're business benefits. And if you actually ask organizations, get down the soup to nuts of this, there are four things that mainly stand out as far as direct business benefits.
So your business will become more agile. Your employees will be more productive. Everyone's going to be more satisfied with their experience with this infrastructure itself. And you're going to reduce security costs. There's no organization that I know of in business that would not want to be more agile, more productive, have happier users and lower security costs.
And the way that zero trust enables that is because you're enabling the right security strategy with the right technology to solve the problems in the right way, which is why we're getting into so much stuff around access control and the authorizations and requirements that are there, because this is really difficult to do at scale.
And this is showing up all the time for folks when they, when they actually get to the point of understanding, what does this mean for an organization to enable this across all these different types of infrastructure like you were talking about earlier within disparate pieces of access control. There's also in clear business benefit. When you ask organizations, if they're more mature, are they saving money? When something bad, does it happen? Then you had this in your slide earlier that you're assuming breach. You're basically saying yes, a breach is probably going to occur.
If a breach does occur, are we able to respond better? Which statistically speaking, numerically speaking, when you ask an organization, they can come back and say, the more mature we are, the more money we save when there is a breach, they on average, the more mature they are, they save about $2 million more than an organization would save if they were immature zero trust and they got hit during the attack.
So again, clear business benefits, clear monetary benefits. And it's not a little bit of money, like couple of million bucks. That's something worth noting. When you also look at this over time, you see the average total cost of a breach by the state of zero trust, how mature they are, goes down. So this is kind of the inverse side of this thing, where if you looked at an organization that had not started zero trust at all, they're going to get hit almost at a level of two X of an organization. That's very mature and easy.
Now, why is this well it's because they've accepted that there will be a breach. They put controls in place that makes sense. The strategy is aligned to the business outcomes, and they are living in an area where they have dynamic control across infrastructure to limit compromises and threats and keep the spread from becoming the end of base, like a problem that you see unequivocally like transom burn. A lot of these problems that we're noting in the space, shouldn't be as bad as they are.
The reason that they are is because authorizations access and the ability to let is what's powering the compromise. If we can stop that interrupt that we win and we can take back initiative, which is what you want to do. I ran a survey recently to just go off and ask the sort of market itself. Totally. Non-biased just literally put this to sell to. It's got about 3,000 respondents said some, ask some very pointed questions about what they thought about zero trust and whether or not this was applicable for their organization. My company see zero trust is necessary.
Strategy strongly 68% of folks said, yes, we strongly agree that zero trust is necessary. If you go into that and you look at the agree side to see there's 14% there. So really 90 something percent of the folks that I talked to out of 1300 roughly were saying that zero trust is a necessary strategy because zero trust is a necessary strategy. You have to have the capabilities to enable zero trust and to do so at speed.
And at scale, if you ask organizations how fast they're planning on moving build trust, it varies, but what's notable noticeable for me in this is that there's kind of a sweet spot between the zero to three, which is pretty soon. And the six to 12 months, three to six is kind of slightly lagging there more than 12 was a little bit too far off, but really a lot of organizations are thinking about how to get to ZT over the course of the next year or three months. And then once they get there, they're going to continue to evolve over the next six to 12.
So what we can take from this is the understanding that it's going to require a long-term effort. However, we're thinking about doing it pretty soon, which is very, very good because we can't continue to sit around and wait for other things to happen. If we continue to wait, we will wind up with more compromises, more failure that we've seen to the firmer based model of security. That strategy simply doesn't work.
We have to move to this quicker, which it's really good to know that 1300 roughly folks in the space specifically say that they're moving to zero trust when you organizations, why they're actually considering the move to this model, like why it makes so much sense for them. It's because it's a more proactive approach. Typically. That's the one thing that they're really getting into is that this is more proactive, is helping to limit the spread of threats. And it's saying ahead of the compromise, instead of continually responding to the compromise.
Now, I think that it's the little bit twist of the model here to say that it's the only way to combat sophisticated attacks. I don't think that that's necessarily accurate.
However, what I really think what folks are saying is zero trust is the most intelligent strategic approach to effectively combating sophisticated attacks. When you really look at sophisticated attacks, most of them are based on access lateral movement and getting into systems.
If you apply zero trust, controls principles, like you were talking about before you eliminate or minimize that Bret effect, if you ask an organization why they would delay an initiative for CT, it's pretty interesting to see that really it's mostly budget, which is kind of problematic when you think about how much money we're spending in the space, but okay. It makes sense. The budget's always going to be a driver, but the follow on to that is really other strategic endeavors, which this is confusing.
When you think about an organization that we just looked at, that said, we're moving into zero trust, we're doing it in zero to three months. We see that this is the best way to combat sophisticated attacks, et cetera. And then they come back and say, well, we have other strategic initiatives that might cause us to derail. Our progress does ETE. It makes wonder, well, if you're the same group, that's saying that this is strategically valuable for you, what other things could possibly be in the way.
This is probably the most interesting thing that has come out of most of the recent studies that I've seen is that there is a line of confusion between when we're going to get to ZTE, how are we going to get there? And what things get in the way? Because if you accept that this is the strategy that makes the most sense, nothing else should possibly be in your way. So does this mean that a business driver or a financial driver or something else that's coming in and getting in the mix? Okay. Most difficult part is you don't trust to manage technically.
And this is super important for the folks that are listening to this particular call is policies. You frequent change. If you look at policies and frequent change, what typically is being modified, manipulated or controlled during a policy change during frequent change in the organization environment, it's going to be access. It's going to be the ability to preach resources.
And it's going to be the accounts and accesses that will proliferate across infrastructure cloud is not the one that typically leads people's launch visibility, analytics, not necessarily user requirements to some degree being hybrid. Okay. A little bit more, but really it's the ability to control policies to do it, that speed in that scale. And to make that word as applicable to the constant change that occurs in the environment in order to stay ahead of business drivers. Like those two is 32 and 23.
That's like over 50% of the problem space that people say technically is going to hinder them from enabling zero trust. People want partners. They don't necessarily want a partner that is going to come over the top and say, we're going to implement this. And we'll just make this happen for you. And we are the people that know this better than you, but they do want a partner to help them get to zero trust over time, because this makes sense. It makes the evolution much more seamless and it helps you things, right?
And I'll have to redo and rework things, because again, you can wind up with budget getting in the way. So the question of whether or not you should consider having a partner be that the vendor or a third party or someone else help you enable zero trust, I think has been kind of unequivocally answered. It makes sense.
60, let's see almost 70% of folks say flat out. We would like to have a partner help us do zero trust in some way, shape or form. And I really think if we think about the strategy, the mini technical requirements, the moving parts, the things that are needed to enable this, it makes a heck of a lot of sense to work with someone who understands the needs, understands the technical requirements and understands the implementation process procedures to get you towards a more zero trust state. This is pretty cut and dry. I think enabling zero trust will stop attacks or limit their success.
Obviously that makes a lot of sense. But when you combine those two of 50 and 33%, that's about 87%. It really stands on its own that you can say, if you enable zero trust and we can look at those statistics earlier about the data and the size of the dollars that people do say you will be better off if you enable this strategic approach to the problem, because it does help limit the success of the attacks. It will help stop attacks sure. To some degree, but in reality, it's not that you will ever be better than an attacker is that you will limit the attack from being successful.
Once they've attacked system, you're going to get attacked period point blank in the story. It's limiting lateral movement, limiting access, privileges, limiting shares, those types of things that will keep you afloat and the biggest technical hindrance for getting to ziti. The thing that will stop you technically from actually migrating towards zero trust in-state is not what I thought it would have been. I thought it would've been new technology. I have thought it would have been like lots of tools and the ability to control all these moving parts in reality, it's legacy technology.
So people don't want necessarily move off of that old stuff because it is there and is driving business. It's doing what we need. It's churning and burning and kicking electrons out the door. And it's scary to move off a legacy technology. And that is where people hit the wall is what we've moved to cloud. We've got these other things where migrating revolving, we're doing cool stuff with tech points to stop us from going full easy is going to be the legacy thing. This is where you would a decision point.
You have to actually have a really good plan in place where it makes sense to have a partner help you to migrate off of legacy stuff, into new things and kill the old things, because it's not going to help you get to CTE any better or faster marketing is marketing everybody markets. There's lots of buzz words that people talk about. It's not a bad thing that this is the buzz word, however camo, you know, I think it's worth noting.
And it's good that we're doing this type of webinar, or we're actually getting into this and talking about the realities and requirements so that we understand not everything is a zero trust solution. You said it earlier, right? There's there is no one single thing. There is no idea rules are on. And a lot of vendors that are out there that have just all of a sudden popped up on the spot. They're not exactly strategically aligned enables ITI or the over the long haul. The ones that really know what they're talking about. Like folks that are on the call are saying, we understand this evolution.
We understand this process. It's going to take work and it's going to require other moving parts to get towards that zero Charleston state. So marketing is marketing. It's not necessarily good or bad, but it is a thing that will continue to be in the space. And you should be aware of it. The first thing that everyone says they got to fix when they're trying to get to zero trust, I think this is really, really super useful because I, you know, it's not firewalls. It's not hardcore network security is not DYOD, it's not end of life code. It's not old operating systems.
It is identity and access management by 40 something percent. If you're solving for zero trust and you're trying to get towards taking care of limiting, spread and limiting lateral movement, all the bad things that happen there you take care of, I am. You apply it across the entire infrastructure and you do it at speed and scale, and you start to win and enabling zero trust. That's how it works. That's what needs to happen. That's what you do to get to zero trust as a starting point.
Hello, last thing I'll leave you with. When you thinking about all the bad stuff, right? We think about what we can and we can't control. We cannot control a recon or weaponization the bad guys. They will map things out. They will find access and they will weaponize exploits and they'll go after systems.
However, if we take care of the access control, we take care of the spread. We take care of the scope. We take care of a lateral movement. We eliminate these other five things. And for the bad guy, they have to maintain access for success. If you as the end-user or you as the implementer, or you as the strategist or the security person and work and say, I'm going to interrupt any one of these things, which require access on the bad guy to have a valid account that have lateral movement capability, et cetera, you win. And they go back to square one.
So that, that old paradigm that we've had people push at us about the backbone has to be right. Once that's not necessarily accurate, they have to maintain their access and they have to be right very, very often to continue to pursue and move through that system. If you interrupt that life cycle with the effected access management and do that at speed and scale, you eliminate the adversary's capability and you begin to. So next up we have Dr. Srijith Nair and Jim Barkdoll from Axiomatics to talk about AMAX and how that fits into an overall zero trust strategy.
Great, thank you. A pleasure to be with everyone here today. I'm Jim barkdoll. Dr. Srijith Nair, and I will take you to the Q and a period. First. I want to thank John Tolbert and Dr. Cunningham. They've done an amazing job at setting up a zero trust that definitions of it. And certainly what's changing in the marketplace today. What Susan and I are going to talk to you about is now how understanding zero trust, the role that APEC and more importantly, dynamic authorization plays in that and how we fit into zero trust.
I think there's a couple of really important things to talk about that have changed market conditions. If you look at the beginnings of dynamic authorization or airbag and the need to augment our back, if you will, that started over 15 years ago, it started with early adopters, very complex organizations that we're starting to see some of the problems early on, that all of us are seeing today. And the two things that have changed today, that's led to the increase in awareness of, of a back and the need to implement zero trust are a, the market complexity, right?
The things that we're all doing in our enterprises, whether it's the legacy applications that Dr.
Cunningham talked about, or it's the move to cloud applications is certainly we're all facing with the need to increase connections inside and outside of our companies, both those things have, have materialized, and that complexity has led to difficulty in policy management and that's for us, what it all comes down to a back is a place where you can have a central place where the business team, the it team and the security teams can be assured that the policies that they want to govern that are meant to comply with the regulations and audits are also meeting their business requirements.
And that there's one central place for those to happen. And again, that that's going to happen in a dynamic fashion.
What, what becomes untenable or, or unscalable is trying to manage this in silos, or, but many of us will find out in, in our back is creating too many roles or, or multiple roles using our back to, to try to augment this. And that's why the timing has become kind of right time, right place for APEC in a zero trust environment.
Again, Dr. Chase talked about marketing terms and zero trust is not a marketing term. Hey back.
And, and I think there was never more prevalent in the fact that this year, the us department of defense put out there that zero trust architecture reference, it was created by DISA. And then I say, showing that authorization and access that John Tolbert and Dr. Nair talked about today are pinnacles are our courts are, are essential to obtaining a zero trust environment. And why, why is it now what's changed?
Well, the complexity in the marketplace has also met with maturity in the marketplace. So all of these things that are driving us, right, that the cloud and the change from legacy applications, there's, there's good news that was talked about here on this call today, there's been the emergence of API gateways partners like MuleSoft who have come in and brought a place to centrally manage those applications via API APIs.
Certainly in the directory services, we've got partners like radiant logic to come in, made it an easier place to go in and pull those attributes that are the basis for those, those policies that we want to create around what someone can and cannot do in your systems. And then also IAM, which of course authorization is a component of that. You've got people like SailPoint that are confirming and verifying that this is the individual that I want this policy to pertain to. So those improvements in the marketplace have led to an environment that now APEC is more increasingly possible.
So now that you can take those policies, have the places and the locations to enforce the authorization that you want your enterprise to have. And I'll let Dr. Nair take us here through, through the rest of the way. Yeah. As you can see, dynamic authorization kind of is central to what we have been talking about with, as a sort of trust.
And this, this architecture is something we maybe didn't come up with. It's something which has been published as a, this publication on Serato structure. And you can easily see that, that the policy decision point and the policy enforcement point and the kind of enterprise resource point it's that control plane that we're talking about, which is so central to how we manage authorization and access to all the systems, which is on the site and all the kind of a management system, which is on the right hand side as well.
And if you look at the, the co-tenants of which have been laid out in that publication, that two things, which I want to highlight the first one, which is that all the source authentication authorization that dynamic and strictly enforced before access is allowed, which basically kind of points to the fact that you need to do that authentication authorization in a very dynamic environment. You need to be able to collect all the information that you have around the context around the user, around the system and so on and not rely on one's computed, cashed kind of data.
So things which were a provision probably is good for a small period of time, but you really need to rely on dynamic and enforce access. Based on that, the second tenant, which I want to highlight is the access to the services determined by dynamic policies and observation of state about the client identity application, service requirements, assets, and so on.
Now, what that basically are seeing is that you kind of have that previous slide that Jim was presenting, which is never trust all this verified, which is that you just because the use of has authenticated himself for her. So that's engaged that showed him that things are going well, you need to look at for that assemble a policy that says that you can view that a court, if you have a mobile device, but you cannot edit it unless you have a patch on my MDM system, audio in Britain, a corporate network, or you're within the timeframe that it's allows them to do that. And so on.
So these two tenants kind of balls down two to five, very specific principles, which is the next slide, Jim, if you could move it and bitches, I don't the runtime aspect of dynamic, which forms the code of the trust. And then the first.
So you need to do that while the system is actually being asked us not before or one-time provisioning, and then the aspect of dynamic nature of it, which is that you need to take into consideration all dynamic data associated with the use of the resources and the context and the third part, which is a new to, to, in that authorization tenant, which is an on policy piece. You want to be able to express your requirements in the form of a policy. It can be any different language.
It can be represented in different ways, but you need to be able to then con convert all your requirements around authorization, all the cybersecurity kind of requirements, make the, do the policy, and then frame your authorization based on that, inform your followed by that. And of course, in order to do that, you need to have point indexes because you do need that finding the end capability, which attribute based access control, for example provides that allows you to write those policies to the level of complexity you need to enforce.
And last but not the least, as everybody in the panel that before me I've talked about is that ubiquitous of the authorization. It's not enough to do that at one corner of your enterprise. It's not good enough to do that. In one phase of your boat flow, you need to have every different aspect of your boat flow, every different part of your architecture as well. So all these five components kind of help you bring into the ultra efficient aspect of sort of trust. And if you go to the next slide, you will actually see what I'm talking about when I say about ubiquitousness, right?
And this looks like a busy slide, but it is there for a reason because this is probably the architecture you would see in your it enterprises. You will have database houses all the way to our wholly gone to your crown jewels. You will have all the internet of things and the business users from the left-hand side, but API translating, allowing access integration, ESPs, which helps the workflows and the business services application services, which are on-prem, which could be integrated and so on. And then you have a whole lot of data around the user. It could be from an
And so on. All of that needs to come together into different ways. One is that dynamic authorization engine, which allows you to do the authorization in a very centralized dynamic way and the, what the, the components called the policy and postman point, which is where all this decision making needs to happen.
So any time, any activity across of boundaries, anytime, any activity needs to flow across these boundaries, or get access to some of the Russo's, as you need to use that architecture method of being able to intercept dynamically, and then be able to do the authorization in a very, very fine-grained as well as a very dynamic manner. And so this architecture actually goes to the core of the principles of zero trust, which then shows the importance also of authorization and why authorization is so-called unimportant to the pseudo trust model, the next slide.
And if you look at what we'd look at as the purpose built authorization model to activate the, to the road trials, you have complex requirements on the right-hand side, which is to achieve disability and control. The one that Dr.
Chase Cunningham was talking about, which is around segmenting different users, but not as an internet level, but in being unable, preventing them from lateral movements and so on, but also the basic necessities of business, segregation of duty, regulatory compliance, entitlement management, audit, visibility, masking filtering, which was mentioned in the first deck of slides as well. And then you have the, the notion of data application and cloud all going across different platforms, which could be on prem.
It could be on the cloud and so on, and all the different contexts that you see on the left-hand side, which is the business context, the identity context, the situational context of when, what, where why, and of course there's a security on next and what we envision as that authorization kind of a central team that I own is being able to work at the dynamic runtime level.
So intercepting in the core of the application around time, the policy management aspect of it, which goes back to one of the things that Dr
I think that will help gravitate and move towards that perfect place of zero trust from an ultra efficient point of view. It's really important to note Sergio that zero trust is not possible unless you externalize and centralize authorization, you can, you can pretend that you've attained zero trust, or you're going to go through an audit.
Every one of those places that maybe your teams, your business team says siloed authorization, or you're still using multiple roles with role explosion and are back, but there is no way as we found after enterprise after enterprise, that you could audit and verify that compliance and report back on what those policies are, unless you externalize it, centralize it, and ensure that you've had a conversation that facilitates the work between that business, the it and the security teams Indeed, very well put too.
And if you can go to the next slide, this is kind of the last slide that we want to present on. It. Hopefully capture the business cases that we have seen people. So it's not, it's not the angle around. We need to secure everything. So let's go to the trust, but it's also the enabler part of it. So we have people who are trying to do gateway based access, because it helps you immediate access to APIs, applications, and context, information, and all that is a way of them are dynamically enforcing.
So the policy enforcement point that we talked about is something that we can then put it at the gateway level. So even if you have data legacy data systems like Dr
So being able to dynamically access control the data, part of it is very, very crucial. It could be filtering, it could be masking. It could be doing a lot of those capabilities, but then doing that in a very dynamic way, not the throats procedures way, the things that are traditional database models of it, and being then doing that across a relational database, big data systems, on-prem in the cloud environment and across all lot of backend systems, right? And you have data systems which are so disposed that you want to be able to do that across both. And that's very interesting use case.
And we have seen that being useful for a lot of our customers as well, and last but not the least in terms of compliance and that this is something that you will see when you're moving across a maturity curve or zero trust as well, is that it does provide a challenge for proving compliance because everything is now dynamic. And being able to prove that compliance is bread and butter for a lot of companies, especially those who work in those regulated space and while powerful usage, the health, you need to be able to pull some of these things in black-and-white.
And so pro your tooling and your capabilities around authorization should enable you to prove that compliance in a very seamless manner. And that also provides a very good use case for then also moving and saying, look, sort of trust us here to say, we will help you move to a sort of trust and be able to prove your compliance, even in a sort of trust environment, which so much complexity, but at the same time dynamicity as well. Great. That's it from outside. Okay. So thanks gentlemen.
That was a really informative, so let's move to our final poll question here, and that is, has you're familiar with the terms below and familiarity with the terms below improved as a result of this webinar, zero trust, dynamic authorization and remote browser isolation and zero trust network access. So go ahead and fill in the blank there. And we'll talk about these here in just a few seconds, you know, while, while people are working on that, I kind of wanted to come back to something you all were just saying around authorization and authentication.
And that to me is, you know, I think that there has been, you know, a lot of interesting and good work in the authentication space, you know, in the last 10 or 15 years there, random authenticators there's, you know, cool standards around that. They're, they've definitely gotten easier to use, but I think something that has been going on and I am for awhile is maybe an overemphasis on, on that piece of not the authorization and access control piece.
In fact, I think back to, you know, enterprise days where, you know, in order to get around doing some of the different kinds of sophisticated dynamic authorization, things that needed to happen, there's a lot front-loading that goes on with authentication, with adding lots and lots of attributes to kind of satisfy any particular use case that might come up down the road.
So you might bundle all sorts of things in a SAML assertion that you know, and that, that violence zero trust when you think about it, because you're, you're giving more information than you need to be able to answer the question. So, I mean, I think another big advantage to dynamic authorization management is just to getting the right bits of information to satisfy a particular use case of not sort of over answering the questions that come up. So let's see here are questions from the beginning. Do you feel familiar with these terms 79%? Yes. 21%. No.
So the word has been getting out and hoping that everybody enjoyed the content today, and we're able to take this as a little bit deeper dive into zero trust and dynamic authorization management. And then let's see last flee has people's familiarity increased and the numbers are the same. So 80% came in roughly knowing about zero trust and 80%, hopefully leaving with more information about that. That's great. Thank you. Thanks to everyone who has participated and thanks for doing the polls. So do you have a couple of questions here that we can take in the last couple of minutes? First one.
Interesting. Do you see data is one of the trends affecting I am considering the data volumes out there in the importance of it.
I'll just, I'll just start and say, yeah, I think it's absolutely essential. I mean, thinking about like, well, there's probably two different ways to look at there's the metadata on data for access control, but then there's the data generated by, you know, I am systems that can also be used for UVA, you know, user behavioral analytics, reducing fraud, reducing data, breach risk. I think data is, is the real boon that we have here and being able to help reduce risks in that case, then I'll, I'll stop there and let you guys take a shot at it as well. Yeah.
I, I mean, I do agree. I mean, it kind of points to the, one of the slides that I had as well, which is around the core sense of being able to protect data at the end of it is very important.
I mean, you have privacy regulations, you have IP protection as well. So all of that kind of plays to the fact that at the end of it, what you're doing with zero trust is being able to protect the word is core to your business. And whether that is around compliance pedals around protecting IP and sharing it, I think those are pretty cold. And so it form core of sort of trust production as well. Okay. Next question. What gets in the way old thinking business drivers, the necessity to double productivity over the last year?
You know, I think those are good observations too. I mean, it can be things like, well, this is the way we've always done it.
You know, it seems to be working just fine as is it surprises me how for many years, you know, colleagues and sometimes in smaller businesses thought that they really didn't run the same risks of the data breach or, or ransomware or whatnot is bigger companies, but that's all shifted. Yeah. Yeah. I'll go ahead And do don't you also think, you know, we're, we're all almost a victim of the environment as well. The noise that's created by all the cybersecurity companies out there that are positioning different solutions are not all necessarily as, as you and Dr.
Cunningham pointed out core tenants of zero trust, and they're confusing the message. So I think what ends up happening, at least what I see with customers is there's a tendency of maybe not the most pertinent projects get bubbled up to budget and get done, right? It depends on a dynamic individual inside a company that gets something, get something to attention versus doing the hard work here as we've identified in zero trust, which is, you know, going out and putting that policy workshop together and bringing the teams together. It's a lot, it's a lot of work. It's a big process. Yep.
That's for sure. It is. It's a process and architecture, it's not a product. So last question here, Z TA it can be implemented as a big bang approach or does it need to be implemented phase by phase?
You know, I guess I would say it's probably a phase by phase. Again, if you look at some of the, the charts and surveys that chase had, as well as, you know, some of the slides that you all had and touches many different things. So I would S I would recommend generally a phased approach where possible your thoughts.
No, I do agree. And I think it goes back to the previous question as well, because I do feel sometimes that people hesitate in doing so trust us, because they think that there's big, huge project, a transformation project for the lack of a better word a while. If you kind of chunk it off and then look at the principles that you're trying to implement, but do that in a phased approach, it's easier to chew and it's easier to do and not get bogged down by the complexity or the ginormous nature of the project as well.
So, yeah, bringing it to a flow there. Yeah. That's very well said.
Well, that brings us up to the top of the hour. So again, thanks to the audience for being here today and participating in our poll questions and thanks to our guests, chase Jeff Sri jet. So thanks everyone. And the recording and the slides will be available very soon. So this concludes our webinar and have a good rest of your day. Thank you.
