cancel
Showing results for 
Search instead for 
Did you mean: 

do you trust the SAP standard rule set ?

Former Member
0 Kudos

Hello all,

I have the impression that, too often, the SAP standard ruleset has been taken for granted : upload, generate and use. Here is a post as to why not to do so. Hopefuly, this will generate a interesting discussion.

As I have previously stated in other threads, you should be very careful accepting the SAP standard rule set without reviewing it first. Before accepting it, you should ensure that your specific SAP environment has been reflected in the functions. The 2 following questions deal with this topic :

1. what is your SAP release ? ---> 46C is different than ECC 6.0 in terms of permissions to be included in the function permission tab. With every SAP release, new authorization objects are linked to SAP standard tcodes. Subsequently some AUTHORITY-CHECK statements have been adapted in the ABAP behind the transaction code. So, other authorizations need to provided from an implementation point of view (PFCG). And thus, from an audit perspective (GRC-CC), other settings are due when filtering users' access rights in search for who can do what in SAP.

2. what are your customizing settings and master data settings ? --> depending on these answers you will have to (de)activate certain permissions in your functions. Eg. are authorization groups for posting periods, business areas, material types, ... being used ? If this is not required in the SAP system and if activated in SAP GRC function, then you filter down your results too hard, thereby leaving certain users out of the audit report while in reality they can actually execute the corresponding SAP functionality --> risk for false negatives !

Do not forget that the SAP standard ruleset is only an import of SU24 settings of - probably - a Walldorf system. That's the reason SAP states that the delivered rule set is a starting point.

So, the best practice is :

a. collect SAP specific settings per connector in a separate 'questionnaire' document, preferably structured in a database

b. reflect these answers per function per connector per action per permission by correctly (de)activating the corresponding permissions for all affected functions

You can imagine that this is a time-consuming process due to the amount of work and the slow interaction with the Java web-based GRC GUI. Therefore, it is a quite cumbersome and at times error-prone activity ...... That is, in case you would decide to implement your questionnaire answers manually. There are of course software providers on the market that can develop and maintain your functions in an off-line application and generate your rule set so that you can upload it directly in SAP GRC. In this example such software providers are particularly interesting, because your questionnaire answers are structurally stored and reflected in the functions. Any change now or in the future can be mass-reflected in all (hundreds / thousands of) corresponding permissions in the functions. Time-saving and consistent !

Is this questionnaire really necessary ? Can't I just activate all permissions in every function ? Certainly not, because that would - and here is the main problem - filter too much users out of your audit results because the filter is too stringent. This practice would lead too false negatives, something that auditors do not like.

Can't I just update all my functions based on my particular SU24 settings ? (by the way, if you don't know what SU24 settings are, than ask your role administrator. He/she should know. ) Yes, if you think they are on target, yes you can by deleting all VIRSA_CC_FUNCPRM entries from the Rules.txt export of the SAP standard rule set, re-upload, go for every function into change mode so that the new permissions are imported based on your SU24 settings. Also, very cumbersome and with the absolute condition that you SU24 are maintained excellent.

Why is that so important ? Imagine F_BKPF_GSB the auth object to check on auth groups on business areas within accounting documents. Most role administrator will leave this object on Check/Maintain in the SU24 settings. This means that the object will be imported in the role when - for example - FB01 has been added in the menu. But the role administrator inactivates the object in the role. Still no problem, because user doesn't need it, since auth groups on business areas are not being used. However, having this SU24 will result in an activated F_BKPF_GSB permission in your GRC function. So, SAP GRC will filter down on those users who have F_BKPF_GSB, which will lead to false negatives.

Haven't you noticed that SAP has deactivated quite a lot of permissions, including F_BKPF_GSB ? Now, you see why. But they go too far at times and even incorrect. Example : go ahead and look deeper into function AP02. There, you will see for FB01 that two permissions have been activated. F_BKPF_BEK and F_BKPF_KOA. The very basic authorizations needed to be able to post FI document are F_BKPF_BUK and F_BKPF_KOA. That's F_BKPF_BUK .... not F_BKPF_BEK. They have made a mistake here. F_BKPF_BEK is an optional auth object (as with F_BKPF_GSB) to check on vendor account auth groups.

Again, the message is : be very critical when looking at the SAP standard rule set. So, test thoroughly. And if your not sure, leave the job to a specialized firm.

Success !

Sam

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi, if I am doing something daft, I hope Jayne will put me right. We're using v 4.0 with v5 rules.

But first, to add my 10p worth, I too have reservations about the standard ruleset, and I believe the potential analysis work involved to ensure an accurate result has been massively underestimated. I think I understand how the rules work and could cope given the time, effort, desire, cooperation etc etc. as SAP suggest. I can't fault the disclaimer. A nice theory in a greenfield implementation, but a tad flawed where CC/GRC is an add-on. SU24 is usually maintained tactically if at all and isn't such a great guide in most places I've worked. I too see a market for ruleset specialists.

My question, however, concerns the engine, rather than the rules. Jayne used ME21N and M_BEST_BSA as an example. I'd like to refer to P017 - SES entry vs PO maint. This is one of the few conflicts that will typically take different ACTVT values from two profiles, 01 from the ME21N profile and 76 from the ML81N profile for example. The engine always delivers false negatives because the ACTVT values are only evaluated from just one profile which we would just never do in reality.

Am I doing something wrong, or is it broke? Thanks, alastair

Former Member
0 Kudos

Dear Jayne,

Thanks for your clear insights with regard to the conceptual strategy of the SAP standard ruleset.

Truly appreciated.

Dear Amol,

As to the list of software providers to mass-modify&upload the GRC functions according to customer specific settings (SAP release, customizing settings, ...), I am still working on that one. I would rather have a complete list of software providers than having a subset. This, to avoid any confilct of interests on this forum from my part.

Best regards,

Sam

Former Member
0 Kudos

Sam,

I am interested in the list of software providers to mass-modify & upload the GRC functions according to customer specific settings. I know you only have a subset, but I'd love to see what you have thus far...any information would help.

All,

We had a team of consultants assist us with the original build of our rule set. They took the SAP rule set and added to it. By doing this, we had the following numbers/results:

Object..................Original Count.......Revised Count

Risks.........................807......................203

Functions...................275......................150

Business Processes...22........................12

Rules.........................171,096................55,796

Notice that the original count reflects what was built by the vendor, and the revised count was after using/tweaking the SAP delivered rule set. Why is this information important? In one word....PERFORMANCE. Since improving our performance, our next focus will be in completing the custom transaction code evaluation for rule set impact and reviewing the current roles that report heavy conflicts for identification as critical which can then be mitigated and u201Cignoredu201D in the reporting for further performance gains. So, I guess be careful how you or others build your rules. You can and will notice performance issues.

For us, the rule set was a great starting point. We worked with our SOX and Internal Audit group and found that the standard SAP rule set fit our needs (presently). Thanks Jayne!

Regards,

Greg

jaynegibbon
Associate
Associate
0 Kudos

Sam and everyone,

Sam brings up some good points on the delivered ruleset. Please keep in mind; however, that SAP has always stated that the delivered ruleset is a starting point. This is brought up in sap note 986996 Best Practice for SAP CC Rules and Risks. I completely agree with him that no company should just use the supplied rules without doing a full evaluation of their risk and control environment.

I'll try to address each area that Sam brings up:

1. Regarding the issue with differences of auth objects between versions, the SAP delivered rulset is not meant to be version specific. We therefore provide rules with the lowest common denominator when it comes to auth object settings.

The rules were created on a 4.6c system, with the exception of transactions that only exist in higher versions.

The underlying assumption is that we want to ensure the rules do not have any false negatives. This means that we purposely activate the fewest auth objects required in order to execute the transaction.

If new or different auth object settings come into play in the higher releases and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these auth objects to the rules.

Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported.

2. For the customizing settings, as per above, we strive to deliver rules that are base level rules that are applicable for everyone. This is why we deliver only the core auth objects in our rules and not all. A example is ME21N.

If you look at SU24 in an ECC6 system, ME21N has 4 auth objects set as check/maintain. However, in the rules we only enable one of the object, M_BEST_BSA. This is to prevent false negatives.

3. Sam is absolutely right that the delivered auth object settings for FB01 have a mistake. The correct auth object should be F_BKPF_BUK and not F_BKPF_BEK. This was a manual error on my part. I've added this to a listing to correct in future versions of the rules.

4. Since late 2006, 4 updates have been made to the rules to correct known issues as well as expand the ruleset as needed. See the sap notes below as well as posting Compliance Calibrator - Q2 2008 Rule Update from July 22.

1083611 Compliance Calibrator Rule Update Q3 2007

1061380 Compliance Calibrator Rule Update Q2 2006

1035070 Compliance Calibrator Rule Update Q1 2007

1173980 Risk Analysis and Remediation Rule Update Q2 2008

5. SAP is constantly working to improve our rulesets as we know there are areas where the rules can be improved. See my earlier post called Request for participants for an Access Control Rule mini-council from January 28, 2008. A rule mini-council is in place and I welcome anyone who is interested in joining to contact me at the information provided in that post.

6. Finally, the document on the BPX location below has a good overview of how companies should review the rules and customize them to their control and risk environment:

https://www.sdn.sap.com/irj/sdn/bpx-grc

Under Key Topics - Access Control; choose document below:

o GRC Access Control - Access Risk Management Guide (PDF 268 KB)

The access risk management guide helps you set up and implement risk

identification and remediation with GRC Access Control.

Former Member
0 Kudos

I made the change from F_BKPF_BEK to F_BKPF_BUK in DEV and imported into our Production system and received the following errors:

Error in Table Data ==>VIRSA_CC_FUNCPRM

SQL:=>Insert into VIRSA_CC_FUNCPRM(FUNCTID,ACTIONS,VSYSKEY,AUTHTREE,FROMVAL,TOVAL,SEARCHTYPE,STATUS) Values(?,?,?,?,?,?,?,?)

Record:=>D VIRSA_CC_FUNCPRM AR01 F-31 ZEQ1 F_BKPF_BUK||ACTVT 01 01 AND 1

Any advice?

Greg

Former Member
0 Kudos

Hello Sam,

I absolutely agree with you, Standard Rule Sets are worth for a kick start implementation but you need to do a lot of research to identify what modifications and other rules are required on the basis of type or organization, what compliance law/Act the company has to follow and risk management policies.

Thanks for you detailed post, we surely can discuss on this topic, So can you name a few vendors who can help in creating structured questionnaires with respect to rule sets ?

Best Regards,

Amol Bharti