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.