Navigating Security Considerations When Adding Custom Transaction Code to the GRC Ruleset

[debashish7]

*image1

Introduction: Businesses are always evolving their operations to keep up with the needs of the market. More often than not, special requirements arise that require customized coding to meet the business needs. SAP customers may implement special coding through ABAP language (in the form of a custom transaction) to add new functions to the system that are not available on the standard platform. As a result, they can unintentionally create security loopholes that make SAP environments susceptible to cyber attacks. An efficient ABAP code for a custom transaction must contain elements that can protect against security threats such as hard coded user and password, sod risk relevance, sap non-compliance ABAP coding, etc. Subsequently, it must be determined whether such custom transactions need to be included in SoD risk matrix.

This blog is more of a checklist which discusses the key considerations you should make prior to adding a custom transaction code to a ruleset in GRC, to ensure that your system remains safe and secure, and risks are accurately monitored while operating at maximum efficiency.

Assumptions: You are familiar with configuring SOD functions and risks in SAP GRC ruleset, or have a basic understanding of it.

Analyzing Custom Transactions from a Security Point-of-view:

a) First things first, always ensure to have a thorough look at the Functional Specification (FS) and/or Technical Specification (TS) documents to get a clear understanding of the custom transaction and its functionalities.

b) Check if the program developed for the custom transaction code has the AUTHORITY-CHECK statements to protect the data and business logic along with the return code (SY-SUBRC) logic. Return logic is used to return the transaction to a consistent state when access is denied to a user. Below is an example of an AUTHORITY-CHECK statement with the return logic in a standard SAP program:

The program associated with a custom transaction can also be identified in the following ways:

• Using transaction code SE93. Below is an example of a standard SAP transaction SU01 and its associated program from SE93 screen.

• Using SAP table TSTC. Please note that there might be situations when TSTC doesn’t provide the mapping of transaction code to program. It is because for programs that have been assigned a transaction code that uses a start object of “Transaction with parameters”, the program name is in the parameters. For these transactions, PGMNA in table TSTC will be blank. The additional information that links the program name to the transaction code is found in table TSTCP (Parameters for Transactions).

c) Ensure that the SU24 configuration is performed and contains all the authorization objects that are being called in the Program Code. Verify the same using the program “RS_ABAP_SOURCE_SCAN”.

Repeating the obvious fact, authorization objects with Check Indicator as “Check” and Proposal value as “Yes” in SU24, will get automatically added to the PFCG roles when the corresponding transaction is added to the Role Menu. Ensure these objects are included in AUTHORITY-CHECK statements of the custom program.

d) It is recommended to run the transaction on your own in the Development or Test environment, just to validate it works in the same manner as mentioned in the Functional Specification document and to rule out any untoward exceptions.

e) Determine if the custom transaction is updating records in a specific table in SAP or it is just a report transaction. Based on this sensitivity analysis, it can be decided whether the custom transaction needs to be included in the SOD matrix or not.

f) Fiori Launchpad over time has emerged as the primary interface for users, hence, it is necessary to check if there is any Fiori app associated with the custom transaction that has been configured to make it accessible in the Fiori launchpad, which in turn will have to be added to the SOD matrix.

If you are interested to know more on how to incorporate Fiori apps and services in the SOD ruleset, please refer to the SAP Blog: https://blogs.sap.com/2021/07/12/how-to-incorporate-sap-fiori-appfapp-and-servicesvc-in-the-ruleset....

g) It is also recommended to check with your System Administrator Team (BASIS Team) to carry out a performance analysis on the custom transaction code in order to avoid any potential system performance issue.

h) By this time, we must have identified the business process associated with the custom transaction and the functionality it enables in the system. Next step is to search for the best fit SOD function in GRC so that the custom transaction, its permissions along with the Fiori app and services (if any) can be added to it. If no suitable match can be found, better to create a new SOD function and then map it to the risk with which it is conflicting. Of course, this has to be done in alignment with the Risk Managers and/or SOD Compliance Team.

i) Know the intended audience for this custom transaction so that an initial risk analysis can be performed on these set of users (and roles too) and results can be shared with the Compliance Team for their assessment and review of the newly generated risks in the environment.

Conclusion: The addition of custom transaction codes into a GRC ruleset is an effective way to extend the functionality of the SAP system for identifying newly associated risks occurring at roles and users. However, caution must be taken when implementing this procedure, ensuring new risk definitions in the SOD matrix are accurate. In this blog we have discussed the considerations that should be made prior to adding a custom transaction code to a ruleset in SAP Access Control, in order to adequately protect the SAP environment.

Please don’t forget to provide your feedback and comments 😊

 

 

** System screenshots shown in this blog are sample data and only meant for reference purpose. Any resemblance to real data is purely coincidental.

*image1 courtesy - blogs.sap.com