Behavior Driven Governance

Good afternoon. Welcome to the deep dive session on Behavior Driven Governance. I'm Stephan Hausmann from the Presets team. Hello, and welcome from me as well. My name is Markus Weib-Ehlers, and I'm a program manager in the One Identity Manager Development team. In this session, we are going to discuss the available integrations for Identity Manager to identify accounts or entitlements that are not used anymore and which may be removed. The session today will be, as we said, about Behavior Driven Governance. And first, we start to explain what we mean by Behavior Driven Governance to give you an idea of what we plan to use it for. And then of course, the most important part is we need to understand what kind of information we can use for Behavior Driven Governance, and especially what we can get into Identity Manager from other ecosystems to use it for that. And we discuss a bit of scope. It's very short to make sure you understand what the plan is. And then we are doing Behavior Driven Governance for a few topics. So we start with using the Last Login. Then we're doing the same with an IdP, or OneLogin in our case. You may have seen that before. And the next one is then about using Safeguard for Behavior Driven Governance. And finally, we summarize that, what you are going to see is a mixture, all the videos and screenshots are a mixture between version 9 or 9.1 and 9.2. So especially the Last Login and Safeguard are with 9.2. So don't look into the current product, just wait for 9.2 to see that what we have out of the box there. And we're starting with what is Behavior Driven Governance? The main focus of Behavior Driven Governance and the motivation is that we talk a lot about least privilege and how to get least privilege. And for all the obvious reasons, it makes sense that users or identities have not all entitlements they may have or might have because well, the most obvious one is the more entitlements you have or the more permissions you have, the more attack factors can be used during an attack, so less permissions is much better. And also, users themselves, when they have too much access, could of course, do things on purpose or by accident. And it's actually not easy to get the least privilege done in a straight way or easy way because in the past, we have been thinking about attestations or recertification for getting to least privilege, but we all know how those things are mostly done. And Behavior Driven Governance will focus on how to get closer to least privilege using the information we have or we can get into Identity Manager for analysis. That's the main topic, I would say. So what are we looking at in the beginning is-- what we have been looking at in the beginning was what do we have with IGA? What do we have with access management? And of course, when we say access management, we talk about OneLogin but you can think of any IdP in that case. It doesn't really matter. So on the access management side, you have all the information as who logs into the system, who uses an application, what kind of authentication methods the user is using. Also, if there's any unusual behavior in terms of where the login is coming from, and so on. So the access management part knows everything about what a user is doing. On the other hand, the IGA, and of course, we are talking about Identity Manager, knows everything about what entitlements and identity has, what accounts identity has. We do all the things for the user lifecycle. And we know, and you may have seen the presentation from Ted yesterday, we actually know what kind of risk is associated with an identity when we just look at it from an identity purpose at it. But there's then a gap. So the gap is, and that's what Behavior Driven Governance is trying to close, is everything that the access management tools knows is unknown to the identity governance tools, and that's exactly that what we are trying to close in the session. So we're having a look what information we can use from access management and other systems to close the gap between what the user has and what the user is using. That's the part we're looking at during this session. And why does it make sense? So first of all, we are able then to clean up accounts and entitlements. So for the least privileged principle, and again, that helps in the tech case to reduce the probability for lateral movement. What it also does is if you have removed entitlements or accounts, this will simplify attestations because what's not there doesn't need to be attested again. But what we also can do, and we are showing that is, we can provide additional information during the attestation. So you know a user hasn't used the entitlement or used the account for a while, it may be worse to share that information with the person who decides if they encounter entitlement can be removed. It's just providing additional information. Then of course, we license costs as an option when we are talking about cloud applications or anything in Azure. So with that, cost may be associated, and that's something we can take care of too. And even the case if you haven't used an application at all, we are able to figure that out in addition. But what we can't do, and I just want to point it out, when you think about an attack and an attacker is already using an account and the entitlements of an account, that's something Behavior Driven Governance is not able to detect because if an account or entitlement is used from the Behavior Driven Governance part, it means the identity, as you will see, we wouldn't be able to identify that this is part of an attack, just to be clear about it. So it's as always with governance, it's a preventive measure. It's not a detective measure in terms of figuring out what's going wrong. And what's the information we are going to use for Behavior Driven Governance? So what we're going to use is the last login of an account. So assume someone is logging into SAP and then there is the last login information in SAP If someone is logging into Azure, that's the last login information in Azure. And this is something, of course, we can also use to understand if an account is used or not. There may be different or there are different levels of usage for that, but that's the first level. The second one is when we have an IdP or we're doing SSO with an application, again, we were talking about OneLogin. But it could be any IDP. Then the logs or the events of the system provide us useful information in terms of usage. So an IDP will be able to say, well, first of all, if the identity has logged into the IDP, second one the IdP is able to tell if the identity has used an application. So it's getting a level lower. And the last one is the usage of application logs or events. And with that, we should be able to detect what has been used within an application. So we are doing that with safeguards, so we're trying to figure out what's happening on the Safeguard side. After this session, there's a session on SAP where Abdullah, can you just wave your hand? Where Abdullah will have a look at SAP trying to figure out-- [INAUDIBLE] figuring out what transaction have been used in SAP and use that. Going a bit into the details, what's useful in terms of this information. So if you're talking about the last login, there's different options we have to look at. So first of all, we may be looking at the last login for a directory like AD or Azure or any LDAP directory where not only one application is attached to it. There's a bunch of applications attached to it. So if we figure out there is this account hasn't been used for a while, that means the account hasn't been used for any of the applications the user supposed to use. Or in the case of Windows or Azure, is probably not even doing any Office work. That's still useful information, but we think that in general it more means something is wrong with the user life cycle process. If someone is not using the active directory or Azure AD, doesn't mean he doesn't use a specific application or a specific system. It means there's something wrong in general. Still useful, but that's not what we are really looking for because it reveals more a Leaver or maybe a forgotten technical account. If you're talking about an application or like SAP or Unix system or something like that, then it means the application or the target system has not been used, and that's a good candidate for Behavior Driven Governance. But again, if you figure out at the same time that for One Identity, and you all know the hyperview we use and how accounts and identities are linked, if a lot of accounts have not used by this person, this also means there's something more wrong in general. It's still good information, but it's not really about removing an account or an application access. It's more about something is wrong in general with the identity. If we talk about the IdP and all the events there, again, we have the last login into the IdP. But if the IdP is used for a lot of application, not only a single one, then the last login of the IdP is again on the same level as the directory. So if you're not logging into your SSO system, it means something is wrong with the identity in general. But what your IdP provides is when an application has been used and also how often an application has been used. This way, we are showing this for OneLogin. And based on that, we are able to remove application access. Dedicated application access, we know that user doesn't use that application anymore so we can remove it. What's important, we need to understand which entitlements belong to the application, otherwise we can't remove the entitlements at the same time. And we can only, because we are looking only at the application level, we can only remove all entitlements or no entitlement. We can't distinguish which entitlements are used while you're using an IdP because we only see the application usage itself, but not what you're doing within the application. The next one is if we look at application logs or events, then the logs allow us to identify which actions have been done in the application. But what's needed, we need to understand what's the correlation between the actions? So what have you clicked or what transaction have you typed in the case of SAP, and the entitlements. So in the example of Safeguard, in Safeguard we can say which account for which assets you have checked out, for example. And there we know to which policy or entitlement the account asset combination belongs, that's part of a group. And then we are able to remove the access for the group for the user, and first identify the user hasn't used the entitlements that belong to that group. For SAP, and Abdullah is going more into details later, so the transaction codes are linked to a function SAP and the transaction codes belong to a profile and the role. And then when we know which transaction have not been used, we are able to figure out if there is a role that can be removed. Abdullah is going to do that in detail, but I think for SAP the more important part is how to get this information from SAP. I think that's the more interesting part here. So scope of the deep dive, what we're doing is we're showing you what's available out of the box for 9.1 and 9.2, and we distinguish for you what's in 9.1 already, what's in 9.1. And what we also do and-- how to do this for custom target systems. So we are going to show or try to share the knowledge how this needs to be done for custom target systems. So if you have your own target system, how this can be done in this case. OK. Behavior Driven Governance using the last log in. And what we're doing is, we're following for all three cases, the same agenda. And Abdullah is also doing the same thing for SAP. So what we're going to do is we are starting with the foundation, and we're doing the request that we need for Behavior Driven Governance. That may sound a bit boring that we do request for the last login so that we can create a last login data, that we do request for the [INAUDIBLE] and maybe boring that we do request for Safeguard. But what we try to do, so we switch in between so you will see 9.2. You will see recommendations. You will see all the different topics you have heard about, so that may be good to see. Then, we show you how we did create the data, then how we did get, in this case, the last login information. And then we go into Identity Manager, how the data looks in Identity Manager. It's important when you want to store your own data in Identity Manager. How to look at the out of the box policies, create attestations, perform the attestations, and then we go into the details of the attestation, what's in the attestation. And this is basically how to get the data from the logs. And if there are some additional things to consider, then we have that in the session. Yeah so the idea is, we want to show you, in addition, not just, hey, this is how it can be done. We can show you how it's done so that you're able to do it for your custom target systems. So that's the main idea behind the detailed agenda here. So the foundation then is, and we try to do everything in videos and you can later on you can just look at the part you want because it's not depending on each other. So the first thing we start with, we're looking into the current state of the user we want to use for the last login. So this is the manager of the user, and the user we're going to use is the Unix user. We look at the hyperview. The hyperview is back in the portal. And you see this guy doesn't have any Unix accounts, so it's only AD and Exchange. So and what we did, and we put of course, it's nothing spectacular. We have an account definition for Unix that's in the shop. And then what we're going to do is we just preparing the data. We're going to request the account for-- No. --the Unix-- This is 9.1 or is it 9.2? That's the question for you. Yeah, 9.1 or 9.2. Too late, OK. It's 9.2. It is. Yeah. It is. So we're searching for the category where I can create new accounts. So that's the account category. Then from there, I'm going to select my Ubuntu system or my Unix system. Add it to the cart, nothing spectacular. Show it's submitted, and done. So now we have requested the access, which is good. And that means at the end of the day, we have now an identity called Unix user having a Unix account. And we have never done anything with that Unix account. We just created the data for the demo. So that means when we start looking into the target system browser and look at the Unix account or Unix user, and when we look at the data then we see there is no data available for the last login. Last login Unix system is also new for 9.2, and we have chosen the Unix system because it's a bit different than the rest of the systems. You're going to see what I mean by that because the last login in the Unix system is a bit more difficult than for like ID or SAP or systems like that. So now of course, now we need to create the data. So we're logging into Unix system. It's not the most spectacular thing. So the Unix user on the top left is logging into the Unix system. And we see I logged in on-- yeah, about one-and-a-half month ago at about 7:00 something. Right, so one thing I wanted to mention, so you are seeing a bit that's a bit older from 9.2, so details may change with the release. Keep that in mind, please. So we are logged in, and what we do then is we need to get the data. Good. So we're doing the target system browser again. And then you see, OK, last login, and it has this nice addition. It's still logged in. Great. So that means the data information is not very easy on the Unix system, especially when we look at the same user a bit later after he logged out. And we see OK, the last login was same time, and there was a session for nearly 20 minutes. So on Unix systems, the last login is a bit dependent when you ask for the last log in and it's also very platform dependent. So that's why we have to do a very special thing here. What we're doing is when we have the stuff in the synchronization editor, you see the last login from the target system and it's mapped to a last login on the Unix value, and I think Markus is showing that to you. I can't read that, Markus. Yeah. Not from here. Yeah, that's why I'm pointing here. There it is. OK. There it is. I guess also, there's also above that-- Another one. --there's another last login. So and that's at the end date we need to fill. So we copy the original value from the target system and then we work on it later. That's what you have to keep in mind for Unix systems. And before we start really synchronizing data, the target system itself that's also new in 9.2, I think. It has to be 9.2. Yeah, it has a time zone information. So when you think about synchronizing a Unix system, please set the time zone for the Unix system. Otherwise, you will get wrong data calculated. Not wrong data into system, but wrong data calculated afterwards. You can change the time zome later and at the last login will be recalculated, but I think it's better to do it upfront [INAUDIBLE] system. So then we login into the system. We synchronize the data. It shows the simulation report here. On this slide, we have just different information. We have the login, we have the date-- the date of the user. You can't read it over there, but this is the-- Yeah, and the interesting thing here is, again, just to repeat this, is here just the last login string, and that's why we have two fields to provide just the last login string and the last login, which contains the date. That will be calculated based on the string. Good. Now, let's look at the data in the Identity Manager. So what's happening now is we see then in the Unix account the copied value or the synchronized value and the calculated value. And the calculated value is that what we are going to see later on in the Unix-- Unix account. Unix account, yes. Thank you, Markus. And why do we have to do it like that? Because first of all, log files-- so the last login is coming from log files on Unix. So log files can be rotated, can be deleted. So it can happen that you synchronize the data and even if the account has been used a few times, it may be empty just because the log files have been rotated away. So and what we do is when we update or when we synchronize the data, we update only the last login string, what Markus just showed, when there's a new value, not an empty value. So we don't overwrite with empty values. We have the dependency on the timezone and also the transformation is pretty complex. So there may be systems we haven't covered that may need a bit of change to the template. But how the calculation is done is simply a template taking care of the different formats and-- Yeah. This is just if you're running the Identity Manager on a mono environment, on a Linux environment or in a Unix environment, the time zones behave a little bit differently. So that's why it is. But basically, for example, if you need to change this because your Linux system behaves differently, then mostly change just the format strings on top to match the data you are getting from your Unix system and you're all done. If you're nice and tell us what you have changed, then maybe we add this in the later version. Good. So now, when we look at the attestation and policies later on, we are, of course, not looking into the individual target systems. We are looking into the UNS namespace, and there we just rely on what the target systems have. So it's like, for the Unix accounts it's the last login. For SAP, it's Ltime. For Azure AD, it's even two different systems because it could be that your user was an interactive or non-interactive login. And at the end, it's all available in the UNS account. May be a bit more complex for Azure, which is on the bottom here. And now, we have all the last logins from all target systems in the same format on UNS side. And then we use default policies and other things for that. Just to show you the data in UNS namespace, we have our Unix user on the Ubuntu target system. And this is having the last login, which is the calculated data. They won't be the same for AD, for SAP, and all the other ones. Just for Unix, it took a bit longer path to get there. That's why we have picked up the Unix one. because I was curious when I created it. We just wanted to show off the new feature of 9.2. Yeah. Right. Want to talk a bit about the policies, Markus? I can try. Yeah. So we have some configuration parameters. They are not new to 9.2, so they're in 9.1 as well. But so under the target system UNS, you have unused user accounts threshold in days. And underneath there is one for days until delete and days until disable. The thing is, the 9.1 unused user account threshold in days, you may wonder there's 90 in the search in the tool. There's currently no usage of the 90 days for the first one. We got the feedback as we had a beta there was just the one. And somebody complained, what, just one day? So this is the 90 days is here to stay in line with the other configuration parameters we show you in the future in a minute for OneLogin for Safeguard. So there we're using 90 days as detection preset. If you want to change these, of course, you can. But these are the ones that are used in the policies. So there is a policy unused user accounts can be disabled and can be deleted. Why are they called can be disabled, can be deleted? Because we do not do anything automatically. You could do that, but currently we refrain from doing that. For example, that's in addition why the thresholds are set very high with 180 and 360 because we do not want it to automatically delete something just because there is an unused user account. Just to keep that in mind. I can see here in the system we use we have over 1,000 policy violations. Yeah, that's the policies we're using. So what the system has does-- anybody give me a hand that hasn't ever used company policies? At least one, yay. OK. So most of you know the company policies. The company policies are a nice thing because they run I think on a daily schedule by default, and they can detect, go over your data, they can detect those anomalies. Not just for unused user accounts, for other things, departments without managers, and some other things as well. So here, they detected that we do have some unused accounts. How we do the attestations, again, a video with 9.2. It starts, OK. The policies were 9.1. They are already there 9.1. It's 9.2. No, but the policies are on 9.1. Yeah. This one, this is 9.2. OK, so we created here, so you do not have to clear that out. You do not have to create a new attestation. You can use an out of the box attestation and then just change the conditions, change the schedules, and so on. We're just doing it here for demonstration purposes to show you how you can create a completely new attestation policy. And I just want to mention, you can change the out of the box. But there's an out of the box one for unused user accounts or the system user attestation. So you can select everything here, framework settings, procedures, and then you can choose the conditions. And here, you will see first, we restricted to a target system type. So in our case, we want to restrict it to our Ubuntu. Correct. And then you can add another one, for example, unused user account. And currently, you can see just by the target system type you would filter down to 35 accounts. And then never use or usage data is not available. You get a bunch of things. So this filter has been added for the case that you don't have any luck in data, null data. So what should we do with that? And there's another one unused for a number of days, you select two days. There's no result up on top here. We select one day, you are finding four accounts that have been identified that haven't been used, and there is our account. Now, we create the attestation policy. So keep in mind actually, you want to attest the other way around. We're just showing you the ones that have been used, but you're probably more interested in the ones that haven't been used. Keep that in mind because here we see the usage data in the attestation. Yeah. So now we have created the attestation cases, and that should be done. OK. Created the attestation cases, now we perform the attestations, and still 9.2. Still 9.2. Still 9.2, dark login button. Easy to detect. So now, we have four pending attestations. And here again, is the data of our Unix Ubuntu user account, correct and up to date. And now, you can see here, the last login information in the attestation case, and can provide a reason for your decision. OK, still in use. OK. And that what you have seen there is all out of the box. There's nothing customized there. They're just showing you the information. Nothing customized so far, right? But what we're going to do now is we're going now into the details if you do your own stuff, how to do it, more like that. So this is how it's done. So the only change here is that there is a property for the attestation case that should be stored in the attestation case, and this is the login information. And so I think this is the only difference for this specific attestation to the normal attestation we have done before. So here we have the last login data in. Additional thoughts, do you have additional thoughts? Yeah. Just mentioning what target system would have another last login for 9.2. So it's Azure, that's new in 9.2. It's Active Directory, that's not new in Safeguard, not new OneLogin, not new. Unix, that's new. SAP is not new. Google Oracle is not new, and also for the Starling Connect, it depends on the Starling connectors if they support last login or not, but the mapping is in the project for Starling Connect available. So those are the systems where you get it out of the box these days. Yeah. And for SAP, we see later in Abdullah's presentation. Yeah, for Active Directory we might have to mention that depends a little bit on your license, I think. You only get the information if you do have an Azure premium license. It's either P1 or P2, so if you don't have Azure premium license, you will not get the last login information. But this is not to [INAUDIBLE]. This is a Microsoft requirement. And you will have to add an additional permission on the Azure side to be able to read it. I don't call Markus before reading the documentation, like someone did. OK. BDG was OneLogin. Do you want to take that one? I can. Yeah. So we're doing the same thing again, just not getting the last login data. It's getting the events from OneLogin. This has been done with 9.1.1, so we notice the difference in the portal immediately. Why did we do it with 9.1.1? Because it's already in 9.1.1. Because it's already in 9.1.1, and I wasn't sure when I get the 9.2 version. I didn't know how much time I really have for the recording. That's why I did it in 9.1.1, and someone was pushing me to create slides. So the foundation, very simple. We log in to the portal, which is the old portal, to show you where we start with. So now we are using-- See, look at the button. I know. It's a different button. So we have now the demo user. It's the same manager. No hyperview at the moment, but we're looking at the memberships. And this guy has only Active Directory Exchange, as we saw before for the other one. He doesn't have any system roles. So it's a default user. But what we have, we have two system roles. One is called Salesforce, and the other one is ServiceNow. We're looking at the Salesforce. And there are three entitlements in. There is the account for Salesforce, in which is done in Sterling Connect. There is the account for OneLogin, and there's the Salesforce role which is for OneLogin which allows you to sync [INAUDIBLE] from OneLogin to Salesforce. That's what we need. And that's the one for ServiceNow. So we're doing Salesforce ServiceNow. We log in into one later on. So and of course, again, we have those system roles on the service item as we requested. It's no big difference, right. So we login as the user requested. This is a user demo. It's a new request. It's the 9.1.1 portal. It looks a bit different. Looking at the categories a different way, and then we get it to the two roads. That's the two roads we're going to request now. Straight forward, nothing specific. It's admitted, we have now a look who is doing the approval. The approval is done because we wanted to show the recommendations in 9.1.1 if you haven't seen it yet. We look at the approval. That's a deny for a specific step for the recommendation, and now the manager has approved that. And if the Manager logs in now, then he's getting the two approvals to do. And he's having then the recommendation visible. Keep in mind, it's not 9.2. It's 9.1.1. And he sees the reason why the algorithm thinks he shouldn't approve that because he's never approved it before. In the peer group no one has a-- because for demo purposes, of course, we approve it. Same for the other one, we approve it again. So if you're on 9.1.1, you could use that already. And that means that now the stages of the identity is having account in Salesforce, having an account on ServiceNow, having an account in OneLogin, because we requested the two system roles we can see over there. If we look into OneLogin, again, he's having the two roles, Salesforce, ServiceNow. And because of that, he is having access to the application Salesforce and ServiceNow. It's called multi-tenant here because we use the template and just called it as a template. It's not a multi-tenant. It's not multi-tenant, right. But they call it-- I don't know why. So and if we look into OneLogin, that's the-- I'm just an administrator looking at it-- there you see he's having access to those two applications. And now, to create a data is very simple. We just have to login to OneLogin. Now, we are going to use only one of the two applications. You see it's a brand new user. It just has skip the starting point because we provisioned everything properly with Identity Manager as already having access to those two applications. We're logging into ServiceNow, but we're not logging into Salesforce. We want to show you later on that we can remove Salesforce, because it has never been used. Yeah. The ServiceNow instance is not the fastest in the world. Hey. Yeah, there we are. OK. And then we just log out. I'll show you that I'm really the user, and then we log out. Now, we have collected the data. We created the starting point. We logged in. Now, we have created the data. And if we look into the events of OneLogin, this is the OneLogin, we can see that one of the events that has an account been created, and another one is that we looked into the service multitenant. That's how I call it. And then, of course, we need to get the events. And that means when we look at the distinct project for OneLogin there is the events part. And in there I just selected one of the events. I see an event type. You see the user and you see the application and you see the time over here. The event type is important because the default project is collecting all events. That means you do not only have the event type 8 but you also have five, six. I got the list of what the events mean, but I forgot. I know 8 is logging in. Yeah, 8 is application usage. You can look up that information and there's this in developer page for OneLogin, a portal where the APIs are available on that stuff. And there, the event types are mentioned. The event types that may be of interest for BDG and other areas in that area are mentioned in the documentation as well. I always forget, but 8 is the one we are using. Yeah. So 8 is going to be one we are going to look at. So if you don't want to get all the events by the project, there's maybe something you want to do, the default project is just looking at a time. So it's time bound in terms of what events we get from OneLogin. But what you may want to do you want to just add the filter so that you collect only the event of 8. So it is documented how it has to look like. So this is a recommendation to do it that way. So just the recommendation, not just to 8, but maybe to just the ones you are interested in because the logs from such an IDP system can be very large and you want to reduce the amount of data just to the ones that are of interest on your end here. So this is the way you go. You can also add with comma separated, you can add more value. So 8, 5, 6, as you mentioned, so this is the option here to go. And this is all in documentation, so it's good to read it if you plan to do it. I, of course, didn't read it and asked Markus and he taught me. It's in the documentation. Thank you, Markus. So the same for the time, the time is in project. It's a fixed value here. I'm not sure how this is generated. It is a fixed value. You set that value at the time you set up the synchronization project. You can, of course, convert this in a variable and then set it whatever value you're needing. So let's say just one year from starting the synchronization back, so it can clear up your event data table. This is the value. But the system is asking you when you set up the synchronization. OK. But we would recommend whatever you need for a certain time, that's what you should put in there. This is just for keeping the data short. You have to remember, OneLogin keeps the data forever. So if your OneLogin system maybe has run for eight years, the data may be very large. So you can limit the interesting data or the amount of data here with that variable. So we have two filters here, event type and the date where we have to look at it. Yeah, because I watched one of my OneLogin colleagues loading the synchronization logs of the tenant he uses for ages. It took a second. Yeah. So the mapping, the mapping is what I find the interesting one because we have a lot of IDs on the OneLogin side. It's not always you can read it in clear text. And you either have to put the effort later when you create attestations or run the policies, or you have to create the effort when you do the synchronization to create it or to create proper keys or references in Identity Manager when you load the data. So for all cases, so for OneLogin and Safeguard, development has decided to do the effort in the synchronization project just to have it easier later with when you look at the data in the system. And for me, as more like an end user to the system, it's also much easier to get the details done instead of looking into non-translated values. Probably something when you do it it makes sense, because then loading is a one time thing, but working with the data is something you do quite often. OK. Then we start the synchronization. It's not very interesting, and then we have the data in Identity Manager. Again, I just picked a random event here, and the screenshots haven't been made with the filter we just showed you before. So we see all the data. So we have here the event date and we have the application we have been using, the ServiceNow. And we see the user we just used for the login. And he again created that. And the date, yeah. That's important. So you see I created that a bit earlier. So the same data, just correlating to the same data we have shown on the OneLogin admin portal page. So out of the box policies-- Yeah, I'll-- You want to do policies again? I can take the policies again if you want to. Oh, out of the box policies, so again, configuration, you see here an unused applications threshold in days. And it's no wonder it's configured to 90 days. If that's not sufficient, you can change that. And those 90 days are really used. Yes. There are some out of the box policies, and one is access to one applications is used regularly. You may wonder why it's formulated in a positive way. I like to explain it so company policy is indifferent to compliance rules we're having in the system. We tried to formulate them in a way that it's good if there are no violations. So if you have access to one login application, you should use it regularly. So that means if you don't use it regularly, it's unused. The policy will throw-- will detect a violation, so just to clear that up. So and then we have another one, unused OneLogin applications can be removed. So this is just we also detect if an application hasn't used at all. So this is again, the use case Stephan mentioned, hey maybe I can save some license cost if something's not used at all, one option. And the other thing is, if something's not used, why am I having the option to use it and I'm proposing a potential risk just because it's there? Again, traversal or lateral movement prevention. OK so access to OneLogin application is used regularly. You can see here that we do have a violating object, Salesforce user demo. And this is the one we haven't used. So remember, we just logged into ServiceNow. We didn't log in to Salesforce, and that's why it came up here. And I unused OneLogin application can be removed. Safeguard for privileged password, so this is a different one. So we haven't used Safeguard for privileged password at all. And that's why it's showing up here. Details of a policy, this is all known, so you just want to show here the condition. What is inside of the condition? And of course, that's why we say, hey event type 8 is enough. It refers to the event type 8, and Stephan told me, hey, we should show that this is how you can access in such a condition the configuration parameter. And you can see here target system one login unused application threshold, and yay, it's used. So this is something new with 9.2. So in 9.1.1, if you look in the implementation details, you will detect the process chain that looks at policy violations. And if the process, if it finds a violation for that specific company policies we have shown before, then it creates an attestation automatically. So this works for 9.1.1, but that's very unflexible. So with 9.2, this is coming new for the company policies, you can assign an attestation policy that is using the same base object. So you cannot assign an attestation policy that is for identities if the company policy is for departments. And then you can opt in if the system should create automatically attestation cases for the assigned attestation policy. So we make it easier to automate things based on policies. So the thing is, the company policies are in Identity Manager are built in a way that can detect hey, this object violates, but there is no additional information or additional data in there. But we want to have the additional information like, hey, when was the last usage? How often have I used the application? And to get that information, we have that information in the attestation case, we create an attestation policy automatically. First things first, if you try this out, please remember to turn on the configuration parameters for the auto removal scope. Stephan has listed here many, many, many-- Presets where I click on everything until it works. Click everything until it works. So even for the application type of attestation here, OneLogin user has used an application, you need to activate the stuff underneath group membership because the application usage is mapped into the UNS account and UNS group tables. So this is the ones underneath you should take a look at. Again, 9.1.1, the attestation policies to create a new one, unused OneLogin application access attestation. So this is the one out of the box you can use. Again, for demonstration purposes, Stephan creates a new one. You [INAUDIBLE] you're typing. Typing is my favorite. So OK, you can choose one of the applications. OneLogin application, access attestation. So this is a new specific approval policy for that type of attestation. To make the case easier here to show, we choose a shorter one. So the other one uses a complex thing. You could then say, hey, I'm still using it and then it goes to the manager and so on that does the auto removal. For demonstration purposes here, we just take one step approval policy. Otherwise, it would be too boring, wouldn't it? OK. So again, here's the options you have to selecting the attestation cases, which object are affected. And so now I see here I have 13, and then I can see here application with a matching name. Now, we have three. I could limit it to specific employees. You can see here it's called employees in 9.1.1, another indicator. So this has changed in 9.2? Yes. It's called identities. And we see the two guys. OK. So now, I do have both applications for the same user. And then you just wanted to show how many options you're having there, right? No, no, I wanted to show that we have unused [INAUDIBLE]. Yeah, but before that. Yeah, of course. So now, unused for days, 90 days. So yeah, OK, it's just the one. We haven't used it all. Yeah. So that also means that you have to be a bit careful when you just freshly provision an application that may also be a reason why it hasn't been used. Yeah. So be a bit careful there. OK. Unused employees. I just generated it now. So for demonstration purposes, to show the difference between both, right, you choose not to use both? Now, perform the attestation. You see the same scheme, and just tell us if it gets boring. Delete, delete, delete. So now, Salesforce and ServiceNow multi-tenant, we're looking at the details. And so you can see here number of logins to the application in total, how many logins in the last 90 days, and the time of the last application usage. That's all in the attestation details. And if you would be looking at the account first, you would also see the last login date. Keep that in mind. And then this is our unused application. OK, no usage data available. Yeah, we don't have any usage data. And you could see, if you're going to remove that one, you only see the entitlement loss. If the auto removal is configured for that approval policy, you can see here, you would lose the system role Stephan has configured, and that would mean you lose the account definition as well and you lose the OneLogin role that gives you access to Salesforce via OneLogin. So it's not just limited to give you or remove the access if you do it via the system for just one specific thing. So he will remove everything. And depending on your setting, he would remove requested access, everything, your direct access, inherited access, whatever you're choosing there. Whatever you configure it in the first place. Yes. If you don't forget that. Why are you showing that? Oh, you want to show how auto remove is working? Yeah. So autoremove-- [INAUDIBLE] I think everybody has seen that. OK, it's done. Just let it run. Also, yeah so there is a script that is called here. That's-- let's do the autoremoval. Because I think now comes the-- no, don't kill it. Don't kill it, Markus, because when we look now at the details that's something I've-- which I find very embarrassing, because when you put in the details you get overwhelmed by information. And I said to Markus, well, that's way too much. We need to have less here. Yeah and you can just configure that. I didn't know that before. So if you want to know how to going through that detail too, how you can configure which values should really appear over there because there's a lot of values in there that aren't really helpful, and from my point of view way too much. So what is showing here is this is the object snapshots we are putting when you're taking an attestation case. Which is the default when you create an attestation. Yeah. This is the default. We're showing the status. He has lost everything, so it's not a really interesting. But you see he still has the OneLogin and he still has ServiceNow, but there's no sensors anymore. It's just showing that the auto removal is working if you haven't seen that before. OK. Hey. Now, you can continue, Markus. Yeah. OK, attestation details again. So how is it implemented? And Stephan already complained about the overwhelming data in the attestation snapshots. And if you look at the attestation, I think we implemented this for 9.0 or for 9.1.1. I can't remember. On the attestation policy, you have the option to define what should be part of the attestation snapshot. So how many objects should be in there? In that case here, it shows just related objects only, and I think that-- do we have a slide with the options? It comes later. No, there's no slide with the options. So and you can, for example, select how to reduce it by display name and so on and so on. We do it later, I think. We do it later? Yeah. We do it later. OK. In the attestation policy itselfm and that's-- we want to highlight, remember it's a deep dive. You can do that as well. So there's no magic we're doing behind. We're just using the normal option to start a script doing the attestation case creation. And there are several scripts here that create the last login, the count of the last logins, and the count of the logins in total. And here on the bottom, you can see these are the related objects that are part of the snapshots Stephan has shown. This is the application itself. We have the user, and this is the identity that the account is attached to. If you look at the script that has been referenced before, if you want to create your own scripts for attestation cases, you need to provide here for which object types they are valid. So in our case, just for showcasing here this one, it can be useful. OLG user has OLG application objects and for UNS account in UNS group objects. And then you can do whatever you want there and provide the value that will be stored in the attestation case. If the configuration options are not enough, you have on the attestation policy, you can override the script that calculates the snapshots. So you can mention here, you can see here the overridable function, ATT get attestation object, and so this is a place to go. And Stephan didn't know. That's why he-- That's why I liked it. He liked it and he wanted to show. This script is actually what allows you to customize what you can show in the details of the attestation. So all the snapshots, that's where you get the details. And even more helpful, if we look into the script you figure out what configurations options you have without touching the script to show the details there. So it's not only the next option we are going to show. It's also what kind of flex have you enabled on the attribute. I didn't fully understand the logic behind it, to be honest. But it helps a lot if you know that script is available, and that's where you can look at it. So it's easy to get attestation objects, in case you didn't know that. Yeah. Reminder just all the things we have seen before for the ServiceNow multi-tenant data, and then we are changing it from 1 to 3 to descriptive properties only. And when you change it to descriptive properties only, you see the list is getting much shorter, really much shorter. And that's more or less the data you really want to see. And then I just selected two fields which I tried to remove individually. And if you look at the scripts, then you can have a look what kind of options you can have enabled or not have enabled to see that there. If you remove those flags, then it's getting even shorter. And keep in mind, you can just touch the script yourself to get the data away, which I find really helpful, at least for demo purposes. It's better to show not too many data and only have valuable data. Yeah, so we have a very generic way of defining what should be part of the attestation of a case in the snapshot. And we have to rely on the flags that are available. So we refrain from implementing for each specific attestation policy a specific way, which attributes should be part of the snapshot. If this is too generic, you can provide, if you like to, for each specific attestation policy a different script. So you have to put it in the same script. Sorry, I may be mistaken there. But you can put some cases in there. For this specific attestation, I'm doing that. For this specific attestation policy, I'm doing that. BDG with Safeguard. OK, so the same theme as before. We're building the foundation, doing the request the privileged access, create the data, and so on and so on and so on. The foundation, so we're using this privileged account. This is the one we want to use. And here you see the group that gives the access to that privileged account. OK, again a service item to request this and the user account, which is already assigned here in our Safeguard system, UserPAM, UPAM. Now, we are going to request the access. And now, it's 9.2 again. So we do a new request. There he is, our Unix user group. I'm going to request this one. Submit and this tells me I can click, right? Hmm? This tells me I can click. You have locked out. Now, again, we can see here I have my identity and I have my user account. Remember here, employees, 9.1.1, 9.2, identities. Yeah. And then here's my user group assigned to that user account. Then, we're creating the data. So we're checking out the password. Or you do a login, right? I do login, yeah, to a Unix of course. That's why we had in the first link project also the data from the [INAUDIBLE] account and the root user and stuff like that. OK. So we're going to Safeguard for privileged sessions. Keep in mind, you're all Safeguard status. So we may not have done this in the perfect way. OK. So how many of you are using Safeguard or doing work with Safeguard? Oh, just a few. OK. So this is how it would look like if you used Safeguard. And maybe Stephan can better explain it than me. We just requested the access to the privilege account. And because I had set up approval, I'm just approving it. I should have updated the license before. You see the mouse is not always going the right direction immediately because I'm not used to it. So now we are proving the access, and then-- The request is going back in again and copying the password. Yeah. We wanted to show every step on the way. Now-- Just copy the password. --did you copy the password? And I believe I'm logging into a Unix system. So all the data you have seen before from the privileged account and root account, that's coming from those cases where I tried it out. Password? OK. Excellent. [INAUDIBLE] them properly. The audit log is now again, using the Pac module. So we're using the standard 9 to the Pac module. So we're using the standard things that we have to-- the user in PAM, there's this user PAM, we have just seen. It's the one who's checking out. So we have first of all the last login for this guy. This is last login for Safeguard, right. We already had that. We already have that. Yeah. You already have that, and the other thing is we're looking-- and Safeguard is doing the same thing as we did for OneLogin. We have the audit log. Then we have the events in there. And there we see the event where we just used password check out and them see there's-- we use it for asset account 14, asset three, it's not really usable. In terms-- it's not really human readable. Sorry, it's usable, of course but human readable. And of course, we're doing the same thing as before. We're taking the data, transforming it into transforming it into readable data or having proper references in the system. So when we have the data in Identity Manager, it's mapped into data we can read and better understand. It seems to be a common scheme and from my point of view, it makes really sense to translate upfront and not later in your policies and attestation cases. The data we see in Identity Manager is then, of course, the last login date for the user, that's one thing. The other thing we see is-- and we aren't using all the information we see, but we see and really there are several events that would indicate that the password has been checked out. I don't know why this one has been chosen. I think was just-- Access request is the generic one. That fits everything. OK, perfect. So we see we checked the password. We see when it happened. You see the translations we did before. You see on what system this happened. You see it's going to the Unix system, that's the user and that's the-- and we also see, and that's important later for removing stuff-- we see which entitlement or which policy has been used for this request. So that helps to translate if we need to understand what can be removed or what can't be removed. And remember, Stephan mentioned that on the first slide. The difference being the logs from the IDP and the logs here from an application, we're looking here at Safeguard as an application log. And I'm not getting just the information I have used an account, but I can tell which entitlement gave me the permission or which entitlement did I have used here. And that's why we have that information here to be able to do some more detailed analysis of hey, I'm not having used a specific asset account or directory account in Safeguard, but I can tell hey, I never used a specific group because I never requested access that the specific group has entitled me to use. So this is really the key to get the additional use cases running here for Safeguard. Because we know we checked out priv account, and by which policy. So policies again. This is [INAUDIBLE]. My out of the box policies, yeah. So we do have a bunch of new policies in 9.2 for that specific use cases. I'm not going to read them all to you. But as we have already told you about, I can say, which assets I used or assets accounts I used. Access options is a little bit specific, so I can tell if a user has the option to access account and he is allowed to get either the password or request an RDP or request an SSH key, whatever the account type is, I can see if a specific combination has been used. Entitlements are used by a group, or what this is an interesting one here for our use case, all PAM user groups are used by users. So if a user has a group, and he never requested an access to everything that-- to anything that is entitled by that group, I can detect that and maybe should remove that access because it's unnecessary and I want to reduce my attack surface. So that's the whole deal here. Well, if we-- can we go back please? If we look, for example, as this one, this opens another field of interesting use cases. That one allows us to understand a group has users and group has entitlements. And this policy will tell you if an entitlement that's assigned to a group and that's assigned to a bunch of users has been used in that context at all. So it can even help you to redefine the groups you have in the system or the roads, whatever you want to call it. The group here is more like a road. So it helps you even to redefine how the roads can be defined within an application. Because we understand what hasn't been used, and I think Abdullah is doing this also a bit deeper than for roads in SAP and transaction codes. This is what you have to keep in mind. You can do much more than just figuring out what users are using, but you can also understand what in context of the internal authorization structure has been used or not used. Oh yeah, another clue. So we're creating all the different policies or attestation policies in one go or three goes, and then do the attestation later on. Again, the reminder, there are out of the box policies for that. Thank you, Markus. You don't have to create them. But I wanted to show them. So we're starting with the PAM user account attestation. It's a bit different compared to the regular user attestation, because here you will also see not only if the user has logged in, but also if he did any kind of checkout or not. That's also part of the PAM user attestation. Yes just showing that the guy is in there. Unused for-- Yeah, two days. That's getting this. And the guy's not in there anymore. OK. We're just selecting the Unix group, I think. Yeah. Be honest, you just want to show that there are many, many wizard options available out of the box. Yeah. A bit overwhelming sometimes. OK. So what's next? So the next, if you continue now, there's I'm logging in again, creating a new attestation. Click. So the next thing you have to click once more. I should have done that in one video. What? I should have done that in one video, not two. Again, that's out of the box policy for that, but I'm typing it. What we're doing now is there's the PAM access attestation. This is where we figure out what has been really used by the user or the entity. The combination. Hmm? The combination. The combination, OK. So again, using conditions, unused by for X days. It's available, but we're just using the group, I think. Same group again, the Unix accounts, and that's it. There we see also a PAM user there amongst them. OK, we have used it. Hey. Yeah. OK. You could see that this user checked out certain privilege account. Now, we come to the next one. Hey, another one? Just click. Click. Just click. Yeah. Another one? That's the last on the slide. The last one? Another one? Yeah. So nobody can tell now that he's not able to create an attestation policy. So at this time, we are doing the user group membership attestation. So PAM user, you will see how it looks like later on. Just for simplifies the use case. That's the only account I can remember. OK. Now, do you show that there is an unused available? I guess so. Oh, user account is unused for X days. Yeah. Oh, the membership is unused for eight days. OK, we have both options. Nice. And now, we're switching back to the third group. Now, you select the group again. I hope so. Specific PAM user group. It can't be so hard. That's our unique user group again. And that's the last session we create for today. OK. Abdullah, are you creating attestation policies? No. Good. Should I show it again? So we accept every question unless the one how do I create an attestation policy. Yeah. And now, we just have a look at the result. Click. So it's perform attestation. And now, you're allowed to click. You're allowed to click, click, click, click. Perform attestation is now, again, because everything is with Stephan or more or less for Stephan, I just have to say, I also want to have those for the chief approval grouping it by attestation policies and then we get the three cases we had. So the first one is the PAM User account attestation. You see now, this is also new with 9.2. If there's policy violations or other true violations, you will see that immediately as part of the list, which is also very nice. Then you see the last usage and the last login. So that's the difference for the general user account. For user account attestation, PAM attestation has the-- Last usage. Last usage in there, and you see it again. And here for the policy violation, you can also get information which policy has been violated. So you look there, and then you can see which policy has been violated, if you want. Same for the [INAUDIBLE] versions. They appear on here. You see also the risk index that appears in the attestation. The next one is the access attestation. The access attestation, again, a few policy violations. But you can see again, which policies have been used, what's the privileged account, what's the user, and what's the usage date. And so what you have to keep in mind here as you look at the data is that the last usage information here is referring to the combination of how you did access that specific account. So which entitlement did you use? Which request policy did you use? And so in the end, you have here the information hey, a specific combination has not been used. It's not the general account has not been used, but this is a specific combination of an account of an access has not been used. And that's the last one we created. I wish I could-- Again, last usage here of the membership. Yeah. So this is now the Unix user group when it has been used last. It has not been used-- Providing all the access. It has not been used by-- this group has not been used by the user to request any access. Can you repeat it? This group has not been used by the user to request any access. OK, great. Thank you. Same here, so that's what you get from for the attestation. So there's a few things in there. You get the policies. That's why there was also a disclaimer, we didn't enable all the policies. Otherwise, we would have seen probably too many violations in the demo data. Yeah. We can skip that now. . So and then if we look at the details of the attestation, it's the same as before. There's again, a script. Another script for the other cases. Then the last look in last usage, but that's all the out of the box one. You can just look into the out of the box policies to see how this is done, have a look at the scripts how this is done, how this is evaluated to give you an idea how you can do that for your own systems. So yeah, so again, the message here is we just use our own things. So you can use the same things we did to provide this for other target systems as you like, or for in general for other attestation cases you may have, these are really helpful, the script things. So that's why we wanted to show you how this is going to be built. There's no black box. We're using the same things that you are able to use for doing your own use cases. Yeah. So additional thoughts? So after we got to build, I got the build, Markus showed me some screenshots. It was the newest [INAUDIBLE]. I didn't want to upgrade and do all the use cases again. So you see now in attestations, if you look at the recommendations, if you looks at recommendations you will also get the usage as part of the recommendations. So this is for user group membership. User group membership, they're a little small here. So in the attestation you can also refer to the recommendation. That's the same thing for the account usage. So you get also the recommendation that's simply saying, well, I wouldn't approve that because it hasn't been used. So this is another level getting down from the details on the data you have seen and the recommendation to get it a bit to the higher level. Recommendation for attestation in general is part of 9.2. 9.1.1 has recommendations for approvals. Approvals, right. And 9.2 has recommendations for attestation cases as well. Correct. And with that, we have been through the content. Just to summarize, we had said, we're looking at what kind of information is available for PDG. So the last login for an account, IDP usage, application logs, events, and we just did it here with the out of the box available things. We did it with the Unix system to show the last log in. We did it with OneLogin for ServiceNow, seeing on how that works. And we did it with Safeguard for using a privileged account to give you an idea how things work. I hope I got clear what we did, hope it was useful for you. Thank you very much and thank you.