Authorization as a Calculated Risk

Okay. I think we can begin now. We've got a number of attendees in people can still keep coming in, but once again, welcome to our session on authorization as a calculated risk. And joining me in this session are pretty distinguished gentlemen authorities in their fields on authentication and authorization.

I've got Jamie Calper, who's the senior director of business development and marketing at knock knock labs, Jerry Gable, the president of axiomatic Americas and Brian specter, the CEO of cert they'll each be speaking on that part of access control, authentication and authorization that they're most familiar with. This seminar is presented by KuppingerCole, who you should be familiar with.

But for those of you who aren't, we are a European Analyst company focusing on identities and access management, their governance and risk management to facilitate innovation and corporate value oriented, secure privacy, maintaining information management and business in the cloud. And in mobile and social computing, we stand for expertise, thought leadership neutrality and outstanding practical relevance and support corporate users, integrators and software manufacturers in meaning both tactical and strategic challenges.

Maintaining a balance between immediate implementability and long term viability is at the heart of our philosophy. We do this through different areas, there's research and analysis services. The core element of which is our reports. Cola provides different types of reports from vendor reports and product reports to comparative segment reports and trend reports on emerging market segments. There's also advisory services, which are based on our research so that we can provide advisory and coaching services KuppingerCole develops and maintains roadmaps for IAM, GRC and cloud computing.

As a structured standardized guideline for strategies and deployments, including defined maturity levels based on key performance indicators. And excuse me, there's also our events. There are flagship eventers the European identity conference held annually. It provides thought leadership, best practices and identity focused information security and IA, excuse me, I a M GRC and cloud computing besides this KuppingerCole is one of the leading providers of webinars and virtual conferences around these topics.

The online events are free of charge and provide up to date, insight into hot topics and all research areas covered by. KuppingerCole such as this one that we're doing now. Upcoming events include the information, risk and security summit, which will be held in Frankfurt in NOV, late November. And as I remember, this one will be conducted in German for our German speaking audience.

Then next may, we will once again, be back in the Munich area for the European identity and cloud conference, which is always conducted in English and coming up, as we announced at this year's EIC, there will also be other EIC conferences held throughout the world. We're looking at Asia Europe outside of Germany and north America. And there'll be more information on these coming up in the coming months.

Now, a little housekeeping for today, everyone is muted centrally. So you don't have to mute or unmute yourself. That's all controlled from a, a central point. This webinar will be recorded and the podcast recording will be available tomorrow. That will be announced on our website. I believe a note goes out to attendees when it's available. You can also I'll I'll tweet about it.

Or as, as will, Kuppinger call when it's available, lots of different ways to find out what's happening. We will take your questions at the end of the session, but you can put them in at any time. If you notice in your little control panel down at the bottom, there's a, a tab call questions and you can just type it in there and send it along. Okay. As I said, this session today is really part two of one. We did six or seven weeks ago called the future of authentication and authorization. For those of you who weren't in that session.

Well, shame on you first, but you can also watch the podcast of that at the URL there listed on the screen. Okay. What we determined in that session was that authentication and authorization really are two sides of a coin. If you will, they are inextricably joined together. They really should be talked about together under the rubric of access control. Now that does not mean that they're not still separate disciplines because they're certainly handled in different way. It's just that as the old song says, you can't have one without the other.

For example, you might think that when the trooper pulls you over for exceeding the speed limit and asks to see your driving license, you're being authenticated, but there's really no authorization involved, right? Not true.

Yes, you're being authenticated, but that drive the driving license, biometric information is authenticating the driver to the officer so that he knows it's really you, but the driving license itself is a token that gives you authorization to drive that vehicle. There's authentication and authorization both involved there. So what about the other side? Can you have authorization without authentication? You go to the movies you give the ticket taker, your ticket, you go in and you watch the film. Okay.

You've been authorized to watch that film through the use of this token, but was there an authentication event? Well, yes, there was. Let's trace back. When you got that ticket, you got it from the ticket seller, right? And the ticket seller gave it to you when you gave him the money for the ticket, which was really just an exchange of tokens.

We have to go back a step further to where you got the money, probably from a cash point or an ATM or from your bank or from whatever you did have to authenticate in order to get that cash, you then took that cash to the ticket seller, exchanged it for this token. At the same time you were being authenticated as someone of the right age, to be able to see this film because of many jurisdictions, there are age restrictions on who can watch a film. So there was a dual authentication there, and then you were authorized with that ticket to go on.

That's just some background setting for what we're going to be talking about today. Our agenda really is this we're gonna start off with Brian. Who's gonna talk about multifactor authentication and something we all really would love to see. And that's the end of passwords. Then Jamie will talk about biometrics and an interesting concept of continuous authentication. And finally, Jerry will come on to talk about risk, intelligent access control, or authorization as a calculated risk. So we're going to start off today with Brian specter.

He's the CEO of C and well I'll, I'll, I'll just leave it there. Brian, you go ahead and, and tell us what you want to tell us. Okay. Thanks. Thank you very much. So my name's Brian specter, I'm the CEO and co-founder of the company behind M pin strong authentication system, which is called erox. And my background has been in information security for well over 20 years now, to feel old saying that. And I've worked mainly at, at companies like RSA and cipher and, and McAfee, mostly in the authentication space.

And I'm gonna try and talk about multifactor authentication at the same time, not Hawking my wearers too aggressively to the audience, but do it in a context that as we talk about our own product really highlight the needs of, of our customers and what we see going out there from an information security perspective, and more importantly, trying to end the, the era of passwords and usher in something new.

So in that context, when, when we designed M pin is a strong authentication system, what our main objective was, was to remove the largest threat vector or the largest threat period in cybersecurity today. And that is really the username password database. And in doing so provide a system that gave you two-factor authentication with no single point of failure, but also probably just as critically improve the UI and the UX experience in my entire adult life at information security.

One of the things I think is an industry that we've always gotten wrong was the user experience of trying to actually strongly authenticate or secure your information to the point now, where I think in the general user population, we've, we've gotten people so beat over the head that they automatically think, well, if it's gonna be more secure, it's got to be much more difficult to use. And we're trying to break that cycle as well, too.

So let me just kind of walk you through the problem from a password perspective, username passwords are obviously necessary to access all of the web services that we know and love today. And obviously information resources in our own corporate networks sites like Facebook, LinkedIn, Yahoo, Twitter, they all still rely on the fundamental username password. Unfortunately, over the last year or two, all of these sites have been hacked, but it's not just the, the type of hack or the fact that that somebody got into the network. That that's the problem.

It's a new scale of hack, which is called the smash and grab attack on an entire username password database. So if you take the LinkedIn example, there were 6.5 million unique cash passwords that were run through a password cracking mechanism, and then post it online to a Russian hacking website. And that's why there's stock drop 20% in one day. So these can cause serious catastrophic, reputational and organizational damage, these types of smash and G attacks. And that's really what we've gotta solve.

But if you, if you step back and think about this problem, the analogy I always use is, you know, it's, it's 40 year old Unix technology. Not that there's anything wrong with Unix, but it's 40 year old technology, username and password, and we're using it to authenticate people on the internet. It's kind of like driving a Ferrari down the auto bond with model T tires. So something has to come along and replace it.

You, you, we just can't continue on this way anymore. And in effect, what we're trying to do is replace it with our M pin strong authentication system. So to that end, let's dial it back a layer deeper and really kind of drill down on onto the problem set that, that you have in an organization or a web service with at internet scale number of users, where you currently have a username password database right now that is vulnerable to a smash and grab attack. You need to replace it with something that in our estimation really gives you a zero knowledge proof system.

Now that's, that's the type of system that M pin is meaning that there is no verifier. There is no credential stored at the server end using cryptographic techniques. We can propagate a system that essentially says, I'm going to engage in a cryptographic protocol with you and you will mathematically determine my identity, but you'll do so without actually having to store any sort of credential about me in your system that could be used to compromise my account. If that username password database, for instance, was ripped off or compromised or stolen.

And that's exactly what M pin does at the back end removes the username password database and replaces it with the M pin authentication server that just has one leak proof cryptographic key. If that key is compromised or stolen, it doesn't reveal anything about the users on the system. So when you're looking at strong authentication systems that are trying to minimize your attack vector here at the back end, where you have that username password database, that's really the ideal. That's where you want to get to whether it's the MP strong authentication system or other type of system.

That's what you should be shooting for equally. When you're trying to replace username and password, you've gotta do it in a way that is above and beyond the authentication that you're getting right now, it's literally one factor. The user has something that they know that they're typing into a, a dialogue input box with M pin. We embed two factor authentication into the experience automatically, so that you're actually getting two factor authentication in an HTML five web browser or in our HTML five web app smartphone client.

So implementing M pin from an implementation standpoint, this is a kind of system where you would, would want it to integrate into and help migrate users off of your current existing systems. We also think that's an important criterion with M pin it's, as easy as plugging an eye frame into your webpage and a common workflow our customers implement. And I can give you one specific use case parallels.

They have a default or a legacy user authenticate with username password, and they're asked to set up their four digit pin inside the webpage right there, and then they are logging in using M pin thereafter. So I can just show you quickly what M looks like in the browser. I've already gone through a registration process. And for the sake of time, I won't do that, but it's easy as punching in a four digit pin. It won't take input from the keyboard. You've gotta use your mouse or a touch input device in order to do this. And we use the Google and open ID connect account chooser protocol.

So you can handle multiple identities here and just flipping that around, enter in my four digit pin. And I log in and that's it.

Now, this is the most underwhelming demo in the world because I'm simply just logging into a website, but that's really the kind of context that you want to get to from an implementation standpoint, how MPI N works is you simply set up your M pin server and your data center installing and integrating in into your application is literally a 15 minute experience. You could download the server straight off our website or build it from source as it's an open source application by finding our page on GitHub.

Lastly, and this is equally as important to the other aspects that I mentioned. One of the things that you wanna make sure of is in this system is that it's a step up from current authentication systems, such as PKI, where you have a single point of failure. So the context that I'm speaking about here is if you've got a root key or a cryptographic root key, that powers your system. One of the things that you wanna look for is an ability to split that key across different physical instantiations, even physical different data centers and setups in order to minimize your single point of failure.

And that's exactly what M pin does we in effect give you one half of the root key generator and your data center and the other half resides with us. And in that way, you would need to be compromised. We would need to be compromised in order for any kind of catastrophic attack to happen on the system. So when you're looking at authentication solutions out there to get rid of name, password, you really want to try and get all of these three things put together.

These of you strong scale, and that's what MP N does it removes your username password database, which is your largest threat vector provides two factor authentication with no further point of failure and a much improved Simplifi UXI. And I think I was gonna pass it back to Dave now. Okay.

Ryan, one question I had, you know, you were talking about how smash and grab attacks on, on passwords are, are so prevalent these days. And one thing of course that happens is that a username and a password from one site are used in multiple sites where the systems such as yours, where, where you're dealing with tokens and, and, and key exchange, is that true also is, is that same pin, is, is it the same pin on all servers or are you limited to just the single servers? You're just limited to the single server.

So now using any type of Federation protocols like OAuth, for instance, or open ID connect, you can authenticate with any kind of mechanism. What makes OAuth an open ID connect somewhat dangerous, or being perceived as dangerous through these Federation protocols that you have is not that the fact that the, the protocols themselves for Federation are bad.

In fact, the open ID connect protocol is a fantastic way to federate the authentication mechanism mechanism of your website, because it has strong cryptography built into the protocol itself. The designers have really taken a great purview to building in security into those standards. What makes them dangerous is the fact that the authentication mechanism is weak.

So I think everybody knows about the, the story of the journalist from wired magazine, who with one compromise on his Amazon account led to a cascading series of hacks across all of his personal, his personal systems, to the point where these attackers literally deleted off his family history from the internet. And it wasn't because of the Federation protocols, per se, although some of them were poorly implemented, it was simply because they were able to get his username password.

And that, that is that's really the, the, the fulcrum of the problem with M pin. What we do is we provide factor authentication in the browser using strong elliptic curve cryptography. So you would need to steal something in the browser that's floated in there, which is a fairly sophisticated type of malware attack rather than justing a username and password. And you'd also need to video capture the four digit pin and then escape all the risk based authorization and access controls that most websites manage to put up. Thank you, Brian.

I think we can move on now to our next speaker, who is Jamie, the senior director of business development marketing for knock labs and Jamie too, would like to do away with passwords, but rather than, rather than tokens, I think Jamie would, would prefer having biometrics used as, as your method of authentication. Isn't that true, Jamie?

Well, yes, I know though. It is. Absolutely. I think the key is the flexibility of options is, is, you know, what we are talking about is, you know, biometrics or form factor that, you know, have strengths and weaknesses. And we'll certainly be talking a bit about that, but, but you know, the idea of delivering, you know, strong authentication, you know, around the capabilities of, of the devices that we have in our hands and biometrics are a natural way to move down that route. So not not labs ourselves, we, we are not an authentication vendor.

What we are providing actually is, is, is the unified infrastructure to support different technologies of which biometrics are certainly a primary driver. And it's been an interesting week, shall we say for, for mobile biometrics?

Certainly, but, but I think the principle is still valid. And certainly, you know, I share many of the same, many of the same ideas that the Brian's talking about in terms of what, you know, the problems we're trying to solve. You know, the idea being that, you know, we have, you know, modern computing ecosystem that is, is, you know, multi device that, you know, we are want to increasingly, you know, we shop, we, we, we connect, we, we, we browse through, you know, non-traditional computing devices and authentication, hasn't scaled, you know, to meet the volume and the devices of demand.

And we're still stuck with, with the same systems that, that are challenging for exactly the same reasons that that Brian talked about. And I won't, you know, repeat what he says and I thought covered the, you know, the problems of the large scale part of parts for databases. Very clearly they just present two clear target to, to hackers.

And if we look for example, at the Verizon data breach investigation report, you know, that this year is one, you know, they're certainly from the security perspective, they're seeing that, you know, four out five breaches involve hacking were, were driven from authentication based tax in 2012. You know, so clearly it's a point of failure across, you know, web infrastructures and, and the elephant there in the room. It really is, is the password reuse problem, you know, whereas, you know, you can have the best web infrastructure, you know, security, you know, in the world.

But if I use the same password as across every site, which a lot of users will do, then, then you know, it is been negated by, by Paul, you know, poor user management. Now the flip side, of course, you know, the security is, is, is vital, but again, it usability has become, you know, how do we allow people to be more secure using the devices they have without putting too many barriers in the way. And I think that's really as well where biometrics can, can potentially add a lot of value.

And if we think, you know, again, you know, we have many, many different devices coming to market, you know, how do we authenticate using Google glasses? You know, what about, you know, the, the watches, you know, there are different ones, you know, a lot of the common use of frustrations today, you know, are really around, well, yes, you can come onto my website, but do you have the code that I sent your phone?

Or do you have the eighth and the 23rd letter of the secret word that, you know, so the combination of the, you know, putting the burden and the complexity on the user is always, you know, something that, that, you know, gets in the way of, of expanding mobility, cloud services, you know, of people being able to complete transactions and thinking about, you know, the next generation of, of devices, as well as the ones we have in our hands today.

So the challenge you, well, the number of them certainly, but one of the problems that we see has been, you know, this, this development of silos of authentication. Yeah. It it's been very tough yeah. For both users and for both relying parties, you know, the backend systems that rely on strong authentication in order to validate a transaction or a user you in that, you know, it becoming flexible to roll out different technologies, you get caught in, you know, a particular infrastructure.

You know, that means that all my users look like this, you know, or me, I have, you know, specific, you know, one, you know, a token that only hardware token only works with one bank. I can't replicate that across different places.

So, so it becomes hard to break out of these silos of authentication. And that's really the problem the, the industry's been looking at and considering how can we, how can we simplify the process to allow different, you know, in, in innovative technologies to be leveraged across backend systems, without a large infrastructure footprint. And the challenge there is, is how do we know it's really, you, you know, traditionally we've seen, you know, authentication, you know, fingerprinting is really ended at the device.

You know, the problem has always been, yes. You know, I, I know that it's the right device, that's hitting the, the infrastructure. I know it's, it's the iPad, the smartphone, the tablet, the PC, whatever it might, but how do we know the, the user that's then connected beyond that device is the right user without having some strong assertion of identity of that identity, an authentication. And what we have today is, you know, we find ourselves in a very, a new place really, or in improved place that we are working around with devices that are rich in potential authentication capabilities.

You know, they have typically, you know, cameras, they have microphones. We are now seeing, you know, fingerprint sensors coming onto phones in the large scale for the first time in the Western market.

You, but if you go to Japan, you know, it's, it's, you know, the, the modality is very common to see that. And I think, you know, there has been some well covered discussions about the, you know, the security and the ability to spoof the, the fingerprint cents from apple.

And, and certainly, I think, you know, we have to look at it a different way, this isn't to minimize, you know, the work done with the cares computer club, but also what's the problem that Apple's also trying to solve, you know? And we certainly think that actually as much as anything it's about, you know, the, the nearly half of, of smartphones out there with no pin or code at all to safeguard the device. Yeah. How do you make it easy for people to level up the security in addition?

Yeah, we do have, you know, secure storage, secure execution environments, you know, within the chip set architectures, one devices, we have TPMS, we have, you know, secure elements on smartphone and increasingly different sensors that can help build, you know, this part of the authentication.

So it's not just about my token as a user, whether that's, you know, a, a fingerprint, a voice print, you know, a cryptographic pin, but also it's about the, you know, the environmental information that someone's able to, to gain from the devices and, and the richness available now is much, much, much, much greater.

So what we, we are saying is, is very much, you need to think about the local device capabilities and how those can be extended and supported, you know, by the backend service, you know, so we can use the devices in our hands, you know, without having to layer, you know, complicated, additional features on top of, you know, to, or having to revert back to, you know, passwords are become impossible to use on, on, you know, mobile devices and allow that system to work. And that's really the work that's being delivered by an industry working group called the Fido Alliance.

And the Fido Alliance is, is, is looking at, you know, this strong authentication protocol. How can we think about a way of taking users, devices, you know, and linking them back to cloud services, to enable, you know, Federation, if you have a strongly asserted identity and authentication to do that, a and that's the work that that's being undertaken at the moment. And this is an organization that was, was founded last year in July, 2012. And we announced actually the public launch of it and not, not allows is a founder member.

What happen just before the RSA security conference in February with six founder members. And that was you PayPal as largescale web service, Lenovo as device manufacturer looking to, to kind of be ad support versus across the stack and, and ourselves and the launch, the company we had fingerprint and, and voice biometric sensor, and a secure element, producer and opinion as well, since then, you we've seen significant growth in across the board.

We've seen, you know, Google ping identity, med impact, joint, add their value in terms of the internet services and different perspective as browser an OS manufacturer. We've seen you more mobile manufacturers and black LG, and we've seen a wide range of different authentication technologies.

You know, whether that is more hardware, token based, more voice face, Iris Ivan, a, a whole wide range of different capabilities, which may or may not be suitable for different types of authentication. I think the key thing there is, is it's about choice.

You know, the ability, you know, what the Fido solution is, is really designed to address. And, and this is, you know, an open standards group, you know, what requires membership and an IP agreement, but certainly the, the vision is this is a protocol that, that belongs in an in-depth standard. It enables, you know, the backend system to understand the different capabilities of the device. What is present that can be leveraged that can then be used to enroll a user creating, you know, strong again, you know, cryptographic link to the backend system for ongoing authentication.

So a user would use a credential, a biometric, for example, such as a, a fingerprint sensor or, or voice to unlock, you know, that cryptographic a challenge locally that's then used to communicate to a backend system where that's a bank, a social network, telco, whatever it might be and the benefits. Yeah.

Again, it's, it's, you've got the unique cryptographic key, linking it to, you know, avoiding some of the common challenges you get with passwords, with phishing and malware attacks and that, that unique verification of identity. And really the key point here I think is, is that, you know, it is this combination, as you know, the title of the webinar says, you know, we, we call it explicit and implicit, you know, the explicit authentication is what is the strength of the assertion I can make?

You know, what are the capabilities that I have on my smartphone, on my PC that allow me to say, yes, I am Jamie. And this is my fingerprint matching locally to allow that information to be shared with the backend server, you know, the, the, the, the modality is the one that's chosen by the, the website, you know, you know, who, what does PayPal consider as a good authenticator? Yeah. Or a combination, you know, because we're talking about potential for multifactor. So it could be, you're looking to layer different ones. Yeah.

Based on the, the, the, the risk based on the value of, of a given, given transaction, but equally it's about what all the different signal inputs, you know, so the implicit authentication, the risk based side of the story yeah. Is yeah.

One, you know, the, the, the explicit authentication, my, my, my facial recognition of my voice print is, is one element in a wide range of capabilities, which might be my location. It might be, you know, the different senses. It might be the, the cardiovascular arm band that's same whether my heartbeat is the same, all these different capabilities.

You know, the interesting thing is there is always good innovation in the front end authentication market. But what we're also trying to make sure is that, that these capabilities can be used by backend systems without having to rearchitect the infrastructure on a weekly, monthly basis, which is impractical costly.

And, and you users should have different, they should be trapped in that particular silo, but should really be allowed to, to use the capabilities of the device they're using today is, is about making it a simple and transparent to the user, not placing that burden on them, but allowing, you know, allowing them to use the device in their hand with the relevant and the risk appropriate authentication capabilities. And that is it.

Oh, Yeah. I'm sorry. I didn't mean to jump on you, Jamie, you just sort of stopped there. I thought maybe that was my, that was my sign to, to take over a question for you. And I don't know whether you have the answer to this or not. When we're talking about alternatives to username password, and we're talking about biometrics in particular, whether it's a, a fingerprint or an Iris scan or an EKG wave, I'm sorry, an EEG wave or an EKG wave to both actually keyboard dynamics. Somebody's got one based on the way you, you walk your gate and all vendors for these things say that they're unique.

You know, we can identify you based on X because it's unique across the entire population of the world. How, How much should we believe that?

I mean, is there, is there, do you know of any research anywhere that says everybody's part rhythms are different? Yeah. It's an interesting question, you know, and there is a degree of maturity about some of these solutions and others are still emerging. And I think still probably work to be done. I think there is, you know, there are emerging standards around this, for example.

So if we look in, in, you know, N testing guidelines around biometrics and implementations, I mean, they haven't got, and certainly I know that, that there is work now on the ISO level to look at, you know, what is appropriate biometric. So to standardize the experience as much as possible, but you're right. There is still, there is still, you know, there's lots of interesting technologies and lots of interesting things, how verifiably unique they all are, is, is, is an interesting challenge.

And I think that's why you, you look at a combination and, and some of them are more environmentally impacted than others. Certainly.

You know, if you look at things like, you know, you need to be sure of the quality of light with some face or the quality of the camera, you know, voice, likewise can be very environmentally impacted by background noise in some environments. It's interesting. Biometrics is a fascinating area in that, you know, we've seen this C change from yeah.

Historically where biometrics have been, you know, strong and widely deployed has been, you know, in areas like border control, where you have, you know, manual verification, the guy behind the desk is making sure I'm not got the latex fingerprint or the, you know, the holding up the picture. So really it's, it's moving away from that remote. If you wanna be able to use it on a, on a smartphone or on tablet, you have to be sure that the anti spoofing capabilities of the uniqueness is, is there.

And, and that is, you know, that's where there's a lot of investment, a lot of work going at the moment and genuinely, you know, exciting technologies emerging, but there is still verification to be done. Okay.

Well, we'll keep watching for those studies to roll out and for the audience, I'll be sure and tell you about it in my newsletter when, when those things happen, because in the back of my head, there's, there's still, you know, that little voice that says, but suppose someone else does have your fingerprint. Yeah. And I think that's a trade off then between yeah. Convenience and security you. So would you always wanna combine that with a secondary you factor such as a secure pin or, or, you know, another factor or even a hardware token in some environment? Absolutely. Right.

But you know, it's about, you know, is it good enough to unlock your iPhone if that trade off, which is the key discussion look only they can decide Exactly. I wanna remind everyone that if you have questions, you can type them into the little question box down at the bottom and we'll get to them as best we can at the end of the session.

Right now, we'd like to move along to Jerry Gable. He's the president of axiomatic Americas. And he has some things to tell us about authorization and how we can, how we can make that a better, better activity.

Go ahead, Jerry. Thanks, Dave, can you hear me okay. Hear you fine. Super well. I appreciate following the authentication discussions so far, because that's typically where our systems take over, you know, that is what can you do once you are authenticated. And what we wanted to discuss today is how you can incorporate some different kinds of risk analytics into the authorization function and get beyond some of the, the basic kind of access control models or, or use cases that maybe we are, we, we see more commonly.

So before I get into all of that, I want to make sure we're, we're on the same page here on what we mean by authorization and, and in particular externalized authorization, where similar to how Jamie was talking about so many applications, having their own authentication method, we see the same thing in authorization. And so what, what this model allows is that you decouple the authorization from the application, and now you can manage this more centrally and external from the application. So you can make changes more easily.

And some of the things this allows is a more contextual authorization, so we can get beyond identity based access control and get into more attributes, more of an aback model. And one of those attributes can be risk metrics or risk analytics, for example, based on how you authenticated. And of course, in this space, we're talking about a standard, you know, if, if we can standardize on how, how to do, excuse me, how to do externalized authorization, then that gives customers a well designed solution, gives them opportunities for interoperability and vendor choice.

And, but we also need to consider some of the drivers, you know, why are we trying to do these enhanced or externalized authorization implementations and, and approaches? The first one is, is consolidation.

And, and this goes back to another comment that Jimmy made about the different silos of authentication. We see the same silos of authorization. So you can imagine the added expense and complexity of the environment when, when that is the case, also an enhanced security, this is where some of the risk metrics come in and being able to incorporate a number of different risk scores or risk metrics into the authorization equation. And then we also see business drivers for enabling new business models or being able to securely share data within organizations and with external parties.

But of course there's always the, the compliance and legal constraints that people have to adhere to based on their, their jurisdictions, or if they're a global operation. And if we look at this from an architecture perspective, cuz this is important in thinking about how the system is, is operated and implemented. We have to think about the architecture of a typical authorization system.

First, you have a policy enforcement point that's in the flow of the access. So this is what's going to stop the, the flow and pose a question to a policy service that has a number of access policies, but it also has the ability to look up additional information through what's called a policy information point. And we'll be coming back to this later because this is typically how you would look up information about a particular risk score or some other kind of risk metric.

And then finally, in these authorization systems, as in many other systems, you have an administrative and management capability so that you can alter the policies, incorporate the access rules and attribute sources, risk scoring sources, and manage the overall operation of the environment. And most commonly, you know, and, and most typical authorization deployments, you have a number of basic attributes that are used, you know, the role of the person. Are they a manager? Are they a contractor? Are they a customer? Are they an engineer?

You know, these different kind of attributes about the user are used in access rule evaluation could also be dependent on their department, their cost center, their location, and their relationship to the data that they're trying to access. But then we can have additional attributes that are more risk related, become incorporated into the access decision process. For example, what is the transaction amount? Is there a threshold where you want to take a different kind of action, maybe additional logging?

You know, if the transaction amount is over 10 million, for example, of a, you know, funds transfer or, you know, some kind of payment limit, and then you can have additional risk scores based on metadata, for example, about the user's location. And this could come from the device, you know, what network segment are they accessing the data from? Is it a local on campus network segment that I'm confident is, is in fact valid or are they accessing the system from a remote location?

Also, you can, you can take into consideration the type of device and make decisions, whether it's a, a tablet or a mobile phone versus a laptop or a, a desktop machine. And this could just be for rendering of the right data, but it also could be for what amount of data gets released to the device. Furthermore, is the device owned and registered by the corporation or the, the enterprise, or is this a, B Y O D scenario where you can, so now you can incorporate these kinds of data or attributes into the access control process.

So, so there, here's three different kinds of examples where we see customers incorporating risk metrics. And I've touched a little bit on, on this so far, but let's expand on it. Furthermore, the authentication risk, I think, is pretty commonly known as adaptive authentication, where you can assign a risk score based on a number of factors, you know, the strength of the authentication, which has been discussed previously on this webinar.

Again, the type of device, is it a registered device or not, and, and a score could be assigned through various kinds of algorithms in other products to the risk level for that particular user. And, and that can be used as a threshold within an authorization policy or rule. The next example here is, is kind of different.

And we, we see this coming up from time to time and we call it an access governance risk. So we're all familiar with a couple of things here, high privileged users. These are just valid users within your organizations that either through their seniority, with the company or their role in the company, they have a lot of access to a lot of systems.

Well, maybe we want to handle them a little bit differently. It makes sure that extra logging takes place when, when these users are accessing the system. So we can keep, keep track of what they're doing. That can be a part of the access control rule. Another way to look at this is examining whether or not users have been certified on schedule.

You know, there's a, either an annual or a six month review, typically in organizations for users within a department, are they still in the department? Are they in the right role so that their access can be certified?

Well, what if my manager skipped mine the last time around, maybe I want to increase the risk score for, for users in that category and make different access control decisions based on the risk score for their governance. You know, have they been reviewed recently because that can reflect how confident I am of whether they're still in the same department enroll and so on. And then finally at the bottom here, some of the business risk metrics, and this is where you can put in these different thresholds for spending limits or trading limits.

And again, incorporating attributes about the device that's accessing the system. Is it in our managed device category or is it a, B Y O D type of device? And so again, we can make different decisions based on this. And here's just a simple rule that shows an example of it. This is not a full exact Mo representation, but more of a shorthand representation that we call alpha. So in this case, I'm incorporating a transaction risk score. If it's less than five, then I'm going to permit this transaction.

If it's below the user's approval limit, but even this number can be a variable instead of hard coding five in the policy. I can have that as a variable that a business owner can manage in a separate database. And I can also look up this transaction score or, or what's the current threshold for the transaction risk score. And that's something that an authorization can system can do is, is to look up this data at run time. So you get the most dynamic and up to date information.

So a couple of things to think about before we go get too crazy with incorporating different kinds of risk scores and risk data. As I mentioned, we do look this information up at runtime through what we call the policy information point earlier in the architecture. So this has a benefit of being very dynamic and up to date. So you don't need to synchronize this risk data into the authorization system. It can retrieve it from the business applications that are already managed, want to be re-architecting or re-engineering applications.

Every time we need to implement a different kind of risk scoring in the policy, but you have to be careful about the performance of the system, because you can go crazy and add lots of look. So you have to be careful how you architect and design your solution, just to be sure you can meet your performance requirements. So to make sure we have enough time for questions, Dave, I think we can turn it over to you and, and see if you have any questions or questions from the audience. Sure. Thank you very much, Jerry. That was an interesting presentation.

Now, generally, when we're looking at, you know, rule based access control like this, we think of it as binary. We either decide yes, there's access or no, there's no access, but can it be graded?

Can we, we change the degree of access based on That, that could be possible because you can, for example, you can send information back to the application that a, a trade of $10 million is denied. But if you go back to 5 million, it will be approved.

I mean, so you can send messages back to the application with, with, with that kind of information. Okay. But we need to integrate then with the application in order to do that.

Right, right, Right. Because, oh, but you're right. Basically the decision is binary it's either yes or no. Okay. We're starting to run out of time here, but we do have a couple of questions and, and we'd like to get to them before we have to sign off. I'll remind people if they do have questions, you can put them in now. And if we don't get to them during the session, I believe we'll be able to answer you privately. Once the session is done, otherwise you can email a question to me, DK KuppingerCole dot com and I'll make sure it gets to the right person to answer it for you.

But I do have here one question, and it appears to be for Brian, the questioner asked if they need to authenticate to each site individually, or can I easily connect once and either federate or use some sort of SSO to connect to multiple sites that are using the M pin server. Yeah. The question is all the answer is all of the above. So The MP server really is just a drop in replacement for username password in all contexts.

So if you think of it in that case, once you are authenticated to the, what is called in, in SSO parlance, the relying party application, when it decerts the M pin authentication token verifies his signature. And it says, yep, the MPI N server said, this is Brian. At that point, you know, a product like axiomatic could take over and say, okay, well, based on some more information inside of the MPI authentication token, we apply a rule based score or just let 'em on into the application.

And if the application itself is federated through SSO, so it, it provides a session cookie that's recognized across multiple websites, or you used M pin as the authentication MEChA mechanism on an open ID connect and enabled website, for instance, and we're releasing an open ID connect SDK for this very purpose, you can federate out an M pin server to end number of sites. So it's really up to the implementer to decide how they want to do it. Okay.

And Jamie, I assume you'll, you'll agree with that since you were talking about Fido and the F is for Federation, isn't it? Yeah.

I mean, one of the keys about fi which faster, actually faster online, but the, the, the, the, the, it supports Federation the service side, but yeah, each, each site and each device is a unique key in a sense. So there's two ways of doing it. You can plug it in so that your device might be built a curing or yeah. It can be plugged into a, into an internal enterprise. Exactly.

So that, yeah, one server which will then federate that strongly authenticate credential via, or via you open ID by Sam, whatever the, for the language you, you wish to work with. Okay.

I know, is there a number of questions that we're just sort of stating in a different way? What I asked you, Jerry, about the ability to, to augment or adjust the authorization level based on the, the risk score. And as you said at the time, it depends on, you can reflect that information to the application, and then it's up to the application to actually do its thing, potentially.

Yeah, go ahead. Sorry. I was thinking about that a little bit more. You could also have different rules developed that account for different risk scores and, you know, the, the rule that matches the risk score could you get fired off so you and this would allow or disallow different functions within the application. So I think there are different ways to approach it where you could have multiple rules that permit or permit or deny different functions, or you could have more of a dialogue back to the application, so it can react to that data.

So, so essentially we could have a, a, a, a, some nested if then statements as it were, if, if risk score is higher than X, do this. Otherwise if risk score is higher than Y do this, otherwise if higher than Z, do this otherwise say go away. Yes. Something like that. Okay. We are just about out of time now. So we're gonna be signing off a reminder about the tool upcoming events that I told you about at the beginning of the session in November, the information risk and security summit. And then of course, next may the European identity in cloud conference.

Just a quick note to tell you that my next webinar will be about access governance, which is the next step after what we've been talking about here. And that'll be coming up in early November, watch the KuppingerCole website for more information on that. And with that, I'd like to thank Brian and Jamie and Jerry for being with us today, giving us some great information. Thank all of you for attending and hope to see you again soon. And with that, we're out.