SAP Basics for Auditing Change Management and Security September 8, 2014

1. SAPBasics for Auditing Change Management and SecuritySeptember 8, 2014 Presenter: Linda Yates Consultant, Risk Advisory Services

2. Course Objectives Change Management • Identify the critical SAP system parameters to protect the production environment • Discuss approach to auditing Change Management and key Change Management transaction codes SAP Security • Determine the password defaults and control settings • Discuss the architecture of SAP Security • Fundamentals of auditing SAP Security • Identify the key SAP Security tables and transaction codes

3. Change Management:System / Client ParametersAuditing Change ManagementKey Change Management Transaction Codes and Tables

4. SAP: Client Settings – Specific Change Options Settings for client-specific change options are maintained via transaction SCC4 and can also be viewed in table T000 (create & maintain SAP System clients) Three Client Specific Change Options (Settings) • Changes and Transports for Client-Specific Objects • Client-Independent Object Changes • Protection Against Client Copiers and Comparison Tools

5. Changes and Transports for Client-Specific Objects Controls whether client-specific objects can be maintained & if corresponding transports can be executed. Potential options: • Changes without automatic recording: Allows changes of client-specific objects and changes will not be automatically recorded (Not Recommended) • Automatic recording of changes: Changes are automatically recorded (Limitations on use should be applied) • No changes allowed: Prevents changes to customizing in the client (Recommended Setting) • Changes w/out automatic recording, no transports allowed: Allows changes to cross client-specific objects, no automatic recording of change, and manual transports not allowed (Only recommended for test clients)

6. Client Independent Object Changes Controls how repository and client-independent customizing objects can be changed within the client. Four Options: • Changes to Repository & Cross-Client: All cross-client customizing or repository objects can be maintained. (Not Recommended) • No Change to Cross-Client Customizing Objects: Does not allow the maintenance of cross-client customizing objects within the client (Not Recommended) • No Changes to Repository Objects: Does not allow the maintenance of repository objects within the client (Not Recommended) • No Changes to Repository and Cross-Client Customizing Objects: Does not allow the maintenance of cross-client customizing or repository objects within the client (Recommended Setting)

7. Protection Against Client Copiers and Comparison Tools Protects the client against reading access for other client, comparison tables cannot be executed and the client is protected against overwriting. Three protection levels are available as follows: • Protection Level 0: No restriction – Setting does not protect the client at all. Client can be overwritten by a client copy and reading access from other clients is possible. (Not recommended) • Protection Level 1: No overwriting – Client cannot be overwritten by a client copy and will be appropriate to protect the production client (Recommendedsetting for production environment) • Protection Level 2: No overwriting, no external availability - Client cannot be overwritten by a client copy and reading access from other clients is not available (Recommended for client with highly sensitive data)

8. Examples – Client Settings via SCC4

10. Examples – Client Settings via Table T000 Transp. Connection Blank = No automatic recording of changes 1 = Changes are recorded 2 = Customizing in client cannot be changed 3 = Customizing can be changed but cannot be transported No Cross-Client Blank = Changes to cross-client & repository allowed 1 = No changes to cross-client allowed 2 = No changes to repository allowed 3 = No changes to repository & cross-client allowed Copy Protection Blank = No protection X = Protection level 1 – No client copy

11. SCC4 Change Logs Survey conducted by ACL Services Ltd When changes are made to the client settings, change logs can be viewed via transaction code SCC4. Change Logs will show: • Date and Time Stamp of the Change • User who made the change • Old Value of Changes • New Value of Changes

12. Example: SCC4 Change Log

13. Change Management Landscape SAP is basically divided into three (3) different landscapes as follows: • Development (DEV): Where changes to code, programs, configuration and security are developed. Can have multiple clients, for example a Sandbox Client, Development client, Unit Testing client, etc. • Quality (QAS): Where changes to code, programs, configuration and security are tested. Multiple clients could exist supporting Integration Testing, Training, Security, etc. • Production (PRD): Business transactions are executed and recorded. Multiple clients could exists to support the client’s business hierarchy and structure

14. Change Management Landscape Example

15. Changes Moved or Made in Production • Use table E070 (via transaction SE16) to obtain a list of changes moved into or made directly in the production environment • E070 Parameters: At a minimum, input the date range of the requests/tasks (transports) moved or made in the production environment • Naming convention of the transports can provide information where the change was initiated or if the change was made directly in the production environment

16. Table E070 and Parameters

17. Results of Query for Table E070

19. View Transports • Detailed view of transports can be displayed via transaction code SE03 based on specified parameters

20. Transports based on Query Parameters

21. Change Management: Key Transaction Codes & Tables Tables for Change & Transport System: • E070: Change & Transport System – Header of Request/Tasks • E07T: Change & Transport System – Short Texts for Request/Tasks • E071: Object Entries of Request and Tasks Key Transaction Codes for Change & Transport System, Programing and Configuration of System: • STMS: Transport Management System • SE01: Transport Organizer • SE03: Workbench Organizer (Tools)

22. Change Management: Key Transaction Codes & Tables - Continued • SE06: Set up Workbench Organizer • SE09: Workbench Organizer • SE10: Customizing Organizer • SE11: Data Dictionary Maintenance • SE38: ABAP / Program Editor • SPRO: SAP System Customizing, IMG • SM30: Maintenance Table Views

23. SAP Security:Password ControlsSecurity ArchitectureAuditing SAP SecurityKey Transaction Codes and Tables

24. SAP Password Controls Default Passwords: Report RSUSR003 shows if the default passwords have been changed for all standard SAP IDs that include SAP* and DDIC.

26. SAP Password Controls - Continued Prohibited Passwords: Prohibited passwords can be viewed in table ‘USR40’ Password Control Settings: Parameters can be obtained through transaction code RSPFPAR. At a minimum, the following should be reviewed: • login/min_password_lng • login/password_expiration_time • login/fails_to_user_lock • login/min_password_diff • login/password_history_size Other parameters for consideration for strong password controls: • login/min_password_digits • login/min_password_letters • login/min_password_specials • login/disable_multi_gui_login

27. Extract from RSPFPAR

28. User Creation in SAP • User Master Records are created for every ID through transaction code SU01 and can be viewed using transaction SU01D. Validity dates for the user can be maintained within the master record, along with administrator locks. • All users are recorded in the USR02 table (via transaction code SE16), which shows the Validity dates, User Type, User Lock, Created By, Creation Date, last logon date / time, etc. • Identify user IDs created during a specified period of time (new users) • Identify inactive user IDs (stale users) • Identify disabled user IDs (terminated users) • Security Roles and associated profiles are assigned to the user’s Master Record along with validity dates for the role assignment

29. Example – User Master Record via SU01D

31. Table USR02 – User Master Record Table via Transaction Code SE16 or SE16N

34. Example of Output from Table USR02

35. User Types in SAP To identify the type or classification of the user ID, 1 of 5 ‘User Types’ is assigned to each User Master Record as follows: User Type ‘A’: Dialog ID and can logon directly to SAP. System checks for expired and initial passwords and provides an option to change the password. User Type ‘B: System ID used for internal system processes (e.g., background processing, ALE, workflow, TMS, CUA). Direct logon is not possible. User Type C: Communication ID used for communication between systems like RFC. Direct logon is not possible User Type S: Service ID is a dialog user that is available to an anonymous, larger group of users. Generally, this type of user should only be assigned very restricted authorizations. During logon, the system does not check for expired and initial passwords. Only the user administrator can change the password. User Type L: Reference ID is a general user, not assigned to a particular person. You cannot log on using a reference user. The reference user is only used to assign additional authorization and implemented to equip Internet users with identical authorizations.

36. SAP: Security Architecture SAP Security is based on field values assigned to authorization objects within a profile. A Profile is assigned to a security a Role, which is assigned to a User within the User Master Record.

37. Role / Profile Assigned to a User’s Master Record

38. Profile, Authorization, Authorization Objects and Field Values (Profile T-DV860568 / Authorization T-DV86056800)

39. SAP: Security Architecture • SAP checks for required authorizations in the User Master Record (SU01) when executing transaction codes • SAP provides information on which authorization objects are required for each transaction code and can be viewed via transaction code SU24 or through the USOBT_C table • Security Roles are developed using the Profile Generator in the Development environment and are moved into production via the Transport Management System. • Profiles not assigned to a security role can be assigned to a user

40. SU24 Example for SE11

41. Table USOBT_C Example for SE11

42. Auditing SAP Security - SUIM Main auditing transaction code used when auditing SAP security is 'SUIM’ (User Information System), which can be used for the following: Identify Users: • Authorization to execute specific transaction codes based on complex selection criteria using authorization objects and field values • By specific User ID, Roles, Profiles, Authorizations, etc. • Users with unsuccessful logons or based on last logon date and password change Identify Roles: • Roles containing authorizations to execute specific transaction codes • By Role Name or by User, Transaction or Profile assignment Other: SUIM can also be used to perform other queries including change documents

43. Access to Critical SAP Profiles SAP has profiles, containing authorizations that are automatically developed with the delivery of the system. These profiles are not assigned to a security role and can be assigned to a user’s Master Record. Some of these profiles are critical and have access to critical functions within the SAP environment. Critical profiles include: SAP_ALL S_RFC SAP_NEW S_TABU S_A.CUSTOMIZ S_A.CPIC S_A.DEVELOP S_A.ADMIN S_A.SYSTEM S_ABAP_ALL S_A.USER S_RZL_ADMIN S_USER_ALL S_NEW_* S_USER_GRP S_ADMI_ALL

44. Users Assigned to Critical Profiles • Utilize transaction code SUIM (Users > Users by Complex Selection Criteria>By Profiles) • Generate queries for each of the critical SAP profiles that are in scope for the audit.

45. Users Assigned to Critical Profiles - Results Output of query will show the users that have the specific security profile assigned to their User Master Record. Here is the result for the query of users assigned to the ‘SAP_ALL’ profile:

46. Identify Users with Access to Specific Transactions To identify users with access and the ability to execute specific transaction codes, conduct the following: • Identify the authorization objects and field values required to execute the transaction • Utilize the SUIM transaction code and follow the path: User Information System>User>Users by Complex Selection Criteria>Users by Complex Selection Criteria>Users • Input the authorization and associated field values and execute the query. • Output: Users that have the authorization objects and field values assigned to their User Master Record that would allow them to execute the transaction code

47. SUIM Execution and Access List Example Find users with access to execute transaction code SE11: Authorization Objects for SE11: • S_TCODE, field value = SE11 • S_DEVELOP, field Activity (ACTVT), field value = 01 (Create), 02 (Change) and 06 (Delete) Utilize SUIM and execute Users by Complex Selection Criteria and input the authorization objects and execute a query for each activity value Results for the 3 queries: 48 User IDs with activity ‘01’, 52 User IDs with activity ’02’ and 48 User IDs with activity ‘06’ What would happen if generated 1 query for all 3 activity values or 2 of the 3 activity values?

48. Access to Transactions & Authorization Objects

49. SE11 / Activity 01 SUIM Query Inputs

50. SUIM Query Results for SE11 w/Activity 01