Hello everyone.

Welcome to next session of SAP GRC Access Control Training.

In this particular session we are going to discuss about maintaining rule sets.

We are going to see access risk analysis where we can see how to maintain rule sets in SAP GRC
systems.

This is mainly we are going to see the segregation of duties, how we can create segregation of duty

rule sets, and how we can maintain these rule sets.

First, let us have a recap on the rule sets and hierarchy.

This we have already seen just to have a recap, because this session is mainly depending on rule sets

and the hierarchy which we have seen.

The first one you can see the rule set.

Here we have seen global.

Global is a standard SAP delivered rule set which we can use as a reference Technically we can use

the global ruleset as it is for your business.

However, it is not recommended to use as it is because it is not necessary.

You need to comply with all the ruleset delivered by SAP.

Let me repeat it again.

Please use this ruleset global as a reference to explain to the customer how the ruleset can be built.

Then, based on the ruleset, you can copy the risk and functions from the rulesets.

Then you can create your own ruleset.

You can have multiple rule sets means you may have different compliance requirement in different
part

of the world.

In that cases you can have multiple rule sets.

In a typical example, for example, you have a SoX control or let's say you have a global compliance

requirements.

For example, your company is a multinational company where P2P is enforced across the region.

All the companies in different part of the world need to comply with the P2P SoD requirement.

And you may have another SoX requirement which is applicable only to US.

Or you may have some itgc requirement which is required for specific countries.

Then you can have multiple rule sets which can be created in SAP GRC.

That is the interesting part.

Actually.

In GRC, the using multiple rule set in GRC product is quite easy.

So we have rule sets and then we have business process business processes like purchase to pay or
order

to cash.

It can be basis finance HR like this basis have its own rule sets.

What is the SoD conflicts which can create a risk in your businesses.

Similarly, in finance we have separately, we have in HR and purchase to pay and order to cash is kind

of a business process which involves multiple modules, which comprises of all the business
processes,

which is required for the purchase till pay.

Then we have risk.

Risk is two.

Business function will create a risk.

The function is for example here you can see a PO approval and the service acceptance.

So these are two different business functions which create a risk.

It can be more than two, two or more functions can create risk.

Then we have actions and permissions.

Actions and permissions is the technical element of your functions as well as the risk actions means

the specific transactions sections which you are trying to execute in your SAP system.

For example, ME22 is the Action PO approval, which has some permissions which is related to the

actions permissions is the objects which is related to the actions which enable the function can be

performed by a specific user.

Actions and permissions are the actual technical elements which can be executed in your SAP
system,

and this combinations of actions and permissions will create a function.

Here we kept only one transaction for the understanding it can be multiple transactions okay.

Service acceptance can be achieved from multiple transaction ML21.

Or it can also from different let's say service order maintenance or service order change.

Then you can drill down to the specific transaction code or specific action.

That means you will have multiple actions and related permissions which will be combined together,

which will define one function.

That means one business function.

So multiple business function will become a risk.

Multiple risk.

We will combine it together and we will call it as a business process.

Here what we are trying to do is that specific risk belongs to which business process.

So the multiple business processes we will combine it as one rule set.

As we said we can have multiple rule sets right.

You have a compliance requirement SoX as well as ITGC where we will be using PO approval as a

function in different rule sets.

We may also use this in ITGC.

We may also use this in SoX

So in that case, you need to create only one function that can be used in multiple rule sets.

That is also quite interesting in SAP.

You don't need to recreate these functions.

You create the business function once and you can use it multiple rule sets.

And if you see and if you see the business process is only element which will be created in SPRO.

That is the IMG configuration.

All other elements here can be configured using the NWBC.

Let us see the key terminologies which will be used in our rule set development.

First one is business process as we have seen in the previous slide.

Business processes are categories in which you would like to report the risk analysis result in the

risk analysis and remediation.

If you see here, it does not have any technical implication.

We are simply identifying the group of risk belongs to which business process, then we have
function.

Function is a group of one or more related actions and permission in the specific business area
means

functions have actions as well as the permissions.

This actions can be multiple actions and multiple permissions means multiple actions and it related

permissions in that specific business area.

You can create n number of functions which is required for your business.

Then let us see what is the risk.

Risk is an opportunity of physical laws, fraud or let us say productive loss that occurs when an
individual

exploit a specific condition in the organizations.

Basically, the functions which we are discussed are the main components of this risk.

The functions can be two or more functions, which creates the risk.

That is what we have seen in our previous hierarchy.

Then we have actions.

Actions is basically the activity which will be performed in the system to fulfill a specific requirement

or let us say specific business functions, for example, creating a purchase order or creating a material

master record.

Let us say ME21 is a transaction code which is an action.

We can say an action is a transaction code in the SAP terms.

Okay, so let us take only purely SAP.

All the actions are related to one transaction codes.

You can have multiple transaction code to create one function and multiple function will create one

risk.

Then we have permissions.

Permissions are.

Authorization allows the user to perform a particular activity in the system.

In the SAP perspective, the permissions or the authorization objects, which is related to the actions

which will be performed.

Let's say the action is ME21 create purchase order.

Then the authorization objects which is related to ME21 which defines the ME21 activity.

Let us say in ME21 you can do quite a lot of things.

So what can be done in

ME21 will be determined by the permissions given as form of authorization objects that are all
permissions.

So actions and permissions create functions.

Multiple functions will create a risk okay.

This risk are collected together in the business process.

Then we will come to systems.

Systems are referred here as where you will perform the risk analysis.
This can be SAP as well as a Non-SAP systems can be SAP, ERP, SAP CRM as well as other non SAP
systems.

Next let us see configuration setting.

We have seen this topic already.

The access control behavior can be changed based on some configuration.

So we have some parameters which can be defined in the access control to change the behavior of
the

system.

For example here 1021 okay.

Consider Org rules for other application.

Now you may ask what is arc rules.

We've seen sods.

Segregation of duties based on the transactions and the permissions Functions.

As for risk rules, my practical experience I have never implemented Org rules, but I can tell you

how it works.

Org rules basically, if you have a conflict, if you want to define a conflict from one company to

another company, let's say you are a multinational company.

All the companies are defined in the same systems.

You know, the authorization for company codes can be controlled using authorization objects and
their

company codes.

For example, in the matter of fact, all the org organization values can be controlled using
authorization

objects.

So if you want to define segregation of duties within this organization values, for example one
company

code to another company code, you want to define this as a segregation of duties that is possible in

GRC.

That is Org rules.

As I said, I never implemented this.

I don't know any customer who is really using this because this is quite complex and it becomes too

intensive since we can also control this using the authorization object.

So let us take another example.

For example here include expired users.

1028.

In many cases, the customer will request that we need to include the expired user in your SoD
conflict

report.

The reason is quite simple even locked users.

The reason is that let us say you have an expired user or logged user who had an SoD conflict, and

we can validate this user and do some fraud activity in the system, and you can change the user back

to expired users.

Similarly, you can unlock the user and do something and you can lock the user.

As we have seen in our previous sessions, we are running the extraction from the ERP system once in

a day.

Whatever you did on the day time, it is changed before the specific job is running, so you will not

know whether this user is changed or had a conflict during the day time, or let's say before the actual

background job is running.

So this is a little bit complicated.

So the expired users also consider as a risk or let's say locked to user also considered a risk if they

have a SoD conflicts.

So if you include the expired users also we can remove the conflict from the user so that if they have

to do some full business process, they have to include some more users, right?

That's the idea behind that.

Again, this is a big topic.

If you see most of the expired users in a perfect scenario, we need to remove the roles.

Yeah.

In the perfect scenario, once the user has expired, then the roles will be removed from the users.

In some cases, they do not want to do that because they wanted to keep it for some time.

Probably the user did not log into the system for quite some time.

Then you had another process to expire the user.

Then they will come back and log in again.

Then they need to reapply these roles.

For that reason they will keep it for some time.

Then they will remove the roles again.

These are all depending on your company policies here in the GRC perspective.

We can include the expert user in your SoD conflict analysis, or we can also include locked user in the

SoD conflict analysis.

Like this.

We can change the behavior of the system.

Maybe let's go to the system and have a quick look.

We are in our SAP system.

Let's go to our SAP.

Reference IMG governance.

Risk and compliance.

Access control.

Then we go to maintain configuration.

Here we have three configurations which was already defined.

Let's say we want to add something.

We say risk analysis.

Then you select the parameter id.

Then you can see all the parameters which belongs to this particular group.

The parameter group is zero three.

That is risk analysis.

So we have all the parameters.

Now as I said, it is not necessary to remember all the parameters one by one and what it is value.

So whenever you have a requirement you can come back and check what is the parameters.

Do we have any parameters for this?

I can say most of the cases, whenever we want to change any configuration you will find some
parameter

for that.

Okay, as I said, we have expired uses.

For example, if you select here expired uses and the parameter value also already defined here, yes

or no, you want to include or you don't want to include.

Similarly, if you take risk analysis.

Let's say default rule set.

Default rule set is for example, if you have more than one rule set, sometime you know when you
run

a risk analysis, you tend to forget what rule set you are running the risk analysis.

In that case, if you want to define a default rule set, you can define it here.

This also should bring all the default rule sets.

So at the moment we have only global rule set which is by default.

So if you create more rule set then these rule set also will be there.

Then you can define the default rule set like this.

We can define all the behavior of the risk analysis.

We may not go to each and every rule sets because it may take quite some time.

In general if you.

As I said you have some requirement you can come back to this parameter settings and see do we
have

any parameters.

So most of the cases you will find some of parameters for the requirement.

Similarly, we have parameters for mitigation as well as for change log mitigation.

We can see default expiration time for mitigation control assignment.

This also quite important parameter.

For example you create a mitigation control and you assign to one user.

This mitigation control cannot be assigned for this user forever.

We need to review this mitigation control on a periodic basis so we can define an expiration time for

this mitigation controls.

For example 180 days after control.

In 180 days this mitigation control will become expired for this user.

Then the user needs to be analyzed it again.

Then we need to assign the mitigation control because this is quite important.

Once you assign the mitigation control, let us say if you assign it forever, then let us assume based

on our previous slide.

If you are not including mitigated risk in our reporting, for example, in the previous slide, what

we have seen if you see mitigated risk is not included in the report, then you will never know that

we have an SOC conflict which is mitigated.

It is important to review the mitigation controls on a periodic basis.

In that case, we can set an expiration date for the mitigation control.

So once it expired then we need to reconsider this mitigation control.

And if it is valid again we can assign it again.

This should be a standard procedure for this.

Same like that.

We have change log change logs.

We can enable the change log.

In my view we should enable the change log for everything so that we know who changed change
the specific.

For example function or the risk.

Then we can trace back what has been changed, because these are all quite important objects in our

SAP GRC.

So it is always better to enable change logs.

We can enable change logs for function change risk organization, rule change supplement, rule
change,

critical roles, critical profiles, rule set change and role changes.

Maybe we can also have a quick look at it.

Maintain configuration setting new entry.

First one is mitigation.

So we have.

More parameters than what we have seen.

Actually these are all the parameters which is related to mitigation.

Then we have change log.

Now these are all the change log parameters.

And here also we have one more SLG1 log level for air trigger.

And we have an additional parameter also here.

I assume that parameter should have been added in the latest updates in the SAP GRC.

So these parameters are keep increasing.

If you see in SAP, GRC ten these parameters are quite less.

Now the parameter is increased and depending on the requirement they will keep increasing the
parameters.
And you will see more parameters whenever you are doing a support pack upgrade.

So let's go back to our presentation.

Next let us create a rule set for our exercise.

We will be creating our own rule set.

We will name it as rule zero one for this training purpose.

So let us go to NWBC.

We are in our SAP system.

Let's go to NWBC then go to setup.

Here you can see access rule maintenance where we have rule sets.

At the moment you can see this is the global rule set which is delivered by SAP.

Creating a rule set is quite simple because it does not have any technical implication.

You can just create it.

It is simply a kind of a container.

Let's say create.

We will give a rule set ID.

I will say rule zero one.

Let's provide a description.

Rule set.

Rule set for.

GRC.

training

Save it.

Okay, this is quite simple.

As you can see now we have created a rule set means this rule set does not have anything.

So we just simply created the rule set.

Let's go back to our presentation.

Let me close this and go back to the presentation.

Next step is we need to create a function.

So in order to create the risk we need to create the function right.

So we will create two different function.

Function one which we will say create and maintain user.

Basically we are going to use the action SU01 and the permission related to that, we are going to use

only one object for our of the exercise.

I want to make it quite simple so that you can understand this very clearly.

And we will create one more function for create and maintain roles.

The action is PFCG and the permission for that.

Let me repeat it again.

This is not the only authorization object required for SU01 the same way.

This is not the only authorization object required for PFCG for us to understand and make it more
easier

during the process, I am going to create.

This functions with one transaction code and one authorization object in the same screen of NWBC.

We could also create the functions.

So let's go to the NWBC again.

We can see here function.

Let's go to function let's say create.

the function id is F underscore.

FUN underscore zero one.

This is our function id and what business process this belongs to.

This belongs to basis.

We could also provide a description.

Function.

Create and.

Maintain.

User.

So this is the details which we gave.

And here you can also see analysis scope, single system or cross system.

We will say single system.

Now you may think what is cross system analysis?

Cross system analysis.

Let us say you have more than one product.

Let us say we have an ERP system and we have an SCM system.

And you have users in both the systems.

And you know, in the SCM systems, you can also have the supplier related activities in there that

cases you want to combine these two systems and analyze whether they have a conflict.

In that cases we can use cross system conflict so that this will combine both authorization from two

different system.

To do the analysis for our exercise, we will use single system to make it more clear to you.

So single system.

Now as we see in the presentation First we need to add the action.

So if you say here add then it will ask you for the system.

Which system.

Because as we said we can connect different systems to our SAP GRC.

So in our case we have added an SAP ERP system.

So we need to connect the system.

So this is the system.

And we are going to define the action.

Action is SU01

And it brings the description from the connected system.

So whichever we are connecting here and the status is active means you can also inactivate the
specific

action means.

As you can see we can have multiple actions here.

In some cases you want to deactivate some of the actions.

Then we can deactivate it here.

You don't need to simply remove the whole thing.

Then if you go to permission, if you see here, it brings lot of authorization objects already.

If you see these are all the authorization objects which you can see in the SU24.

If you go to the transaction code SU24, in the ERP system, in the back end system and find out the

authorization objects, which is related to this particular action.

And these are all the authorization objects.

As we said, we are going to use only one authorization object, okay.

The authorization object, which we are going to use.

S

Underscore user.

Underscore group.

This one.

Yes.

S Underscore user underscore group I will make it.

This is active.

And this is also active.

Maybe we can recheck with our presentation.

So we are going to see the activity zero one and zero two.

Zero one and 0203 also there.

Zero five also there.

But to make it simple, let's enable only zero one and zero two.

Save it close.

Then let's create the second function that is function zero two.

That is the action PFCG function.

Create and maintain role.

And this is the authorization object here also we are going to use zero one and zero two.

Let's go to function again.

And this is already opened.

So okay.

It's here.

Let's say create f underscore f u n underscore zero two.

And the business process is basis.

Let's give a description.

Function.

Create and.

Maintain roles.

Let me say add.

Then select the system.

The action is PFCG.

This is role maintenance.

We go to the permission.

And let's select s underscore user underscore agr.

Here s underscore user underscore agr.

Let's activate this zero one and zero two and save.

Now we have created two functions.

Then if you go here user defined filter.

Here we say f underscore star.

Then select this.

You can see these are the two functions which we have created.

Let's close this.

Let's go back to our presentation.

Next let us see how to create and maintain risk.

We are going to create a risk which is create user versus role development using the functions which

we have created.

So we have one function for create and maintain user that is user maintenance.

And we have one function F underscore FUN02 which we have created for create and maintain roles.

So we are going to use these two functions to create one risk.

So let us go back to our NWBC the same menu path we can see access risk. u

So here let us say create.

So we are going to create the risk f underscore.

Risk zero one okay.

This is our risk.

And the business process is basis.

And let us give a description here.

Create.

User versus.

Role.

Development.

So this was the description.

vs role development.
Then the risk level.

This is also quite important.

If you see in our presentation we defined as medium.

Here we can define medium high low and critical.

This is again a SPRO setting which we have done in our SPRO.

Or let's say we had the BC sets.

Then we had this predefined from SAP.

These are all the risk levels.

In our case we will leave it as medium.

And here also we can define this particular risk is active or inactive here.

Uh.

Description.

Let's say

Create users versus role development.

Then the control objective.

Okay.

This is again a very good place to document your control objective in GRC

If you see it goes hand in hand with documentation, we can have almost all the documentation
which

is required for your, GRC can be documented within the system itself.

So it is always better you document as much as possible within the system.

Otherwise you create so many risk and so many functions.

So you may little bit, you know, overwhelmed with lot of informations.

So you don't need to go back and find out what was the reason why we created this risk, what was
the

objective, and so on.

So we can document almost everything here.

Here we will say user administration.

Let's say user admin should not create roles.

That is our objective.

And now we need to add the functions here.

So the functions which is going to create the risk will be added here add
So the functions which we are going to use is that f underscore star.

These are all the functions which you will be using these two functions.

If you see it is quite simple to create this then we need to assign this particular risk belongs to

which rule set.

Okay.

This is also quite important right.

So we need to assign it comes under which rule set.

So we have the rule set which we have created.

That is rule zero one.

Okay.

This belongs here.

Okay.

Then we have something called risk owner who will be the owner of this risk.

At the moment we do not do anything here.

We will just leave it like this.

We do not assign any risk owners here.

We will come to this again.

So every risk should have a owner for that.

Who owns this particular risk means any modifications or anything related to this risk will be owned

by this specific person.

Okay.

This we called as risk owner.

You can have one or more owners for the risk okay.

We will come to this again.

So at the moment I will not assign any risk owners here.

I will simply save it okay.

We created the risk.

Let us go back to our presentation.

So whenever you create or modify any rule, we need to generate this rule.

So in order to make this objects active we need to generate these rules similar to your PFCG
generation.
We also need to do a generation of rules.

So this is quite important.

So how do we generate this rule using the nwbc we can go to the same screen.

You can select the risk and we can go to the generate rules.

And we can do it on foreground or background.

If you have quite a lot of rules, let's say if you are uploading the rules then you need to generate

the rules on the background.

Otherwise if it is 1 or 2, we can also do it in the foreground.

Let us see how to generate the rules.

Let us go back to our system.

Let's define the filter f Underscore star.

Okay.

This is the risk which we have created.

F underscore risk zero one.

Select this and go to generate rule.

Then go to foreground.

And okay.

This is the risk which we have selected.

The ris zero one.

Then let us see confirm.

To view the generator rules please click the following link.

That means the generation is completed.

Okay, this is quite fast.

Let us say if you see the actions, you can see the risk one which has functions zero one and function

zero two.

Function zero one has the action zero.

SU01 and function zero two have action PFCG.

If you go back.

If you go to the permission.

These are all the permissions which we have enabled uh s underscore uh user underscore group zero
one
and zero two and s t code is the default uh authorization objects.

That is SU01.

And similarly PFCG and the related authorization objects.

This is how we can generate the rule set.

So it is very important whenever you make any changes or when you create a new rule set, we need
to

generate the rule in order to make it active.

Now let me close this.

So let's go back to our presentation.

Now we have created the rule set and we also created the risk within the rule set.

Now we need to see how this rule set is working.

For that we will have a simple exercise.

We will create a role is Z underscore PFCG and Z underscore SU01.

This is for the user maintenance.

This is for the role maintenance with the objects which we have used.

Then we will create a user.

Then assign these two roles to the user.

So in general this have one function, this have another function together.

It should create a conflict.

That is our test case okay.

So for that first what we need to do is we need to create a role is a PFCG and we need to create a
role

SU01 and we need to assign this to the user.

And if you remember one thing, we have scheduled the synchronization job from the ERP system to
the

GRC system every day night.

In the practical scenario, we need to wait for the job to run in order to get these changes
synchronized

in your in your GRC system.

So what we will do right now, we will be logging into our ERP system and create this user and role.

This is our ERP system.

Let's log in to the system GRAC underscore all.

Let us create the roles first.

Go to PFCG.

Let's create the first role Z

Underscore just SU01 and let us say create single role description.

I will say.

Create user.

We can also add it in the menu.

but I am not going to do that now.

I will simply go to authorization.

Change authorization data.

Not going to use any template.

I will add it manually.

S underscore.

T code.

I will say.

SU01

And we also need to add the authorization object.

So in the authorization object which we have used for this specific function.

SU01 is s underscore user underscore g r p.

Okay.

This is the object.

Let me enable.

..

So here activity.

We set zero one and zero two and user group I will say star.

It can have more than this objects or the more than this transaction code.

I will just simply create it.

Simple rules.

Then the next role is Z.

Underscore PFCG.

Create.
I will give a description.

Role development.

Authorization.

And S Underscore TCode

And I will also add the authorization object.

Underscore user underscore AGR.

Okay.

The transaction code was PFCG.

And the activity here is zero one and zero two.

And role name I will say star.

So I've created both the roles.

What we do now we need to create a user.

That is Z underscore

TST_SOD01

..

Test user one.

Let me.

Generate some password and then go to the roles.

We will assign both the roles Z_PGCG

And Z underscore SU01.

Now if you go to our GRC system and look for this user, this will not be available because this
repository

from EH8 is not synchronized with your GRC system.

Maybe we can have a quick look.

This is our GRC system and NWBC go to access management to check the risk analysis.

We will use this user level.

Let's select the system.

If you go to the user and let's search for this user.

This user is not available because the synchronization job is not yet run.

So we need to wait till the synchronization job completes.

Then only we can do the risk analysis.

So we will continue this particular session after the synchronization job is completed.

So at the moment what I did I executed the background job manually once again.

So in order to continue this training.

So let's check it again.

So I executed the background job.

We can also show you that I copied the background job again and executed successfully.

Now if you see the user should be available.

Let's go to user level analysis.

Go to system.

Let's select our system.

Let's check the user.

This is the user search.

Yeah.

Now you can see this user is available.

How to do the risk analysis.

If you go to Access management Access risk analysis then you can see the user level analysis.

In order to execute the analysis on user level we will use user level analysis.

If you go back to our presentation you can see this is the analysis which we are discussing.

This is our risk analysis screen.

We have two type of results.

We have action level and we also have permission level.

Let's execute the analysis in the GRC system.

Then we should have the risk analysis based on our rule sets which we have created.

Let's go to user level analysis.

So first we need to select the system which we have only one system.

Then we need to specify the user.

This is the user which you would like to analyze.

Let's select the user.

And if you want more selection criteria we can simply add it here.

You can add more users if you want to okay.

Then you can also uh analyze based on the user group, custom user group and the risk level.

Our risk which we have created is medium for the analysis I will say all.

Here we can select the rule set which rule set which we are going to execute.

We also seen that we can also define a default rule set, since we did not assign any default rule set.

It is blank.

So this is the rule set which we are going to see.

And if you want to have additional criteria as I said you can add.

And if you see these are all the different criteria which is available which can be added.

So we will make it quite simple.

So we have action and permission level analysis.

The format which we have here we have summary detail management summary and executive
summary.

We can see that.

And the views we have technical view business view and remediation view.

Okay.

So at the moment we will leave it everything in default I selected action as well as permission level.

Then let's execute in foreground.

You can see we found the risk that is f underscore risk zero one.

The action level risk that is PFCG is conflicting with SU01.

Okay.

These are the two or transaction code available in two different roles.

So at the moment if you see we don't see which is the role this particular transaction code is coming

from here we have the format summary.

If you go to detail now you can see the role and the profile okay.

So the SU01 is coming from this role.

And the PFCG is coming from this role which is assigned to the same user in the remediation process.

You have to remove one of these.

If the user is doing the user administration then we should remove PFCG.

If the user is doing role development then we need to remove the SU01.

This is an action level.

If you go to permission level here you can see all the objects.
These cases we need to remove appropriate permissions which is related for this particular conflict.

And if you see here in the previous session we discussed about mitigation risk right.

The mitigation risk can be created during the risk analysis.

Now we perform the risk analysis.

You can see the mitigation risk tab.

If you select here mitigation risk here we can assign the mitigation control.

And if you want to create an mitigation control from here we can say create control.

It will bring you to the same screen.

This is what we have seen it in our previous session.

Okay.

This is how we can do a risk analysis for the user.

User level risk analysis.

So let's go back to our presentation.

Next one is role level risk analysis.

As we have seen in our method.

First we need to make sure that roles does not have any conflicts in technical scenario.

Let's say these two transaction codes that issue zero one and PFCG is available in single role.

Then it will be a conflict.

The role itself, the single role itself will have a conflict.

So in order to simulate the role risk analysis, what we will do, we will create a composite role,

assign these two roles.

So these particular composite role should have a risk the same risk.

So let's go back to our ERP system again.

Let's go to PFCG.

And I will create role PFCG.

And SU01.

Create a composite role.

Let's say.

SU01.

Okay.

Then I will assign these two roles.

Assign these two roles as you know, again, we need to have the background job running.

Otherwise we will not be able to see the role.

So let's execute the background job in our GRC system.

Let me copy this again.

And copy it.

We can see now it is in schedule.

I will go to change start condition immediately.

So we need to wait till this finishes in the real time scenario.

You will not do this.

You will do it in the next day or once the job is completed.

So in order to continue our training, I simply copying this job and executing it manually.

Now we can see the job is completed.

Let us go to NWBC

Let us go to role simulation.

Let us go to role level risk analysis.

Let us select the system.

And the role type is technical role.

And we need to define the role.

The role is uh.

Is z underscore p f c g, p f c g star.

Let me search.

Okay.

This is the role.

We have one role.

And this is the role which we wanted to check.

And let's select both action and permission level and let's say all and run in foreground.

Now if you see here, you can see the risk found in this particular role, but you can also see some

additional access risk IDs.

That is because we did not select which rule set to be used in the user level.

We selected the rule set to be used.

And you can see here the rule set is not present.
So we just add this.

And here rule set and select only the rule set which we have created and run it in foreground.

Now only have the rule set which we have created here action level and also permission level.

But if you want to see the detailed report then you can see the detail report.

You can see this particular permission is coming from which role and this particular permission is
coming

from which role.

This is how we can run the risk analysis on the role level.

And here also if you do not select anything then it will run for all the rule set.

If you select only the global rule you can also run it here.

And you can select the detail.

Okay.

The global rule set also has the same rules which we have created okay.

The BS13 and BS14.

So let us go back to our presentation.

Now let us discuss about risk simulation.

We have seen that we can simulate the SoD conflicts before you assign any roles okay.

Or we can also simulate the SoD conflict to see which role if you remove the conflict will be
remediated.

So we have a scenario.

We have created a user which has a conflict we wanted to simulate.

Let us say if you remove one of the role whether this conflict will go or not.

For that we have an option role level simulation.

So when you go to the role level simulation, we go to the same process again where we can remove
one

of the role, which is not required.

Let us say if this user is only doing user administration then the PFCG is not required, right?

In that case, we can simulate by removing the role of PFCG and see what is the conflict exist.

So this will become very handy when you are doing a SoD remediation.

Similarly, when you are assigning any role.

We could also simulate by adding a specific role.

So let us go to our system and see how we can simulate the SoD conflict within a user.
Similarly, we can also do the simulation on the role level.

Okay, the same thing works for user level as well as the role level.

So we are in our NWBC.

Let us go to access management.

Go to user level simulation.

If you see in our user level SoD conflict let us say.

So if you see the user level SoD conflict.

This role is conflicting with this role.

In our case is very simple.

This may not be the actual scenario.

Simulation become very handy because you will have many conflicts which you will not be able to
make

a decision.

So you need to go based on the process which we defined like single role composite role.

Then come to user where we could simulate whenever we make a decision whether specific action
will remediate

the particular user.

So right now we have two roles.

Let's assume that this specific user does not need this role.

So we wanted to simulate by removing this role.

Does this user have an SoD conflict or not.

Okay let us close this.

Then we go to user simulation.

Here we will select the system.

This is our system.

The user is.

Z underscore test SoD.

Okay.

The risk level.

We wanted to see it for all.

Then this is the rule set.

We want to simulate for action as well as the permission.

Then go to the next step where we need to define whether we are going to add a role or a remove a
role.

And the removal is quite critical.

Okay.

Here we have role.

Here we will say add.

And this is a technical role.

And this is a system.

The role which we wanted to remove.

Is Z underscore.

PFCG

Okay.

Then action is exclude

We want to exclude this particular rule.

So let us say in the other way around if you want to include this particular rule then you will say

include.

Then we will see what will be the simulation.

So in our case we want to exclude and say exclude.

So once you select your selection criteria say run it in foreground.

Now you can see the analysis the result.

You do not have any conflict okay.

Similarly if you add any rule you can also see if any conflict is getting generated or not.

Okay this is how we can simulate the user level SoD conflict.

Similarly, we could also do the same simulation for row level also.

Let us go back to our presentation.

Next we are going to see configuring audit trail.

We already seen we have parameters which will enable the change log.

So change log we call it audit trail.

It is recommended that we enable audit trail as much as possible.

Because most of the activity if you see here it is very critical.

So let us go to our system and enable the audit trail or the change log.
Then we will make a change in one of our function which we have created.

Then you will be able to see the changes which is done.

So first what we will do.

Let us go to the NWBC, let us go to function and let's open our function.

Let's open the function.

And you can see the change history.

Here you can see the change log.

But it's only in the higher level.

You can see some additional information.

SU01 is added.

You don't have more details.

Actually this is a very high level change history which is available.

Let's go to the system and go to SPRO SAP.

Reference IMG.

Governance.

Risk and compliance.

Access control.

Then maintain configuration setting.

Here I will say new change log.

Let's enable change log for function and the parameter value.

Let's say yes and save.

Save the configuration.

Now we have changed the configuration.

Let's go back to NWBC.

Let's go to the function.

And let's open our function.

And this is the function which we have.

Let's open it.

Let's go to the permission.

And maybe I will go to the same uh.

Let's enable this also.

Let's make zero three also active okay.

And save and close.

Plus we did some changes.

Let's go back to the function.

Open the function.

Go to the change log.

Here you can see what is exactly done okay.

The permission status.

It was inactive.

We changed to active.

What was changed?

Okay.

This was the authorization object zero three was activated.

Okay.

So this is quite important.

So if you see the change log which was done, it's an update from the existing function module.

And if you see this is very detailed level change log.

If I go back and let's say open again and go to permission I will disable this.

Let's make it inactive.

Save it again.

Go to the change log.

Now you can see we have inactivated.

So the change log history.

What you will get from the change log is quite in detail.

This will be very helpful to see when you have changed and who changed this particular object.

This is changed by GRC configuration user.

This is the user.

This is a quite useful option.

My recommendation would be.

Enable the change log for all the critical objects like functions and risk, as well as for the rule

set.
Change logs and so on.

Let's go back to our presentation.

Now let us discuss about SoD rule management.

SAP GRC also gives you an option where you can download the rule sets.

As I said initially we have the standard rule set which is delivered by SAP.

That is a global rule set.

In many cases, you may also need to download this rule set for your analysis.

So we have the standard functionality where you can download the rule set.

Similarly, let us say you have your own rule set which is created.

You do not need to manually go key in like what we have done.

You can also upload the rule set as well as you can also delete a rule set and you can also transport

SoD rule set.

Now this brings you a question whether do we do a download and upload in different system, or do
we

do a transport.

And the other way is should we do it directly in the productive system.

So this is three different ways you can do it.

You can download and upload let's say in the development system.

Then you can upload it in the quality and productive system.

This is one way to do it.

You can also do a transport of SoD rules.

So whenever you make any changes in the SoD rule set, if you want to keep it consistent, then you

can use the option to transport where you can transport the SoD rule set from development to
quality

and production.

And we have one more option we can directly change in the productive system.

Now it brings a question how do we control if you make the changes directly in the productive
system,

because the changing the rule set can have big impact.

For that, we can have approval process using MSMP workflow that we will see in the next exercise.

However, as you can see here, we have download, upload, delete, SoD rules as well as transport

SoD rules.
Options are available.

Let us have a quick look into this because this will become quite handy whenever you are doing
implementation

of any SAP GRC.

Let us go to our system.

Go to Access Risk analysis.

And you can see a SoD rules.

Here you can see download rules.

Here I will select SAP R3 LG.

So that will download all the rule set.

If you select only this then it will download only the rule set which is assigned to the system.

That is only the rule zero one.

We want to download all the rule set.

Then we will select SAP R3 LG where global also included there.

Right.

You can see here we need to download everything separately.

Business process function.

Function.

Business process function.

Action function.

Permission rule set.

Risk.

Risk description.

Risk rule set.

Relationship as well as the risk owners.

We need to specify the file where you wanted to download.

We will create the files first.

Let's say new one text file I will say business process.

Then I will create next one.

Let's say function.

Then create the next one, let's say a function business process.
Then I will create another one.

A function action.

Then the next one will be.

Function permission.

Then.

Then we have rule set.

I will say rule.

Then next one is for the risk.

I will say risk.

Next one is for the risk description.

Risk.

Description.

Description.

Then we have.

Risk rule.

Relationship.

This is the one risk rule relationship.

Let's say a risk rule.

Relation.

Then the last one is risk owner.

Let's select these files here.

Let's go to download.

First one is business process.

Business process.

The second one is the function.

And the third one is function.

Business process.

That is function business process.

Then function action.

Then function permission.

Then we have rule set.

Then we take the risk.

Then we take risk description.

Then risk rule set relationship and risk owners.

So these are all text files here.

So it's quite easy to manage and simply execute it.

Now you can see it says zero bypassed, but it's a green mark.

Anyway, I am not sure why it is saying zero bypass.

Let's have a look into the text files which we have created.

Whether we have any output there, it should not have any problems.

These are all the files which we have created.

Let's open the first file business process.

You can see all the business process.

It's in English as well as in German.

And then the function okay these are all the function, just the function detail.

Then we have function business process function and its related business process and function
action.

All the actions that is the transaction code.

Then function permissions and the function and its related permissions.

And we have rule.

We have two rules.

One is global and one is the rule which we have created and the risk all the risk global, as well as

the, uh, rule which we have created, all the risk and risk description.

This is a risk description and risk rule relation actually which risk is for which rule.

Okay.

That also we did mapped if you remember.

So that also available here you can see here risk which we have created which is related to rule zero

one.

Others are related to global.

Then similarly risk owner.

Risk owner we did not assign in the global.

Also there is no risk owner assigned by default.

That's the reason this is blank.

So like this we can download all the existing rule sets.

And we could also upload the rule sets if you go back.

upload rule sets the same sequence we have here two option whether you want to append or you
want to

overwrite.

Same text file, same format, you make all the changes, then you can upload it.

This is upload rule sets.

Similarly we have delete SoD rule set.

If you want to delete from the system, either it is a physical system or logical system.

We have one physical system, or you want to delete from the logical system.

Or if it is a cross system we can delete it.

So you should be little bit careful.

Also make sure you do the backup before you delete means you download the existing rule sets.

Then you delete it to make sure that we are not doing anything wrong.

If anything goes wrong, then we can upload it from the backup.

So this is to delete the rule set.

And we also have transport rule set.

You can select whether you want to transport the rule set for one physical system like what we have

created or for the entire logical systems.

We also have many other options let's say generate rules.

The generate rules which we have done in the NWBC.

We can also do it from here.

We did generate rule set in the NWBC after we created.

Instead.

You can also do the generation of rule sets from here.

Let's select the risk ID.

Then you can generate it.

Let's say if you are uploading it from SPRO

In that case, instead of doing it from the NWBC, you can also do it here.

This is also quite useful.

Let's go back to our presentation.

Now let us use MSMP to enable workflow function for function maintenance.

So far one.

We are creating the functions.

We do not add any workflow or any workflow approval.

Basically what we are going to do here, we are going to enable approval process for function.

So for that what we need to do is first we need to maintain the configuration in the access control,

maintain configuration settings.

Here we are going to enable that function.

Maintenance requires a approval step.

That is the first configuration which we need to do.

So let us go to our system.

Let us go to SPRO SAP.

Reference IMG governance.

Risk and compliance.

Access control.

Maintain configuration.

Here lets enable Workflow.

Let's go to workflow and the parameter is 1064.

And if you go here we have quite a lot of configuration which is available for workflow.

And the configuration which we need to enable is function maintenance 1064 the parameter value
set

to yes.

Now what happens is whenever you change or whenever you create any workflow, this workflow
need an

approval step.

As we see in the workflow, configuration is done in MSMP.

So we need to use MSMP, the process sap GRC function.

Approver.

We need to enable the workflow for the approval of the function maintenance.

So let's go to our SAP system and go to MSMP Workflow Maintenance.

And we will maintain these steps.

We will maintain the rules and we will also maintain the agents.

The next step we will enable the path.

And we will also enable the stage and we will maintain the route mapping.

So let us go to the system.

Let us go to SPRO.

SAP.

Reference IMG then go to governance risk and compliance.

Access control.

Then go to workflow for access control.

Then maintain MSMP workflow.

As you know this opens the MSMP workflow configuration.

What we could also do we can add the transaction code to call this MSMP configuration directly
here,

because we will be using it quite often.

So we have a transaction code.

We can add it here.

Let us go to favorites insert transaction code.

The transaction code is.

G r f n m w underscore configure underscore w d.

Okay.

This is the transaction code.

We can directly call this transaction code.

This will bring you to this screen.

Now let's log in to the system.

GRACALL then the password.

Now let us configure the MSMP workflow.

The process ID which we are going to use is function approver.

So select this.

Then we will go to the change mode.

Here we do not need to enable the function escalation function or the notification event, because we

are not going to use notification or any other functionality for this exercise.
Let us go to maintain rules.

So maintain rules.

You can see we have initiator a rule which is the function approver initiator.

Then we have notification variable rule function approver.

That is for the notification rule.

Then we have agent rule.

Then we also have agent rule for approver.

This is for creator agent rule and this is for the approver agent rule.

And.

If you want to see the approver you can also select here and say modify.

You can see this is the process ID and this is the agent rule function.

And we will leave everything default here.

And let's go to maintain agent.

The next step then here we have current approval basically GRC API rule set.

It's a GRC API rule.

So we don't really don't need to do anything here.

And also the function approval.

The function approval.

You can see it's a PFCG rule.

The role which we are going to use for the function approval.

This is a standard rule which is delivered by SAP.

You need to make sure that user who is going to be the approver has this specific role.

So we already know what is the PFCG agent type means that whoever has this particular Role can
approve

the specific function.

So we are going to use the function approver.

The PFCG role.

And we also have requester.

Okay.

GRAC requester.

So we need to keep note of this.

And as we know we can also create our own roles.

Then you can modify this to be our own role.

Then let me go to the next step.

Okay.

Next step is variables and templates.

And here we have variables for approver and escalation rejection as well as the variables for work
items.

So we will keep everything as it is default.

Then let us go to maintain path.

Here we need to maintain the path.

So this is the default path based on the the BC sets which we have enabled.

SAP delivered you a default path, so we can also modify this.

So if you see here you do not have agent and approver type and so on.

So this if you see if you modify show details.

So these are all blank.

So we need to specify which agent will be the approver in this stage.

So as we discussed the path can have multiple stages okay.

In our case it's a simple workflow approval.

So we do not need to have multiple approval here.

So in that case we have only one standard stage.

We will use a standard stage.

But this needs to be configured.

So let's select here.

Then you can see the approver agent is this one okay.

The function approver.

This is a PFCG role.

We also know what is the role and the approval type is any approver?

Any one of the approver can approve and escalation type will leave it default.

Because we don't want to do escalation at the moment.

Now I will save this configuration.

Okay.
Now you can see the agent ID is the function approver.

Any one approver.

No routing enabled.

And it is default.

And if you go to modify task you can also see that we have selected the function approver as an
approver

here.

And if you want to modify the behavior when you are doing the approval you can also do it here.

For at the moment we we are saying confirm the approval and confirm the rejection.

If you want to forward you can enable the forwarding allowed.

If you want to notification, then we also can specify whether you want to notify the approver or the

requester.

Okay.

And if you want to have command mandatory and you can also say command mandatory for
approval or rejection

or both okay.

So at the moment we will leave it blank.

So we make it simple to understand how the workflow works.

And then the next step is maintain route mapping.

So here we modify the route mapping is by default we have.

This is the initiator.

And this is the result of this initiator.

And this is the path okay.

Default path we can see here.

This is the path.

Then let's go to the next step the final step generate version I will save this first Let's say create

a new transport request.

MS..

MP.

Changes.

Okay.

We created a new transport request.

If you want to save and simulate, we can also do save and simulate.

The simulation.

We can check if we have any errors.

We have two warnings.

This can be ignored.

And activate.

So we have activated the new versions.

Now what we need to do is we need to create a approval.

So the approval we have configured here is go to approval modify here.

This is the role which we need a SAP underscore GRAC underscore function underscore approver.

So let's create a user.

Let's go to our SAP system.

Go to SU01

Let's create a approver user S underscore.

Function approver.

Say create.

GRAC.

Function approver.

I will give a password.

Then let's go to the role.

Let's assign the basic role SAP underscore GRAC underscore base.

and sap underscore GRAC underscore and NWBC.

So this is a roles which is required.

And let's assign the role which we have assigned as an PFCG approver type SAP GRAC underscore.

Function.

Underscore.

Approver.

So we assigned all three roles.

Maybe I can simply log in with the user once.

Because the first time login you may have to change the password.

Okay, so the user is working fine.

Let me log off from here.

Now what we will do is let's create a function.

Let's go to NWBC.

Then let's go to setup and create a function.

Let's create.

Let's name it as function three F underscore FUN03.

Zero three.

And this is also basis let's say function.

Zero three.

And let's say add a action here I will add SCC4 this for the client maintenance permission I just

leave it like that.

We just wanted to see only the approval workflow how it's working.

Now I created my function I will say submit.

Now you can see here the workflow request submitted successfully.

That means there is a workflow is being generated for this specific request.

Let me close this and let me check here F underscore.

Star.

You can see here that the function zero three is not yet created.

That means the workflow is generated.

The function is not created.

So based on our configuration, the approver, the approver user ID which we have created should
have

a workflow which is generated for this specific purpose.

So what we will do let us log in with that user.

Let us log out.

Let me log in with the user which we have created AC underscore func underscore APP.

Then let me key in the password.

Now we are in the user.

Let's go to the workflow inbox.

As you can see we have an access management.

There is one request.

You can see the rule approver for function request f underscore fun underscore zero three.

If you select this.

You can see the details.

What was the function is about.

And you can also see the permissions.

And you can see here two options whether to approve or reject.

So in our case let us say approve.

The function is now approved.

Now let us go back to the GRAC user.

Let's close this.

We can refresh this.

Then this will disappear.

Okay.

So once you refresh, that will disappear.

So the workflow is now gone from this user.

Okay.

Let's log off.

Let's log in with the GRAC user.

Now lets go to setup and you can go to the function.

Let's see f underscore star.

Then you can see the function three is already available.

Okay.

Now if you make any changes here still you may need an approval step.

So let us go here.

I will change the activity zero two and zero three as the S_TABU_DIS is active and submit.

You can see the workflow request is successfully submitted.

So until unless we approve this request, this will not be active.

If you open it again.

Permissions you can see it is still inactive.

And we will also create one more function.

Create f underscore.
I will say function 4.

This also.

I will say basis.

Here let me add.

SE38.

Okay.

And s developer I will say activate and submit.

Now you have two requests which is created.

Now let's log in to the user.

That is the function approver ac Underscore.

Function.

Approver.

Let's go to the workflow inbox.

Now you can see two functions zero three.

We have edited something.

Let's open this.

And you can see that we have activated these two.

Let's say approve and close.

If you refresh that particular workflow should disappear from here.

Then function zero for the status is decision pending.

Let's open this and we will also approve this function.

Let's refresh.

Close.

Now let's log in with the GRAC user.

Let's go to setup function.

Let's list our function.

F underscore star.

Then you can see function four is visible.

Now select this.

Open.

The permission.
You can see now it is active.

This is how we can enable MSMP workflow for function maintenance.

Let's go back to our presentation.

This we already created function approver.

We have done this step already.

We have created the functions.

Now let us see how we can create risk using workflow similar to functions.

We have an process ID which is GRC risk approver.

We can enable the workflow for risk approver using MSMP.

The similar stage.

However this works a little bit different.

We will go to the next slide.

For risk approver we will create a risk approver.

And we also need to maintain this approver as a risk approver in the access control owner.

Okay.

In the function we did not do that.

And it's a directly a PFCG approver type.

So we simply assign the role.

So whoever the users who has the specific role which was configured in the MSMP will receive the
workflow.

Here when we create the risk.

We need to maintain the rule set, as well as we need to create the risk owner based on the risk
owner.

Then the workflow will be triggered to that specific user.

Then the user can approve that.

That is the difference here.

So let us go to the system and maintain the MSMP workflow.

We run the MSMP workflow.

So we are going to use this risk approver.

Select this and go to change.

And the next stage you can see the maintain rules where we have all the rules.

We have the initiator rule risk approver okay.

And.

We have the agent.

And where we have the current approver as well as the SoD risk approver.

Then go to variables and templates.

We will not do anything here.

Let's go to maintain path.

So we will use the default path as it is.

Please remember it is not necessary to use the default path.

You can delete this path.

You can create your own path.

Since this is delivered by SAP, we are using the default path as it is.

It is not necessary to use the same path as it is.

Then let's go to modify show detail.

Here we need to specify the agent ID.

The agent ID is SoD risk approver and approver type is anyone can approve okay.

Then save the change.

We can also see the task settings.

And we keep the same as it is.

Save it and go to the route mapping.

Route mapping is by default it is defined and this is the initiator role.

And this is the result and this is the path.

Let's go to generate version and save.

I will use the existing.

TR and save and simulate.

We do not have any errors and activate okay.

Once you activate then you should have a new version for this.

Okay.

New version for the risk approval.

Now we will create a user in the back end system.

Go to SU01.

We are in our GRC system.

Let's create a risk approval.

Let's say create.

GRAC risk.

Approver.

I will give an initial password.

Then go to the roles.

Then let's assign the default role first.

SAP GRC base and SAP GRC and NWBC.

And we will assign the role which is required for the risk approver that is the risk owner.

So we have a role sap GRC underscore risk underscore owner.

So this is the role which is required for this activity.

I will save this.

Let me copy this user.

Let's go to NWBC.

Next step is we need to maintain the owner.

Access control owner.

We will say create.

Then specify the user id.

The GRAC risk approver.

Here you can see risk owner.

Let's select this.

Say.

Risk.

Owner.

For.

Training.

Okay.

Save.

Okay.

Now we have configured the workflow.

We also created the risk owner.

Now let's create the risk.

So let's go to setup and go to access risk.

Let's say create.

And let's say f underscore risk zero two give description zero two business processes basis and
description

is.

I will say function three versus function four.

Here we need to add the functions.

That is f underscore star.

So we have three and four.

And the rule set we will add the rule set.

Here We will use the rule set which we have created.

And here we need to specify the risk owner.

If you select here and select this one, you can see the risk owner which is populated from the access

control owners.

Select this.

If you don't define it in the access control owner then this will not be visible.

Okay, now you save it.

Now you can say data has been saved.

There is no workflow created because we missed one configuration that we did not do, the access
control

configuration which enables the risk approval workflow.

That's the reason it is saved.

Okay.

So if I see here.

This risk is already available here.

So what I will do, let me delete this.

Let me let us enable the configuration.

Let us go to SPRO sap.

Reference IMG.

Governance.

Risk and compliance.

Access control.

Maintain configuration.

Setting new entry.

I will say workflow.

And risk maintenance.

That is 63.

I will say yes.

Save it.

Okay.

Now we have enabled workflow for risk maintenance also.

Now let us go back to NWBC access risk.

Let me create the risk again.

Create.

F underscore risk zero two.

Basis.

Function three.

Versus function four.

Let's add the functions.

Three and four.

Rule set and rule set.

We will use the rule set which we have created.

And the risk owner we will assign the risk owner.

Now let me submit.

Now you can see the workflow request is submitted successfully.

And if I go here and look for my.

Risk.

The risk.

Is not it active.

So now let's log in using the risk approver user ID.

AC underscore risk approver.

And the password is.

Since we are logging in first time.

Let's change the password.

Let's go to the work inbox.

Now you can see the rule approver for risk request.

F_

Risk zero two is available here.

Let's select this.

And you can see the details function and the rule set as well as the risk owner.

I will say approve.

Now the SoD risk is approved.

Let's close.

Now log in using the GRAC user.

Please remember the function approver as well as the risk approver.

Also have access to risk as well as the function in the NWBC.

Just for the demo purpose, I am using the same user which was used to create the function as well as

the risk.

Otherwise, this risk also will be visible in the specific approver user ID itself.

Now let's go to setup and let's go to access risk.

So define let's.

Select.

You can see the risk zero two is visible now.

This is how we can use MSMP to enable approval function for risk creation as well as for the
maintenance.

With this we are coming to the end of this particular session.

Thank you very much for listening.

I will see you in the next session.

Bye bye.