The Future of Authentication and Authorization

Well, good morning, everybody. It's 10:00 AM here in the east coast of the us. The time we've assigned to start this webinar, I hope everyone is gathering in place. We're going to give people a minute or so so that they can get themselves connected. I know that I'm always surprised at how long it takes, go to webinar to actually start running and put me into the room.

What I'll start with here is a few little housekeeping details that we can get out of the way we will be taking questions at the end of the webinar, but you can send them at any time through the little webinar panel that should be on your screen may be hidden. You can bring it back up and there's a place there where you can type in your questions and we'll see them. And then we'll take them, as I say, at the end of the session and go on from there. We'll maybe another minute we'll give people to get in here.

I see we've got a good group of people in, but just, just in case we'll, we'll wait a few more minutes and to get them in here. And if by any chance you have to leave early, the webinar will be recorded and will be available for playback most likely later on today. And I use today loosely because of course we're all in different time zones, but, but that it will be available Not very long after after the session ends today. And with that, I think we, we may as well get started as the room's filling up now. And we'll just go into this little slowly and see what happens.

I'm Dave Kerns, I'm senior Analyst with copier Cole. I'm going to be talking to you today about the future of authentication and authorization. For those of you who were at the European identity conference in Munich in may, you may recognize the title of this as the same as a title of a presentation I gave there. And in fact, this is an elaboration of that short presentation I gave there. You may recognize some of the slides from that presentation, but there indeed is much new material added here. And so with that, we'll just go ahead and begin.

Now I'll start off with the bold concept and then I'll into why it's important for you. First. I believe that we need to stop talking about authentication and authorization as if they were unrelated concepts. They are in fact, simply the twin prongs of the discipline that we'll call access control. Now they are generally still separate ceremonies and each can be discussed as different access aspects, rather of access control. And they may even be handled by different services on different platforms, in different places still.

I can't think of any reason to keep the two concepts of authentication and authorization separate after all. Is it even possible to have one without the other when you're tooling down the highway and a trooper pulls you over and asks for your license and registration, that could be considered an authentication event, but it's also an authorization event. He's doing the first step in verifying that a you're authorized to drive and B you are authorized to drive that vehicle. Your license is a token that is used to authenticate you and prove your authorization.

The registration for the car is also a token that proves you're the owner and authorized to drive it. Now consider going to a movie. You give the ticket taker, a token that is to say the movie ticket, and he allows you into the theater. You're authorized to see that movie, but have you been authenticated?

Yes, you're experiencing role based access control, and you've been authenticated in the role of a ticket holder, but there was a previous authentication. Also when you purchased the ticket, which technically was actually a token exchange cash for ticket. You are authenticated in the role of someone old enough to see this film with the cash needed or credit or a coupon or a pass to purchase a ticket. Not all authentications need to be of an identity unique within a name space. Often it's a role or a class that is sufficient.

I remember a few years ago, for example, in the early days of amazon.com, Microsoft employees were given an extra discount when they went to amazon.com from their Microsoft account. The fact that they were Microsoft employees was noted and no other information was really needed to get that extra discount. It was a role based, Dave, I'm sorry to interrupt you.

Sorry, Dave, we cannot see your presentation. What's that is the title. We cannot see your presentation. Can you please check only? Yes. Now we do. Okay. So we missed a couple of slides. I should have actually opened the audience view there. Darn you missed my, my neat slide of the, of the trooper. I'll show it to you. Then. There you go. There's the trooper who stops you on the highway. All right. We can continue from there. As I said, let's stop talking about authentication and authorization as if they were separate. Let's simply talk about them as access control.

Now you're probably familiar with the term role-based access control, where your role as hopefully you can see this slide as, as parent or employee or farmer or opera singer is enough to give you access to any particular resource.

You may also have heard of attribute based access control or EAC, but the future, as far as I'm concerned, and as far as we are concerned that Cooper coal lies with risk based access control, risk back collects context, data from a transaction who what, when, where, why, which, and how, and we get into those in a moment and then can either approve authentication, deny the authentication or request further authentication factors. What we call multifactor authentication.

If the authentication is approved, the risk back system assigns or causes to be assigned authorizations, dynamically consistent with the risk associated with that authentication and context. If the authentication isn't approved, then a different reaction can occur. And the resource is simply not presented to the person trying to access it. Doesn't that sound a lot like the future?

Well, as it says, the old Testament book of Ecclesiastes, there is no new thing under the sun. What has been will be again, what has been done will be done again.

Now, the book of Ecclesiastes was written in about 250 BC. And even at that time, identity and security went hand in hand. In those days, the Roman empire was involved in the Punic with the African kingdom of Carthage, somewhere in the Libyan desert, a century at a Roman camp would be calling out halt who there friend?

Well, of course he said it in Latin as our cheerful little Roman soldier saying on screen there. Now this is an example of both a challenge response system, as well as an implementation of role-based access control or our back. Only those people filling the role of friend were going to be allowed access.

But that century also relied on the same three categories of proof for authentication that we use today, something, you know, the daily password, something you have in this case, a scroll, what we today call a token sealed with the wax impression of the General's ring, which was an early form of security signing Or something. You are the biometric. In this case, a facial scan. If the century personally knew the person attempting to access the Army's resources. And if the century didn't recognize you, then he'd start looking for multifactor authentication. Sure.

As the years passed, walls grew up around the resources with gates protected by similar centuries, asking similar questions. If we fast forward now, a couple of thousand years say 50 years ago, we find our digital resources behind walls with gates or doors protected entry to the computer room. There's no century, but only those with the right token, a key can gain entry. Now as more resources are gathered, though, we find some people's access needs to be more restricted than others.

We could build rooms within rooms with more doors and locks, or we could adopt another of the old Roman C methods, passwords, digital resources keep growing though. And the desire to protect them through the use of username. Password combinations grows right along with them. People create special databases called directories just to hold the username and passwords so that they're always available and everywhere available. And cause these directories are always available.

People start storing all sorts of information in them, addresses phone numbers, personalization, data reminders, identifiers, and much more Collectively. These became known as attributes items associated with or describing the account or the account holder. Unfortunately in practice, we create multiple digital repositories, which all seem to have developed their own specialized directory. We've created what we call silos towers to hold information for a specific organization, website or single purpose with no connection to each other, removing the silo walls while retaining the integrity.

And the security of the data are one of the goals of modern identity and access management. We wanna create specialized services traditionally called identity providers or IDPs, which collate these attributes on our behalf and present our credentials when called upon services called relying parties or RPS, which need to know that we are thought authenticated. And that we can, the attributes that the RP is looking for with our approval of course's return to for a moment, I said that he used the same three categories of proof of what for authentication that we use today.

Something, you know, something you have or something you are, but he didn't use those things in isolation. For example, the facial scan biometric may have told him that he recognized the face before him, But was it the face of a fellow soldier he'd seen during roll call of the face of a scout or an officer, or was it one he'd seen locked up in a cell? The century would use context, the context within which he first saw that face to help him determine the authentication status of the approaching person and as follows the access or authorization that the person would have Context.

According to the dictionary is the circumstances in which an event occurs, a setting, the whole situation, background, or environment relevant to a particular event or personality relevant is the key word for is here.

Personalization data such as the color scheme that I use for my desktop while it's an attribute of my account has no relevance to whether or not I should be granted access to the financial database, but my job title, my role and my employment status are relevant as is of course the proofs I offer as to my authenticity context is the way to help our digital centuries determine who is a friend and who is a foe who should get access to what, and when the relying party determines which relevant attributes it needs, the identity provider serves them up after the user approves to the Roman guard, the title of general, the role of scout and the employment status of active duty are what's relevant.

Yes, indeed. There's indeed nothing new under the sun, but what do we actually mean by context context? The circumstances in which an event occurs, a setting context, isn't the event, but might be considered in a word we've heard a lot about lately. The metadata of the event Simply put context, is the who a name, a role, a title for what? The platform, the operating system, the where inside the perimeter, outside the perimeter, a safe location and unsafe location when normal business hours, not normal business hours, special days.

Why, what reason are we desiring access to this particular resource? What is it that the user wants to do?

Which, which resource is it that the user is trying to get access to and how, in this case we're looking at, how did they authenticate? And by access transaction, we mean both the authentication and the authorization, the tool are now, or should be tightly intertwined. The answers to these questions, can each be assigned a risk value by our access control service, which we then place in what we call a risk matrix to determine the amount of risk for the transaction and make the go, no go decision.

Now this slide illustrates a vastly simplified risk matrix using the traditional Unix terms of world group and user to indicate various levels of access, perhaps read only rewrite and read, write, execute, or create, or maintain and delete, depending on the answer to the question, a point value is then assigned within the contest risk maintenance matrix and given to the authorization enforcement engine, which decides What authorization this particular user should have.

That decision engine gathers the context and judges the result, according the rules that have been set by the organization, operating it, and then makes the access determination. It's more than likely possible that the risk matrix service will return a value to the access control system, which will base the level of access on a scale determined by your organization at Ture call, we believe the future will be highly impacted by what we call the computing Trico, the cloud, mobile computing and social networking.

Now, since mobile devices are shared more often security experts say it's important to authenticate both the user and the device before granting access. In other words, you need to take context into account.

In fact, the world is fast becoming a future of bring your own, bring your own device. B Y O I B Y O P B Y a B Y O S B Y O C. We're running out of V Y O four letter acronyms. We'll have to go to five soon so that the enterprise space of tomorrow is not really going to be different from what we talk about as the user-centric space today of which social networking is a large part. So there's really no need to have that risk back engine in your data center and lots of reasons to move it to a service in the cloud identity providers residing somewhere in the cloud can do all the work.

In fact, those IDPs are better positioned to gather the necessary context data, because through Federation they can connect to the multiple identity attribute and information silos. We mentioned earlier, remember that if you're thinking the enterprise can host their own IDP, the enterprise doesn't hold all of the attributes necessary. They are not the source of authority for things such as social security number or a corporate credit card number or a corporate issued mobile platform device, someone else's someone else is the attribute provider there.

So it makes sense to even here a contract within IDP in the cloud, who can gather those attributes for you and bring them all together because those IDPs can in turn, calculate the data that's both necessary and sufficient for the current transaction. So what do I mean by necessary? And when I wanna buy a drink in the bar, I'm often required to show that I'm a legal age to do so typically this would require showing a driving license or a passport or other government issued document, which contains among other things by date of birth.

But it's those other things, my address, identity numbers, even medical conditions that are something I'd rather not share with the bartender or anyone else standing at the bar so that the IDP and the cloud could assure the bartender that I was of legal age without revealing any personal information about me that wasn't necessary for this particular transaction. Well, the same can be done with a context based transaction.

The IDP collects the contests context requests, an authentication, then calculates a risk factor and passes that onto the resource holder or relying party who can then make the yes or no decision to allow access or not, or possibly change the level of access to meet the perceived risk, risk based access control, encompassing context based ceremonies conducted by purpose built services.

That's the future of authentication at authorization five years ago at the second European identity conference, I looked into the, at that time far future and predicted that a contextual view of the changing relationships among relevant attributes and objects will enable ad hoc authorizations and real time security based on automatically created policy triggers. In other words, context enabled risk based access control. That future is now very much closer. Let's get to the questions. I don't see the questions. Bear with me a moment. Okay.

Alexei, why don't I see questions a question window. Hello. Let's see. Okay. I just took a quick look at the questions and they were all about the, the startup.

However, we do have a one here and I, again, for the technical people on here, I don't see a question window in my panel. Hopefully we've enabled questions. The question came, what role does exact Mo play that's extensible access control, markup language, and Zal currently will plays a very important role here. It also is becoming a controversial role.

Those of you who follow my writings know that about a year ago, we were talking about SAML security access, markup language, and the fact that it had problems of scale, and shouldn't be included in your future plans for authorizations and by extension authentication. The phrase SAML is dead, became an internet meme. And we talked about it a lot this year.

There are those who have said that exact mold is dead for some of the same reasons because it doesn't scale as well as, and I really don't wanna get into too many what we in the us call inside baseball discussions here, but it's, there are other things that are being put forward as a, as a better choice than exact mall. However, exact ball is the language of choice, excuse me, for policy engines, policy enforcement, policy decisions, and so forth. It's the language that that's used to exchange information among these devices and services.

And if you were building today, the decision engine for risk-based access control Z would be a good thing to use to enable the conversations among the various players within the system. Now, this also does give me the opportunity to tell you about something that's about to happen. In two months, we will be doing a follow up to this webinar, another one called authorization as a calculated risk. That'll be done on tentatively scheduled for Thursday, September 26th, that four o'clock central European time, 10 o'clock Eastern time, seven o'clock Pacific time. And it'll be a webinar in two parts.

In the first part, I will talk about how risk and context based access control would help you to reach the next level of security for the connection, even incorporating the value of the resource into that formula. And if the resources information, then the potential loss should that information be leaked also needs to be calculated once we've determine these factors, the access decision can be made grant deny, request further authentication or lower, or raise the level of authorization. But as most applications today are not built in a way to take such information into account.

In the second part of that webinar, I'll talk about how to make your applications incorporate and process the risk and context information. Ideally, we have applications that rely on externalized authorization systems, for instance, but not necessarily based on example, but most current applications and even most newly developed applications are not built based on social advanced security architecture approach. So workarounds and other solutions are required. And one such would be a claims based architecture where the authorization is still done within the application.

Another is the use of gateway approaches such as XML gateways, or web access management, where the risk based authorization is done. So we'll look at the potential solutions and the application patterns that show what this could look like. And to what extent existing applications can be enhanced to support risk and context based authentication either with, without customizing your code in a non-intrusive way or with additional coding, which is more complete, but also a lot more intrusive.

And remember that will be coming up Thursday, September 26th, watch the events log@coturecole.com to learn more about that, or read about it in my blog, post our newsletter that comes out every other week, which you can subscribe to@coturecole.com define to find out more about that now. Okay.

Another question here, and it says in general, how caught up are the IAM vendors with this vision in general, the IAM vendors like this vision, the IAM vendors see this as the future, which is the question of being able to deliver, because this system that I've described to you here is made up of multiple parts. There are the IDPs, there are the decision enforcement points. There are the policy servers and so forth. It's needs to all be brought together.

And in fact may require that we design a new language or a new protocol so that they can speak to each other, but it's quite possible today to put together a system like this, using existing protocols, existing, a markup languages, existing tools with the existing services and applications that you have. It just takes a little bit more work I'm reminded of 20 years ago when I was still in the it business, I put together what would be called an extremely primitive provisioning system.

Oh, this provisioning system used the email transport to move messages automatically around the system to people telling them what they needed to do. It could not automatically add people as an account within a database or so forth. It simply could remind the person whose job it was to do that, to do it. And that may be where we are today.

With this, we may be at the it's a little bit more manual than we'd really like it to be stage of authorization and access control. Let's see if we have any more questions here. Okay. It says the approach appears to be insensitive to the need for user privacy.

No, not at all. In fact, this enhances user privacy, as we saw with the example about the proof of age concept, rather than having to show a bunch of strangers, a lot of information that you don't want to share, you simply need to show that you are of legal age, which is necessary for you to get the drink. It's also sufficient for the purpose also when working with IDPs and RPS, whether within the enterprise or on your own, the only attributes that are released are those. You use the word authorized to be released, but are those that you approve to be released?

The relying party may ask for particular attributes because the relying party thinks they need them, but you, as the individual involved, don't have to release them. Now this could mean that you can't use the service that you're trying to get to, or it could mean that further negotiation is necessary will lead that as an exercise for the reader. But generally speaking, privacy is enhanced when you go to risk-based access control, because you are More, the user is more in control of the information that's being shared.

Now you may follow up that by saying, well, this context, information, this metadata, you know, isn't that something that people would prefer to keep private? Well, yes, in some cases they would, but usually in the cases that they would like to keep it private, it's something that reflects the fact that they're trying to do something they shouldn't be doing when you are working with corporate data and you're doing it in your office during working hours. And you've logged in from your normal computing device. And you've authenticated in the way you normally do.

You're not really revealing anything of a private nature. If however, you do this login from a wifi access point at a hotel in Rio Janeiro, and the company doesn't know that you're supposed to be on vacation, then it should raise a flag that perhaps you're somewhere where you shouldn't be trying to do something that you shouldn't be doing. Is that a privacy problem? Or is that a security issue? That's a question that's, that's really involving lots of people in discussions in the us right now, and indeed all around the world.

The question becomes For me, do you know that that metadata or context is being collected? If you do, then you're back in the situation we talked about with the IDP and the relying party, the user has to give a set to releasing the data. If you want access to the resource that you're trying to get to, then you need to allow access to the context of your authorization and authentication. That's simple as that. Do we have more little difficult here? Because as I say, I don't have, I usually have these things, a nice little box that shows me all of the questions.

Oh, there we are. There's the questions. Okay. Much better. All right. And I have the question box, and it's gonna take me a minute or so here, because it's really tiny. The question is of context seems to me the most difficult to assert and encode. How would that work in practice? And any of you have seen me give this presentation or one like it in the past, know that the why is indeed the toughest part of doing this? Why goes to the user's intentions?

And it's not something that we can measure automatically, generally speaking, when people need to have the why I tell them what you need to say, pop up box, that either is multiple choice or is free form to allow the user to indicate what it is they're trying to do. This can then be matched up with rules and, and, and you go on from there. Unfortunately, the user who is intent on malfeasance rely. So you're going to have to look at other context at the same time. What that is useful for however, is for audit and log purposes. You can do that.

Then in retrospect, you can look at it and this can help you formulate other controls that might be necessary moving forward. Because again, remember, as we say in the information stewardship paper that Mike Small and I wrote, it's not a question of, will your data be breached and leaked, but when will your data be breached and leaked it's going to happen? And all you can do is use each instance to help build a better protection for the next time question, is, are there emerging standards for defining risk aware access controls?

There is no risk protocol as it were, although there are some protocols having to do with rules, rules based engines and so forth and built around exact well as a way of transferring that information back and forth. And those are the ones that, that we will be using to construct these particular systems.

Oof, version two, for example, is a good way of handling authentication in a dynamic way. Excuse me, that is to say raising or lowering the amount of authorization that someone has based on the risk metric that you've arrived at. Certainly it's the way we suggest that you use going forward. How can OTP be positioned in regards with authentication methods? Is it a safe way on context based authorization? Yeah. OTP one time passwords is just another factor in the authentication ceremony can be quite useful in the past.

I've recommended that out of band one time password through SMS, text messaging is a useful way of adding a second factor to an authentication ceremony. You would log in with a username and password. A secret code would be texted to your smartphone, which becomes the second factor, the token involved here, a hardware token. And then when you receive the message, you enter that into a box as part of the login, and you now have two factor authentication and you're in, there are ways to subvert this process, but then there are ways to subvert just about any authentication process.

The one of the reasons why we, we go with context as a way of determining access control is because there really are no 100% secure authentication methods, all can be broken. Even in combination, they can be broken even three and four factor authentications can be broken, but by gathering the context, we can determine much more about that.

Ceremony, for example, would be SMS texting to the smartphone versus second factor. This can be, there are ways to intercept this difficult ways, but there are ways it can be done, but by gathering the context of where that phone is and where you the user are, if they're in different places there something's wrong. So we assign a very high risk to that particular transaction. They can see how that works. Next question. Do any products exist that you know of that can actually do what you're talking about is the future here today? Yes. There are products that can do this.

No, you can't just plug and play. There's a bunch of work that has to be done. And that's what we'll be talking about in the, the seminar in September. When we talk about implementation of these things. Now question is unfortunately business models of service providers rely on context and identity data to do intensive data mining.

If I, as a user will deny such information, I usually get a bad risk score. So I don't see an advantage to risk based access control.

Well, the risk is being, there's two risks involved here that you're talking about in this question. One is the risk that your data will be used for purposes. You don't intend it to be used for. The second is the risk of the relying party that you will do with their resources, something they don't want you to do. As in any transaction, you both have to agree on the methods for it to take place as an example or real simple example, you go to McDonald's and you want a big Mac and you don't have any cash in your pocket. So you say to the clerk at the window, I would like a big Mac.

I do not have any cash. So I will spend an hour cleaning the tables to pay for it. Now that's probably a good transaction, but the person at the counter isn't able to agree to that they have, you know, a particular way. They have to do things. They have to collect cash or a credit card to pay for the items that you ordered. Perhaps the manager could negotiate that for you, but it takes you outside of the normal transaction process. And the same thing happens.

Then when you are going to a relying party, a relying party tells your identity provider, which attributes it wants to see the identity provider. Then make sure that you're okay with releasing these. And if you are, then the transaction goes through and everybody's happy if you are not. Then ideally a negotiation process takes place in which you challenge the need for an attribute. And the relying party decides either they need it or they don't need it. And you decide either you're going to provide it, or you're not going to provide it. That that's, that's how that works.

As far as the metadata, the context data is concerned. Again, we are not talking about collecting context on your telephone calls and, and the data mining that might be possible from that. We're not talking about A relying party, creating huge data piles of this information. The ideal at the end is that the relying party actually keeps only that data they absolutely need. And they keep it only as long as they absolutely need to, or are required to by various laws regulations. We're not close to that yet. No question, but we are working towards that in the future. It'll be there.

If I didn't think we would, then I, I wouldn't be advocating going this way. Question is how does mobile access influence authorization and authentication? Mobile is just a platform, mobile phones, tablets, smartphones, our platforms, just like a, a desktop, a laptop, a network, a tablet. What have you.

So yes, we have to take into account the fact that it may be running a different operating system. So we need do something about that could be an Android device or iOS device could even be a Symbian device. We need to take that into account. When looking at the context, we also need to take into account. The fact that mobile devices are more often shared than non-verbal devices.

And as I mentioned, I mentioned that one of the slides, so more important to look at the context and authenticate both the platform and the user or the device and the user, there are issues of loss stolen or strain mobile platform. So we have to be concerned with that.

And again, context is important. If someone is trying to get access using that device, of course, the security concerns of data that's stored on that device is beyond what we're talking about here today. We're talking about is access control.

Now, when the person who has that device is let's say, it's, it's their own device. This is a, B Y O D situation leaves the enterprise. Then something has to be done to cut off their access to the services that have been provided. That's part of your provisioning system, which has to take into account this mobile platform. But the authentication engine of course, may have to check to make sure that this person is still of the class, or that is allowed access to this particular system and may have to actually interact with that system to do that.

Are there white papers, case studies for risk based access control? There are papers talking about aspects of risk based access control.

The, and of course, I can't think of any of them off the top of my head, but let me see if I can, I can find one for you quickly here as just a way to start looking at this. Well, if you go to the Ture call website and, and type in risk in the search box, you'll see a number of, of papers about risk management and, and what to do about that. And a matter of fact, you know, pages and pages of things about risk, Risk based access control is alluded to in a number of the papers that we have there, but we have not done the definitive paper on this yet. We will sometime in the future.

And now my question B got closed again. Okay. Next question. How do you sell risk-based access control to CEOs and CIOs? I think it's an easier sell than a lot of things we do in, in than access management, because they understand risk risk is a major component of, of the business side of the enterprise, as well as the it side business risk. And it risk actually should come together. So by explaining here to them, the, the simple thought that this will do two things, it will, it will reduce the possibilities of data loss or linkage.

It will reduce the possibilities of loss of intellectual property. And by ensuring that the right people get access to the right things at the right time, it should improve efficiency and have a very positive impact on the bottom line. All things that your CEO and COO and CIO and CFO want to hear about, what do you think about Fido's future? Fido is a new protocol that's Being developed for identity on the web. Let's see if I can explain it to you easily. If you go Alliance, you'll more about it.

It's, it's another to remove passwords from the authentication situation. There are some major and some smaller players involved in the fight Alliance to do this. PayPal is perhaps the one that's best known or the Lenovo. The people who make PCs and laptops, notebooks are also involved. It's the problem I have with Fido is that their intent is to remove passwords from the equation to fi give people other ways to authenticate. They call themselves an open approach to secure authentication.

The conclusion that I've reached, and this is my personal opinion, is that we're gonna have passwords for a long time to come. Users may not be enamor of passwords, but they get the job done quickly and easily. Implementation is easy. Use is easy. People know how to do it. The problem is of course, that they're insecure and there's no way to make a password secure. So instead we change the focus using risk-based access control. We let people put in a username and a password. This lets them choose the account that they're trying to use for access. And that's all it does.

It doesn't authenticate them. It's simply an indicator of the account they want to use. We then take context into consideration and decide whether or not they are the person who should be allowed access to that particular account. If they are, we let them in. The user has only had to type in theirs, username and password the way they always do. So I'm not particularly sanguine about fi, but I certainly wouldn't go out and say, it can't work. The hard part is convincing people that they need to do something that's not a password. Next question.

How do you handle the risk that the level of access granted is calculated too high, allowing malicious users to cause damaged? I could say it's a trial and error thing that you'll eventually find out What the proper levels are, but in the reality of the situation should not be that difficult. What you are going to do is for very high value resources, you're going to need a very low risk level. And if you can't get that simply by examining the context, then you're have to go.

Then you're gonna have to do even more, perhaps even, you know, calling the user on the phone, just to verify that they're actually trying to authenticate right now. Again, it's a manual process. It costs more money to do that that way. But if you're protecting a million dollars in assets, spending $50 to verify the person who's trying to log in, seems like a pretty good deal.

You know, that's the way I would handle it at this point in time. Okay. Someone here's a doubter. I don't believe that companies are able to calculate a risk score. They even are not able to calculate a business case for I am projects, which is nothing else than a calculating risk, which also is a measure for value. I don't know what to say there they're the you're not going to be operating in a vacuum, calculating the risk scores. This is something that security people have been doing for many years. There are guidelines to use here. They need to be adapted to your particular business.

But the difference here between calculating the risk score and calculating the value of an it project is the understanding on the part of senior management who has to give the go, no go decision. They understand business risk much more than they understand the needs of it much more. And that's what you have to rely on is their ability to evaluate the business risk and understand that risk-based access control is something that will be very, very helpful for them. Now I see. We're just about out of time. So I'll take one more question here and then we're gonna have to go.

And the question is, is trust back trust based access control, the logical place beyond risk back and trust back is simply the inverse of risk back trust and risk are, are really measures of the same thing. That's the question of how you look at it.

If the, for example, if the risk factor is 83 out of a hundred, then the trust factor is 17 out of a hundred. So you can talk about it either way. And in fact, if, if it makes it an easier sell for you, talk about trust based access control rather than risk based access control. The advantage of talking about risk back is that your C I S O and other security people will understand what you're talking about. When we talk about trust, it's rather an amorphous concept that everyone seems to have their own idea of what it means.

And with that, I think we're going to, to wrap up here, I thank you very much for joining us today. It's a pleasure as always to talk to all of you. And as I said, we'll be meeting again in about next month. August is the month when we all go swimming, I think, but in September, when we'll talk about implementations of this, both from the it perspective, as well as from the application vendor perspective. So you.