Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

ABAP CUSTOM PROGRAMS vs SOX - What is your best approach?

Former Member
0 Kudos

SOX defines you must put in place controls to be sure your users can do only those activities wich are not able to create a risk for your company assets.

You can use GRC AC to get clean and stay clean, but the problem is in your custom developments. Indirectly called transactions are not included in the transaction start check, so I think you must use "authority checks" to validate either stantdard authorization objetcs (sy-tcode, company code...) or custom authorization objects before to call a transacction/BAPI inside a custom program to be sure the user has the right permissions to complete this task.

Should i validate any single authoritation object defined in SU24 for each single transaction called Indirectly?

Any other quick win approach?

thx.

3 REPLIES 3

Former Member
0 Kudos

Hi,

If a standard tcode is called in custom tcode, you should add it in all roles where custom tcode is added.

So it will come in s_tcode and SOX will be checked accurately.

one more suggestion, if you don't want users to see standard tcode(which is called in custom tcode) in their menu,You can add it in role via authorization default.

Hope this helps

Former Member
0 Kudos

Manuel,

There are various types of controls that could be put in place for accomplishing this. Below are some things you could consider to mitigate this risk as I have done in the past which has been sufficent to auditors.

1) Have a solid review process for Functional Design Specs (FDS) reviews of RICEFW objects being developed into your SAP enviroment and be sure to have the process and review documented. This process will allow you to proactively seek out potential issues before they are coded to senstive areas where the potential risk to financial reporting could arise.

2) Implement coding standards for Security such as use of Program Auth Groups, Table Auth Groups, and implement certian SAP notes to secure S_DEVELOP object properly. Refer to https://websmp110.sap-ag.de/securitynotes for security notes.

3) Have a review/monitoring process in place to review access and authorizations to critical objects and transactions. GRC AC is one way to approach this.

You can use abap program "RSABAPSC : Statistical program analysis to find ABAP language commands" to seek out Authority-Checks in custom development as part of a quality review.

Thanks,

Matt

Former Member
0 Kudos

> Any other quick win approach?

It depends on how the code is written and how much time and tools to want to invest in keeping the code. Unfortunately, older forms of modularizing code and using generic includes will make this task and the security aspects a technical challenge.

I usually take some samples, scan for some techniques used, look at the stats to see what is being used (this is only an indicator to improve the error margin of the samples) and try to make a best guess.

There are some blunt tools and tricks you can use, but they should only be used as work-arounds. Examples are S_PROGRAM, S_TCODE, custom function modules implented in the reports, etc.

I suggest also taking a look in the blogs section by one from Matthew Billingham around October 2009. It was called something like "The noble art of code review". That, with good tools and getting it right first time, is the way to go.

Cheers,

Julius