Good afternoon, ladies and Tren. Welcome to our K cold webinar. I am for the user achieving quick wins in your identity and access management projects. Minimizing the risk for your IM project by showing quick wins for the user. This webinar is supported by Hitachi ID systems. My name is Martin Koran followed on a principal Analyst at KuppingerCole. And today with me, we have who's the CTO of Hitachi ID systems who will be the second, who will do the second part of the webinar. Before we start some general information on some housekeeping center, before we then dive directly into the content coming calls an Analyst company, we providing enterprise it research advisor services, decision support, and networking for it. Professionals. We have our research services, our advisor services and our events amongst the UNS. We have two important ones coming. One will be held in Sen in China, in January to focusing on digital risk and security architecting architecting, the global digital business.
And the other one will be our well known European identity and cloud conference. It's number nine right now around identity access management, cloud security GRC, and how this helps you in sort of ization of your business. It will be done again in May, 2015, fifth to 8th of May in Munich. We have a number of webinars currently, all in drum language. There will be some starting next year in March, I think in English language. So next year there will be a number of seminars, presents onsite seminar seminars. We do German and English language have look at our information around that. And then regarding the webinar itself, some guidelines you are muted center, so you don't have to mute or unmute yourself. We are controlling these features. We are recording the webinar and podcast recording will be available latest by tomorrow, and we will do a Q and a session at the end.
You can the questions anytime using the questions featuring go to webinar control panels. So it's control panels at the right side. Usually if you screen there's an area fog or the questions or whatever, depending on language version where you can, the questions, ideally you enter your questions when they, once they come to your mind. As we have a long list of questions to deal with RQ and a session, okay, agenda for today, three parts as usual. Then first part, I will talk about five areas for quick ones in identity and access management projects. And second part, then Elon will have keeper into detail and look at some of these Quicken areas and some others maybe looking at feature, such group requests of service, password management, this around how they lead to successful implementation. So going, as I've said, more into detail around that, and then we do the Q and a session by the end.
So let's start to start. Maybe it'll start with a point which goes a little bit, or which is I think very important. What is the failure? So when do we talk about success and when do we talk about failure? Clearly a failure is when our project fails completely. These situations we, we have from time to time, we start a project at the end it's Dias without any tangible results. However, I would say it's also failure when we fail in achieving what has been promised. So when we started big and, and very small, when features are missing, when people are disappointed, I would say this also counts amongst the failures, what you also have frequently seen on which I also would consider a failures if a project is technically done, but it lacks acceptance, or just the recognition of success. So people don't see that this has been a successful project and also something went wrong or we do something.
And when it's ready, we are already outdated to something which also can happen in, in this rapidly changing market. So what we should do is, should be sustainable for some time, at least, and sort of sought out enough to be ready. So simple example, if you currently do an identity management project and architects and the, the pronunciation, an architect that on implemented architected, only for our employees, we might end up with a situation where we say, okay, when we are ready, the business already demands, how do we deal with our business partners? How do we do we deal with our customers? Then at least the architecture should be good enough to do this next step. Maybe the implementation was good for right for now was, was the smaller, smaller focus, but it should work. It should be architected for the bigger scope. So, and why is this challenging with I am?
And so we have a lot of different types of projects and, and some areas we don't have to talk that much about quick win about success or failure. Why is it a challenge in identity access management? One of the reasons we in inevitably have cross platform projects involving managed stakeholders, even in it, we have projects which have to support a number of different technologies, SAP, the mainframe Lotus notes, the Microsoft environment, etcetera, et cetera, it's across platform projects, different stakeholders makes it difficult. And I don't even talk about the business alignment involvement of business, which is, I think the second part identity management frequently is considered an infrastructure project, but it's a business enabler. It's what enables rapid adoption of business process, which in fact enables business to do a lot of things it needs to do today in this digital age and the digitalization of business.
When it's about better dealing with customers, when it's about access via APIs for mobile uses cetera, a lot of these things are around and access management. And so when it's positioned as an infrastructure project, but has a farer scope, then we have to solve this challenge. We have to move it up the stack, so to speak, and we will require a business involvement. Everyone who has tried to set up a enrollment project role model, I think has their own lesson. It's something it for loan can't do. It's something which happens together with the business to businesses, the user's the consumer. We have to work closely with the business, which makes things more challenging because many organizations we still have to scale between it and business. And then there's the sort of the elephants thing. So when we started looking at identity access management projects, they tend to quite frequently become and quite quickly become very large projects, sort of the elephants.
And as we all know, it's hard to eat an elephant unless use less to small pieces and large projects are difficult to handle. So we have to understand how can we cut down? How can we slice the elephant into pieces, which we really can manage, which we can handle identity management, maybe it's little bit more complex. If you look at the broadest scope of identity management with provisioning Federation, single sign on strong authentication, PTIs inform regimen, whatever you could put in. There's a lot of stuff which you can count to identity management and it can become very big, very complex project. So what do we need for a successful IM program? We need executive support, very fundamental thing. It must be something which is not only driven down for the it infrastructure technologies technology side. It requires executive support. When we talk about this alignment, it requires business involvement.
It requires a clearly scope. So what do we do in the project? Why not? And finally we do need to do technology, right? So to understand what is out there, what can we do, et cetera. And even then projects are not that simple. So one of the challenges we really need, need to understand or to, to faces, we need a quick win. So I've seen projects on their budgets for 10 million, 50 million sometimes. And then clearly people say, I want to see some result before I, when I start spending that money, they people, the business gets nervous. So I said, okay, what is the, the result? Can we see any achievements? And so we need quick wins. We need, regardless of the budget. And if we have a longer running program in many organizations, and I think that makes sense, have set up an IM program to succeed in an IM program, we need quick wins and for any single project as well.
So the reason is yes, we have large programs with many parts. And when we don't show quick wins at the beginning, people become nervous trust because of the significant S we frequently have for something considered being infrastructure. Our identity access management can be quite expensive, not necessarily, but frequently over time, if you put it, make it big enough your program, then it will cost some money. If you, especially, if you count the average type of cost, not only software hardware implementation, but also the internal costs that are done, it can be a quite interesting number. So again, breaking it down into pieces helps another point is it's complex technology, hard to understand. I think things became better here in that area. When I go back some, some five years, even for me, it was not that easy to explain to someone, what am I doing?
I do Analyst Analyst for identity access management and related stuff. Right now people have a far better notion of identities just from their personal life, from the internet, from their personal experience. So it's definitely easier to explain, and they are a positive thing which really starts helping us identity management. We see more and more business demand. So we see more and more areas where, where business really demands solutions from us singles amount to the cloud, onboarding of business partners, access control, access to business partner, applications, integration of the consumer social login, etcetera. All of this is around at anti access management and it's business requirement, which is brought to us. Another point is that the various stakeholders involved in an identity access management program frequently have different priorities, different targets. And you might experience that. Then one starts yeah. Starts putting up hurdles for you when he feels that there's no success because he has, he don't want this bro.
Even don't want this broker to succeed just realistic situations. So we need quick wins. What are areas for these quick ones? I have put together five, clearly not the all areas where you can have quick wins, but five, which are quite typical to achieve quick wins. One is single on whether it's within the enterprise or to the cloud signals are known as a classical area for achieving quick wins, because this is something which is directly visible to the end user. The end user experience changes in a positive way, less passwords to remember less user names, to remember less sign on activities. Great. That's really something which helps actually a benefit. And it can be equipment because it's relatively simple to achieve simplified password research and password management, again, something which is not the most complex per of the broad identity access management space. But it's something that helps the end user, which might even drive down, help discuss, but which again, definitely helps end users, safe service access, request management, another very important area.
So how can you enable your uses to request the access? They eat themselves in a SIM simple way, in a way they really can handle, instead of having a specialist in every department who does the access request, or instead of having eight or 10 or more different places where people have to request access to various applications centralized last simplified self-service access request management clearly is an option for a quick win. And again, it's something which can be depending on where you are in your infrastructure, et cetera, can be potentially done relatively quickly. And especially if it's specific area that is shared folder self-service request management. I need access to this folder on the file server, very common something, which if you don't have good approach and it might end up in chaos regarding your access controls, which right result in compliance issues and security issues. Again, self-service request management makes life easier, improves, compliance, improves security, and something which is not the most complex part of the identity access management world.
A little bit more complex, but something, if you do it, it's considered definitely a win is efficient change process. So the mover process and trying to move lever to something where, where I see when I look at at organizations, talk to organizations where I see a, a very significant portion of organizations still struggling with, so what happens if someone moves to another department or another location, how is this handled? And then there is issue, okay, this person should have access in his new department some days before he really starts working there, or he should have access for, to some system in his old department for some weeks. How do you handle this correctly? Not cutting off access rights, but on the other hand, not forgetting to revoke this access. This is not that easy. It, if you don't solve it, well, you have a lot of trouble, a lot of manual work in your organization. This is something where, where boost the business and it benefits if it's done right. So another area for quick wins, however, it's not only about quick wins. The other very important thing to succeed in identity access management projects is very simple. Think big, but start small. This is, I would say very most important rule for success and identity and access, or you will fail because you will fail because you started big.
So your project was just too big to manage. And then the risk of failure time, or you stopped too small. So you did it only for a part of the problem. And then you are done and you've realized, oh, my problem is far bigger right now. And maybe your architecture, your solution doesn't ISN, isn't ready to grow with the changing business needs. So think big, understand the big of identity, access management, all the pieces and how they are related, prioritize them, make small projects out of the, within the program, and then move forward in a way which ensures that you have results quick wins and other longer wins and move forward. Step by step towards a little bit of moving target because the world doesn't stand still, but it helps you to do it really that way. And this is very important. And as a final thought, a little bit, I wouldn't say out of topic, but beyond the, the, the quick one topic is when you do that, also start rethinking common approaches.
And I have trust put together five ideas, sort of, of as food for salt to re rethink common approaches in anti access management. So, so one of the things we we commonly do is recertification. It's hard to convince departmental manager to do that, right? Maybe we can think about the one other area, not everywhere. It doesn't work. And nothing of this is, is the, the holy great solution, the Niana whatever. But what about time restricted entitlements was reapproved instead of re-certification. So for critical things, you have to, reapprove more frequently, you get under information. Thus, this user still needs the access rights. If yes, then reapprove, this is putting it into chunks, smaller chunks, and making it better to understand than doing the complex recertification process. Trust is an idea. If you have an enterprise single sign on single sign on solution, you can also do single sign on to the cloud because it's about web application access.
Clearly there are things beyond that federated provisioning or using Federation, unless you federate it works quite well. And even when you have the option to fit it, right, in some cases, it might be good enough to avoid having another solution. One of the challenges we frequently see is identity information, quality. A lot of attributes are outdated. Why don't you use recertification for end users? So let them recertify their identity attributes because they know best about the correct values with new types of users, business partners, consumers, cetera, coming in there might be the idea of saying, I have a user employees trust a specific type, a specific quota role, instead of saying, okay, I have my, my typical identity, which is the end user. And then I think about how to handle the partner, the consumers that are, maybe you turn it around, put it one level higher, say there's an identity that can be today, employee and tomorrow partner, a customer.
And a few days later, or weeks or months or years, it can be the service thing, whatever. I think it grows better. Another frequent discussion we see is integration with identity, identity of identity and access management. The service catalogs hard to do if you put the service catalog in front, but why not? Are there ever things through identity and access management? So the person needs services. Why not doing it that way around it tendency? And it's not a simple question to answer, not a simple thing you have to think about. Roughly tendency works better than the other way around. So just some ideas around that. Instead our hand over to who will then dive more into detail on some of the quick ones. And so it's your turn, em, 80 percenter.
Okay. Thank you, Martin. Alright. So continuing with the same thing in moving away from kind of the broad ideas of quick wins, what I'd like to show today is some very specific ideas for quick wins. And in particular, I'll, I'll talk about three processes and I'll also talk about how the implementation of the identity and access management system as a whole can be made a quick process. So let's start with password management. This is one of the items that Martin mentioned. So what does password management mean? We say password management. We throw the words around like, they're like, they're very well defined, but may, maybe they're not so well defined. So when we talk about password management, we're talking about enabling users who forgot their password or locked themselves out to fix their own problem. Now there's actually a bigger problem space here. We also want to allow users to manage multiple passwords together.
That's password synchronization. And we also want to enable users to manage other kinds of credentials, security questions, tokens, smart cards, biometrics, but the, the most basic component of password management is, is basically self-service password reset, which is this. So how, how does, how does this work? Well, if the user forgot his password or logs himself out, then you need to authenticate him with some non password mechanism. Usually most inexpensively that security questions, it's something like this, but of course there can be other things we could send a pin to your phone using SMS. We can use biometrics, we can use a hardware, one time password device. We, we could do any number of things, but the fundamental notion is you start with non password authentication and then the user picks his own password. Simple enough. The, so, so what does this mean for the customer?
Right? So the organization that deploys a password management system, what can they expect? Well, first of all, how long does it take to implement a system like this? A very simple system, you know, it could be up in production and weak. A very complex system might take a half a year to, to go from idea to production deployment. And that's a pretty big range. So the question is why is there a big range? Well, it depends on what you're integrating with. And if you have to deploy software to the users, endpoint device, to their laptops and PCs, and frankly, it depends on how complex and slow change management may be in the, in the environment. We I've worked with companies where it takes three months just to get a server, right? So yeah, there you go. Three months, half of your, your time, what have you done in those three months?
Probably nothing. So, so that's just reality. What's the return on investments? Well, in it help desks up to half of the call. Volume is people who forgot their password to lock themselves out. So you could eliminate app up to half of the calls into your help desk, and you can then calculate cost savings. In one of two ways, you can either assign some dollar figure or Euro figure to each call and calculate your savings by how many calls don't happen anymore. Or, and I think this is more realistic. You can reduce the number of people that take calls in the help desk. And the call savings is the number of people that don't work there anymore, or the number of people that you otherwise would've had to hire that you didn't, every project has risks. What are the risks of putting in a password management system?
Well, the, the main one is if users do not adopt self-service, then there's no return on your investment. There's no cost savings. One of the reasons they might not adopt the service is because when they need it, it's not available. So anybody can stand up a web-based password reset system. I could probably hire a student to build one in two weeks. That's not a big deal, but there's more complex scenarios. What about if the user is at the login screen? What about if you have full dis encryption and the password prompt is before the operating system begins. What about if the user is working from home or traveling? So these are real world problems. And if you don't provide password reset where the user needs it, then the user cannot use it.
What are some, some real world examples of how actual companies benefited from this? I remember years ago, we did deployment in a us bank and this bank was already getting 30,000 password trouble calls every month from their employees. And the reason was bank tellers, frontline people are, they move around a lot. They, they hire them very often, very fast. They, they quit very fast. And so this population of users is calling with forgotten passwords at very high frequency. And at the rate of which the bank was growing, they projected that they would need to hire 100 more help desk people just for the increased password call volume within a couple of years, not only that they didn't have room for, they didn't have another 100 desks, 100 seats. So they, they would've had to lease a larger facility in order to have these hundred additional people.
So we worked with this customer and through automation, both from the desktop and on the telephone, we managed to eliminate 80% of these calls and the call savings that the customer was something on the order of 3 million a year. All right. So that's great. But what happens in the real world? I mean, as I already said, a web-based password reset system is very simple. That what complexity can you expect in reality? One problem is your, your computer, your laptop, or your PC cashes passwords locally. So what, well, if you change your password somewhere else in the network, if you call the help desk and they change your password, then the password that's cashed in your PC is now wrong. It's the old value. And, and the password on the directory or the application is the new value. Your PC might continue to offer the cashed old, wrong password to different services on the network.
And if your PC offers the old password to enough things, it'll lock you out. So password cashing can turn your lockouts. It's an interesting real world problem. Another problem is people increasingly work outside of their office. I'm not in the office right now. I don't think Martin is either most password reset. Technology requires that the machine that you're using to access password to reset is physically in the office, not VPN, not off site, not on the internet. So you need technology that allows password reset to work. When the PC that you're connecting from that has it locally cash password isn't at work. And that's complicated. Increasingly we deploy full dis encryption software, and increasingly you have to type a password before windows or another operating system boots. That means that you need password reset before you have an OS running on the system. And that's a whole other problem.
Again, most password recess systems. They work either from web browser or perhaps from the windows login screen, but not pre-boot. And that's a problem. If you have a pre reboot password, another problem is users just ignore you, right? So you put up a password reset system and you have to enroll information from users, security questions, mobile phone numbers. You invite the users to do that, and they don't do it. If they don't do it, then when a user forgets their password or has a logout problem, they cannot authenticate and they still call your help desk. So you, you have to figure out how to get users to actually enroll.
And the last challenge you run into is inconsistent login ID. So I have one user ID on this system and another login ID on that application. And if I have different user IDs and different systems, probably there's no good data that correlates them. If there was, maybe we would've cleaned up the IDs already. So you need some way to map IDs so that when I reset passwords or synchronized passwords, that can do all of them, not just one at a time. All right? So, so these are the things you have to worry about that might turn the quick win into, you know, slightly less quick win, perhaps.
All right. So that, that was one kind of quick win approach in identity and access management. Here's another one. And, and this is also one that Martin pointed out, and this is self-service requests. And here I'm going to focus specifically on self-service requests for security group membership. Okay. Users don't know about groups. I mean, ultimately when we give access rights to things, we we're usually attaching users to groups, but the business users that need access to something, they don't think about groups. They think about shares and folders and SharePoint sites and documents. They want access to something or some service, and yes, it's true to get it. They need AC they need to be made a member of a group, but they don't really know that. So the basic definition of self-service group request is, is to allow users, to request access to these things and actually get group membership, but without having to call it right, we don't want the help desk or the security administration team in the middle of this process.
This is how a group request usually starts. A user tries to open something and they get an access denied error. And depending on the client platform and the server platform and the application, the error will look different, but it's basically always the same. It's always access to nine. You see that in, in every dialogue here, of course it could be in a different language, but it's the same problem. Same error message. So one interesting way to resolve this. And this is really a quick win is to deploy technology that replaces the default access, denied error message with one like this that has a new option access denied. Would you like to request? Okay, so that that's essentially the change, right? We went from an error dialogue that was not actionable is a, the end of the process. Okay. Now what, I don't know, a call to help desk, to a process where you see that you, you don't have access and you can request access. And this starts the navigation towards a self-service solution. How long does it take to go from that to a, a working self-service request system? It could be very quick. It could be one week or maybe one month. It's actually quicker than password management systems.
And typically what determines the length of the deployment efforts is just the change control process. The, you know, the rate at which the organization can deploy new technology. Do you get a return on investment here? Well, in your help desk, if password recess or problem, number one, access request is probably problem. Number two. So this is allowing you to move problem. Number two, to automation, the users benefit from this because they get the access, they need more quickly. And of course it gets benefit because the access requests are handled in self-service rather than in calls to it. Workers are there risks? Is this as simple as all that? Well, nothing is ever as simple as it looks. One of the problems you run into is people request access to something and, you know, it's a share or a folder on the network, perhaps. And the access rights defined on an object are just inappropriate, they're wrong.
And so you're continuing the use of badly defined access rights, another and perhaps more serious problem is usually the approver for group membership, cuz ultimately the user is gonna request a group is the owner of the group. Well, what if you don't have good data that links groups to their owners? What if groups have no owners or the owner on a group is an invalid user or is a valid user that really shouldn't own the group anymore. Data quality is, is a big risk here, real world experience. So one of our customers is a us defense contractor. They, they make weapon systems, they eliminated something over 10,000 access requests per month by moving their group membership request system to this kind of self-service what could go wrong? What could make this more complicated than it first seems? Well, the first thing you need to think about is nested groups on simple applications.
Groups are atomic construct. They contain users and they get access rights. But on active directory in particular groups are frequently nested. So let's say you have a share or a folder and there's access rights granted to group a, but group a contains, not just users. It contains group B as a, as a member and maybe group B contains group C and so forth. And it is not group a that you should grant access to users should actually be assigned to group B, not a, so there should be assigned to the child, not the parent group. So here there's an example of a place where policy has to come into play to decide where the access right should happen.
And another extension of this problem is that the groups might exist on different systems. So again, in, in windows you can have groups locally on a windows server and as members they can contain active directory groups and then active directory groups in one domain could contain as members, another active directory group in another domain in the same forests, along as the groups of the right types. So this, this actually makes group nesting more complicated because groups can contain groups on other integrated systems. And when you have all this nesting, you have to think about two problems, visibility and request ability. Visibility means can the user that needs access to something even see the parent group, or should you just shoot him right down to the child group and request ability is should the user that's making a request be able to request the parent group or should you force him to select the child group?
So, so these are basically user interface and policy questions that have to be answered. But the, the basic notion is group nesting and data quality, particularly around group ownership are the two kind of challenges that you have to overcome in order to deploy self-service requests for group, for access to resources. All right, third quick win automation of onboarding and deactivation. This is the most basic identity access management functionality and really every organization that automates any IM capability should do this. So a basic definition, you should be able to automatically create and delete login accounts, mailboxes, home directories, and, and other artifacts for new employees and automatically deactivate all these same things. When your employees leave, I'm using the word employees rather than users. Why is that? Because automation implies that there's a system of record and there is usually a system of record for employees.
That's your HR system. There may not be a good system of record for contractors. There may not be a good system of record for partners, but for employees, at least there should be some system that you could watch. You could monitor, which says, you know, we hired somebody here. We fired somebody there. So the, what does this look like? Well, automation doesn't usually have a user interface. So probably better to look at a, a process diagram. Essentially, you, you have a process which consumes a list of people, right? This is what comes from HR. It's a list of people that work for you, but it also has to consume a list of accounts. So who already has an account on, on windows, active directory, Salesforce OS what have you. So it's consuming two kinds of data, data about people on data, user IDs. It may do some identity synchronization, but more importantly, it detects changes.
It, it sees that this person was hired and this person was fired and this person was transferred and it responds to each of these change events by submitting workflow requests to create mofi delete why workflow requests. Well, first of all, workflow requests are an audit records and they show a history of change. But secondly, you can calculate some extra bits of information you can require approval. You know, maybe it's somebody has to approve that. It's okay for this employee to be onboarded, things like that. So that it's an opportunity for further processing on a case by case basis. And then once each of these requests is calculated, completed approved, then you hand it off to transaction manager, which really, which really runs connectors and creates and deletes and enables and disables user IDs on your infrastructure. Okay. So that that's essentially the process that you need for automation.
What does it take for customer to do this? Well, I've seen deployments as quick as about a month and it's low is about four months. So it's, it's not huge. And it depends on process complexity and, and like everything else. It just depends on the rate of which you can procure servers and approve change controls and do production migrations and pilots and all, all these usual it projects, components. What's the ROI. Well, the most common and complex access requests are higher and fire. So you can automate higher and fire, at least for your employees. This means that your new hires get better SLA, right? They can get to work immediately rather than waiting a week for their login ID. And it means for your security team, that deactivation is more reliable. When, when you terminate somebody, their access just automatically goes away. What are the risks with the main risk is that the HR data is garbage and this happens more often than you might think.
So incomplete data from HR on reliable data from HR or data from HR that just comes late. Maybe they only create a record for somebody when it's time for the next payroll, right? So you've hired somebody they're already working for you. As far as HR is concerned. They're not here yet because they don't need to be paid until next week. So these are all serious problems. Another risk is that the access that you need to grant is, is more complex. And the HR data is very simple, right? So the HR data says we hired this guy, but it, it, there's not enough detail there to really predict all the, the things that this user needs access to. And the other risk is actually it's the deactivation that that's a complex process. So the complexity, when he onboard somebody is what to give them the complexity.
When you deactivate someone is you want sequence to turn things off and archive content and move content around. So different kind of complexity for higher and termination. A couple of real world examples here. One of them is an energy company. It's a, it's a big multinational. So we spent 30 days of of efforts. So 30 days of consulting over the course of two months to deploy an automation system. And this allowed them to automate 2,500 change changes per month. So either hiring people or terminating people 2,500 times a month and all the access rights that are required as a consequence of that, or being assigned and revoked automatically. The second one is, is more precautionary tale. So this one is, is actually a much smaller organization. They operate a bunch of retirement homes in north America and the deployment effort was actually quite a bit less.
It was 20 days of effort, so not too bad, but it took eight months to deploy. And so you might ask, well, 30 days and two months, 20 days and eight months, what happened here, delays, you know, resource availability, other projects go on the way, readiness, server availability, things like that. So, so nothing specific to identity and access management here. Nothing, no risks, no special complexity, but sometimes time goes by when you're, you're just busy doing other work, right? And this 20 day of investments basically automated a hundred changes per month. So much, much smaller and more static organization.
All right. What could slow you down in an automation project? Well, when you're onboarding, one of the things that you need to do is detect when somebody that looks new isn't right. So HR hired somebody. And actually it turns out that you've had this employee before. Maybe it was a contractor before maybe you're hiring a contractor and he used to be an employee. When you hire somebody that you've employed before, you probably should just stop and either reactivate the old profile or block the process. Because when this person left, before they left under circumstances, that mean they should not come back, but creating a new user profile for somebody that's been in the organization before generally is a mistake. So you have, and people don't volunteer this information. So you have to detect that this is actually a returning individual unique identifiers. When, when you create access for somebody, you need to create login IDs, email under us as employee numbers, there needs to be a process to assign these things in a global unique way and reserve identifiers and so forth.
And the rest is just figuring out where to put things. Where do you create the account in the directory? Where, where do you create the home directory? Where do you create the mail folder? What, what do you put in the home directory? What access rights do you assign all these basic tasks for onboarding on the flip side? It's multi-step so when somebody leaves, especially if it's a, an orderly scheduled deactivation retirement, end of contract resignation, what have you, you want to give advanced warning to managers so they can maybe change the date. They can say, well, the contract was supposed to be over next week, but we have more work and we push it back month. You probably wanna leave objects in place so that if you deactivate somebody and it turns out that it was a mistake, somebody has access to the oops button undo. You wanna be able to archive information like entitlements on group memberships, file system objects. You know, what was in your home directory, mail folders, keep, keep a copy of that stuff because you probably need it for data retention and you may need it in case this person is hired again later it's reactivated. Right?
All right. So those are three kind of quick wins, but what about standing up the entire IM system more quickly? Well, turns out that most companies deploy more or less the same IM functionality. So why is it that we're building IM systems for every customer, every organization from scratch. This is like buying a car 150 years ago. They would build a car just for you, right? Design it from the ground up engine, transmission, chassis, wheels, just for you. That's crazy. We, we had a thing called the industrial revolution where we could buy the same car. Hey, you and I could buy the same car. And it would be a hundred times cheaper. Really? We should be doing the same thing for IM systems. So before every implementation really started from scratch, right? You have a product pro you have some basic technology, but you're assembling business processes and validation rules, and data flows and integrations from scratch.
Every time that's crazy. Some code reuse, but not huge amounts. And some of the business processes sound simple, but they actually have complicated boundary conditions. Like how do you set somebody's initial password? How do you get them to set their password? When they come in on day one, how do you do multi-step the activation and archive and clean up? How do you transfer when you, when somebody changes to a different branch office, let's say you probably need to move their mailbox or home directory. Somebody changes managers, maybe you need to re-certify them. So there's all kinds of side effects and complexity. These complex processes often require some script code to be written and that's expensive and risky and buggy. So this really gets to the problems that Martin was alluding to earlier. This is why IM projects used to have multimillion dollar budgets. That's crazy.
So instead of that, why don't we start with a fully configured system, not, not a framework, but a really fully configured end to end system that has all the business processes already set up. And why don't we preconfigure even integrations in HR feed or a system of record, a directory connection, a mail system connection, a home directory system environments. And instead of building the entire system from scratch, why don't we just modify it a little bit as required, right? The, and then why don't we eliminate scripting, right? Whatever script we need, we'll preconfigure out of the box and then make the configuration data driven policy driven. So the, what we want is for IM implementation to be fast, efficient, reliable. So what does that look like? Well, we've actually done it. We've, we've got a, what we call a corporate reference implementation. So this is a reference implementation of an IAM system for a corporation or an organization that functions like a corporation.
So we built HR and directory and mail integrations. We assign login IDs, group memberships roles. We configure it for basically two user communities, employees and contractors. We eliminate script code. It's all, you know, policy driven rules driven. We have automated onboarding, automated deactivation, automated identity synchronization. We have self-service password resets security question, enrollments. Self-service for simple things like updating my contact information. You know, here's my new mobile number, or self-service more you more complex sense request to access, to applications, to shares, to folders, delegated administration. You know, my manager can change my profile approvals and re-certifications so all of these things are things that basically every corporation needs. So why don't we just preconfigure them? What we have. And so what you do is you install the software. And 10 minutes later, you have things like this transfer is scheduled or deferred termination leave of absence, group requests, urgent termination, and so forth. So, so the all, everything you see here in the first 10 minutes, it's already working.
And that includes complicated things. So when you transfer somebody, maybe you need to move their mailbox. Maybe you need to move their home directory. Maybe you need to re-certify them. When you hire somebody, you have to automatically detect if it's really somebody new, or if it's actually somebody coming back, if you have a scheduled deactivation date and there's early warnings to allow the manager to move it, there's a disabled, there's an oops button. You know, oops, shouldn't have been disabled. Turn them back on archive cleanup. There's a whole process for new users where they enroll security questions, except corporate policy documents choose their own password there's approval processes and, and so forth. All of this stuff built in now, not everybody can use the same pattern. So in the same way that the car company might make 10 different models of cars, we actually have to do is have different reference implementations for different styles of businesses or different styles of organization.
So the corporate one is the one I've been talking about, but actually you have a whole other reference implementation for B2C websites. For consumer facing websites. You have a completely different one for B2B, for, you know, partner Porwal that, that you might throw off to interact with your ecosystem of suppliers and resellers and so forth. You have a whole other one for universities and colleges and, and so forth. So I, I, I'm not suggesting that one reference implementation is good for every IM deployment, but I am suggesting that five or 10 reference implementation can handle 90% of all the IM systems. All right, Martin, shall we turn it into a Q and a session?
Yes. Perfect. So thank you. And I will make me presenter again. If you have any questions, please enter them right now into the control panel of go in the question area and go to control panel of go to webinar. So no, I have it there. The first questions here, one is more from the administrative side. So do we get the slides after the webinar? The slides will be available for download together was the podcast latest by tomorrow as PDFs. So you can then download the slide X. This is an information here. The other thing, which, and as I said to all the attend is trust your questions now, or send over questions later on to either or me, depending on who you want to ask something, the email addresses should be here and are easy to find. So the other thing is what I really like is this approach of saying we have preconfigured solutions or something. I, I think I've been asking vendors for many years. I've seen a few very few, but yes, I, I couldn't agree more. I think it makes a lot of things far more easier. So it, it definitely makes sense to do that. And I think it would be, it's a good idea because really helps to, to become quicker, achieve quick wins. And it also helps in, in sort of mitigating the risk regarding the cost and complexity projects. Clearly there are a lot of things in this. I think you brought as well, special systems to connect cetera, but if you once have something up and running, I think it makes a lot of,
A lot of sense to do it that way. The other question I have here is around password sync versus password reset. So what do we really need?
I'd say you need both. If you have multiple systems or directories where users have passwords, I would say, make the password policy as strong as those systems can collectively support and synchronize them. I know as a user, I, I have enough trouble remembering two or three passwords, right. I have my work password. I have my secure personal, you know, banking password. And I have my disposable password for social website and, you know, junk website that's enough. I don't need 10 different passwords at work. I don't think I can handle it.
No. Yeah. Finally, I have a number of passwords and I can't remember the passwords, but I usually can't remember which passwords did I use, where, which
One is where yeah, I do that too. I sometimes type the wrong one on the wrong site, which means I'm giving it away.
Yes.
So I think password synchronization is absolutely worth doing. And I think password reset is also absolutely worth doing. And the idea that it's one or the other is, is a false economy. You really should do both the only case where you should. So you should always have password reset. And the only case where you should not have password synchronization is if you only have one directory or one system that has passwords, or if you have two systems, one of them is just incredibly stupid and it cannot take a strong password at all. I, I can't think of any other reasons why you'd want to continue with multiple passwords.
Okay. I also think that having, making these things easier is definitely something which is interesting. There's a question from the attendance. Umm, not sure whether fully guys, right. So how many companies open password reset to the web? Probably allowing to reset it. We add a web
Well quite a lot, you know, among our customer, maybe 10 or 20% of them allow their employees to access corporate password reset over the public internet. But there's a big bot and it's not a security one. If you have a corporate laptop. So it's a domain member and the password that you type is essentially your ad password, but it's authenticated locally. It's a local copy. A web-based password reset will not help you because it will reset the password back on your active directory domain controllers. But it will not change the password that's cashed than your device. So you need something more. You need integration with the network clients and the VPN and so forth so that when a user is off site and they do a password reset, it actually changes the locally cash password value that this is a fundamental issue in password reset technology web is usually not enough.
Okay, perfect. So I think we are at the end of the time anyway, there's also here a list of related research. There's far more related research available from keeping a call. So it's right now, time to thank you. Say thank you to all the attendees for listening to this webinar. Thank you for touch ID to, for supporting this webinar. Thank you to for presenting in this webinar. Thank you. Hope to see you soon again. And some other webinars
Have a nice Martin.
