Transcript
in the Identity Manager. BDG was just created to get actions in the Identity Manager influenced by user behavior or by a data situation on the outer side, which is typically not taken in consideration by the Identity Manager natively. And what I'm talking about is, for example, the usage of applications. Are user accessing applications they have assigned to or not? I'm talking about access rights which are not used. For example, there is somebody, an admin, but this admin is not doing admin tasks, so maybe he don't need to be an admin. I can also talk about, for example, the complete removal of entitlements in a system which are used by no one. Remember, please, to create entitlements is pretty easy in each target system, but to get rid of is sometimes a very big and complex process. But if there is an automatism that just say, hey, these entitlements are not used for the last half a year, I can just start to remove something like that. However, Behavior-Driven Governance, it's a cool thing. And in the Identity Manager 10, it was improved again. We had, of course, Behavior-Driven Governance just implemented on the account level, and we now extended it to the application level. Let's go a little bit into detail, but before I start to do that, there is one thing left I forgot on the first slide. And this is, of course, that Behavior-Driven Governance currently is available together with target systems Entra.ID and SAP. What is the reason behind that? The reason behind is that this type of how often is something used information needs to come from another system, for example, from Entra.ID and from SAP. Other target systems, like, for example, a local active directory or an LDAP, are not just delivering these informations. Because of that, we can't just use such applications currently in BDG. So we have currently Entra.ID in there and SAP. And now let's talk about the technical details. Application level usage insights. At the end, in difference to just reporting in IAM, if you have access to use an application or not, it is now the question, what is the user doing? That means how often the user will have at the end access to that very specific application. Governance based on user patterns means that at the end, you can figure out how often such a user is using an application or not. And depending on that, you can then add, for example, automatically deprovisioning processes or reporting processes, bring that to the mind of someone. Of course, with all the data that gets imported in the Identity Manager, a policy automation could as well work. You can, for example, create governance policies and can dynamically figure out if there are problems or not based on an outer expiry or of entitlements or inactivity. With that, you have a complete new world of compliance rules available. And if the assignment of entitlements or access to applications is getting more dynamic, then, of course, you have also improved your compliance of least privilege. That means in your next compliance audit, it is much easier to pass, especially because you have now the typical last privilege management, what all people are looking for. What was on the roadmap for the Entra ID world in case of BDG? First, to read the data from the Entra ID, of course. Then at the end, we want to use and analyze this data to react on the application usage. We need some company policies for checking. One hand side, regular usage of application access. Other hand side, the usage of restricted and slim configured applications. And we want to ensure that a risk-free interactive sign-in could happen. In the Identity Manager 10, there is a new attestation policy. You can see the name, unused Entra ID application authorization attestation. This is then just generating attestation cases for unused applications in Entra ID. To store the data, there's a new table necessary. That is then the AAD app role assignments table. And the whole process, this means the data in the table where the attestation cases are based on supports then in the attestation as well out of removal if configured. That means on a denial of an attestation case, you will just remove from that application usage. And last but not least, there is then, of course, in the attestation for that specific application, as well a recommendation. That's the first yellow question mark in the right hand picture. That shows that this application is nearly unused. And so you can then decide if it should be removed or not. With that, we have a new company policies available that on the one hand side detects unused Entra ID applications. And we can ensure that users who do have now the applications left assigned will as well use this specific applications. For that, of course, Entra ID applications must be restricted. It is necessary that each application is just controlled by one group. We ensure that any assigned applications are used by the different users. And it is necessary to ensure that Entra ID just one group only manage the access to one application or application role. However, with all of that, we should have Entra ID user accounts, which should work really risk free. On the report side exists first a report that shows the application usage by user. On the one hand side in an overview graph, as you can see on the right hand side and down below then in detail. And secondly, there is a report that shows the recent sign ins for a specific tenant. And as you see it as well in the animation, it is possible to drill down in that report down to the location. It is a street map that shows the location where that specific access you are looking at was just attended from. To clean up the full data, because we are collecting now a lot of usage data and this usage data blows up the database, exists a scheduled process. This scheduled process is then cleaning the last not used data. And it's doing that on the basis of a configuration parameter, which is the first bullet point in target system for Azure Active Directory exists unused application threshold in days. And this is the amount of days where the data keeps alive. And now let's talk about the same for SAP. First of all, what is behind that? In SAP, we are not talking about used applications. We are just talking about SAP transactions. User might have access to specific transactions they don't use. And that could then, of course, be used just to remove permissions. And at the end, maybe remove the access to SAP if not specific transaction are used. But the user just work with these transactions he really needs in different to giving him the access to many transactions he never will need. Therefore, in the identity manager at the end, three months of SAP data should be stored and allow them, of course, attestation in the same way then reporting. What is necessary? That is the transaction users. Of course, we will get all transaction data and will allow the CISO or the specific user who is allowed to do that in an attestation to decide about the transactions or not. And yes, of course, the transactions you need to decide about. That means the attestation case is built on as the transaction the user is not using. With that, of course, we allow a better segregation of duty as well. If you remove as well based on these decisions, for example, transactions and with that SAP permissions, that might have a very positive effect on license costs in SAP as well. What at the end was to build in SAP? Yeah, just to read the data. And then just to react on SAP roles and profiles. And of course, roles and profiles assigned to specific users. And the roles itself are in SAP typically managed in business roles. And so the business roles of SAP roles and profiles are as well part of the story. From a building perspective, we have here two attestation policies. One attestation policy takes care of role assignments. And the other attestation policy takes care on profile assignments to specific users. To get that implemented, the usage data needs to be stored in two tables, one for profiles and one for SAP roles, of course. And the attestation itself on a denial allows in both cases as well auto removal. Last but not least, you can see that on the right hand side, recommendations exists. This time, the second yellow question mark again, where you can get on the attestation a recommendation that, for example, specific SAP profiles was not used for a specific point in time. With that attestation, it should then be able on a company basis to ensure that users are just using their SAP business roles and their SAP profiles they just have assigned. With the help of attestation, of course, then they could get removed if this is necessary. And as you easily can see on the right hand side, there is a nice report that shows you the information exactly about that. We also provide, as you easily can see on the picture again, the complete usage of transactions in the identity manager, which at the end is the basis of the analysis we have seen before. And the cleanup exists as well in BDG for SAP. That means there is for SAP R3 as well unused thresholds in month parameter available. Three is the default, as we have seen before, and a schedule that cleans up all of these transaction data on the basis of this specific parameter. Today, I like to talk about something where marketing says these are the ITDR playbooks. And honestly, if I, as a non-native English speaking person, just hear these type of terms, I think about gameplay or something I like to install on my PlayStation. However, what this is, is much more serious. As we know, identity threat detection is something that happens more and more in the access control world. What is behind that? Simplified said, it is quite easy. If I am signing in in, for example, Germany, Berlin, and I'm starting my work and half an hour later, I do the same in the United States, it is pretty common that there is something really wrong, because I can't just switch from Berlin to the United States just in 30 minutes. And so the system says this type of access is not OK. And because of that, something needs to be done. However, this type of detection, this type of access security could now, and this is the idea of that feature, tied together with the classic identity and access management. And so the developers in the identity manager world decided with version 10 of the identity manager just to connect the identity threat detection together with the identity manager. Now, this is one of these features where we try to bring all of the ideas of access management, identity and access governance and privilege access management together, because here the identity threat detection, something an access management system typically does, does have effect on the identity manager, which is the identity access governance tool. What comes with these responses? First of all, as mentioned, the playbooks here is the reaction of the identity threat detection in the identity manager. They could be defined in a way of that if there is a threat detection available now, the identity manager response and the type of response is, of course, something we deliver out of the box. Or you can, of course, like always in the identity manager, just customize your playbooks. And with that as well, the reaction to do so. First of all, the deactivation or suspension of, of course, identities is easy to do. This is just a flag in the identity manager with a provisioning action, high priority based directly after. And then the accounts are just locked. This is one thing. The second thing, of course, is if you look at the accounts, we can, of course, disable and lock them, which is easy. But then users cannot work, even the users who really needs to work with these things. But we can also enforce that user just to change the password and we can use the complete password change mechanisms behind, which ensure that the user who changes the password is, of course, the user who should change the password. A third thing is, of course, that the identity manager does have a super high sophisticated provisioning engine. And part of this provisioning engine is, of course, to send out messages. And that could be done, of course, per email, for example, to the person itself, to the manager, to the target system owner. So that all gets notified that there is a threat detection just detected and something happened. However, the same synchronization engine, and I now talking about the blue shape on the right lower, can as well handle with additional actions. That means additionally to what target system connectors are just doing, it is possible to fire each type of script. That could be PowerShell script. That could be command shell script. We can also call XE files if we like that. But that means this provisioning engine can just do nearly everything additionally a user like to do. And yes, of course, this is something an identity and access management system should always do. This is now the left lower circle here. We are just able to react with the full power of identity and access governance on these things by just opening tickets, for example, for specific people or by just starting attestation cases and react on these different things. So with that, the identity threat detection becomes not only something which is available in the access world, it becomes something which comes as well available in the identity and access governance and administration world as well. If we then look about the values, then we will see automated responses is one of the things. Absolutely killer. We talked about it. Customizable workflows is something I maybe have not noted enough, but all out of the box stuff could also be adapted. You can define your own playbooks in the same way. Then you can, of course, modify all of these standard processes and build your own logic if you like to. The majority of people will not do that. The majority of the people, if they want to change something, will just adapt these things and add or change things. Yeah, we have improved security and compliance. That's true because threat detection becomes now part of identity and access governance. We have a scalable governance there because now we are reacting on that and we have a seamless integration. This is because directly from an access system, this gets just triggered into the identity and access governance system. And now let's talk, of course, about the technical implementation in the identity manager happened first time in the identity manager 10. Before we start with that, we need to just identify one very important specific thing. The threat detection itself is something that happens typically on the outer side of the identity manager. It is something an access tool is doing. Whatever access tool you use, maybe the access tool is able just to contact a REST API. That means you will just send a specific message to a REST API endpoint. And with that, you will then trigger some action, the playbook in the identity manager. The implementation in the identity manager is made in a way that there are several endpoints available, could be used. And depending on which endpoint is at the end used, a specific type of action happens. Typically, processes or scripts are involved and the endpoint describes how the system should just react. From a technical implementation perspective, you see there are several new tables necessary, all starting with POL at the begin. There are also processes necessary, some of them. And there is, of course, a QER playbook lifetime parameter necessary, which allows to configure how long that type of action should keep alive. First, let's talk about the endpoint that exists on the API server side of the identity manager. All are underneath of the main node ITDR. And then with the endpoint playbooks, you can just get a list of available playbooks and playbook names. They are important then directly for the next endpoint, especially because it is possible that a system just sends in the name of a playbook plus the incident. This is then the ITDR playbook run endpoint. If that is used, the user account plus the playbook gets sent in. And depending on that, that playbook gets played. In difference to the ITDR incident itself, this will also start a playbook run. But you will enter typically an account and a severity. And of course, the system will then depend on that. And this means the identity manager system will then select the configured playbook. The authentication for all of that is via OAuth 2.0. You can see that down below. And from an identity manager perspective, there is a user used, which is a system user API data import. And this user needs the permission group QBM API access. Without that, nothing will happen. Now let's talk about the ITDR playbook actions that are available for identities. Remember, actions can happen on an account basis or for an identity basis. Identity basis are typically a little bit more harsh than the account basis, because if you act on the identity, then all the accounts are typically part of the story. If you act just on the account, then of course, just this account is affected. Let's start on the identity basis. What is possible? It is possible to deactivate the identity permanently or temporarily. That will then have effects on accounts, of course. Then you can mark the identity as security. You can inform the manager or the identity itself about the problem. And you can create an attestation case for that identity, which is then more than information. It is just the hint to an attester, for example, the manager, to attest what should happen. At the end, to technically implement that, exists a couple of events. Events are typically used in the identity manager just to connect processes to them. There are several events available, and you see that the number of events are in conjunction with the number of reactions on the left-hand side. That means for every of these actions exists one particular event. And bound to that event is then a particular process. And you see they are typically named in the same way. There is the POL, then POL playbook run for identity, then the suffix, which identifies at the end here the event. And this is then the process that is getting triggered on a specific event. The same exists as well for a single account. In difference to the identity for an account, there is one reaction type more. And this is, of course, to force the user to change the password for that very specific account. The rest, of course, is exactly more or less the same what we have discussed before. You can deactivate and activate the account, which is then lock the user. And you can, as you easily see it there, permanently, temporarily deactivate that account. You can also inform the identity to the account in the same way than the manager of this identity for the account. And there is one more thing that is not possible for the identity. And this is to inform the target system manager because the account is part of a target system. Target systems could have target systems manager. And with that, you can inform the target system manager as well. Yes, create attestation is also part of the story. Right hand side, exactly the same behavior than before. There is an event available per action on the left hand side. And there is an according process for this event as well available. To send out messages, there are some default email templates created. You see them directly on the upper list. Default email templates exist for informing the manager, the identity itself, and the target system manager, depending what process is getting triggered. And in the configuration parameter section of the identity manager, you find three new parameters to just configure that.
