Audit

In this post we will be discussing about some of the basic SAP Security Audit Guidelines. Since each company has its own set of business requirements and various business processes, the audit guidelines may also slightly differ from company to company. The points which are being discussed in this post and in the subsequent post on Security audit (SAP Security Audit Guidelines – Part II), more or less cover the basic points which need to be taken care of during SAP Security audit.


SAP Role administrators and compliance managers should follow these guidelines while preparing for the SAP System audit:


(1) Status of SAP Standard user ids should be checked using report RSUSR003. The SAP Standard user ids are SAP*, DDIC, EARLYWATCH and SAPCPIC. From audit point of view, the passwords of these user ids should not be default.


Default passwords of SAP Standard user ids are as follows:

• SAP* – 06071992

• DDIC – 19920706

• EARLYWATCH – SUPPORT

• SAPCPIC – ADMIN

(2) Security audit log should be properly configured. It is configured using transaction code SM19. Certain parameters need to be enabled during configuration of audit logs.

The parameters are:

• rsau/enable – The value should be set to 1.
• rsau/max_diskspace/per_day or rsau/max_diskspace/per_file – Either of the two can be set
• rsau/selection_slots – This is used for deciding the number of filters based on the various types of logs needed (like a filter for logs related to RFC function calls, filter for logs related to transaction and reports executed by users etc.)

The logs which get generated can be seen using tcode SM20. SM20 gives logs based on the filter which has been set ( like what transaction or report was executed by what user at what time etc.) It also gives a very important information – i.e. from what terminal the transactions were executed.

The old logs can be deleted using tcode SM18. This access should be restricted to Basis team only.

(3) Maintaining User Groups : It is a Best Practice to maintain User groups. User groups can be created using transaction code SUGR and can be assigned to users. User groups are very helpful as they help in identifying whether the user is a business user or an IT user or System user etc. To some extent this helps in identifying the responsibilities that a user is supposed to have.


Some of the user groups can be as follows (name can be used as per convenience):

• BASIS – For Basis Team members

• SECURITY – For Security Team Members

• MM, SD, FI etc – For IT production support users belonging to various functional modules

• BUSINESS – Business Users

• ESS – For users who login through portal

• CANCEL – For cancelled users

• INACTIVE – For Inactive users

• SYSTEM – For user type system

• SUPER – For super users like SAP*, DDIC, etc

(4) Table logging : There are certain tables where table logging should be enabled in Production system. The technical setting of such tables need to be adjusted to “Log data changes”. Transaction code SE13 can be used for verifying whether table logging is enabled or not. Table DD09L can also be used with the condition Log = X to get an overview of the tables for which table logging is enabled. Change document for such tables can be viewed using table DBTABLOG.

(5) Maintaining proper values for Profile Parameters : Proper profile parameters values must be maintained as per the Best Practices so as to satisfy Security Audit Requirements. Below are examples of some such profile parameters.

(6) System and Client Setting options:

Following System change options should be set for Production environment. These can be set using transaction code SE06 (System Change Option):

• Global Settings: Not Modifiable
• Software Component: Not Modifiable
• Namespace / Name Range: Not Modifiable

Following client setting should be set in Production environment:

• Client Role: Production
• Changes and Transports for Client-Specific objects: No changes allowed
• Cross-Client Object Changes: No changes to Repository and cross-client customizing objects
• Catt and eCatt Restrictions: Catt and eCatt not Allowed

Audit is a never ending topic. We can continue to talk about as many security audit concepts as possible. We will discuss about some other very important points in our next post on SAP Security Audit Guidelines.