Good afternoon, ladies and gentlemen, welcome to our coping or cold webinar, seven common symptoms of IM and IHG diseases, the causes, and how to heal them. I will talk about roles, recertification and processes, lessons learned and best practices. So my name is Martin coping arrived, the principle Analyst Analyst Analyst at coping or cold call. And as I've said, or the next 30, 35 minutes, approximately I will talk about these topics and provide you some, some insight and lessons learned from our advisory. Copy. A call is an Analyst company. So we provide enterprise it research advisory services, decision support, networking for it, professionals through our research services, our advisory services and our events. Our upcoming events include the EIC 2016, which will be held may tenths to 13 in Munich. Again, it's the number 10 event. So it's a Chile for us, for the trauma speaking. Once we have a very interesting next generation cyber security summit in two weeks from now, which will be held in VPA, which is looking at broader information security view on, on how things are changing, what we need to do with information security beyond the firewall and beyond the parameter.
So some guidelines for the webinar, you are muted centrally, so we don't have to mute or unmute yourself. We are controlling these features. We are recording the webinar and the podcast will be available by or latest. And that will be a Q and a session at the end. But as always, you can end the questions at any time using the questions features and the go to webinar control panel, which you usually find at the right side of your screen. And so I will, I might also pick up questions during the webinar if appropriate. Otherwise I'll do the Q and a afterwards the agenda like thus wide simple. It's me talking about a challenges we observe around. I am and I, she and guidelines, processes, recertification policies, role management. And so at the end, I think a lot of this stuff is, is really increasing project risk if not addressed properly.
And a lot of these things are not that hard to address. Some are not easy to address. That's the CR side of saying, but frequently there are, there's some common causes for, for challenges. We observe in projects. We, we, we see from whatever angle and we see a lot of projects. And so that's where we think doing some things more in standards. We're adding some things, doing some as, or solving some things which frequently are, are not solved well in projects. That might be something which really helps you to be, to mitigate risk in your own projects or in the projects of your customers. So what are the seven common symptoms of I am and I achieve diseases. So what, what, this is what you really observe. So one of the very typical things is users are complaining. So users say, we have, we complain about interface for the access request.
It's too hard to use. There are too many of these interfaces, whatever. I don't understand what to do. I don't understand the entitlements. I have 200,000 entitlements to pick from things like that. Second area is that they complain about not having single sign on. So if they have so on, that's working, they usually don't complain. But if you don't have, they tend to complain for a good reason. I would say performance might be one of those things. So it takes too long frequently. It's not necessarily the tool performance, but more a processs performance. It takes too long to onboard and you user takes too long to make the required changes in change to scenario where someone is moving from one department to another, et cetera, overall usability. I think this is one of the major challenges we are seeing. Another one is this is more on the, the IM program side, not that much on the end user side, this is sort of the target missed in connecting systems, reducing manual work.
So starting big and saying, okay, we will connect so many systems and automate everything. And at the end of the day, five years later, you have connected five systems and still a lot of systems are not connected. And there's a lot of manual labor, et cetera, lengthy processes for onboarding users. It takes too long to onboard someone, very common challenge. So when people come into the enterprise, they should ideally be productive for new area. Beginning the same applies clearly for challenges around the Mo movers, levers, processes, and revocation of entitlements. So missing our erroneous processes. So the mover process being cumbersome, a lack of lever processes, or a lack of emergency leave process, which is a very important process or just entitlements never are revoked a lack of support for additional groups of users. That also is one of the, the, the frequent symptoms we observe.
So employees work more or less well, and then the organization identifies, oh, we have business partners. We have customers what to do with that. The IM program is not able, not capable of handling these new requirements, bump your re-certification. I think this isn't. So I, I estimated a talk and then I had a number of people in, and I asked whom of you has a recertification process running. And number of people raised their hands. Then I ask, and who, who individual of your organizations are people lucky and happy, or at least don't complain about recertification and no single hand went up. So bumpy ertification, which was hated by the users by departmental manages, etcetera. It's so very common symptom, incomplete and inconsistent role models. So role models, which started big and, and at small, where, or where you had the first and the second and third try. Also, these are things which we still frequently observe. So these are symptoms. And the question is what are the causes?
And I wanna go through the list of causes. And then I, in the next, the next couple of slides, I will look at what could you potentially do to sort of cure the disease? So the symptom of complaining users are already attaches to, to some decree. The cause on one hand might be that there's, there are inconsistent or any adequate user interfaces. So, which also includes that technology terms are not translated well into business terms. So if you want to interact with an end user, you should talk his language. You should have, should have a tool, which is easy to use. So users usually don't request access on a daily basis. They go out and say, okay, I need access. Now, next time it might be one year or two years later, or at least a couple of months later. And in that case, obviously it's very important that they can do it very, very easily.
And if they have to scroll through lengths of lists of entitlements, which they never will use, that's not the right way to do it. So this is one or many interfaces. So SAP rights goes through that. Windows rights goes through that interface. The rest goes through another interface. It doesn't help reducing complaints. So the cause on one hand is, is a lack of integration. I would say a lack of user orientation, understanding that the business users and the sort of your internal customers needs on the other hand. Other part that, that frequently also the processes behind that are not well sought out if they are defined at all. So in fact, many, usually you have implemented, but did you ever write down the process? So this is one of the areas, the lack of support of target systems. See two, two main reasons for that.
One is unrealistic expectations. Mm. So this is clearly one of the challenges you say, okay, I, I will automate and connect and you have to sell your, your project. But, but nevertheless, it's, it's about remaining realistic. The other thing is even, so it's a realistically, a large portion of target systems never will be directly connected. And in that case, it's important to still have a working and auditable processs, which means you have to integrate. So either you have to provide some ticketing as part of your implementation, or you have to integrate with your existing it service management and ticking ticketing to have different standard way to direct fulfillment, to direct status of these requirements. You send to systems to add operators and administrators or systems. So this is what you need to do. So you don't still would have a lack of support, but at least you have something which is a standardized process, which doesn't go wrong all the time.
Lengthy processes, the causes from our experience that very frequently, there's no process di knew whatever approach you use of use business process modeling language, or rely on the, on the UN. So the EPK EPC diagram. So doesn't, doesn't really matter which type of approach you use, but frequently these things are lacking. So more or less processes are developed on the fly while implementing the product. This is not the right way to do it. Think about the processes first, because this will help you to be more consistent, to be better in, in, in, in the definition and to ensure that you have all processes defined and notably. So when you, when you talk about identity management, there's very commonly, there's the notion of JML or join or move lever. Yes, but not only three processes. If you go through the entire list of processes, you approximately have at least 25 to 40 different processes, because it's not only about the trainer move and lever process.
There might, there are, for instance, at least two lever processes, the standard and the emergency leave. There are potentially of the trainer process and there are the model management process. So the process around, how do you define roles? If you work with roles or groups of entitlements, how do you onboard applications? How do you do recertification or whatever you do in that area? How do you do the auditing and all this, that type of stuff. So it's not three processes. It's a far bigger number of processes. It's not hundred. It's not three it's. As I've said, I would say between 25 and 40, if I look at our own standard process models, these are in that range, 30, 35, you have them, you have the area of a or missing processes, same cause. So different symptom. You could also say it's one symptom, weak processes than it's one cause nevertheless, same challenge behind lacking support for all groups of users.
So no support for customers, etcetera. This is an design problem of your identity management. Over the past years, I've talked with many organizations and I said, you know, from, from design perspective, think about all types of users. You might potentially have. You might start from an implementation perspective, was focused on the employees. And many said, you know our target right now, our employees, we do it for them only. And then the consumer demand or service managing consumer identities, this demand comes in and then the questions, how to handle it. So it's basically the many identity management implementations had the strong focus on the end user. Only on the MBA. Only this is one of the challenges bumpy. Re-certification okay. Not easy to solve there, there are, there are various causes for that. So, so one major thing is that re-certification for itself has its limitations.
And one of the fundamental challenges is I always say, compare it with how you handle emails. And I think this is true for most of us, if I receive an email. So it might be something which I directly move into a folder because it is nothing I have to act on. And then there are emails I have to, to reply in some way or not. There are emails I look at and say, okay, simple answer. I can do it quickly. And there are emails which I look at and say, oh yeah, this will take me a while. And these are emails, which I done frequently sort of hold back and say, okay, I'll, I'll do it. When I have sufficient time to, to really provide lengthy answer and lengthy question or go through all that stuff. So if you look at re-certification means you present a metrics of people and titlements or something like that might be done a little different, but restal is basically the same to a departmental manager, for instance, who has a lot of other work to do.
So, the first thing he might do is say, oh God, do I have to do it? And then he might sort of push this task back and say, okay, I'll do other things first making this easier clearly is, is a very important thing. And it's it's about on one hand, the, the, the amount of things you, someone has to, to look at and the other element is to make it easy, to understand so to translate it. So basically within re-certification. So one aspect which I frequently see as a challenge is there's no, multi-level re-certification as I call it. So the departmental manager, he understands which business activities his people have to do, but he usually doesn't understand which whatever SAP transactions are required for them. So you should ask him for, are these people still doing their job? Are they in that project? Ask him at the higher level, the things you can easily answer.
And only these things, the question about which technical entitlements are part of which business role or whatever, maybe there are even multiple level of roles. These are questions which you have to ask. Other people, the business architects are whatever people is responsible business role owner. So the people who understand which of which entitlements does this business role consist of. So distributed workload across a number of shoulders, the lack of translation, big challenge. So don't ask people things they don't understand. The answer never have a, will have a good quality. And another cause is that there's a lack frequently of communication incentives. So people must understand why they need to do it. And ideally there's sort of some incentive, at least communicate that it helps mitigating risk in an organization and inform people upfront that they will have to do re-certification at a certain period of time.
Don't do it different or think about there's something I will touch later on. When I look at the processes, think about getting rid of the re-certification in the standard approach of presenting sort of a big matrix, get rid of it entirely. And there are ways to do this in a compliant fashion. And then there are the imperfect role models where, where I see two major causes. One is not the well saw our models. So models, which where, where you missed making some decisions involving all the people, etcetera, and no strict enforcement of the rules and decisions you've made. So role models require that you consequently follow some design principles and decisions you've made. So what are some of the golden rules for role management? I could add another lot of others. One is role engineering is an add on not the solution. So start top down, understand your business process, your business activities.
And you can prove it by role engineering bottom up, but just doing role engineering. So looking at what I, what you have, and then trying to, to, to create some roles will not be sufficient because you most likely will, will, will violate the need to know principle, the least privileged principle, because you, you sort of rely on, on, on the, the past. So potentially excessive entitlements, which you then sort of codify. The other thing is segregation of duty as an integral part. So when you, when you go out and you have to talk with your, your, your business department, so with people in the business department, which ideal is more sort of a business architect or someone who's sort of the, the link to the it, not the departmental manager, first of all, keep it short and try to talk about the major aspects once not in many different meetings.
And when you start about talking about roles or activities, then you can also talk about segregation of Judas because desegregation of duties occur between roles and activities. So try to do it in one meeting and a number of meetings you need the business contact on. So part of your job clearly is that there is someone in the organization in every department who is your counterpart. And if this person's defined yet, then it's top of your enterprise organization department to create that business role integrate business. That's sort of the same. As I already said, you have to talk with business. You never will succeed in doing role management at the it level. What do it lean at the operational level? So don't try to talk, go into a workshop four days with the departmental manager or something like that. I've seen things like that, but it doesn't really work out consistent role models.
Consequently enforce. This is probably the number one goal rule at the end of the day. So the hierarchies relationships between different levels of roles, levels of roles, the terminology, the requirements for, for system level entitlement. So they must be free of OD conflicts. For instance, all this must be defined upfront and it must be consistent. It must be consequently first. So no exceptional allowed. So if someone comes and says, oh, I need to, to sort of group business roles into business roles. And you made a logical decision beforehand saying, there's no, there are no cyclists, no, no grouping of the same level of roles in each other. Then clearly the answer must be, there are no exceptions allowed because once you start allowing exceptions, nothing Bloomberg anymore, first of all, roles need processes and they need a life cycle. So it's not that you only say I approve a user, every role and every role change needs an approval and explicit approval.
It's not about, only about saying, okay, I create my 300 business roles, so sort of ideal work. And then I push it to my identity management system. And then I'm done these need to be approved at that point of time. And if something changes, it needs to be approved. Again, you need a process. You need a life cycle here as well. This must be part of your product. So this has some golden roots for the role management. You also will, will observe. And this is clearly one of the tougher challenges that roles are insufficient to solve everything. So if you have an insurance company and you have someone who's looking at the damage reports, then some might approve damage reports up to 100,000, $0 or some might do it above that level. So this is the competency. You also might have a context in which as if someone goes in, comes in with a insecure device using an insecure network, he's not allowed to do everything.
Or someone in a salesman is, is only responsible for people in a certain region or someone. A bank is only in charge of certain customers. And these are things which you can't successfully map into roles. So you, you might find some workarounds for, for particular organizations. So in provisioning, not only the role, but some additional attributes of, of the, the applications approach or you move forward to what we call AP adaptive policy based access management. ORAC. So all the stuff around XML, this is one of the areas you might look at, but this is clearly a little bit more the, the, the, the higher maturity level of things, doing things here, but you need to understand and think about how can you solve these things and finding the balance between avoiding a role explosion and being good enough, what you deliver to the systems. When I look at re certification.
So I talked about it, I think there there's some, some challenges in re-certification. And one of the challenges clearly is that people don't love it for, for understandable reasons. The other thing is I will this, as I said later on again, the other thing is when we, when you look at sort of to prevent, detect response part, so this, how do we work? And our evolution has been from administration. So we made director service then provisioning, where we had a little bit of workflow towards access governance, where we had some business involvement where we also might have done some integrations or our scene tools, cetera. And the challenge we we have here is still that it's sort of a very detective approach. So every 12 months, or maybe every six months, we go out and say, okay, let's look at the entitlements are still correct. However, there, there, there are some challenges. One challenges. If you do a recertification after 12 months, it means you can have 11 months and 29 days of excessive entitlements. So you might say higher risk. I go down to six months of recertification in the world, and you are at five months, 29 days. Doesn't really solve your problem.
If you do a working re-certification process, plus well saw processes for approving and requests for, for new, new access, that then you should end up with a relatively low risk. The other thing is your user might become an internal tech or at some point of time, or his account might become high tracked. So he might have some entitlements, for instance, for doing a bag. He might do 12, two backs instead of one and taking one home. So he didn't use other entitlements. He just used to once the app to have, but he app used them. He changed his behavior. And so behavioral analytics becomes more and more important in what they're doing. So we need to go clearly on the midterm or short term, depending on your risk and where you are in identity management beyond purely doing re-certification. And there's another point as upset, and I will touch it later.
We should also think about, might we do some things easier than with the big recertification metrics. So can we do do things easier? One of the challenges we, we, for that we always have to keep in mind also is that's something which goes into the processes, which also goes into re-certification, which goes back to my multilayer multi-level recertification. So we have access governance, we have identity provisioning, and we have a lot of systems below that. And in fact, it's that we have our role model, which frequently hierarchical and at, so the lowest level might be system roles or authorization objects, or entitlements that maps to something which is exposed by an underlying system, em, active directory, global groups, or SAP business roles, whatever, which are not the same as the identity management business roles. So when you do re-certification, you do it for the person to the business role, you do it for the business role to the system role, but you even need to do it for has something changed below.
So thus this active directory global group, or the SAP business role still have the same, the correct content, or is something which, which has changed. So you need to do it at various levels by various people, but always the right people. So do it. Multilevel do plan for a multilevel recertification and, and notably all the parts which are more system inherent or intrinsic. So business role, the system role system, or ad global groups to local groups. So this mapping layers, this is always a re-certification process. So this should go through sort of the standard approach of re-certification. While you can ease the drop point, I will touch later the ease. You can ease the drop of the departmental manager, whoever else who's responsible of re-certifying business roles to persons or, or users, this something I person believe you can make easier than metrics set up your organization.
Another very important point. There are various roles and tasks in your organization, and you need to have the right people. So departmental managers, which are doing recertification or approve access requests, they're data owners, they are role owners, which then are one part of the re-certification business architects system, owners, administrators, yeah, process owners. You have governance layer for the overall identity and access management, it architecture, operations. So have a number of, of roles. And you need to understand which roles do you have, which tasks do you need? The presentation slide deck will be available also for download. So I don't go into detail for every single role here, because you just can download the slide deck afterwards and look at it. I think this something I, I keep I so short here, but ideally you should understand there's decentral it where you have technical role owners at that level for, for the exposed entitlements, where you have the system administrators, your system owners, or application architects, there's a central it level, which is the IM level where you have business role owners at that type of things.
Are it functional road owners? And you have the business departments where you again have the, the higher level view of the business and the data owners, etcetera, and you need the governance function. So who owns the identity management processes, who does the identity management governance who's in charge of, of, of deciding when there's some decision to be made about how to handle an sod conflict, et cetera, you also need a side of a well sort organization and a good role concept. You need policies and guidelines. So you corporate policies and your regulations, in fact, influence your policy pyramid. And so you have to high level policies which can go down into concrete guidelines, ensure that you have the entire poly pyramid ready with current policies. So investing in the policies is extremely important, and this should be one of your first tasks defining how things should run it. Information, security, identity, and access management, and the various parts of identity and access management, because this influences your processes and your organization and policies. You know, this is, this is something where you can rely on best practices. So without it, multiple times and policies basically are not fully the same, but they are very consistent across organizations. So it's not something you need always to reinvent. Look for someone who provides you as a best practice.
Another very important thing is then when you talk about policies, maybe not that much about policies, but when it comes to processes, et cetera. So if you look at re-certification roles, these are complex things. So particularly in that area, don't try to be better than the rest of your organization, build your processes and build a process model. I have a sample here for lean process model model, which is not working this roles. We have two sets of process models ready for, for, for, for sort of realizing so things where we have standard process models. And this is example, which is close to one of these, these models, not the exact one, but basically there are some things. And so there's model management, onboard applications, software applications manage your key uses, create entitlement groups, preapproval for standard entitle management with are automatically requested, have your standard leave and emergency processes.
And what we did here, I think this am zero four is the most important thing. Maybe here. What we did here in this model is we said, okay, we have re-approval for time restricted entitlements. So instead of doing a full reification, we say, okay, you grant. So you, you request an access for your request from entitlement or business road, whatever. And this is done only for six months or 12 months, depending on the risk. And one month before this period end, you get, or the approval gets reminder, says, do you want to reapprove then there might be another reminder and that's it. And if, if it's not reapproved it's removed. If it's reapproved, it's fine. That moves from a big metrics of things. Someone has to look at the departmental manager to singular decisions. Yes, no. Should he have access or no, very simple to do.
Makes it far easier for everyone. Particularly if you manage to distribute the re-approval of a new user across a few weeks or days, so that everything happens the same day, and this is something where you in first least privilege. And from my perspective at a better quality than was any re-certification metrics. Because if someone has to look at a complex metrics of 20 users and 20 entitlements, these are 400 decisions has to make in once very complex. And if you, if instead of using a tool, he has to, to look at 75 or 150 pages printed out of entitlements, it never will work. So won't be good. If it's simple decisions, the results will be better. Look at standard processes for escalation and approval, etcetera. And this is what we do saying, look at standard process, ask you, when are you integrated or someone else such as us for standard processes, don't start from scratch, start with 80% or something of what you have.
So what we, for instance, deliver our standard process and the EPC notation. So our based on the errors tool with additional robust description of what is in what you have to consider, where are the typically changes, or where did we make a decision to go that way? But you might do it the other way. So there are standard processes such as standard leaf or emergency leave. And this is really where I see the point. So follow golden rules for, for role management, understand your role management, look at guidelines and policies and look at standards for those best practices. Look at standard processes, particularly because this is a very essential element in getting better in your identity management. And then you will get rid of a lot of these diseases. So this was a quick run through the, the challenges, the, the symptoms, the diseases, and some ideas are on how you can address these right now. I'm open for your questions. Happy to take these questions. And if you have any questions, first, the questions don't hesitate to, to call us and my colleagues for further information for further detail. Or if you say, Hey, this topic should be something you should do a separate webinar on, just drop us an email. Maybe we do it and go far more into detail. Then limited time we have one webinar. So questions from your end.
So, so one of the common questions around the process model clearly is does it work with, with average tool? The answer is there might be challenges even while, while we have a lot of experience, we, one are tool. Clearly it's also part of, of selection. Basically a process model must be independent of the underlying tool. So if you change your tool, the process model must work, must still work. This is a very important aspect to, to keep in mind. So it must be independent. On the other hand, the point is that you can save a lot of money on implementation. I think this is a very, very important thing to, to, if you have processes, your developers know what to do, they don't start with sort of trying error implementation of workflows. And this is where, where you really save the money. Okay. I have another question here.
It says, if you have complex processes, how do you avoid role explosion? I, I, I think that the, the role explosion challenge doesn't come from the, the process, the role explosion comes from application requirements, which, which are around that. You might have applications where, where you have the need to say, I have, I've brought up some examples. The, the insurance person who is only the approval to, or the right to approve to a certain amount of, of money, etc. So the best way to avoid this, to implement for these situations, aback. So attribute best access control or APM model. The other thing is look at the single application and look at what do you need to provide a side of the road? So can you provide, for instance, provision sort of certain attributes into the application or make it accessible as part of the identity, if you can't do that, then the only solution is to accept that you at least at a technical level, need to create these roles and then try to find a tool which supports in doing this as automatic as possible.
Hope this answers the question, but, but have you go into sort of offline into, in a deeper discussion on that? The other question I have here is sod should be considered while designing roles. Yes, no question. However, different ERPs have different processes. So how to handle so D in sort of such a scenario. So I think we have to, to differentiate between two levels. One is sort of the, the system internal part of sod and the other is the cross system sod. The cross system sod is, or the cross authorization objective. So what, what we expose or the cross system role is what we really look at in, in the, at the identity management level. So, so first of all, everything which was supposed, which can be used in the identity management must be free of sod conflicts inherently. This is the first rule. The very important rule. The second aspect to consider is then how do you handle then sod conflicts, which might happen because you assigned two SAP entitlements in your identity management, or even cross systems. So things which go beyond just the SAP system, that's where you then need to understand. That's a hard job. You need to understand the, so here, here, you really need to understand what, what does the single sort of entitlement you have at your IM level include and how do you build your sod roles rules done here?
So this is really partially it's, it's a, a manual process, not very easy, but you need to sort of, and have your own sod management, which means you end up in fact with two layers of sod management. Another question I have here, are there any standards around access to request end user screen for each day, 30 applications in landscape looking into end user firms? No, I think you should, should try to, to keep it simple. So, so it's, you have one X request where request things at a high level. So for instance, at the level of business roles where you converge things within applications and the part, and, and so you don't request per application, but you request a business role, which includes various things within an application. So it's really building a higher level of roles here. And this is one of the things where you already say, this is my, my cross system approach here. Hope this answers the question. Otherwise, feel free to, to, to connect back offline, start me an email, other questions. So if there are no further questions, then I hope this, this webinar delivered some, some, some valuable information, some valuable insight to you feel free to contact us source of questions.
And thank you very much for attending this call webinar. We have a number of upcoming webinars in next few weeks. So have a look at these and hope to see you soon again, one of our upcoming webinars or other events. Thank you. And bye.
