cancel
Showing results for 
Search instead for 
Did you mean: 

Handling of the SAP-delivered ruleset

Matthias038
Participant
0 Kudos

Hi to everybody,

we are facing the challenge to answer the question if the SAP-delivered ruleset is sufficient.

In OSS-note 986996 we learn that the SAP-delivered ruleset should be understood as "start-up".

Or in other words, there is no guarranty or confirmation that this ruleset is sufficient for the normal business and for the auditors.

(I must admit, as SAP I wouldn't say that either )

Now I would like to know about your experiences regarding the following questions:

- where does the SAP-ruleset is/was approved to be sufficient? (f.e. SD-billing we faced a lot of gaps)

- where not?

- how much effort was it to adjust it to the needs?

- how long does it take?

- how much were the auditor(s) involved?

- how about the effort when updating your own ruleset, based on the changes SAP deliverd each quarter?

I know it is a lot to discuss, but hopefully we will get a good collection of helpful informations.

thank you very much in advance

all the best

Matthias

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Matthias,

The ruleset is a good starting point and nothing more. Let me cite myself to give you a good example about a weakness in the ruleset.

Transaction codes may link to other transactions via drilldown, buttons, views etc. The table TCDCOUPLES contains the list of transaction codes that call other transactions. To ensure that the called transactions are also subjected to an authorization check the check indicator check in the table TCDCOUPLES for the entry of the pair calling and called transactions must be checked. Maintenance of this field in the table TCDCOUPLES is done via the transaction SE97. Basically the parallel with the transaction code SU24 ´Maintain the assignments of authorization objects’  is that authorization checks on S_TCODE in SE97 for called transaction codes can be switched on –and off the same way authorization checks are switched on and –off via transaction code SU24.

Two examples: The transaction code MM50 allows the extension of a material master for other organizational units. As standard MM50 calls transaction code MM01 and therefore users with authorization for MM50 also require authorization for MM01.  It is a common situation where MM50 is required by users but MM01 is not suitable.  In this case it is better to set MM01 as "do not check" via SE97.  Users can access the MM01 functionality when called through MM50 but do not require MM01 in S_TCODE any longer.  If they try to run MM01 they will get an authorization as it is not access through/coupled with MM50. Like SU24, SE97 isn't completely accurate

Transaction code RSSM ´Business Information Warehouse Authorizations’ may call the transaction code PFCG (profile generator) without the value PFCG being checked on S_TCODE: This implies that users with access to the transaction code RSSM can jump directly to transaction code PFCG. In this case it is better to switch the authorization check for PFCG on via SE97.

How does this relate to Segregation of Duties reporting and the exclude transaction code checkbox? As the above explains that not always the transaction code is checked to perform a task there is sufficient reason to run reports without a transaction check and only on authorization object level. Although the chance on false positives is higher.

Answers (8)

Answers (8)

Matthias038
Participant
0 Kudos

Thanks again to everybody who joined the Q&A for this discussion. I will set to "assumed answered"

If some more news are coming up, please let me know

Thanks in advance

Matthias

Matthias038
Participant
0 Kudos
Matthias038
Participant
0 Kudos

I also want to make you aware of Gretchen's blog entry. You can find it here:

http://scn.sap.com/community/grc/blog/2012/01/30/lessons-learned-from-sap-grc-projects

all the best

Matthias

Matthias038
Participant
0 Kudos

Hi all,

do you think there is a chance to announce a rough cut amount of adjustments of the ruleset?

For example:

Department sales

amount of risks               30 in SAP-ruleset

amount of risks added     15

thanks in advance

Matthias

simon_persin4
Contributor
0 Kudos

As mentioned earlier in the thread, Note 1809810 gives the details. There is an attachment in the note which highlights the changes to the rules.

Simon

Matthias038
Participant
0 Kudos

Hi Simon,

I see my question wasn't clear enough. I didn't mean the adjustments SAP gives with the update. I was talking about the adjustments you did yourself for the needs of your company.

Thanks

Matthias

Matthias038
Participant
0 Kudos

Dear all,

thanks a lot for your helpful input. TCDCouples was new to me. We already experienced some strange combinations in the risks matrix and that might have to do with the entries in this table.

When I look to all answers we got so far it seems to be clear, that SAP is working hard to provide an approved ruleset, but we - as the business part - have to check it and make our own input according to our special needs. This is also challenging regarding the authorization rules - of course.

We felt quite safe and satisfied with the SAP-delivered ruleset over the last years, without changing it in the sense of adding own risks for standard transactions. For our own designed transactions we took an individual ruleset to be able to make an easy update of the GLOBAL ruleset.

Since SAP stated more clearly in the note 986996 that the ruleset has to be understood as starting point, we realized that this could mean there is no longer the complete acceptance of the auditors.

We are now putting our knowledge together to make both, a better ruleset and at least not too much effort (specially the effort of the auditors checking the own-designed ruleset should be less).

Matthias

neerajmanocha
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi All,

SAP delivers GRC Standard ruleset based on the best practices and this helps for the beginners while implementing GRC into their business. This is approved & accepted approached by most of the customer/auditors into their business. Customers can start using the standard ruleset at the time of beginning and can modify/enabled/disabled the standard rules based on their company standards.

As far ar the gaps in standard ruleset is concerned, you are always welcome to send your suggestions/recommendations to SAP any time. In SAP, we always give respect to the customer suggestions and try to modify after consulting with area specialists. Last update in GRC standard ruleset was in Q4, 2012. Please refer to SAP Note 1809810 for more details about Q4, 2012 changes.

Whenever you find any gaps or having any suggestions about standard ruleset, please raise a message under GRC-SAC-ARA component OR you can approach directly to me on my email id neeraj.manocha@sap.com. We take all the suggestions very seriously and try to accumulate accordingly.

Thanks & Regards
Neeraj

Matthias038
Participant
0 Kudos

Hi Neeraj,

thank you very much for stepping into the question / discussion. May I ask you another question?

When SAP built up the ruleset, was it discussed / designed in coorperation with the auditors (like PWC, KPMG or others)? I guess it was. If yes, is there something like a statement from these auditors about the validation of the ruleset or about the ranges which are covered by the SAP-delivered ruleset?

Thanks in advance

all the best

Matthias

simon_persin4
Contributor
0 Kudos

Hi Matthias,

As an SAP Partner, I know that the SAP ruleset is a joint effort! Jayne Gibbon used to run a regular Ruleset Advisory Council which allowed recommendations to be communicated and applied to SAP standard. I believe Neeraj has taken over this function now.

Big 4 audit firms were definitely involved with the rulesets but they will not be able to provide firm validation statements as to its coverage since there are too many variables involved with the customer implementation and maintenance.

Also, issuing such statements would also place some sort of "duty of care" or additional liability onto the issuing party and could in theory lead to litigation if subsequent issues were found by an audit. Normally, the audit firms will review the implemented ruleset with a view of placing reliance upon it for future audits and then assess the changes & change control procedures around maintenance rather than repeating the detailed content review from there.

Cheers, Simon

neerajmanocha
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Matthias,

As I mentioned, these rules are built up basically based on best practices and after having discussion with area experts and also accepted by auditors/companies in the globe and also meeting the expectations of majority of the globe companies. The whole idea/motive is to provide customer a strong start rather than starting from scratch.

I am personally not aware about the statement from auditors but various big companies are running/relying with/on SAP standard ruleset along with their custom ones which are additionally built up based upon their company standards.

Thanks & Regards

Neeraj

simon_persin4
Contributor
0 Kudos

The main weakness with the SAP delivered ruleset is not just the transactional coverage but the associated permissions required to actually perform that particular function.

The SAP ruleset will be riddled with false positives (deliberately so) since SAP will not know the different organisational or specific process restrictions implemented by customers during their own SAP projects. Therefore, the SAP delivered ruleset can only be expected to go to activity based (actvt) checks rather than complete checks.

That also assumes that you are using complete SAP standard for all of your business processes and using the appropriate standard SAP transaction codes for their "normal" and intended purposes.

Basically, SAP's ruleset is there as an accelerator for GRC implementations. It is a good starting point but it is vital that the risks are evaluated, augmented and classified according to individual customer (and often external auditor) requirements to ensure that the ruleset is fit for purpose to that particular company.

The "how long" will depend massively on the changes which are required, it could take a couple of days but could take weeks! You'll always find some additional tweaks to be made throughout the lifecycle of your implementation as well so factor in ruleset maintenance as a regular activity.

Cheers, Simon

Colleen
Advisor
Advisor
0 Kudos

Most of the effort has been with the Internal Controls (Audit background) reviewing the business processes to look at the control point and determine which would be SoD or Critical Access (e.g. there might be an inherent system control instead).

Some things to consider for the rule set

  • transactions you have in design
  • custom functionality (Z and Y transactions and objects)
  • web services, etc that are not transaction driven

The analysis of your system functionality would determine the "gaps". SAP cannot give guarantee as businesses operate differently and have industries, countries, regions, etc may have additional compliance requirements.

Matthias038
Participant
0 Kudos

Dear Colleen,

thanks a lot for your input.

In the first approach we created an individual rule set containing just or own programming (Y/Z reportings) as addition to the SAP one. That saved us from updating one complete ruleset every time you have a new customer transaction.

We found the SAP-ruleset sufficient in the beginning and now we are wondering that we should adapt it. I expect the ruleset to be nearly complete in finance because this is most obvious.

In the mean while we are analysing and preparing our own investigation. hopefully it does not show up as a very huge project.

best regards

Matthias

Matthias038
Participant
0 Kudos

Hi Colleen,

just one more question. Did you put the Y- / Z-transactions into the same ruleset?

thanks in advance

Matthias

Colleen
Advisor
Advisor
0 Kudos

Yes that's our intention to make reporting easier for end user.

We are implementing a template solution so we don't require multiple rule sets. Intention is to copy GLOBAL to build own but only include the actions (transactions) that are in our design.

Each time a new transaction is added to design we can then complete a risk review to determine impacts to rule set and any necessary mitigating controls.