Skip to Content

Security Diagnostics: Improving the Analysis Process Through Influence

During session SIM 150 at SAP Tech Ed 2009, we discussed pain points in the area of SAP security.  From this brainstorming and networking session several ideas surfaced to improve the security analysis process for failed security authorizations.  If you have performed troubleshooting using transaction SU53, you quickly learned that the last failed authorization check is not always the solution to the reported problem.  With many authority checks being in a hierarchy, the last failed authorization check may be an administrative or BASIS related authorization.  One solution to determine the minimum authorization value required to resolve the issue is to perform a trace using transaction ST01.  The trace in ST01 would show all of the failed authorization checks for the process.  However, this also may not be the final solution if the program exited with the error prior to performing all required authority checks.

Several companies mentioned that the use of ST01 was not permitted in their environment due to the potential performance impact to a production environment if the user did not restrict the trace properly.  What can we do to improve these processes?  Through ASUG Influence we could request functionality changes with the support of multiple companies.  Some possible process improvements are as follows:

• Write all failed authorization checks to a log file which contains the date, time and program where the failed authorization occurred.  The SU53 report would be updated to include the date, time and program fields.  The analyst could confirm that the failed authorization was actually related to the user error reported.  The log file could also be reviewed like ST01 to determine if the initial failed authorization check would have resolved the user issue.  This would provide some of the benefits of ST01 without requiring a trace to be executed in a production environment.

• Add activity or action objects to the ST01 transaction.  This action would allow a security developer to restrict the use of the transaction to the task of tracing authorizations.  The current process allows a user to select a radio button for authorizations, but there is not a function that allows you restrict the user to this action only. 

You must be Logged on to comment or reply to a post.
  • I like both of these potential improvements, and I hope that we can get an ASUG Influence Council together to work on making them happen. In the past it has seemed to me that improvements to the core system have not been regarded as very high priority compared to improvements to the latest new solution, and that has disappointed me; no matter which of the various extra solutions customers may have deployed in our ERP landscapes, we all have a core system, so improvements there have a much wider impact. Thanks for getting this effort started!


    • With the help of Gretchen Lindquist, Richard Fowler and Ben White we hosted a security and internal controls community session in Orlando on May 18, 2010.  We will be submitting these requirements along with some new requirements for GRC Access Control and BW soon.  Our goal is to make SAP a better tool for all users.  I am surprised that there were no requirements from SDN, but maybe the works as designed approach is good enough.