Access Risks - from SAP to the Outer Space: an Identity & Access Governance Journey

Good afternoon, ladies and gentlemen, welcome to our equipping a cold webinar access risks from SAP to the out space and identity and access governance journey. This webinar is supported by Chris ideas. The speakers today are me marching clip of a cold and Marcou of course ideas. Yes. Before we start some general information and some housekeeping information. So first of all, keeping our call Analyst Analyst company, we are focus on enterprise it, research advisory decisions, program networking for it, professionals for our subscription services, our advisory services and our events.

And the most important event is our European identity and cloud conference, which will be held next time in April 17th, to twenties to Munich. I think you definitely should have a look just at the agenda, our conference website. It'll be definitely the place to be around identity, access management and security and all the other things, especially also around the topics we've been discussing or we will discuss today. So you will find all the information online regarding the webinar itself. I have slides with some housekeeping information.

First of all, you are muted centrally, so you don't have to mute or mute yourself. We are controlling these features. You don't have to do anything around us. Second thing is we will record the webinar and the podcast recording will be available latest by tomorrow and our website. So the same side where you find the information about event, where through Dell, we also will put the podcast and we will also provide the PDFs of the two presentations of today there. So you will find all the information in one place Q and a will be at the answer.

We'll do a formal Q and a session at the end, but I think that's very important. You can ask questions at any time using the questions tools. If you look at the right side of your screen, just go to webinar control level, you have an area of questions and you can questions at any point of time. And we will pick these questions either appropriate during the webinar to directly answer these questions or in the Q and a session. So we've all done do this.

And my, my advice always is if a question comes to your mind, enter this question directly, because I think that serves two purposes. One is you directly have entered the question. You don't forget about it again. And we have a comprehensive list of questions once we start a Q and a session. So it definitely makes sense to do it. And there's then there's a use here.

You'll also be able to earn, or we are starting providing CPA, CPE credits, so called continuing professional education credits, which allows you to, depending on certifications, you have to use this webinar as one part of your continuous education as an it professional. We have define learning objectives for this webinar. So after attending this webinar, you will be able to list your alternative approaches to managing risk at the enterprise. Describe the SAP specific aspect of managing access risks.

In fact, focus of access risk, and describe how to implement access risk management and access governance in a way that works for P as well as other information systems. So that's what we are doing today. This event qualifies or will qualify then for one group internet based CPE, and to obtain this credit, you will need to take and pass a test. Following the webinar, when your attendance has been confirmed, you will be sent an email containing a link to the test and you can and do it. You can do the test.

And again, this is something we do. We are web. So we have all set right now for this CPEs and we are looking forward to do it continuously for every webinar we will do in the future. So I think another very good reason to attend, copy a cold webinars besides the once, you know, and which led to your participation today. Okay. The agenda it's split into three parts, like, like always the first part is my presentation. I will talk about how to manage access risks for the enterprise for all environments. And I think that's the important point.

So really looking at all the different environments, the second part that will be done by Marco ity, of course, ideas, and people talk about how to implement an integrated approach for access, risk management and access governance. It works for both SAP and the rest of the world. And on the third chart, finally, as I've said before, we will do the Q and a session for the questions we have will picked, curing our webinar. So that's it. And so I directly want to go into the detail. Now I have a pretty much pretty big list of slides and mark also has a lot of slides.

So we have to look a little bit at the time. So access governance services, what is about, so what we are talking about is we best defined terms. First. I think there there's three main questions to answer them are some more questions, but three main questions. I always see when it's about access governance that's who has access to what, who has access to what and who has created access. So that's basically what is the reason for doing access governance. And we have a lot of regulations and we have a lot of other requirements.

So the internal need for information security, which lead to a situation where we need to be able to quickly and correctly answer these questions. There are a lot of technologies involved, so typical access governance suites. So the products which the products, access governance, which come different flavors from different vendors, they both different technologies. One is an access warehouse source and store where you have your access rights, right out of the different systems connected and where you have a sort of a complete repository of these access rights.

We have the access re-certification. We have the access analytics and intelligence prior to really analytical features. We have access request management. So how to request access based for example, on roles that also leads to a situation that virtually every access governance tool also has a strong support for enterprise role management, which is more sort of an underlying concept, which needs to be supported. And finally, we have the area of access, risk management access, risk management is done something that helps you to act in the context of a specific risk.

And for example, to say, our re-certifications cans are different for high risk items and high risk systems, high risk information than they are for other types of information. So that's what we're talking about today. And we'll talk a lot about risk in that context. So a risk one is we have a threat, so we have something we are facing. There's a probability that this happens that has an impact on assets, and that has some, or we can do some valuation around this and in the consequence, it also has an impact on business processes.

So I think there are different different ways to define risk, but I think talking about threat probability, the impacts on the assets or the valuation and the impacts on business process is a very good starting point. And a very important thing around risk is that there is probability that there is a measurable impact. So it's that uncertainty, it's a risk. It's something we know that could happen that would have this impact and where we could think about what do we do to mitigate this.

There are some commonly distinct types of risks, like the strategic risks for business perspective, the operational risk for business perspective, the it risk some also talk about reputational risks, which could be also defined as is operational or strategic, depending on how Soly your reputation is affected. For example, when you have to do a breach notification because some information leaked from your organization. So we have different types of risks.

And I think a very important point I will touch on touch on this later again, is that when we think about it, risks and about access risks, they always have an operational impact. In some case they have strategic impact. So if you're have a severe issue with your information security leaking PII data, for example, so personal identifiable information that might end up with something which really affects your teaching in the business, which in first case might drive you out of business. So the reason why we look at these things is trust because they might affect our business.

I've put one, one picture out, which is a little bit more complex out of our report on the PRC reference architecture, which again, trust shows we have Strat with a probability and impact valuation. So the assets affected the business impact we have there, and what we need to do when, when talking about risks on a higher level is we, we, we need to understand what are our risks, what are requirements we do? I could defining controls, power requirements modeling. We have to do the status investigation, which could be quarterly, monthly, or sometimes daily.

And the more we do automated, the better we can do it daily. We need to do improvement activities to mitigate risks. So that also includes the projects and we have to have a crisis and incident management in place. I won't dive that deep into this. So there are a lot of podcast recordings out available there, but I think what is important to understand is access risk is also something which is in the bigger picture. So when we think about access risks, we have to model the requirements. We have to analyze it to the TRC status investigation.

We have to improve our status by bringing in the right processes, the right tools. And we have to be ready for, for reaction on when something goes wrong. And by looking right now specifically about access risk to the try core aspect of our webinar today.

So why, why do we need to sink and risk? So, as I said, a risk is right on an asset to specific probability and impact and informational risk is specifically for information we have to, all I think about is from the perspective of business. So what could happen to the information in that case? That's the information risk part. We have a business risks and business risks just there, because information is part of business processes, information, risks, impacts business processes, and does imposes the business risk or operational risk probation, risk, strategic risk. And so access risk.

When we look at this, then we are looking at the part of information risks, which are related to information access, which is the biggest part of information. That's the reason why we are talking and looking about these things and why they became so important for many organizations, what you need to do. So some simpler rules around us are, we need to know about the information. We really need to understand what are the assets, which are in danger, right? Danger. We need to understand risk associated with specific information. We need to mitigate this risk.

So we need to focus on this to understand what are the most important things to look at and how can we mitigate the risks, which are either the biggest risks or overall the risks where the balance of risk and reward fits. So in some cases you might, might end up with saying, okay, I could, that's my biggest risk, but I can't successfully mitigate it in that case, the balance of risk and reward doesn't fit. So that's where we have to look at it. So that's a big, basic picture.

So what we need to do is to understand which information is used by which services and which impacts which business processes we have to understand, which are the threats we are facing, who are the ones who are threatening the information, which could be accidentally. So it could be someone who doesn't want to do it, but he doesn't, or it could Beely, it could be someone who really attacks us or someone who bypasses or tries to bypasses or de controls and other things I think, knowing who is the, let's say sort of D quote of enemy is a very important thing. There.

We need to understand what could happen. So think about sods and about critical information elements. What could happen if someone bypasses an S O D rule or ANV rule, which isn't enforced by a system, which is only printed on paper. I think we had a lot of very, let's say prominent exams around this. If you look at the finance industry and the UBS case or substitution, or I case, for example, the other thing are critical information elements. So even while we might not necessarily have an, an SD violation, there are a lot of things around access, which are sensitive for themselves.

So someone who can approve a contract above a defined amount of money is dealing with the critical information element. So we have a lot of critical information element and we have to look at these things. So there are a lot of threats. We have to look at the probabilities and we have to be realistic around proba.

So what, what we really frequently observe in our advisory businesses, the companies tend to let's say rate risks too low. In many cases. I think that's a very important point to look at and we have to look at impact. So what is the realistic impact? Also something where, where I've seen a lot of, lot of organizations underestimating the impacts and attack, or a problem could have which business assets and processes are impacted. And we also should move towards working with standardized impacts in a direct and indirect way.

Another very important point for my perspective is that we, we need to understand when, when thinking about access risks, but access risk is not thinking about system security only. So in this picture, I have the level of service governance, process, governance, information governance, and then the traditional approach. It's sort of not even service governance in most cases, more sort of the system governance, which means we are looking at, at which risk is a specific system.

However, there might be information, a system like PII, which is at a much higher risk of financial information, which is much higher risk where it's other information. That system is at a very low risk. So it's not a system itself, which defines its information. The next step would be to understand which information is held on which system and to understand the system specific and the information related risks. So that's a, let's a much higher level. That's where we're to talk about really information governance. And that really also leads typically towards the same more service approach.

Sometimes it's more systems. Sometimes it's more service where we are looking at it's moving forward there. When you really think about services, then I would say that's sort of basic cloud governance and information service governance, where we really understand which service accesses, which information or deeps, which information. And we look at relationship of this. So that's a for sure, a more complex thing, because we have services in one dimension and we have the information, the other dimension, but we really understand then in that case much more about there is.

And then, so the target over time should be full governance, something which is really cloud ready, and which is very business oriented where we say, okay, in fact, the, the link between the services and the, the information that this are a business process. So we have a business process, we have technical services and information used in these business processes. And if we look at all these perspectives, then we are much better able to have a very CR fine crane, very granular view on the information risk.

And then we can much better target our activities and, and understand where do we really have to look at? Where are the biggest threats, where things we have to address? So access risks, that's from that perspective about defining risk. And so we have to system you, the thing I've talked about, I'm, don't think it's sufficient today, even while there are some standard slack Fisher spit off analyze of protection requirements, which still deals with this approach. I don't think that it's enough and we need the information you there's much more fine train. And just as an example.

So, so for example, if, if someone is reading a large number of PII records so much might be a much higher risk than changing just one of them. So it's really at the end of the day, it's about the activity or the business process and the activity, the function within the business process, look at the information and at the services within a system. So we have, so dilemma system for itself is sufficient. Information probably is more, but also not fully sufficient. We need to combine these views.

So more detail to end up with some more detailed view at least of system and information better would be servicing information or direct relationship to, to the business process like I've talked about and unexplained in the chart on the slide before. And we also need to have a, let's say a standard approach for risk rating. So at least for in initial approach, sort of this type of rating is usually something.

We, we see a lot. So where we say, okay, if easier, the, the impact is very high or the probability is very high, then it's red enough. Then there are some yellow areas, and then there are some green areas. So we can at least have a basic rating of these things, for information, processes, services, and or systems. And I think we, we need to do this in a, in a way where we really look at a business as well. We can't do access risk management. We can't do the entire GRC things of GRCs term for governance, risk compliance, where access risk management is a very important part.

And without really understanding the business side of things. So it's about understanding the relationship of different risks. Generation risks can turn to strategic risks if they're big enough, but it risks are only relevant because they affect operations in somewhere or another. And that's also, they couldn't impact corporate strategy. So one of the examples I I frequently use is let's say Sony, the attacks against Sony in the plays station slash online gaming area in that area.

It's if, if things like that happen too frequent, then you might really lose your let's say, market position in that market. And I think that's really where thing turns into a strategic risk. The thing is you can ignore risks. So it's always about a mix of manual automated controls. You need to have things in place and it needs to be consistent. And if you look at regulations, for example, they're always also about it. I want to keep these things a little bit shorter, but I want to have a look at the it thing as well.

So it's in, in the, it, we also need to understand the relationship of different risks. And that's where, where we come to this SAP topic where laid sort of the foundation right now, which is much around the access risks thing itself. And Marco later on, we go much more into detail and regarding SAP specifics and our things. And the point I want to make is we need to also understand that we can't focus on one part. So in TRC, in general, we can't focus only on the business side in it. We can't focus only on SAP.

So business process never rely on SAP systems, only sensitive information isn't held in SAP systems only. I don't know any organization where that would be the case. You might have documents in the file system where you have a lot of other business systems. In many situations, you have to think about all the CDs and process systems down tole, SENSIT information. You can ignore the risks, sods and critical information elements are in SAP only. And there are also sod. There are sod aspects for sure. On the system level, there are sod aspects frequently, which span a lot of business systems.

You might have our system. So we have to look at all like risks and we have to do it in a consistent way. And regulations are not only about SAP. And so from that perspective, it's very important when we start really looking at access risk and how to do it, right, we shouldn't ignore the out space like it's called in the title of webinar. We have to look at it for both sides. We need to do it sufficiently good for SAP, and we need to do it sufficiently good for the rest of world.

And we need to do it in a way where we can link these approaches by either using one approach or by our tight relation of the things we are doing at all areas. So, so we need to understand the, this, the complexity of machines environments on the other end. So we have our business processes with our function or our business roles, the policies and sod, which are cause consist across the entire enterprise, sort of we have the information, its risks, and within the systems, then we have a lot of, let's say very specific, let's say concepts in there.

So we have business roles or, you know, versions profiles. We have transactions in SAP. We have 80 visits, different types of groups and the ACLS. We main the mainframe environment we have yet, yet other concepts. So for sure, it's a complex environment we are dealing with, which doesn't make it easy to end up with one approach for everything, but we have to move forward that direction. And that usually is done by, let's say sort of a multilayered approach where access governance is sits on top of more technical interfaces to different, which could consume also things.

And it's, you might have some provisioning, which is where targeted to SAP. We might have other provisioning solutions in place, but you need to link to business C as well, and you need to provide an interface for the business user who can look at access, risk policies, analytics, all these things from one perspective, an access governance is sort of the layer where you really could bring things together and you shouldn't end up with doing these things fully separately for SAP and for rest of the world. It needs to be very consistent.

And I think that's a very important message I have to, to, to bring over there. And for sure, that's sort of I'm dilemma. We are facing there to, to some degree. So if it's about cross platform capabilities, for sure system specific administration tools, or just some specific GRC. So you like a P GRC are better. Whereas other tools like classical provisioning or governance better suit the needs of our environments. And it typically central genius. On the other hand, we have to look at a GRC readiness of information and there it's about governance or specific solutions for different systems.

And so when we look at this area, the question is how can we find something which is in the upper right at, which is system specific enough, or how can we integrate it with the things we're doing system specific. But what we shouldn't do is we shouldn't say, okay, we do it here for SAP and we do it there for the rest of the world. So the dilemma is sort of to detail us for particular systems versus the coverage of all systems. That's from my perspective, occuring we have to look at so how to manage risk and hetero environment.

I think there's a organizational side and there's a technology side. The organizational side is we need a common framework. So one approach for process policies, one terminology. So it might be a group at a system level or a role or whatever at the next level. It should be one term we are using. We need a consistent role concept derived from the business process. On the other hand, technology wise, we need to go beyond SAP, but be strong in SAP, have a common top layer, access governance infrastructure in place.

That's typical recommendation doesn't fit always, but in most cases, and we might also require some other system specific solutions for detailedness, but there are three to look at, what can we do consistently and how do the things we do across all the systems? How do they interface is what we do at a system level? So that's the way we should move forward. And the business has a very important role to play Darren. So who knows about access policies who understands the business risks requires access and should request all these questions are questions, which enroll to business.

So we need to end up with some approach which truly integrates business and it in a consistent way, I won't go into details regarding that slide. We had a several webinars, which focused on things around that. And you will also find in our PDF version of the, of the, the presentation. So you can go more into detail. There.

Last slide from my perspective is then about how to balance work and regard because when we want to hit all business, we have to give them something back, keep it lean, inform the business, show the benefits prepare well, what you're doing by guidelines, works policies and so on and work focus. So that's what you should do to, and how to do it in an environment where it's really about SAP or SAP in the hour space. That's what Marco right now will explain. So I hand over directly to Marco and yeah. And try the presentation of Marco For the second part of this webinar.

Thank you, Martin. Thank you everybody. I hope you can see my screen already. And while I'm Marcou I cross idea, look after alliances at a moments. And today in the next 20, 25 minutes, I will touch on a few things, including some my level details around cross ideas, the way we approach. And we look at the identity access governance solution, and specifically how we do address the specific nature of SAP. And finally bridging the gap between the SAP specific universe and enterprise level identity access governance.

This will lead us to conclusion and we will open up to question and answer so about cross ideas. Very briefly cross ideas is a leading innovator in identity and access governance solution. We believe that our solution really enable organization to achieve their compliance bullet and access management objective cross ideas, by the way, is just a new name for a company that dates back already almost 10 years.

And it started playing all in the Italian market with a name that was angio web security at the time in the authorization management segment, providing solution originally framework and later product to manage externalized authorization capabilities and layer moves up the stack providing also the lifecycle and Al identity management. So approval flow, segregation of duty, and finally approaching the so-called access governance space. So including features like well mining and modeling, running access certification, and segregation of duty, also specific for the environment.

More recently since last June, the company change is naming cross ideas and to a management buyout and became an independent company now approaching the international market. So that being said, what do we do? And now we, we do that. So starting from, from the basic, if we look at the way, the major consulting firm like APMG or Deloitte, what they do consistently report in terms of major it security audits, it's still unusually ranks the first row, the inability to certify the right people at the right access to the sensitive information.

And then after that other requirements, which are more on the tracking and logging and auditing what the action has been about. But what is interesting for our purposes today is that if SAP is part of the application estate, well, that is probably the place where they will be starting from for a very easy to understand reasons that a large portion of the core business is in there. So talking of anti access governance in general, what we do consistently find is that the most frequently asked, ask the maturity path that our customer follow pretty much look like depicted in this slides.

So the first step is about collecting information and getting to one single view about who can do what, and that becomes the perfect place to check the distance between expected state and actual state in terms of policy compliance, sod, but also other. And then moving up to the second, the, the usual approach includes start cleaning. The current status. Cleaning includes usually running one or more access certification campaign or access review or attestation campaign, as you wish. And thus reducing the inappropriate access UI distributed.

This means involving business user in approving or rejecting permission associated to people reporting to them. Moving up after this cleaning, usually we see that our customer looks like looks at building roles to better represent what are the access rights in place and to make them consumable for the next phase, which is managing in a more structured way access request to provisioning and the provisioning process with a proactive involvement of business user. And that's pretty much what we, again, we see consistently around in terms of identity and access governance requirement.

But for those who also has SAP, there are some specific issue that pops up pretty quick in the conversation we usually have. And those questions are like, are my SAP roles already including violation per se?

I mean, not very cleaning design or more specifically, what about my SAP user? How can I check appropriately if there is any sod segregation on duty violation is affecting them. And this has to do with the specific nature of the so P optimization model that we will discuss later. And third I in general, my role accurately designed, or to put it differently is the role name, reflecting what they actually really deliver. So those key question can be summarized in a more eye level person or abstract one that can be phrased, like, do I really need a dedicated approach for SAP itself?

And if yes, does it also mean that it should come from a specific solution from a specific product? Well, hopefully the, the rest of my presentation will address this question and we will close with, with our answer to those. So to answer this, we need to have a closer look at what is an identity and access governance deployment set of stepping stones. So not just what logical step, but rather the way to get there.

So every customer would really like to get to an augmented set of control in place controls are for instance, segregation of, or running access certification or managing exchange request or measuring and monitoring risk over time to understand if we are improving or not. But to get here, we have to step through some intermediate steps. The first one world is very technical is very, very obvious is about integrating the information from the systems. And this can comes in two flavors. It's a read only approach or a read bright approach, depending on the level of automation I wanna reach.

What is missing in feature is that is the core one, what really bridges the it languages to make it consumable to the business level. And that's the translation or the logical integration, if you will. So that's basically includes two methodology, one pretty well known, which is the role modeling and the other, which we name activity modeling. And on the importance of this middle level, I will, I will spend a few more slides because this is really what makes a big difference in unlocking the option to address in a consistent way SAP and other application at the same time.

So talking of translation well about roles, just one single slides to account that roles are the most effective way to provide business user driven, provisioning, aggregating, and so abstracting from the fine grain distribution of it permission and also abstracting from the it name to a more business readable set of names. That's easy, nothing, nothing new.

Okay, but about activity, the second type of description of a translation that I introduced well, that's, that's something less well known activity based translation has to do with the definition of a business activity, three meaning processes subprocesses and business activity that constitutes a description of what a company deliver. This sort of description might come from predefined samples existing in our solution, for instance, or from existing three already present in the company from maybe other GRC or process management systems.

But adding such a description is something that can be used as sort of unified taxonomy to look at how to translate application permission, basically asking to the application owner to define link between each and every permission in a given system toward the right business activity in the tree. And this is the fast, possible way to provide some degrees of translation of what an application deliver. If I have such link.

Well, basically I'm describing, I mean, modeling my reality in a way that looks like this is a two layer approach, a pure business layer where I have a business description and that is managed by business specialist and by them approved and an it layer, which is about linking the right activity onto the right place in the application estate. So it's a very clean separation about who defined, what is the business like and who defines Saudi it supported business. And this is also perfect for a meaningful and readable segregation of modeling.

So that for instance, I can clearly define in a very business level language that purchase order creation should not deliver in conjunction with purchase order approval, permission, or other activity, which are in conflicts. So that segregation of duty becomes a series of link across business activities with such a model implemented. We can get to a view on the existing distribution of access, right? That looks like this at least look like this in our solution where the user is recognized as a conflicting one.

And the conflict I had is described in two waves, there's a business level description. So aux senior inventory entry, which conflict with physical and quantity balancing, but there is also an it description, which is about which permission associated to those business activity are actually making the comfort such in this case by accident, we have a SAP specific permission, but this could have been from permission coming from active directory, if you name it.

So well, the point here is that we have a two separate layer, a business description, and it level description of what is a segregation of duty constraint. Like now that being said, we should clearly specify what are the key things that the role model delivers and the activity model delivers just to summarize them. We have two complimentary way to look at the application states. So starting from the application and from the permission exposed, we have the role modeling, which is the best approach possible for an effective provisioning and access certification.

While at the same time, we have an activity modeling, which is the best possible approach for an effective segregation of duty model.

More in general, what we see here is that we have a clean separation between the way I deliver access and the way I control access, which means us to narrow way of control that we can apply on what we deliver, because we can have definition of things like conflicting roles, meaning roles that, that why when jointly assign, deliver a conflict to a user or more interesting for our purposes, the notion of illegal roles, a single rules that already intrinsically includes a segregation of duty conflict. And by definition propagating the same conflict to the user that get assigned to it.

So this is, this is something that really is applicable to any concept of role. So roles is a pretty broad definition. We have two basic concept of roles. We have the enterprise role where a role means collection of entitlement from multiple application, but we also have the notion of SAP roles where a role is a collection of SAP transaction, plus authorization object, plus field, et cetera.

So that what really makes us able to address the combination of SAP and entire universal Saudi SAP, is that we provide two ways of managing access control, an enterprise level, where we look at SAP as just like any other application. So SAP's subject to provisioning and the provisioning can be subject to access to certification is considered one measuring risk. But at the same time, we also look at SAP with a specific methodology to better understand our user and roles are doing against our access control policy. So let's have a closer look of what we deliver specifically on SAP.

So first bringing back the same description I had before regarding a conflicting user. If I look at these lights and iCard this the question we started with, how do I make sure that those SAP roles that I'm using at enterprise level are not already including conflicts? How do I make sure that this user is really including this segregation or duty conflict when it comes, when it's assigned to multiple SAP roles and more in general, that specific name, that those roles has is really meaning what it sounds like.

I mean, it's just, is not delivering anything else apart, what is described by the name. So to, to, to better understand why we are this issue, I will, I will recap a few things about the root code that goes, that create this issue. The first one is about the nature of the authorization model of SAP, which is based on things like transaction authorization, object and, and fields that qualifies them. This model is some specific implications.

So just to make it very, very quick for the Porwal of our conversation today in building large role with SAP at transactional authorization object, I can have the cross-contamination that among the transactional authorization object that deliver an unexpected unintended set of permission, that was not really meant to be delivered. Okay. So in essence, I need to be extremely careful about which transaction and which authorization of that I combine not to have this unintended permission creation. The second route chose is about role design habits.

So nothing to do with the, with the nature of the moderate itself, but rather to the way I build grows, given that why building roles in SAP, we have to deal with thousand of transactional authorization object SAP provides a way to specify wildcards in building them, but this leads to some very frequently bad habits like that can be summarized like, well, if I design a role, I for sure test that what the role was meant to deliver is actually in not necessarily, or not usually, or not always, I do verify that anything, anything else is in.

So basically I'm not really checking that I'm not adding too much permission to a single role to make a geographical analogy out of it. I can have a name, role whose name is Germany, but in reality it covers much more. So the question becomes, how do I understand really what a role includes or to put it differently back to my analogy, geographical analogy. I do. I define country borders, which shows up in every single role to do that. We introduce a new notion, a notion that in cross a ADSS, we call risk entitlement. That's that is our version of the county border.

This entitlement are a combination of transaction plus authorization object plus parameters that define the well-defined entitlement to, to perform actions in SAP. The good news is that we are not supposed to be building. We have the list of risk entitlement in every single customer, but rather using a catalog of redefined risk entitlement that can be used to identify what law will deliver. If I have risk entitlement, it means that rather than looking at SAP rules to describe in terms of business activity, what they mean I can link my business activity three at that level.

And again, this is something that given the commonality among the various SAP implementation is largely coming from predefined examples. So once I have this, it means that with the notion of risk entitle and I can identify which concrete are belonging to which role. So here in this graphic, the highlighted ingrained role is be, is made, actually made of those risk entitlement.

And this is a achieved that we pattern matching analysis that identify what is constituting that role, and also is identifying in the same way we show up before, which are the conflicts that this role might already include. So in this case, we are detecting a legal role depending on the country. They actually really show up in there, so that in making a long story short, we have multiple things that we can check specifically on SAP. We can detect which other legal roles around we can do a very detailed analysis on the conflict of user.

Also keeping into account the notion of cross contamination that I mentioned before. And then we can do a meaning validation of what, what a role deliver, even that we can identify which risk and tie.

So that, that, which business activity actually assigned are possible with a specific role. And finally, we can identify, which are the best practice role design violation in place, meaning which role has been designed with the range transaction or star transaction and, and others.

So that back to my question list, I believe that now should be pretty clear that we have an answer which has, which is SAP specific and depends on a combination of factor, including the notion of risk entitlement and including the notion of business activity three, that makes possible to the answer one by one, the key concern they usually SAP user have.

So now coming back from the SAP level to the enterprise level, if we have an enterprisewide approach to of access governance, well, we can look at SAP the same way we look to any other application talking of, for instance, of segregation of duty business activity modeling. We can just trust the SAP role, but that is an option that can be later changed. And so that we can change our mind and maybe dig the level down.

So I ignoring SAP roles and, and linking our activity model to the risk entitlement and provi and bridging back this to the role level, identifying the violation and fixing them, and finally bringing up back enterprise level the correct and accurate linking of what SAP roles are really delivering in terms of business activity. So as a final sales slide to close my conversation, what we deliver at SAP specific level links to what we deliver enterprisewide level. And it links because it comes from the same solution with a unified approach.

Basically SAP provides SAP specific level analysis, provide a translation and more accurate translation of what SAP roles are delivering. And this can be useful for the purpose of an enterprisewide identity and access governance approach. At the same time, the enterprise-wide approach can extend it to SAP. The things that is meant to be delivering, right, like access certification, provisioning, and risk scoring to make it visual.

As a final example, talking of access certification, an ordinary access certification will probably look like this, where for instance, as a business user, I'm required to approve or reject an SAP roles that by the way, feature a description that probably the application owner typed in to express what the role really means, but both the role title and the role description can be better translated with the deep dive, into the SAP model.

And with the analysis that delivers back, what are the business activity really provided by this wall and bringing back a much higher degree of visibility and certainty about who can do what? And with that, I closed my presentation and bringing back the key question that I started with, do I really need a dedicated approach for SAP?

Well, absolutely. Yes, there are multiple solution on the market, but that's what ACP deserve and requires. And the second question does it also mean that they need a SAP specific solution. So only for SAP, well, hopefully you understand that not really, at least cross 80 years provide a solution that can understand both the SAP at the enterprise level.

So that with cross ad, we have a unified model again for SAP on SAP, and we leave the flexibility to the customer to choose whether, to keep it at enterprise level the beginning, and maybe digging a bit more later into the SAP specific level or the other way around, up to the customer. And finally, still leaving the option to apply to ad the controls beyond the OD likes as certification provisioning and risk scoring. And with that, I open it up for question, I turn it back to Martin. Okay.

Marcus, thank you for your input. And one thing I'd like read to stress again, is what you need in any way is something which integrates to different words. So I think the really very, very most important thing is really to understand that you can't do these things and then we separate it from each other.

And so, like mark said, and going back to our agenda, you can ask questions, you should ask questions and really ask you to answer your questions. If you haven't done it yet now, so that we can have a DNA session talking about the points you might want to, to discuss a little bit more in detail, you can use the questions area in the go to webinar control panel for that purpose. So I want to start with just some, some two or three questions, which I have here right now. One is just question to, to Marco, which level of details must and or should have activities.

So when you think in this concept of activities in many organizations, the business process documentation is incomplete. So you you'd like to have something where you say, okay, these are the activities, but you don't find it how to deal with that situation.

Well, we, we see a big diversity depending on the customer sensibility and depending who is starting the question. So for instance, we range from customer that has something like 300 to 500 activities in three, which means, which is already a pretty detailed example of business three from other customer, which are doing very course grain approach. So on addressing a very tiny subset of the entire set of activity that a complete description would require. And so having something that is totally compacted, so there's not a unique answer.

It also the extension, the size of the business activity is another way to look at the maturity at the approach in dealing with sod that we find in our customer base. So, so what you're saying is in fact that even, even if you have don't that much don't have that much of documentation around business processes in place, you could start anyway, because you can set up things for the critical areas pretty quickly. You can focus on specific areas. You don't need to have a sort of a complete process, Des business process description, place to start. That's absolutely right.

And by the way, we do provide along with our solution, a set of templates of business activity tree that reflects various verticals, various industry. But as you said, the business activity is not, this is not something that is meant to be fully blown since day one. Okay. Something that is typically subject to refinement over time and maybe driven by different needs or different focus area where we're looking at in the access governances approach. As I said before, if you have any questions, please enter them now so that we can pick them within the session. For sure.

You can always approach two percenters of the dated Analyst. So Marco and me also via email after the webinar. Another question I have here is, and that's probably a question which, which I want to, to start answering. So how can you solve the dilemma of not having business involvement? So the rules, the organizations in place, you also don't have a tool. And on the other hand, you have a tight schedule. I think that's something we, we see frequently in the advice risk we are doing that. There's the problem of to do it, right?

I ideally would have, I would need a lot of time because first of all, should understand what, what are my processes? What is, let's say the entire, what are the entire requirements to pick the right tool, the perfect tool. And afterwards, then, then starting really implementing the tool on the other end, if time is tied, it requires sort of a approach where, where, where customers try to do as much as possible in parallel. I think that requires requires some, some experience requires also what from our expect really helps our, our first of all, best practices and, and very lean approaches.

So what we see, and I think that sort OFS where, where, where customers should be alerted is that let's say, for example, world definition, there's a range at least of the factor, 10 or 15 or 20 or more between lean and that's lean approaches. So a lot of things could be done much, much leaner than they are sometimes. And if you combine this ride, you should end up with a, an approach that works. If they're market, would you like to add something?

Well, yes. Yeah, just taking it from the role example that you just draw out what we, again, if you think back for a second in my slides where we were summarizing, that roles are good for provisioning, but there are activities in our model. And by the way, we are not alone, which are good for sod.

Well, the two things that's completely different times of adoption to do a complet and good and welled model takes a significant amount of time. And is one of the challenges that customer are, are trying to, and, and we, as a vendor are trying to simplify through role mining solution and best practices of our consulting partners while the business activity model is something that is much faster, not just because it comes with pretty fine template, but also because, because it's providing just a control.

So an overlook on the distance between the expected state and the actual state, but just dropping a very simple example. If we design an activity model, which doesn't make any sense, we are basically aligning in appropriate violation. Okay. We are now removing access or delivering access to user. We are providing control with this way. What I mean is that from a critical degree standpoint is not as critical at the point in time, as we are typically. I don't know if this answered your question of, of maybe I MIS completely missed what you, yeah. I think That that fits fits well. Okay.

So again, if there are any other questions from the audience, please enter them now. So we are reaching the end of the, the webinar. So it's time to enter the question finally, so that we keep counting them up during that session. Okay.

The, the, the last question I have currently here is, is one which I also observed pretty frequently. So roles are term, which is used in, in many systems. So you find roles, many systems, but they are used, this term is used in many different ways. And sometimes the cause are sort of a BA situations with a lot of people talking in different languages, not understanding each other. So how to address this Marco. Oh yeah.

That's, that's a there's well, there's no answer for that. That's just a matter of life.

I mean, role is a pretty used world in appropriately used in many circumstances. And in general, at least for the purpose of our conversation, as we discussed earlier, we should probably at least try to use name like enterprise role, meaning per roles when men to be addressing multiple application. Okay. So permission for multiple applications, that's a definition of enterprise role. Enterprise role might be far refining business business role.

If they're meant to be all job title role, given what is the part of their design for while SAP and SAP is not alone calls, roles, the permission it exposed for consumption enterprise level, that's where the AMD comes from. So we, we, we do our best to keep it separat in terms of wording, talking of SAP war, enterprise world, but unfortunately, well, the world role Flos and popups all over the place. And so to be clear, it's not so easy sometimes.

Yes, I think it's something which is always an issue in projects. So from our experience, things have helped, are clear guidelines on how to do identity access management, identity, access governance, which also define the, the terms and which define where does this map and what does, what maps to which system specific term. And I think the other point, which is very important is then to really define some that's part of it.

In fact, defining some, some terms for the levels of roles you're using in organization using this consistently, consistently in the tools and in other guidelines. So that, that helps that also still end up, you still have end up sometimes with discussion where, but that's not a road or my roles are different, but then it's really about saying, okay, that's where it maps. That's it map this? Let's say maps to that thing. I call from, from a higher level perspective system road, for example. And then usually you are, are pretty well able to deal with this. Despite some discussions you have.

Okay. Any other questions from your audience at that point of time?

If not, then I just wanna quickly mention again or, or European identity conference. You definitely shouldn't miss this event, have a look at the agenda. Then I also just remind you. So if you want to qualify for a CPE point, then you have to pass the test and you will receive an email, which includes the information. So these are the, I think the most important points from that. So it's up to me to say, say, thank you to all the attendees for participating. This could be called webinar. There will be a lot of other webinars in the next few weeks.

So hope to have you onboard again soon, you will find all the presentations on the, the podcast that our website. So that's it from my side. Thank you to the attendance. Thank you to, to you, Marco. Thank you. Goodbye.