[MUSIC PLAYING] Hi. My name is Abdullah Ahmad. I'm a senior solutions architect at One Identity. In today's session, we will discuss the behavior-driven governance for SAP systems.
First of all, we want to understand what is behavior-driven governance, or BDG. What information can BDG use for SAP systems? What's the scope of this deep dive session? How BDG can use LastLogin in SAP systems and how BDG is using transaction usage data in SAP systems. And at the end of this session, we will summarize.
So what is behavior-driven governance, or BDG? The unfortunate truth is that today, a significant high percentage of user applications are under-utilized. Many users have unnecessary access to critical business applications containing sensitive information.
Companies often do not correlate unsafe behavior with appropriate access. Criminals are searching for privileged credentials, regardless of whether applications are being used or not. The principle of least privilege says any user should only have the bare minimum privilege necessary for them to perform their function and for the shortest duration necessary.
So let's have a look at differentiation between access management and IGA system. The access management system usually controls the activity of the users. It logs who signed in from where, which device, and how. All those data will be logged in an access management system.
And also, the information, what application the user is using, regardless of devices, of course. This provides insight about behavior of users, but it's not directly correlated to the risk. The IGA system controls and governs access.
It assigns access by role, access request, or birthright. The system also monitors and prevent unauthorized access by policy. For example, in segregation of duty. An IGA system can also revoke access. For example, during mover or leaver processes, but also during the certification processes. The access represents the actual risk in an organization.
The observability gap is that the IGA tools control and monitor access on target systems, like accounts, entitlements, permissions, et cetera. Access management tools controls and monitors access to applications. Authentication indicates usage and activity. The IGA tool that controls the accounts and entitlements does not have visibility of the activity associated with that access, which could inform governance decisions.
And now is the question, why we need to bridge the observability gap? So to improve the security of your system, you have to enforce least privilege and reduce the attack surface by revoking unnecessary access. You should know which access is truly necessary by monitoring the user's behavior.
Do they actually use the applications? So reducing the capital and operational expense, reduce the license cost for unused applications, reduce operational overhead by eliminating unused applications altogether, and encourage best practices by monitoring applications adoption. But it will still exist a blind spot for accounts entitlements, which already have been used as part of an attack.
So now let's go to see which information BDG can use for its ecosystem. What information can be used for BDG? We can use the LastLogin of an account and SAP system. But more interesting is, of course, also using the transaction usage data to see which transactions the users really have executed.
For LastLogin of an SAP account, the SAP applications, they have their own user and entitlement store. They will log the LastLogin of users and those information can be used to see if a user have been logged in or have executed system permissions. For example, if a user has more than one account in an SAP system, maybe that will lead to an additional or different problem, especially in mover and leaver scenarios.
So let's come to the transaction usage data. LastLogin does not help as the SAP account is used. The ST03N provides information about transaction usage data, last execution of a transaction code, how often a transaction code was executed. It is required to understand which transaction code belongs to which ABAP role. All or no ABAP roles of an account in an SAP system can be removed.
Scope of the deep dive. What is available in SAP for BDG? LastLogin and transaction usage data. How is it done? Here begins knowledge sharing.
So in this scenario, BDG is using LastLogin in the SAP system. We will go through these steps. We will understand the foundation. We will request an account for BDG purpose. We will create data.
We will log in with a user in the system and we will see the LastLogin. We will get the LastLogin data from the backend system. We will see those data in Identity Manager. I will discuss the out-of-the-box policies, creating attestation, and performing attestations. We will see the attestation details and what is.
So for the foundation, first of all, we have here an example user. Let's call him Nicholas. Nicholas has an employee record, but you see currently he hasn't any SAP account here. In this step, we will request access for Nicholas in the SAP system.
So please log in on the portal. And he will create new request. You can select or search that account, but you can also go through the categories. And here is the SAP account, which we want to create for him.
So any object before it is released or submitted, it can be also checked proactively to make sure there is no SAP conflict. But the system will also do that automatically. So the user, Nicolas, will now request that access and after approval we will get an account in the SAP system.
So once that account has been provisioned to the backend system, our user, Nicholas, will get an SAP account. We see he has here an account definition. This SAP account belongs to that employee and that account is created in the SAP D01 client 400.
If you're going to the synchronization editor and using the target system browser, we can search for the user Nicolas here in our example, and we will see that the LastLogin for that user is currently empty because there have been no LastLogin since that have been created.
Let's create the data for login. That reason, Nicholas will go to the system and log in with his username and password. Once he has logged into the system, we see Nicholas is in the SAP system.
How can we get these past login data? You see, first of all, in the target system browser, when we browse again, we will see that the user Nicholas has now a LastLogin timestamp here. In the synchronization project for the mapping of SAP users, we will see here a field which is called LastLogin. This field is take over from the back end without any transformation of the data.
And once we have executed the synchronization job, to load the data science class synchronization run, we will see that for the user Nicholas, we will get the LastLogin timestamp. So now we will see these data in Identity Manager.
In Identity Manager, if we will open the record of the user Nicolas, we will see in the field LastLogin the LastLogin of that user have been synchronized from the backend system. We are using the UNS namespace and LastLogon instead of system own individual namespace of the target systems for policies and attestations.
Here is an example for Azure AD, for example, how this data will be recalculated or mapped. But as you can see for the UNS account, we have the LastLogin field. But for the SAP system, we have Ltime. For Unix accounts, we have LastLogin. And for Azure AD, we have different fields here, which we didn't calculate it and convert it to the LastLogin field of the UNS account.
If you are going to the table UNS account, searching again for our user Nicholas, we will see here is the field LastLogon with that timestamp. So which part of the box policies we have there?
So with version 9.1, we are providing configuration parameters and policies. With the version 9.2, we'll then provide also the certifications. So first of all, you see here for the UNS namespace those three config parameters. The first one is indicating a threshold for number of days, how long an account has been not used. And if we will use the policies, [INAUDIBLE] data.
So you see we have out of the box here two policies. One of them is unused user accounts can be disabled and the other one is unused user accounts can be deleted. Those two policies indicates I'm coming from those two parameters.
So important is also to understand that the policies will ignore empty values for the users because we can't distinguish if the value is empty because there was never a login in the backend system or because the target system does not provide the LastLogin information.
To create now attestations for that purpose, we will go to the portal, create a new attestation. We will create new LastLogin attestation for SAP system. We will select the session procedure. We can select a number of approvers to make sure our selected approvers will approve that.
We will have different attestors here. And of course, we can have a calculation shadow and an individual one, or maybe you want to calculate it every week or every month, quarterly, every year, whatever. So of course, we will have also an owner of the campaign and so on. In the last part is, of course, to select the target system. In our case, that's then our SAP system with a certain client and we will create that attestation. That's it.
So once we have created the attestation, we have to perform that station [INAUDIBLE]. So we see from the perspective of the attestors, we will see here attestations which is pending, and the attestors can click there, go to the details, and see the LastLogin information of a certain account in the certain target system. Regarding that information, you can decide to approve or deny the attestation. In case it will deny, that account will be revoked from the backend system and from that user.
So what's different in the attestation details. If we are going here, we will see we have only a very small change to the standard attestations and that is the property number four-- property number four here. That's the display name and that's the value field. That's all we have added to the attestation. And now we will see the details of the LastLogin.
So BDG using transaction usage data in SAP. That's our second use case. We have discussed the LastLogin. Now let's see which data we need to get and to perform attestations regarding the used or not used transaction codes within the above roads.
Here, we we'll follow these steps. Understanding the foundation, then the general settings for statistical data. We will download the transaction usage data. We will import the transaction usage data.
We will see the data in Identity Manager. We will create attestations. We will perform attestation runs. And we will discuss the attestation details and additional thoughts.
So what's the transaction usage data? Transaction usage data is the workload monitor of an SAP ABAP system, and usually that provides a lot of log information, which transaction codes have been used by the user and so on. So we will go through the general settings for that statistical data and we will download the transaction codes or usage from the SAP system. And of course, we will import those data to the Identity Manager.
And how is it done? General settings for statistical data. Statistical data required for the BDG includes information about executed transactions per user. This data is stored on the application servers file system and the standard retention period are two months.
In the context of BDG, it is advantageous to extend this duration. The settings that need to be performed to adjust this area are outlined in the following. So we have to go to the C03 transaction code, go to the collector and performance DB. Then we will jump to the performance database, workload collector database, reorganization, and control and set the values for memory usage profile.
The retention period for monthly aggregates to six or better 12 months, or 18 months. So those data should be then stored in your production system. And of course, we should set the data for both monthly aggregates retention period, that's the fifth column, and then the total monthly aggregate retention period, which is then the last, or the eighth column.
So now we will see how it works. We're calling now the transaction code. ST03. And you will see that workload monitor. From here, we'll go to the collector and performance DB. Then we will select performance DB.
We'll go to the workload collective database. And here, we will select a reorganization and then click into the control. So searching for the area WJ, memory usage profile. And here, as we mentioned, and the column number, fifth and eighth, we have to change data. In our example here, we have in the system already configured 12 months.
Now we will change it to 18 months. And the last column has also to be changed to 18 months. So from now, we will store usage data for the last 18 months in the system. But depending on your hardware and resources, and how many data you have used, you have then to check which retention period is necessary for your purpose.
So here, let's see a few screenshots of those details which you have seen already now. And remember, you have to go to the memory usage profile and set the data for monthly aggregation here. Monthly aggregation.
So once we have set the settings and we have usage data in the production system, we have to download these results. So how can we download this transaction usage data from an SAP system? So in order to download transaction usage data, the user must have the object S_TOOLS_X, authorization object assigned.
Otherwise, user information is either encrypted or accumulated. Depends on their securities. Note that this data should always be downloaded from the production system.
So these are the steps or the details we should perform using the transaction SE37 and start the function module SWNC_GET_WORKLOAD_STATISTIC. And then we have to specify input parameters as follows. So for the SELECT_SYSTEM, we will leave it empty.
For the SYSTEMID, we will put here our system ID. The INSTANCE, we can select a certain instance or put in total. In that case, we will download the data aggregated for all application servers, which is coming.
We have to set the PERIODTYPE. So we will load the data or download them monthly. And we have to perform a PERIODSTRT. So in that case, we will specify the first day of every month to download data from the backend system. And for SUMMARY_ONLY, leave it empty.
Now we will go to the transaction code, SE37, as I mentioned. We have that function model, SWNC_GET_WORKLOAD_STATISTIC. We will execute it.
And here we have to add data for SYSTEMID. In our case, it is system ISD. The instances, we can select one or put the total for all the instances. We will load data for the August 2023 and run.
You see we will get here a long list of different tables and we are interested in the table memory. Go there to the object and display list. So as you can see, we have here not only the transaction codes with the execution numbers, we have also the executed reports. So we will go to the system list, save as local file, unconverted, and put here a file name to download.
So in our example, we are using a certain pattern to recognize them again, the SYSTEMID, year, and month and save it. Once we have generated, we will have those data. So we can also now perform the same activity for another month. In that example, we will download for the month of June 2023, exactly the same steps, and we will download for that one.
So for this session we have not yet connected this function module with a synchronization editor, but it's a idea maybe you can connect that and load the data through the synchronization editor directly from the backend system. So that's the content of the file, and you see we have here a lot of data.
Here's, again, a few screenshots of that example. We have executed that function module, the SWNC_GET_WORKLOAD_STATISTIC. We have filled these input parameters. And here on the right side, you will see after the execution, you have to select the table memory, go to the object, display entire list and then, of course, go to the system list, save local file, and save the data in unconverted format.
So you can see here again we have multiple tables and we are interested only in memory. And we have 122 entries in that example. So once we have downloaded or we have executed that function module, we will see the details.
Here's the number of executions, the client, the account, and, of course, the entry ID, which is containing the transaction code. And the last character on that line indicates if it's a T code, or transaction code, transaction, or it's a repo. Currently, we are interested only and transaction.
So local file through the system, list save local file unconverted, and save it. So now let's import these transaction usage data into the Identity Manager for that reason. We have on the right side our text or CSV file, which contains the usage data. On the left side, we have a custom table which contains the SAP transaction code usage for SAP user data.
So you see here, of course, different parameters or columns from the table, but we have also foreign keys. For example, for UID, SAP [INAUDIBLE], or subsystem, or subtransaction, or also for SAP users. Once we have loaded those data in that custom table, we will see the foreign keys, which have been calculated, and we found all those users. And of course, you have also the counter here, the month period here. All those information have been now extracted from the input file.
So the data in Identity Manager. Here is the second table, which contains the above roles and transaction codes of the SAP user. So you see here an SAP rule, transaction code, and the SAP user. And, of course, how we have calculated the content of that table.
Now here you see the account name. For example, that's the [INAUDIBLE] number of executed counter, 303, and the transaction code-- transaction display. So we have created a custom script. And that custom script calls or executes a predefined SQL statement.
And here, we will get exactly the executions of transaction codes for users, and add additional the ABAP roles, which contains that transaction code. And we will bring this information to that custom table. And regarding that custom table, which we have already seen, we will then use them for the certification rules.
So here is the example of that predefined SQL, which gets all these transaction codes and SAP users. That's the predefined SQL. And in that last step, we have exactly executed that transaction-- and that SQL, or predefined SQL.
Yeah, maybe you will do an exercise and create these predefined SQLs and scripts. And yeah, just give it a try and find out how it's working. So here's the detail and screenshot of that predefined SQL. So you're welcome to use that and find out those information.
Then we have a second predefined SQL, which gets certain SAP transaction codes from certain SAP roles. And here we are using the predefined standard function definitions with those two parameters and getting the necessary information. So then we have, of course, additional scripts here. Make sure that the data, if it's loaded again, we will delete the entry from the table. And the next one is just inserting data into the table.
Of course, depending on your programming style, maybe you will do that on your own way and a better way. But for our purpose, for example, it should just visualize how we calculated those data and how we have added those information to that. So once we have now execution data, transaction usage data from the backend system, we have calculated a custom table which contains now every user, or SAP user, SAP user with his assigned ABAP roles and the transaction codes, which is part of the ABAP roles. And of course, the number of executions.
So now we will create attestations. So on the portal, we will log in as user Hans. He is the owner of the attestation campaigns.
He is going to the attestations, attestation runs, and filtering the currently pending attestation cases, which means the running campaigns. And he has here created two different campaigns. One is SAP user to SAP role without usage and SAP user to SAP role which contains the transaction users.
So you can go here to the campaign. You can see the details-- attestation details, how many attestations are currently pending, how many have been executed. And of course, here, you can see the list of attestors, how many pending attestations, or attestation cases are pending by users. You can go to the attestation cases, which is already there, and you can download a report from the perspective of an attestation campaign owner.
And the same, of course, for the user account with-- to the SAP role without usage. Same thing here again. We have here certain attestors who can download the report.
Once we have created those attestations, in this example of the next few examples, we have created those custom attestations, as we have added here additional data. But we have used the standard template and just copied them to the custom name space. So the one is the SAP user to SAP role with usage.
And of course, we have given the attestation policy with selected approvers and with automatic removal of assignments. We have attestors who decline the attestation that will become deleted or revoked.
So then our next attestation campaign is the SAP user to SAP role without user. Again, the same approval policy with select approvers and automatically removal of assignments in case it has been denied. So you have created attestations for those [INAUDIBLE] attestation cases. In that example, we have different users here and we have different ABAP roles, which we have created for this purpose.
Here is the attestation case from the Manager View, manager as tool. And here's the workflow. Here's the approver step. And it have been declined, it will go to the automatically removal of that assignment.
So let's perform an attestation. So we are now logged in with the user Petria, who is an attestor. And he is seeing 17 pending attestations. You see everything here, but you can also go to the filter and concentrate on one campaign. For example, the SAP users without usage or SAP users with usage, which means we have two different campaigns running.
And he sees, for example, the SAP user account [INAUDIBLE] be assigned to the SAP role ZZ_BDG_ROLE. So you can see here by clicking details, all the account information, role information, but also which transaction codes are part of that role, and which transaction codes have been used by that user.
And we see also the workflow which users are [INAUDIBLE]. You can go to the details and see which information additionally, or in the details their account information, role information. So if he is approving that assignment, everything is fine. And look at the reason. And of course, you can then approve it.
So let's change the attestation runs. Go to the attestations without usage. And in that example, we will select one user, for example, John Wrigley. We will search for John. And you will see there are three pending attestations for John which contains the above roles 002, 003, and 004. And for all those roles, he has not executed those transactions in the past 12 months.
So now the decision is, of course, very easy for the attestors to make sure OK, if he has not yet executed that in the past 12 months, then it can be revoked. In that example, we can see that a role can also contain a long listed transaction codes. In the first example, it was a short list of two or three transaction codes. In that here, we have 10 transaction codes. And it can be also 20, 30.
And he sees OK, the transaction codes have not been executed. Let's select this role. That's the first-- let's go to the SAP system, have a look there which roles have been assigned to the user, role numbers 002, 003, and 004.
Let's get out here, change the perspective, and we have here selected the role number 004, and we will deny that attestation. We'll see OK, and which out of the box reasons we have there for our decision, but we can also add there additional comments, or a reason for our decision. Let's say not used in the last 12 months.
So as soon as we will save that. So we will deny that attestation for the rule number 004. The system will immediately calculate and say, OK, there is an autoremove of assignments regarding that attestation case decision, and it will immediately revoke that assignment from the backend system. So we see now certain processes are starting and the user will lose the assignment to that ABAP role. And that, because we know he has not yet used any transaction code of that ABAP role in the past 12 months.
So if you are going now to the user again, display John, you see the timestamps have been changed. And here we see the role number four have been revoked from the user. Usually, you have in production systems a lot of accounts with a lot of assignments that did that BDG with the using of the transaction codes. We do that. We can then shrink the access only to those roles, which is really necessary in helping boost.
So from the end user perspective, now we have logged in as the user John. And let's go step back. He is going to the Request, Request History, and he is selecting his role number 004. And he sees the current status as unsubscribed.
And if he is going now to the details, he will see in the workflow why he has been unsubscribed from that already assigned to, which was already assigned to 14. And now you can see the user, Petria has rejected the attestation for John for the role number 004.
So here again, we have a few screenshots. Here is our attestation, performing attestations. Let's see the details. That's the user account, SAP role, transaction codes containing in that role, and which transaction codes are often the user has executed in the past, let's say, 12 months or three months. It depends on your requirements.
So here's another example. The above role contains a lot of transaction codes, but none of them have been executed by that user in the past 12 months. So the attestors can easily deny that attestation.
So the example here, we have a long listed transaction codes. Here we have a short listed transaction codes, another role. And, again, here you have no executions in the past 12 months.
Denying an attestation. I think here a reason for the decision and decline. We will immediately see the revocation process and that the user will lose his access to that SAP ABAP role.
The end user can also go to the portal and see through the request history and see the unsubscribe assignments that have been subscribed, and these information will give them, then, the details of the attestors have rejected that attestation.
So let's go to the attestation details. What we have here? We have created two attestations, customer attestations. We see here customer file. One is the SAP user to the SAP role with usage and the next one is without usage.
You're using the table SAP user and SAP role. The different standard attestation is the property number one and two and the display name for that property number one and two. You see we are calling two scripts. One of them is get transaction codes of SAP role and the second is get transaction users for SAP user. So those two information, and now we will go to those scripts and have a look here.
So the first script, which contains get transaction codes of SAP role. You see here we are using a predefined script again here, which we are calling get transaction of SAP role. And that predefined SQL contains just a SELECT statement. And from that predefined function. So we have a parameter that's the ID of the SAP role and we are getting the listed transaction codes from that role.
In our next script is going there and using again. It's using, again, those details of good transaction codes of an SAP role. We have already the information seen before. And then we can go there and see one by one if we will get the list of the transaction codes which have been used by the user, or if it is empty and we will just put here in string to say, OK, it has been not executed in the past 12 months.
You see it has here, in our example, hard coded. But of course, that can be a config parameter like 90 days, or 365 days, or months, whatever. And of course, here, we have a predefined scale again, which is giving us the number of executions regarding that username, keycode, and [INAUDIBLE].
So now we have seen all those details in how you can build your own BDG for the usage data. And which additional thoughts we can have here? So let's go here.
Let's go back to that certain step where we have downloaded the transaction usage data. You remember, we have used that function module SWNC_GET_WORKLOAD_STATISTIC, that one, and we know how to download those details. On the left side, we see a lot of tables which contains a lot of data.
But the only table we are interested is that memory table. And within that memory table, we are interested only in objects of type transaction, not report. At least not in our purpose currently.
So we have those. Data we download them and the text file. We remember.
So why we should not get only the transaction codes, which is interest for us? Here is an example, which we have created without any warranty. So just as an example to give an idea.
We have a function module, which is giving us the [INAUDIBLE] the username, the T code, the period start, and a counter. That's it. All those informations which we need in Identity Manager is exactly here.
And from here, we can then get which months, which year, which date, whatever. All those information, you can get them, and allocate them, and calculate additional steps. And what we did is copying that standard function to the custom namespace, deleting everything which is not needed, and that's that what's already there.
The rest we have deleted. You will see now in the few screens the whole content of that module, a function module-- a custom function module. Again, there's no guarantee, just giving an idea coming exactly to that flat list of objects, which is necessary for us.
So that's the first picture. The code is going further here. Now we are only interested in that memory table, not the rest. We are putting here instance period type and period string.
So what we added here additional is at the end of that call function at destination, and here select system, which means you can use also an RFC function definition, or RFC definition to-- RFC destination, sorry, to remove data from a remote system. So by adding the RFC definition there, that's an additional thought what we did here in standard code.
And that's the end of that function module. You see, we are looking only for the objects of type transaction code, and only those objects will be then added to the table decode usage data. So how can we use and execute that function model exactly in the same way as we have executed that with that standard function module?
Put here the data. And then you will see as a result, only one table. And our table, in our case, let's now take our usage data we are calling it, and we have only eight entries. Before, it had been 122. In a real production system, we will have here millions of lines of entry in codes. But we are interested only in the T code users and the result will be there.
Here, something like that. Again, that's example code without no guarantee. It's just giving ideas to make things simpler and for our purpose, it should be good enough.
So let's summarize what we have discussed. So our first question was what information can be used for behavior-driven governance, BDG for SAP for LastLogin of an account, or application logs/events. For the LastLogin, BDG have used LastLogin in the SAP system. We have seen that. We have discussed and we have seen also the certification.
For the application logs, BDG is using the transaction usage data, ST03N. That's the transaction code, and SAP system, too, get the execution of the transaction codes and use them for finding out which roles have been really used or not used to make sure the users have only those roles assigned, which they're really ever be using for their business purposes. So with that, we are at the end of this session. I thank you very much for your attention. Bye.
[MUSIC PLAYING]