SAP BASIS

R/3 Security- Audit Check

SAP R/3 user ID SAP* and other system user id has been adequately secured.
Performed the following steps to confirm that user ID SAP* has been adequately secured:
Verified whether default password of SAP* was changed in all production clients:Execute transaction code SA38, and run report RSUSR003.
Reviewed RSUSR003 report to verify that the parameter login/no_automatic_user_sapstar is set (value =0).

Who has sap_all andsap_new
Execute transaction code SUIMClick on “User”Click on “List of users according to complex selection criteria”.Click on “By user profiles”.Enter SAP_ALL in the Profile field and click Execution button
Execute transaction code SUIMClick on “User”Click on “List of users according to complex selection criteria”.Click on “By user profiles”.Enter SAP_NEW in the Profile field and click on the Execution button
Risk: The SAP_ALL profile grants a user full/complete access to all functions in the SAP system and has the potential to be misused. The SAP_ALL profile should only be assigned to a minimal number of users on the system.
The default SAP R/3 passwords for DDIC, SAPCPIC and EarlyWatch (in client 066) have been changed and access restricted to the super user.Performed the following procedures to verify that the default SAP R/3 passwords for DDIC, SAPCPIC and EarlyWatch have been changed and access restricted to the super user ID:
Execute transaction: SA38
Program: RSUSR003
Default passwords that should be changed:
SAP* - PASS
DDIC - 19920706
SAPCPIC - ADMIN
EarlyWatch - SUPPORT
Risk: SAP comes supplied with a number of default user IDs, all of which have default passwords. The passwords to these IDs are well known, and therefore if they are not changed, the IDs could potentially be misused
To review any passwords which are not allowed for users to use:Execute transaction code: SE16Table name: USR40 Risk: Table USR40 is used to prevent users from using a list of commonly guessed passwords. If it is not used it increases the possibility that users could select trivial passwords or you can use profile parameter to do this

The SAP R/3 system profile parameters have been set to appropriate values. Performed the following procedures to determine whether the SAP R/3 system profile parameters have been set to appropriate values:
Password Control in SAP Systems

There are two ways in which you can define your choice of user passwords:
You can use the system profile parameters to assign a minimum length for the passwords and define how often the user has to set new passwords.
Invalid passwords can be entered in the table of reserved passwords, USR40. This table is maintained with transaction SM30. The entries can also be made generically:
- ? denotes one character- * denotes a character string
The SAP System also has pre-defined password rules. You can control passwords with profile parameters login*
login/min_password_lng - Defines the minimum allowed length of a new password.
login/password_expiration_time - Defines the expiration period of the password
login/fails_to_user_lock - Locks the user after the specified amount of wrong logon attempts; user is unlocked at midnight if the login/failed_user_auto_unlock parameter is set
login/fails_to_session_end - Ends the user.s session after the specified amount of wrong logon attempts
login/disable_multiple_gui_login - Refuses multiple logon of users; only users listed in login/multi_login_users are allowed for multiple logon
login/min_password_diff - Defines the minimum number of different characters between old and new password including rotation
login/password_max_new_valid - Defines the validity period of passwords for newly created users
login/password_max_reset_valid - Defines the validity period of passwords reset
login/min_password_digits/_letters/_specials - Defines the minimum number of digits/letters/special characters in the password
login/disable_password_logon and login/password_logon_usergroupControls the deactivation of password-based logon
login/disable_cpic -Refuses incoming connections of type, CPIC
rdisp/gui_auto_logout - Defines the time for automatic SAPGUI logout
login/no_automatic_user_sapstar Controls the SAP* user
Default password, and protecting SAP*
Starting with installations of SAP Web Application Server release 6.10 and higher, the passwords of SAP* and DDIC are selected during the installation process.
Use the User Information System or report RSUSR003 to monitor the passwords of allpredefined users.
If possible, make use of the profile parameter, login/no_automatic_user_sapstar.
If you create a new client the default password for SAP* is pass. If you delete SAP* userid, logon is possible with SAP* /pass.
The DDIC user maintains the ABAP dictionary and software logistics. The system automatically creates a user master record for user SAP* and DDIC in client 000 whenthe SAP System is installed. This is the only user who can log on to the SAP Systemduring a release upgrade.Do not delete or lock user DDIC because it is required for certain installation and set-up tasks. User DDIC needs extensive authorization. As a result, the profile SAP_ALL is allocated to it. The users, SAP* and DDIC, should be assigned to user group SUPER to prevent unauthorized users from changing or deleting their user master record.
Default clients in an SAP System:
• Client 000 is used for customizing default settings. SAP imports the customizedsettings into this client in future SAP System releases during the upgrade processor even with support packages. Client 000 should not be used to customize datainput or development.• Client 066 is used by the SAP EarlyWatch service and should not be used ordeleted by the customers.
New Password rules

Overview of the improvements and changes in password rules or logon procedures that are delivered with Web AS ABAP 7.00 or NetWeaver 2004s
Passwords: Differentiation between upper and lower case; maximum length increased from eight to forty charactersFor new passwords, the system distinguishes between upper and lower case ; in addition, passwords can now consist of up to forty characters (up until now, the maximum has been eight characters). In newly-installed systems, this applies immediately to all users; in systems that have been upgraded to Web AS ABAP 7.00 or NetWeaver 2004s from an earlier release, we have ensured that all users can continue to log on using their old password. Information that tells the system whether a user has a new password or a password of the old type is stored in the user master record; this information is analyzed when the system checks the password: if the user has a password of the old type, the system converts the first eight characters of the password into upper case; the remaining thirty-two characters must be spaces. Otherwise, the password is analyzed in its entirety and without being converted into upper case. In Unicode systems, you can use Unicode characters in passwords.Relevant (new) profile parameters:
login/min_password_lowercase
login/min_password_uppercase
login/password_downwards_compatibility
Password history: size can now be defined as required (it used to be limited to five entries)The passwords that the user has assigned in the course of a password change are stored in the password history (passwords set by the user administrator are not stored in the password history). The system prevents the user from reusing previously-used passwords. The password history used to be limited to five entries; you can now define the size of the password history (maximum value: 100 entries) using a profile parameter (login/password_history_size).
Lock period for password change can be selected (it used to be limited to one day)To prevent the password history from being bypassed, a user may only change his or her password again after the lock period has passed (exception: the user is asked to change the password by the system). You can now select this lock period using the profile parameter login/password_change_waittime (maximum value: 1000 days).
(Advance) password change with stricter password rulesYou can now set the system so that it asks only users whose current password no longer satisfies the current (stricter) password rules to change their password (in advance). To do this, set the profile parameter login/password_compliance_to_current_policy = 1.
Validity period of unused passwords can be restrictedPasswords that are not used by the authorized user are a security risk. For this reason, you are now able to restrict the validity period of these passwords; here, the system distinguishes between initial passwords (that is, passwords that are assigned by the user administrator and that are to be changed by the user at the next opportunity) and non-initial passwords (that is, passwords that have been set by the user). (Technical) users of the type SERVICE and SYSTEM are exempt from this regulation.Relevant (new) profile parameters:
login/password_max_idle_initial
login/password_max_idle_productive
Logon: Compromising error messages are avoidedIf you attempt to log on using incorrect logon data, the system now only issues the generic error message "Name or password is incorrect" as a rule; further reasons for failed logons (for example, locked user accounts, user account is outside validity period, and so on) are only given in detail when valid logon data has been passed. Error scenarios in which the system could not check the logon data, or where no further check is allowed are the exceptions to this rule:
"User has no password - logon using password is not possible"
"Password logon no longer possible - too many failed attempts"
The default values of certain profile parameters that are relevant to security have been changed:
login/failed_user_auto_unlock : 0 (instead of 1)Locks for failed logon attempts remain valid for an unlimited period.
login/fails_to_user_lock : 5 (instead of 12)The lock for failed logon attempts is set after five failed passwordlogon attempts.
login/no_automatic_user_sapstar : 1 (instead of 0)The emergency user must be activated explicitly.
login/min_password_lng : 6 (instead of 3)Passwords must consist of at least six characters.
login/ticket_expiration_time : 8 (instead of 60)Logon tickets are only valid for eight hours.
The profile parameters login/password_max_new_valid and login/password_max_reset_valid have been replaced by the profile parameter login/password_max_idle_initial, which means that the system no longer distinguishes between the first and the subsequent setting of a password by the user administrator regarding the restriction of the validity of the resulting initial passwords.

The production system has been set to productive.
To verify that the company codes utilized in the SAP R/3 systems are set to productive. There are various company codes that come as default within SAP. This is to ensure that only the company codes that are being used should be checked and set-up as productive. SOX team/ Security team should perform the following steps:
Execute transaction code: OBR3
Review “Productive” column and ensure applicable global settings have not been checked off.
The production client settings have been flagged to not allow changes to programs and configuration.
Performed the following steps to verify that production client settings have been flagged to not allow changes to programs and configuration:
Execute transaction code SCC4 (all clients) and SE06
Double click on the applicable production client.
Verify that changes to client dependent and client independent objects are not allowed and that the client is set to productive.

Access Restriction: SCC4 and SE06
Transaction codes SCC4 and SE06 are critical transactions which can be used to prevent direct changes being made to the production system. If these transactions are not appropriately set there is a risk that unauthorized changes may be made directly in the production system, without going through the appropriate change management process.Performed the following steps to verify that the ability to make changes to client and system settings is restricted and access privileges are appropriately assigned based on job responsibilities. Perform the following stepsQuery 1
Execute transaction code: SUIM
Select User by complex criteria
Authorization object: S_TCODE
Transaction code value: SCC4
Authorization object: S_TABU_DIS
Activity: 02 and 03
Authorization Group: SS
Authorization object: S_TABU_CLI
Indicator for cross client maintenance: X
Query 2
Execute transaction code: SUIM
Authorization object: S_TCODE
Transaction code value: SCC4
Authorization object: S_ADMI_FCD
System Administration Function: T000
Authorization object: S_CTS_ADMI
Administration task: INIT
Query 3
Execute transaction code: SUIM
Authorization object: S_TCODE
Transaction code value: SE06
Authorization Objects: s_transprt
Activity Value: *
Request Type: *
Authorization Objects: s_cts_admi
Administration Task: RELE
S_DEVELOP is secured
Only the SAP R/3 super user has S_DEVELOP authorization object with critical activity values in the production system.Performed the following procedures to verify that only super user has S_DEVELOP authorization object with critical activity values in the production system:Query
Execute transaction code: SUIM
S_TCODE: SE38
Authorization Object: S_DEVELOP
All fields: “*”
Risk: The risk here is that users who have this access, have the ability to perform development related functions in the production system. Such access should be restricted to developers in the development system only.

Change management is secured and controlled
Performed the following procedures to ensure that SAP R/3 change management environment provides a secure and controlled structure for software changes. Start the transaction SE16, enter the table name and choose option Display.
TCESYST Environments Inspect the table TCESYST which details the various environments.
TCETRAL Cross Transports Inspecte the table TCETRAL, note various transport layers. Reviewed transport layers .
TCEDELI Recipient systemsInspect the table TCEDELI which details with SAP systems receive released transports.
Developer access in production
The ability to make changes to the SAP R/3 Data Dictionary is restricted and access privileges are appropriately assigned based on job responsibilities.Performed the following procedures to verify that the ability to make changes to the SAP R/3 Data Dictionary is restricted and access privileges are appropriately assigned based on job responsibilities:Executed transaction: SUIM
Authorization object: S_TCODE
Transaction code value: SE11
Authorization object: S_DEVELOP
Activity value: 01 or 02
Other fields: “*”
Risk: The risk here is that users who have this access, have the ability to maintain the SAP database (data dictionary).

Identify users who can do development in Production
Execute transaction code: SUIM
S_TCODE: SE38
Authorization Object: S_DEVELOP
Activity: 02 and 03
All fields: LEAVE BLANK
All fields: “*”
Risk: The risk here is that users who have this access, have the ability to perform development related functions in the production system. Such access should be restricted to developers in the development system only.
Execute transaction code: SUIM S_TCODE: SE38Authorization Object: S_DEVELOP Development Object ID: PROGActivity: 02 All fields: “*” AND LEAVE BLANK
Risk: The risk here is that users who have this access, have the ability to perform development related functions in the production system. Such access should be restricted to developers in the development system only.
Execute transaction code: SE16Table Name: DEVACCESS
Risk: Developer key is required along with the open system to make changes within production.

Change critical number range is restricted. (company code, charts of accounts etc.)
Performed the following procedures to verify that the SAP system appropriately restricts the ability to change critical number ranges (i.e., company codes, chart of accounts, accounting period data, etc.).
Execute transaction code SUIMAuthorization object: S_TCODETransaction code value: SNROAuthorization object: S_NUMBERActivity: 02Number of number range: “*”
Risk: The risk here is that users who have this access, have the ability to maintain critical number ranges.

Custom tables has auth group
Performed the following procedures to verify that all customized SAP R/3 tables have been assigned to the appropriate authorization group:
Executed transaction code: SE16Table name: TDDATTable name: Z*, Y*
Risk: If tables are not assigned to authorization groups it is not possible to appropriately control direct access to tables.

Locking of sensitive systems transaction codes in Production environment. Query
The authorization to lock and unlock transaction codes should only granted to selected few users. This also applies to costumer developed tcodes provided they are entered in table TSTCA through transaction code SE93
Do check using the following report in production who has this access.
Execute transaction: SM01OR Execute transaction: SE16Table Name: TSTCC info field: 20 to 20
Risk: SAP recommends that certain sensitive transactions be locked in the production system to prevent accidental or malicious use. The risk therefore is that these transactions be accidentally run, or run with malicious intent.Query Generated a list of users who have access to lock/unlock transaction codes.
Execute transaction code: SUIM
S_TCODE: SM01
Authorization object: S_ADMI_FCD
Field value: TLCK (lock/unlock transactions)
Risk: These users have the ability to lock or unlock sensitive transactions which should not be run in the production system.

BDC user types should has only required access. Don't need sap_all
To verify that BDC users are assigned only authorizations to perform the required task, performed the following steps:
Execute transaction code SUIMClick on “User”Click on “List of users according to complex selection criteria”.Click on “By user ID”.Then execute by clicking on the small green check mark.Click on “Other view” twice to display the user type for all listed user IDs.
Risk: The risk here is that these IDs have been provided “super user” access rights, which is excessive based on the typical needs for these IDs. Such IDs could potentially be misused. An overview of jobs scheduled in the SAP R/3 system is performed regularly.Performed the following steps to produce a listing of batch input sessions:
Execute transaction code SM35Enter a * in the “Session name” field and “Created By” field.Click on “Incorrect” Tab.
Risk: If batch sessions are not monitored on a regular basis, there is a risk that important batch sessions will contain errors or not be completely processed and therefore processing of critical financial information will not be complete and the issue will not be identified on a timely basis
Run Program in the back ground
By default user is allowed to schedule reports for background processing, but cannot release. Authorization for to release jobs is controlled by S_BTCH_JOB. Activity RELE is needed to release jobs. Activity PROT is required to display log. The other authorization like delete change andmove should only be assigned to the batch adminstrator.
S_BTCH_ADM should be granted to batch administrator and not to all the users. This is a critical authorization can release other users jobs. Controls access to jobs in all clients of a system.
S_BTCH_NAM can be used to schedule jobs under a different user id. Never give * as this would allow the user to start batch jobs under any user id.
To check who all have acces to this production follow the instruction below
Execute transaction code SUIMS_tcode: SM36/SM37Authorization Objects: S_BTCH_JOB, S_BTCH_NAMJob Operations: RELE: Summary of jobs for a group: “*”Background user ID.: “*”
Risk: The risk here is that users who have this access, have the ability to run programs directly in the background, bypassing transaction level security in SAP, and could potentially run programs /transactions they are not explicitly authorized to run.
Batch input - SM35
Batch input transaction code SM35 needs authorizationforobject S_BDC_MONI. You can restrict the privileages tocertain sesssion byentering the respective session name or name range. If you use name range then naming convetion should be used properly.
Execute transaction code SUIMS_tcode: SM35Authorization Objects: S_BDC_MONIBatch Input monitoring activity: “*”Session Name: “*”
Risk: The risk here is that users who have this access, have the ability to process batch transactions without being explicitly authorized to do so.
Changes to critical SAP R/3 tables are logged and management regularly reviews the logs.
Run transaction SE16, table DD09L and noted that tables have been selected for logging. Query
Execute transaction code: SUIMS_TCODE: SE01Authorization object: S_TRANSPRTActivity: 02Field Object in Workbench Organizer: UPGR
Risk: The risk here is that users who have this access, have the ability to transport matchcodes into the production system. Such access should be restricted to basis administrators only.

Scheduling Batch jobs
By default user is allowed to schedule reports for background processing, but cannot release. Authorization for to release jobs is controlled by S_BTCH_JOB. Activity RELE is needed to release jobs. Activity PROT is required to display log. The other authorization like delete change andmove should only be assigned to the batch adminstrator.
S_BTCH_ADM should be granted to batch administrator and not to all the users. This is a critical authorization can release other users jobs. Controls access to jobs in all clients of a system.
S_BTCH_NAM can be used to schedule jobs under a different user id. Never give * as this would allow the user to start batch jobs under any user id.
To check who all have acces to this production follow the instruction below.
Performed the following steps to verify which users have the ability to change the SAP R/3 job schedule:
Execute transaction code SA38, RSUSR002S_tcode: SM36 (Schedule)Authorization Object: S_BTCH_JOB Job Operations: RELESummary of jobs for a group: “*”, *
Risk: The potential risk here is that users who have this access, have the ability to run programs directly in the background, bypassing transaction level security in SAP, and could potentially run programs or transactions they are not explicitly authorized to run.
Monitoring Batch jobs
Run transaction SM37 to check if any of the jobs that had been during the last year are still active.
Risk: If jobs are not monitored on a regular basis, there is a risk that jobs will not run to completion and therefore processing of critical financial information will not be complete and the issue will not be identified on a timely basis

Access to run reports should be restricted.
Execute transaction code SUIMS_tcode: SA38Authorization Objects: S_PROGRAMUser action ABAP program: SUBMIT ( foreground and background)Authorization Group: *, “*”
Risk: The risk here is that users who have this access, have the ability to run programs directly, bypassing transaction level security in SAP, and could potentially run programs /transactions they are not explicitly authorized to run.
Execute transaction code SUIMS_tcode: SA38Authorization Objects: S_PROGRAMUser action ABAP program: EDIT (maintain attributes, text elements, ABAP/4 utilities to copy and delete programs)Authorization Group: *
Risk: The risk here is that users who have this access, have the ability to maintain program attributes.
Critical and custom SAP R/3 tables are restricted.
Execute transaction SUIM
Authorization Object: S_TCODE
Transaction Code: SM31 (enhanced tables maintenance)
Authorization object: S_TABU_DIS
Activity: 02 AND 03
Risk: The risk here is that users who have this access, have the ability to maintain table data directly in the production system. This includes transactional, masterfile, security and configuration data.
Execute transaction SUIMAuthorization Object: S_TCODE Transaction Code: SM31 Authorization object: S_TABU_DISActivity: 02 AND 03Authorization Object: S_TABU_CLI
Identify if custom transactions have references to authorization objects.
Execute transaction code: SE16
Table name: TSTCA / TSTC
TCODE: Z*
Check table TSTCA and verified that no Z transactions existed. Verified in table TSTC that the majority were secured by Authorization objects. Since all transactions are secured by S_Tcode this control is still effective.

SAP BASIS

Wednesday, July 4, 2007

display a customer-specific text on the SAPGui logon screen

R/3 Security- Audit Check

About Me