Good afternoon, ladies and gentlemen, welcome to our KuppingerCole webinar. Top considerations for selecting an identity and access management as a service. When so on I ask this webinar is supported by Centrify. The speakers today are Barry cut, who is chief technology officer at Centrify and Martin Kuppinger I'm founder and principal Analyst at Ko a coal. Before we dive into our content, just some quick words about keeping a coal and some housekeeping information and some information about agenda for today. Keeping a call is an international independent Analyst Analyst organization.
We are focus on information security, identity and access management governance, and a lot of topics around the digital transformation provide advice, expertise, or leadership and practical, relevant information. We have three main business areas which are research, where we provide our research such as the leadership documents and other types of research around trends around rating of products and best practices and how to information.
We have our events, including our webinars, our conferences, and talk about this in a minute.
And we deliver our advice for service, where we provide render neutral advisories, for instance, for tools choice for maturity assessments, readiness assessments, and in other areas such as strategy development and roadmap development. Looking at the upcoming events in, by the end of the year, we'll have our consumer identity world conference with the two events in Paris. So the European one on the Asian one in Singapore, we will do a rec tag world early December and end of February, early March.
We will run our digital finance world, which looks at the digital transformation in finance over very relevant, very hot topic. And then our flagship, we went with may next year, which is European identity cloud conference, which we were under 12th time and MUN.
Again, the conference around these topics, I would say not only in Europe, so definitely a master 10 went in the area of advisory. We have a new offering, which is our GDPR readiness assessment. So the channel data protection regulation, which will become effective May 25th next year, where we provide a standardized approach on assessing your readiness for that and identifying the actions you have to take to comply with that and to mitigate the risk of non-compliance.
Our agenda for today is split to three parts.
In the first part, I will talk about the challenges modern businesses are facing when expanding that cloud option with a focus on the regulation on one hand in particular focus on what does IDAs mean for that? And so why can IDAs help here? And the second part then various Scott will talk about pain points of specific organizations, outline approaches towards design, right strategy and selecting the right data vendor to support in the third part. Then we will have RQ and a session. And as always, you can enter your questions at any point of time. So feel free to enter these questions.
We will record the webinar. So the recording will be available latest by tomorrow, as well as we will provide a slide deck for download them. So we will get access to all that information afterwards.
So let's directly start our identity as a service or identity and access management as a service has become a, an increasingly popular market segment over the past couple of years. So it's not that long ago that IDAs started as a market segment. And right now it's some, it's a very popular segment already.
However, it's not that there's one fully consistent approach, but what we observe is that there are various approaches on I DDAs for our current current leadership compass documents. I have split this into three areas. The two leadership compasses are out and I will look at one of these more detail later in my presentation. And then there's a third area. The I'd ask for digital transformation where I'm just finalizing the leadership compass service will be out probably in the early in November timeframe. So I looking at IDAs, the one area is IDAs SSO.
So really just focus on single sign to the cloud, where which started originally at how can my employees get a single sign on to all the cloud services, which are procured in my organization over time.
This has started to change and to evolve, extending the focus beyond employees, to customers, adding support for on premise applications, integrating with existing directory services in particular active directory, which has deployed in many, many organizations and also more frequently supporting mobile management capabilities because many of users come in with mobile devices and want to access the cloud. So how can you manage that?
On the other side, we see the for BWE, which is, is more sort of migrating the standard identity provisioning identity and access governance or IGA, or it tools to, to the cloud. In the sense of they are deployed from the cloud.
They provide full identity provision capabilities also to the OnPrem environments, adding access governance capabilities here, strong focus on the employees approach here, but as a service and not on premises, several of these solutions in these Ida for B2 E space in fact are not turnkey cloud services in the way we see them in the I O space, but they are more sort of a managed service offering, but with a more, an elastic deployment model with some paper use or a similar type of licensing model.
So they're sort of shifting to the cloud, even while some of them you might argue they're another full cloud service here. When we look at a digital transformation thing, their focus is down the increasingly complex relationships across the entire supply chain and value chain. So integrating customers and consumers, employees, business partners, and very frequently also including specific support for collaboration. So really enabling this identity management across the entire supply and value chain from the supplier down to the consumer.
So this is what we see and what we expect to see there is an over time, more and more convergence of these segments. We already see some convergence with SSO going beyond pu play employee SSO to the cloud. So where some of the consumer aspects come in by some of the suppliers of the solutions, etcetera, but basically they it's, it's building around the IDAs core, which so that's okay.
I need to federate out to cloud services. I need to be able to support proprietary sort of mechanisms for provisioning and sign on at other things in various areas. And one of these areas is collaboration.
So enabling the collaboration between the various types of users, one is integration into directory services or providing own directory services. One is identity provisioning. So more support also for on-prem and also better support for provisioning to the cloud services, because this is still one of the shortcomings that things are on is the problem which should solve quite frequently while provisioning. So configuring the users, controlling access is less frequently solved access governance capabilities.
So really the, the getting a grip on who has access to what who's allowed to access, which servers and which role etcetera, these things and mobile management. So we see that conversions and it'll be interesting to see how, how close these various types of servers come to each other, and then which other evolutions we might face.
So consumer identity playing in that field as well as another type of frequently as a service delivered identity management.
What, what I think is very important is that when we look at this, this market, something which is a cloud service only, so an I Ida service, and as a service solution, only for managing access to the cloud, that's not sufficient because the hybrid reality of business or the reality of businesses that most of them are hybrid and will remain hybrid.
So even while we see an increasing number of businesses following a cloud first strategy for, for a variety of reasons, at least perceived cost reduction, revenue deployment services that haven't been available for small and medium businesses, most businesses still have a strong on premises. It, and if you look at banking insurance course, many of these will remain here for a very, very long time, right?
In manufacturing, if you have a manufacturing, then you will remain hybrid because that's a part of it remain your own factories. So we see more services moving to the cloud.
We see an uptake, a strong uptake, but cloud only enterprises aside of startups, which sort of started as cloud only from the very beginning and small businesses will be rare. So reality is most it will remain hybrid. And that means IDAs mass support hybrid environments being strong SSO for cloud services is important, but it's not enough that leads us to the question, what should we look at and how should we select an IDAs provider? And so there's the, the general way of selecting a provider, which is not very different from other vendor selections.
So this is sort of standard tools, choice scenario. The first thing is you need to understand your requirements. You need to understand what you need today and what you most likely will require in the foreseeable future.
But this is where it's important to, to really look at, look beyond sort of the, the, the arching need to, where will this go? What is your strategy, understanding where you are heading, then you need to define your requirements. So understanding, defining them, listing them, understand the market.
So what are the layer in having a long list, reducing it to a short list, and then the usual request for information request for proposal or quote, the selection of vendors or proof of concept, and then you should run a POC with. So the typical solution is to run it with two providers, decide and implement following a well sought out rollout plan. So understand what you want to implement in which order etcetera, give your, if there's customizing, there always will be some customization, have a nuclear plan on how to customize it. Having it process is defined, all that stuff, being ready.
So this is the sort of the standard process. And right now let's have a look at sort of required capabilities. So what are the required capabilities? When we look at I vendors, particularly when we look at the I, so vendors, obviously outbound Federation on single channels. So outbound Federation, meaning federating two cloud services, web applications, but also being able to provision users to these services, create a user account, doing at least some level of, of access control. Here. We obviously need a directory service. That can be one you already have. That could be, can be one.
You create. That could be one, which is part of the Ida service, but directory services are obviously as well, a very important element in when selecting your I service. So you need to understand where do the user authenticate, where are they managed? What does it mean for your director's strategy?
If you have multiple directors, if you have different types of users, all these things must be defined.
And, and the requirements obviously are changing over time. So more complex relationships, different types of users beyond the employee, other require capabilities, authentication support. So it's very important to be flexible regarding authentication. That's true for your employees because they are getting more and more mobile and they want to use a convenient way of authenticating with the mobile device of their choice. And that's choice will be, will change over time. So what is the hype device of today might be totally outdated in two years from now.
We don't know, no one really can predict what the next hype device will be. We need to be flexible to support them, our standard Alliance, et cetera. We need to be able to control the access. So having policies which control, who is allowed to access, what, the more fine crane, the better, in many cases with IDAs, we still end up more with very cost create approach says, okay, Martin is allowed to access that cloud service, but not to access that cloud service.
We are not at the end of the journey, obviously, but it's important to have good capabilities here and the better, the more granular they are, the better it is. And then also we, we see a strong demand, a strong need for, for inbound Federation, S so more and more of the uses. Particularly if you go beyond your, your employees will come from other organizations from other services. So consumers might come in through public identity providers while others will come through the directors of your business partners, etcetera.
So inbound Federation supporting them to Aus Kate, and then do be passed through the Ida solution to your cloud services increasingly important, and also sales for registration. When you look at business partners, customers, consumers, self registration becomes more and more important. So these are some of the, the key capability areas. And then when you look a little bit more into detail on some of the aspects to evaluate, when you look for, for an Ida solution, we find a lot of these.
And so our leadership compass, for instance, it goes very much in detail on many of these, but to give you some, some, some idea about what, what are, which others think we rate high in which we find of particular importance than we, for instance, FG on premise to creation, which is integrating back to existing on premise IM environment. And clearly also the directory services such as the active directory. So in many organizations, still a lot of people rely on the active directory to authenticate.
You rely on it to manage the desktops and many other stuff, and it will not, you will not get, get rid of it quickly. So support what you have support onboarding of externals. I already touched it, self registration, flexible authentication schemes. They might come in with different ways to authenticate than, than your, your employees to clearly very important aspect is the location of data centers.
It's.
So I'm from Europe and Europeans frequently ask for that location of the data center due to the national, or in future that you data protection laws and the concerns in general regarding where does the data reside and having good answers on that is important APIs application programming interfaces. So how can you connect to this service? So not having only a UI, a graphic interface, but the ability to, to integrate your applications to, to automate cetera. So we expect boost breadth, so variety of capabilities and depths.
So really well sought out and very, very comprehensive APIs for managing, for configuring customizing services. Rest based APIs, reporting capabilities obviously are very important thing. Also integration with existing reporting tools, et cetera, the number of preconfigured cloud services for rapid provisioning. Another very important thing. So the more services are supported, the better it is.
However, it's not only about the breadth, so to speak the number of preconfigured services, but it's also about the death of these services.
So to which extent can you really control the integration? So it's really only an authentication, or is it an advanced control of entitlements? Is there provisioning support to the Ida services? Can you configure this? Can you go more into detail? This clearly depends very much on the, on what the cloud services expose.
Many of the cloud services are not very good in exposing the interfaces for managing identities and access, but if there are the interfaces and the better ones have it, then you should be able to use it, which also leads toity of access control policies. You can set the more flexible you are in the, in the depths of sort of integration with cloud services, the more granular your access control can become strong authentication as well. Not a highly important area. You need broad support for strong authentication, step up authentication, adaptiveness, all that stuff, support for standards.
Very obvious we're talking about cloud. So it's about standard support.
Yes, and it should be a cloud service in the sense of elasticity, flexibility, and upgrades, cetera, getting the service levels to support having this required level of security, having mobile management in. So there, there are a lot of aspects to look at when, when, when trying to select the Ida provider, there also some emerging areas such as support for new standards, such as human manage access, managed access and pH Alliance standards, which are upcoming more importantly, obviously full and strong Sam and OS and open ID connect support.
I'm a big believer in having some sort of a graphically workflow for adaptation, for instance, of S processes provision to the cloud. Very important ski standard support is one element of it, but should go beyond to already touch the APIs. They should be comprehensive, consistent self-service interfaces for all the common requirements authentication.
We already touched mobile management. We touched. So there are a lot of things we look at when we, when we do our leadership, there are a lot of things you should look at when selecting an Ida provider.
What we do then is that we create our leadership compass documents and I trust have on the next four slide, some the high level results, the high level overviews from that recent leadership compass, Ida SSO, as always with these things, my sort of warning is don't just pick a vendor. Who's sort of the, the, the, the topmost in the upper right on the right side, look at your requirements, just specifically requirements, go into detail. So this helps you getting more information and our leadership composers, they have 56 70 pages.
So they really go into detail, but it's not that it's only what is sort of the generic view, the best one, always the best fit for you.
So really go into detail, do a rough evaluation, do a rough process, but obviously vendors which are strong, usually are the ones which have a higher tendency to appear on your, when you're short list than be used for deeper evaluation, but they're always our specialists and some of these specialists might be the better fit. So what we do is we look at an overall leadership.
So the more to rewrite the higher rate, this overall leadership, in fact, combines market leadership, product leadership and innovation leadership, which are three categories. I look at in a little bit more detail right now. And so one of these categories is the product leadership. So product is looking at the overall product features from, from very broad perspective. And we see there's a tough competition, so entire group of leaders here. And so this report is also available through Centrify and a very, probably touch on this and his part.
We have to innovation leadership.
So looking at what are the most innovative vendors from our perspective and having the most innovation features. So the, the horizontal access by the way is always the overall leadership, the vertical access in that case is innovation. So they're more on top. They're better rated innovation. The more to right, the better rated the overall leadership. So this is the picture we have here. And we see a lot of innovation in this market. Obviously it's a new emerging market with a lot of new ideas, but also when there's really picking up these areas, we see as important.
I, I already touched them for, for the, the innovation leadership. And then we have the market leadership, which is about not only the size of the vendor. It's about number of customers. It's about a size of customers to size it's about the global ecosystem. So if you are world famous in the Germany, so to speak, it doesn't make you a global leader. So you need your partners across the globe. You need your ecosystem across the globe to, to really support your customers data center and various locations, et cetera. So this is our review we take.
And as I've said, the document is published and their other leadership published with that. I hand over to Barry, we'll do the next part of the presentation and make him center. So Barry it's U-turn
Good afternoon, everybody. Thanks very much, Martin. My name's Barry Scott. I'm actually the, the EMEA CTO for Centrify. For those of you who haven't heard of Centrify before, we're basically a security vendor we're in the identity and access management space. And there's really two areas within IM that we cover. One is IDs, which is the subject for this afternoon identity as a service.
And the other is privilege management. And I won't be going too deeply into that this afternoon, except to, to really just touch on where it interfaces with.
I'd a, so moving on from what Martin Martin has been going through so far, just really to sort of set the scene of where we are today and to give you some sort of recent security updates, shareholders aren't safe. So we, we had a PON study recently about four or five months ago, which states that the average stock price tends to drop by about 5% after a breach has taken place.
And also 30% of consumers tend to discontinue the relationship with that particular supplier. I must have made, I've made a mistake on the slides here.
I thought I'd updated this to a more European one, but there's a company called Chipotle in, in the us recently who had a big breach and there was a 400 million loss to their shareholders. So the shareholders aren't safe, also consumers aren't safe either, unless you've been living in a cave for the last month, you'll have heard about the Equifax breach, 143 million consumer details stolen had an 18% impact on the share price. In the first four days.
We've also had the announcement of the SCC last week, and the fact that the, the big Yahoo breach in 2012 or whenever it was, was actually 3 billion records rather than what was originally thought. So consumers have a problem as well. And also governments, of course, the office of personnel management in the us, couple of years back, lack of strong authentication and thinking of privileged accounts resulted in 25 million records being stolen.
And also the companies aren't safe, you know, DNS provider knocked off line by botnets all of these different companies being affected by that sort of thing.
So just moving on 80 billion was spent roughly 80 billion were spent on security in 2016, but two thirds of companies are still being breached. So there's something ADR here somewhere and, and even worse, they're being breached on average five or more times, those particular companies. So there's a problem here. The enterprise perimeter no longer exists.
Either there, as Martin has mentioned, everyone is ultimately becoming hybrid, but 90% of enterprises are using the cloud. There's 150,000 enterprise cloud apps, allegedly 8 billion mobile devices.
And, and the number of I T devices is just going up week on week and is becoming Absolut, absolutely colossal. And the important thing where we start to talk about IOD a is identity is the top attack factor. If you look at the da Verizon data breach report, this year data breach investigations report, it's at 81% of breaches involved, weak default or stolen passwords.
That's up from 63% the previous year, which was, was quite shocking, 80%, according to a, a Forester report, 80% of breaches involved privilege, credential misuse as well. So identity is a big problem.
We need to, to get a handle of it, not only for the end users, inverted commerce so far as IDAC is concerned, but also privileged users as well. So there's a new threatscape effectively.
The, the firewalls have come down. We no longer, you know, one could assume that we're still spending money to fix old problems, but the firewalls have come down.
You know, the users are inside or outside the services they want to access, or the systems they want to access are inside or outside. And actually assuming there's a boundary, just a boundary and networking terms, just isn't really the right thing to do anymore.
So if we look at one of the changes we have to think about, if we look at risk on the left hand side here and users over to the right, we go through from the, the number of users that we have, the number of privileged users on the left is obviously pretty small number in our workforce is getting bigger.
The number of our partners is quite large. Nowadays, a Gartner report recently said a hundred percent of us allow external people access to our networks. And the number of customers is, is obviously huge and related to the number of privileged users. On the other hand, though, if we look at the actual risk of those accounts, if, if I lose my identity to my cooking, a Kohl account, for instance, it's not a big deal in the global scheme of things, obviously, if all of the users were to lose their identities, or if they were to be THF by somebody, then that becomes more of a problem.
But generally the, the kind of risk of these identities is almost inversely proportional to those particular users. But the point is we've got to secure access for all of the enterprise identities. It's not good enough just to do privileged users or end users or customers. We have to, to cover the whole piece to really address our, our potential risk problems.
So, as I've said, there's, there's a need to secure identities everywhere. So what we're talking about this afternoon with, with ID a is stopping breaches, that target applications. So there's just so many apps out there. And so many different accounts in very of in many situations, many people have far too many accounts. People are increasingly working in the cloud as an increasing mobility. They're looking after their own passwords. There's many password reuse, unsafe practices.
And so on provisioning and deprovisioning is a, is a nightmare as it has always been many orphaned accounts lying around the time to be productive for new employees can be quite, quite poor as well. And also we need to address remote access as Martin Martin said, you know, it's been strong in cloud single sign on isn't enough because we still have, and we'll always have those applications that are living on premise, those, those servers and things that are living on premises that we still need to gain access to from remote places.
So that's stop stopping breaches that target applications, but we'd also gotta be looking at stopping the breaches that start on end points. So the, the advance of bringing your own device over the last six or seven years has, has obviously given us a load of headaches, the number of remote workers, the general mobility, the fact's too many apps managing local administrators.
You know, many companies now will have only local admin account for every device that goes offsite, every laptop, every Mac, every windows machine. And there's a lot of weak authentication about. And also we need to start bringing in the, the context of the user's access and whether we trust that cap context and what they might be up to. We've also gotta stop breaches that are abusing privileged access to our infrastructure. So it's slightly outside the scope of today, but again, we tend to have too many accounts, too much privilege.
Generally people have got too much access to too much stuff from too many places that they really don't need. We need to safeguard about against stolen credentials across the whole piece. We've gotta expect that we're gonna have a heterogeneous infrastructure as well, not to mention a hybrid infrastructure too. And we're gonna be allowing remote people access to our systems, this huge infrastructure as a service adoption as well, the likes of AWS, as you Google compute, it's, it's really coming on a lot faster than I think a lot of companies expected it to.
And there's an increase in burden in, in regulatory compliance as well. That it's very important that we address.
So we need to implement best practices for identity and, and the diagram we have here on the left hand side, we have risk on the, on the vertical, the Y access, and really the further up there we are, the more risk we have in our environment. And what we want to do is move further over to the right, to a state of good maturity.
And another figure in the PON report that I mentioned at the very top of the presentation, they found that companies that were breached because it's still gonna happen to people, companies that were breached, they recovered quicker. If they were more mature in their security posture, in their identity and access management practices. So we see lots of people who are in this danger zone. They've got too many passwords, they have too much privilege.
You know, you have a different, a different password for every SAS application, a different password for every server, a real nightmare situation.
So what we first want to do is establish identity assurance. So consolidation of identities now, as Martin mentioned, lots of people are using active directory and will continue to do so for many years. So they want to be able to, ideally we want to use that security principle from active directory to be able to authenticate to all of these different places that you might have to authenticate to.
So that leads us on to having single sign on everywhere. And that's really where the, the IDAC side of things comes in. We want to have full on federated authentication. Okay? Sometimes we're gonna have to do some password replay, but, but you as customers should be demanding of your vendors that you have federated access with single sign on. So that this, this password, which is such a problem for us, isn't exposing us to more risks than is absolutely necessary.
So we've consolidated the identities. We've got multi, we've got single sign on everywhere.
We then want multifactor authentication everywhere as well. It's with the best will in the world. Your passwords are never gonna be incredibly strong. You want some method of backing that up, and that method is gonna be multifactor or two-step authentic. Two-factor authentication, whatever you'd like to call it. So that needs to be everywhere as well.
It doesn't matter if it's your end users accessing NetSuite or office 365, or, or if it's your Oracle admins accessing a database and shutting it down, or Unix admin accessing a server and changing some configuration files, you should have a consistent approach to MFA everywhere across the piece. But the problem with MFA and in, in the ID, a solution with end users, especially the problem with MFA is that people get fed up with it.
They get, they get irritated by being constantly interrupted by, by requests for multifactor authentication. So this is where risk based access comes in.
And it becomes important that if, if Martin is sitting in his office in Stuttgart, wherever he might be, then that is normal behavior. He should be allowed to log in. He shouldn't get hassled all the time for, for multifactor authentication, but if he comes and visits us in the UK, he should possibly because that's out of the ordinary for Martin, he should have step up authentication, but it's gotta be dynamic. It's gotta be based on that particular access at the time. It shouldn't be static rule based just saying that he's outside Germany, it should learn to adapt.
And if he, if he's frequently in our office is in bra, then, then it should learn that that also is part of the normal, which is, was, which is that user's particular behavior.
So very important that we have that as well. So having established identity assurance, if people do get into our network, we wanna limit lateral movements. So we need to establish zones of systems require access, approvals, automate provisioning, and all of that sort of thing.
Now, automating provisioning, of course, as Martin has mentioned, is very important around the SA applications, especially, you know, you need to support scheme. You need to have flexibility around how these applications work, how they're provisioned, and so on. Also minimize VPN access.
Again, we've said already that it's not just about single sign on to cloud apps. It's also about having single sign on for the guys that are outside accessing your internal apps. VPNs are notorious for being the source of breaches. I'm sure we can all think of a couple where it started with a VPN. So secure point to point access from your road warrior, sitting in the coffee shop to an on premise application without having a fire up a VPN.
It's very important, very useful as well, because you don't end up with these kind of, kind of fractured remote access solutions that are lots of horrible bits and pieces trying to, trying to interact with each other. Then we get into least privilege.
And I, I, I won't talk about this too much today because it's really outside the scope of, of identity as a service, but in terms of least privilege at the application level, it's generally around. Do you have access to the application particular parts of the application or not to servers to network devices, obviously least privilege means something slightly different.
It's, it's logging in as yourself, and then being able to execute particular commands out of the role that you find yourself in. You should also be able to request access to things as in when you need them. So that's what the just in time privilege and just enough privilege is about, and also on a purely PIM type privilege level, don't break glass use, don't use overly privileged account if you can possibly avoid it.
So then we want to get ourselves into the optimal state. We wanna audit everything. We want to analyze the risk, going back to what we said earlier about the risk based access.
We want to be able to monitor people's sessions. We want to integrate with SIM solutions.
So again, as was mentioned that the, the ID a platform, if you like, it needs to be able to integrate it needs to, to be accessible via APIs. And I think to be honest, as, as time goes on, we'll find that the way that, for instance, we, we present the Centrify service that just happens to be our skin on top of it that we've designed and more and more customers will be actually using the rest APIs to use the functionality of the, the engine, if you like behind it all.
So it's really about in terms of the vision it's secure access for all enterprise identities and, and Ida is a very important part of this because that's about securing access to apps that you see on the left hand side here, regardless of whether they're on premise off premise, regardless of where the user is as well and secure access to infrastructure, a really classic point of crossover here is if you look at AWS, you have traditional CIS admins who need to log onto systems in AWS.
And that is a pure privilege management kind of use case if you like, but those privileged admins also need to have Sam federated authentication to the AWS console itself. So the idea of end users being the I'd ask people and admins being the privileged user people, that's all gone.
Now, it's all, all gray across the, across the two spaces.
So secure access to infrastructure cloud on premise hybrid, cetera, cetera, and from any endpoint users demand to be able to use their Mac. We we've got a very strong MDM solution within our ID. A because you know, it, it all sticks together in that you want to use your end. You want to use your iPhone for multifactor authentication. Therefore it needs to be strongly managed in the first place so that it can be trusted so that it can have access to those apps that you want.
And it's gotta be for all users, as well, as I've said, it's, it's end users, it's privileged users, it's your customers. It's outsourced it. And it's your business partners as well.
So in terms of what Centrify offers, what we've been talking about today, it it's a platform solution basically. And what we've been talking about today specifically is the application services on the left hand side.
So just to go through it again, single sign on adaptive MFA workflow, lifecycle management, the mobility management is very important and also access to the on-premise apps, as well as just single sign onto SA apps in the cloud. Managing the endpoint is important, various different features there that you can see endpoint management in terms of infrastructure it's integrating systems, units, Linux, et cetera, with active directory, it's adaptive MFA for, for privileged access.
Like I've explained for application access shared password management is part of privilege management as is well secure, remote access, very similar to the, to the application gateway so that people can have access from remote to, to onsite systems.
And of course, auditing and monitoring and there's core services that live beneath all this, the application service is offered as a cloud service, a multi-tenancy cloud service and beneath it there's, there's its own directory, as well as using active directory. Or you might want to use Google directory.
You need multiple directories, as well as time goes on, you need a central point of policy. You need the Federation engine behind it all. And the workflow and reporting that I've mentioned then across the top analytics, this risk based user scoring, is this a normal access for this person to be doing at this place? Or should we block it, or should we just do app leveled authentication?
So this just drills down a bit further.
I put this in more for, for those people that look at the slides later, but it, it really just repeats the, the, the previous slide about application services being the piece that stops breaches, that target applications. So single sign on workflow, adaptive mobility management, the application gateway as well, and, and really just rounding off because, because we produce software that covers a, a multitude of sins as it were, and that we're in the privileged management space, we're in the Ida space as well.
Some people are concerned that they might be losing best of breathness if that's such a such a phrase, but you can see there we're in the cooking, a cold leadership compass as Martin described earlier, we're in the, a leader in the Gartner ID, a MQ, the critical capabilities report that came out with last year.
We were at the top of that for ID a, but we're also a leader in the Forester pin wave as well. So it is across the whole piece.
There's no need to be concerned about compromising quality by going for a platform solution that happens to include ID a and I think just a brief summary, what we're doing, addressing the top attack, vector, compromise, credentials, the password is still a problem for us ultimately. So doesn't matter if it's an ID, a solution or PR or pin solution. We have to stop those breaches that are targeting end users and a privileged account centralized the only end to end platform, addressing the identities for apps, users, and infrastructure and supporting on-premises cloud and or hybrid environments.
You know, I think the pendulum has settled in the middle. Now, everyone was charging off to the cloud about two years ago, then they were saying, they'd never use the cloud. And now we've reached this sensible point in the middle where let's face it. We're gonna be hybrid from here on in, I think, and we're trusted by over 5,000 customers, including more than half of the top fortune 550, rather. So that's it. Thank you very much. That's my piece back to you, Martin.
Thank you,
Barry. And so let's continue with the Q and a session right now. I have to make me to presenter. So here we go. Time for a Q and a, and it's time to enter your questions right now. We already have a couple of questions here.
So, so the first question I wanna touch is can you explain the architecture of your Ida solution a bit further?
Okay, good. One to start with. So I mentioned that it's a multi-tenant cloud based solution currently based on Azure. So each of our customers will have their own tenant. There's a couple of customers have got, who have actually got, what's called a pod of their own, but the majority will have one, one tenant might be in EA, might be in the us. So that addresses the, the, the location of data that you spoke about earlier.
But, but to be honest, there's not that much data held in a, in a cloud service. So multi-tenanted cloud service. Now within your environment, typically as just been mentioned, we're gonna connect active directory up to that cloud service so that ad users can log in and what we have on premises, we have one or usually more because you want resilience, what's called a Centrify connector, and that's a multifunction service that lives on a windows machine.
And basically all it does is it makes outgoing in terms of connectivity. It makes outgoing HTTPS connections to your tenant.
So there's no need to put anything in the, in the DMZ. There's no need to puncture loads of holes in your firewall. And basically that's what talks between the tenant and makes sure that active directory is available for the mental authentication and such like also we'll have, through that tenant, there will be settings pushed down to the, to the mobile devices that, you know, the iPads, the Samsung devices, Google devices, et cetera. So those will come out of the, out of the tenant.
If we're going to SAS services, then depending on whether it's service provider initiated or IDP initiated, basically there'll be authentication happening for which we'll be responsible for. And I think that's, that's about it.
As I say, the main parts. Basically you have a tenant in the multi-tenanted cloud service in the cloud, you have on-premise connectors, which connect active directory up to the cloud. You add more than one for resilience, but you definitely wanna make sure that you, you have more than one, obviously. Yeah. And that's it.
Okay. We have a lot of other questions already here. So the one I think is very, which is very important, this, because I think there were some learnings as from, from others. Do you synchronize active directory or parts of the active directory information to the cloud?
Mm, yeah. So what the, as I mentioned, what the Centrify connected, does it actually connect active directory or indeed any other directory service up to the cloud? Now there's, there's a number of attributes that are copied up to the cloud so that people can log in. And basically if for whatever reason, you know, you can do reporting on the users. You've got, if they come from all different directories, all of that sort of thing.
The, the critical point is that we don't synchronize credentials to the cloud. So basically the, the, the cloud tenant will be connected to a number of different directories. Typically one is gonna be ad, but rather than having a sort of meta directory approach, it's connecting by the connectors to, to the different directory directories as, and when needed. So there's no replication of credentials. So people would say, oh, what about if the connectors are down?
What about if the network is down?
Well, that's why I mentioned the fact that you have multiple connectors into your network for resilience. Now, the, the important point is if you are, if you were to be synchronizing credentials to the cloud, and if there was no inter interaction with on-premise when people authenticated, if somebody left the company, but at the same time the network was down, or if there was a problem with the connector or with the, the replication, if you were replicating ad to the cloud, people would still be able to log in.
And there's a, there's a finite risk of people being able to log in when their accounts had actually been disabled. So that's why we don't replicate credentials from ad to the cloud. So that's it.
Okay. Another question I have here is any considerations in terms of mobile onboardings in banking and other domains and how to make these identity checks best.
I'm not quite sure. So is
There any considerations in terms of, so I repeat any considerations in terms of mobile onboarding in banking and other industries or domains, that's sort of the first part.
And the second part is them how to make the identity tracks or the identity, the authentication best work in. So from your, your experience,
Okay. So in terms of the, the MDM side of things or EMM or whatever we like to call it, generally what will happen is that customers would enroll their mobile devices with the service. And part of that enrollment is a certificate exchange, basically. So which leads on kind of to the second part of the question in that we can trust that device. And we know, we know that the device belongs to that person, et cetera, and it can be configured properly.
And a list of applications can be presented to that user on that device based on typically their active directory roles groups, rather, it's actually driven by roles within the cloud service as to what they'll see, but the roles might be made up of active directory groups or users from Google directory or, or, or whatever. I'm not sure if that, does that address the question Martin or, or not?
I
Think, I think it's, it's, it's, it's a good answer. And maybe we got a follow up on that question. Another question I have here, where are the data centers where you run your Ida service from located?
Yeah, so, so we're based on Microsoft Azure, that's where the, the cloud service lives. So it's really wherever Azure today, he has their data centers. So you can have it specifically in Europe. You can have it specifically in the us, as I say, based on where Microsoft has their data centers for Azure. And in fact, we're, we are one of the biggest customers of Azure in terms of actually writing applications based on Azure.
So we're, that's the answer to that one.
Okay. Another question. How do you provide access to on premises applications?
Right.
So, so this comes back to the, the multifunction connector that I mentioned earlier. So that act, acts as a application gateway as well.
So that, as I said, it, it just makes outgoing connections to the cloud. If you are sat in your local coffee shop working, and you need to access a particular app, basically what happens is that you will go into the app through your tenant back down that outgoing connection on site, direct to the system, that's offering that application.
So rather than having to fire up a separate VPN and sitting on top of that with the potential risk that, you know, you need to have a device that you know, is, is not compromised, et cetera, et cetera, but we we're actually isolating the network from that risk because we're using point to point HTTPS from the application on premise all the way to the user's device, wherever they might be at that time.
Okay. Can you explain a bit more about risk based access?
Yeah, I think I, I tried to touch on it and didn't make a very good, good job during the presentation earlier, but the risk based access at the point of access of when you are trying to access an app or in the privilege world, when you are trying to check out a password, when you are trying to connect to a system, it's the fact that at that point in time, the decision is made whether to do multifactor authentication or not. That's, that's kind of distinct from rule based access where the rules are very fixed.
There's actually a load of machine learning and a great deal of intelligence and very fast calculation done at the point of access to say, Barry, doesn't normally do this. And based on the, the rules, then I will either throw it out all together because it's too high risk.
You know, maybe he's trying to log in from North Korea at two o'clock in the morning, and he doesn't normally go there. Or alternatively, we can just step up to multifactor authentication. But as I say, rather than being a rigid set of rules, that's saying can't log in from this location. It's actually working out the risk of that particular access based on a number of vectors, and then deciding, should we do multifactor or should we block this access all together? And hopefully that, that explains the difference.
Okay. I think fitting well to that question, we have another question here.
So you already touched sort of rule based policies or access controls. So, so what about support for, for more role based or active directory group based access controls, or other ways of, of controlling who has access to what sort you already touched policies that you touched sort of of more algorithmic control?
So any, anything to add here around that?
Yeah. So typically, as we've said, a few times active directory is driving some level of role based access control within all our organizations. So what we can do again, within the tenant, the rules that we apply to people, the profiles, if you like that, we're applying to people and the policies, they can be built up using active directory groups as their source. So we could say that everybody who is in sales will have access to these particular apps.
These are the apps that will appear on their Porwal Porwal on the mobile device, or sorry, on the app, on their mobile device or on the Porwal on their on premise system, sorry, the Porwal on their workstation type device or laptop. So basically you'll get that different set, but you do need flexibility. None of us are gonna be a hundred percent tied to active directory, but that's our history, to be honest is where Centrify came from, was integrating Unix and Linux with active directory.
As time goes on, people are still very much using active directory, but we have to be cognizant of the fact that they might wanna put business partners in the Centrify directory within the cloud. They might want to get, they might be, want to be using Google directory and so on. So that that's, that's really how that works.
Okay. I think we can pick one final question. So that's your either solution support? So the web management use cases are the ones where, where the service does not support one of the Federation or Federation related standards such as Sam or OLS.
And if so, how do you do it? I think we have one or two minutes left. So let's pick this final question.
Okay. So I would say the best thing obviously is for customers to be demanding that their applications, they use support federated access like Sam or oth or whatever it might be reality is that there are some applications that don't support that. So what we can do in those cases is effectively log on via a password replay. We can also put multifactor authentication on top of it, but at the end of the day, that that isn't the preferred method for logging in.
But at times you just have to do it because there is no, there is no alternative. And let, let's be honest. At the end of the day, there are certain things that you just won't be able to interface with. So let's call them legacy applications in inverted commerce. They tend to be on a case by case basis. Some you can do password replay to some, if they were on premise, to be honest, you might be able to do curb Ross integration too, which, which brings us into a, a different area of our product set.
So for those sort of call 'em legacy applications without demeaning them, it it's on a case by case basis, but we've got password replay. We've got Sam, we've got the different base that one would expect for an I solution of, of authenticating.
Okay. So thank you very much, Barry, for all the answers. Thank you very much to the attendees for asking so many questions for attending this group, a call webinar and hope to have you soon back in one of our upcoming webinars or at one of our events. Thank you and have a nice day.
Thank you.
