Skip to Content

Having worked for multiple companies with SAP applications, I have consistently found that many security analysts are very careful when maintaining standard transaction authorization objects.  However, when they develop roles for remote connectivity to support interfaces, portal applications, web services, and etc. they provide excessive access.  What do you do if months or even years later you discover that the S_RFC authorization object was implemented with full access to all RFC names?  Can you remediate this access without resulting to rocket science? 

You might ask, why not follow standard development processes and gather requirements.  Can you do this without impacting production processes?  Do you have resources that can provide the complete requirements?  In many cases, the appropriate resources are not available to document these requirements after a project is already implemented.  If resources are available, the ability to document the requirements timely becomes an issue.  Even if you implement changes, finding resources available to test the processes can be difficult.  In the end, a timely reduction of risk does not occur.

I was recently sharing with another user about a SAP tool for ECC 6 that was provided by Frank Buchholz.  I used this tool to identify and reverse engineer multiple system id’s which were previously provided unrestricted access.  Since this process is more of an art than a science, there are also multiple ways to arrive at the same goal.  I have also been working on enhancements to our Security Audit Log and came across SAP Note 1716731.  The note explains the general process for collecting RFC names through the Security Audit Log.  With the appropriate SM19 settings you can use SM20 to perform analysis once the data is collected.  Depending on the amount of data that you collect, the risk of impacting a production process is greatly reduced.  If you understand the frequency of the processes, you can determine the length of time to analyze.  Once the data is collected, you can export to Microsoft Excel for analysis and summarization.  

I believe that by reverse engineering the requirements, the risk can be reduced without negative impact to production business processes.  Whether you use the process documented in SAP Note 1716731 or a utility program that reads the statistics data, you can feel confident that the actual required function groups and functions will be identified.  The true requirements for the authorization object will be complete and after implanting the new authorization object values you will have reduced risk to your environment. 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Julius von dem Bussche

    Hi Greg,

    Sm19 (and the RFC server profiles in ST03N – beware that some program names are renamed, which effectively changes the function group or transaction context!) are very usefull as a frontline defense, to reduce the surphace area of misuse and attacks.

    But you have to remember that you must still authorize the application areas correctly (including critical ones with many objects like basis, HR, etc). Much like SA38 or Debugging authorizations, the application authorizations of RFC also offer intentional und unintentional vectors for misuse if you only restrict S_RFC and authorize the rest with SAP_ALL minus a few things like S_TCODE and S_USER_GRP, which are normally the first point of call.

    IMO, any misuse in this area is a ver targeted misuse, and only restricting S_RFC will not do the trick.

    Correctly authorizing the RFC functions with documented “where used lists” for the application authorizations is also possible (see SAP Note 1682316) and then all the dark horses and undocumented hacks are excluded as well.

    Cheers,

    Julius

    (0) 

Leave a Reply