SE16N and SAP_EDIT

This is a continuation of the many different articles on this blog around security around tables. However, the articles till now has concentrated on the different methods provided by SAP to restrict access to tables. Today’s article on the other hand will talk about a common method of accessing tables, the security implications for this form of access and how we react as security consultant when faced with requests for this form of access.

A powerful and often dangerous feature of the SAP ERP system is the easy with which we can directly access the business data stored in the tables that make up its database. The extracted data can be manipulated within SAP or through external tools to allow for data analytics or through configuration entries to change how the SAP software behaves.

SE16N is one of the standard tcodes provided by SAP to access tables. Its similar to the other more common tcode SE16 but provides a host of other features not provided by the older transaction. The screen below shows the initial screen of the transaction displaying the selction options for a common security table. We can use the use different selection values in the screen to select rows  from the table which meet our criteria. Using SE16N to report on data can be a valuable tool for analysis for power users and display of tables can be restricted by using the correct security configuration through S_TABU_DIS, S_TABU_CLI, S_TABU_NAM.

However, one of the most unique features of the SE16N transaction is the ability to enter data into any table through the use of the &SAP_EDIT option. For me, its the possible use of the this option that makes SE16N so powerful and a potential headache for the security consultants. In a SAP system which allows &SAP_EDIT ( the functionality can be activated or de-activated by the use of appropriate OSS notes), we need to input the command &SAP_EDIT as shown in the screen below.

As long as &SAP_EDIT is available and the user has the correct authorizations, the editing option is indicated by the highlighted indicators. Once activated, the user would need to click the execute button when the transaction branches to the editing screen.

The editing screen for the table allows the user to change existing entries, copy entries or add new entries as shown below. The updation happens from the SE16N screen itself without a need for a maintenance dialog being called.  This is helpful for a person on the data correction team as not all sap tables have maintenance views defined and creating a maintenance dialog from scratch needs the services of a developer. As a direct result (the screen below indicates the same) of the above, any of the fields in the table can be updated, something that would not be possible through a maintenance dialog. This is very powerful and very dangerous as a non expert user can easily turn your data to junk. Please do not quote me on this but from what I have heard, the &SAP_EDIT functionality was something of a hack used by SAP developers to quickly update config tables. However, the hack got out into the wild and sap clients started asking for &SAP_EDIT access from the hapless security consultants.

Now we come to the part which really impacts most readers of this blog. Why do SAP Security Consultants all see red when asked for &SAP_EDIT. The reason is given in the security trace below which shows the authority checks happening behind the scene, when someone tries to use the &SAP_EDIT option. The main culprits are highlighted below. SAP will only allow you to run &SAP_EDIT only when you have the authorization object S_DEVELOP in your user buffer with activity values 01, 02 for object type DEBUG. This same access is used by ABAP developers to debug code and with change access they can change the value of the return codes after a failed authority check (RC = 4 to RC = 0) and execute almost anything  in SAP. For all practical purposes for an experienced user, the said S_DEVELOP access is same as assiging them with SAP_ALL and letting them loose in the Production server.