http://www.sapsecurityonline.com/tutorials.

htm

R/3 Security- Audit Check

There comes a time when you have to deal with auditors. I have put together a check list
to go through. If this is a new implementation you should go through this and may be you
can impress your boss.

If you have any doubts as to whether or not revisiting your SAP infrastructure security is
worth your while, take this short test and see how well your SAP systems security now
fares:

1. Launch your SAP GUI, enter “066” as client, “EARLYWATCH” as username, and
SUPPORT” as password. Were you able to log in? If you could not log in, give yourself a
passing grade for this first test question. Your inability to log in means that either you
have successfully changed one of the known passwords (SUPPORT) of a standard SAP
username (EARLYWATCH), or you have locked this username. If you were able to log
in, give yourself a
failing grade for this question. Logging in under these conditions means that one of the
basic security measures at the presentation and application level was not performed, and
therefore any person with access to this SAP system can log in using this known
username, which, while not a full-privileged one, has enough authorizations to perform
certain functions that could be considered risky.

2. Walk over to a colleague’s workspace and try to run the SAP GUI from that person’s
PC. Could you do it? If you could not run the SAP GUI, you pass this test question. Your
inability to run the SAP GUI means that your colleague had basic security measures —
something as simple as having a password protected PC or screen saver — implemented
at the presentation level. If, on the other hand, you or anyone can freely access the
applications installed on any PC, it means that someone could use this gateway for
unwanted actions, or even fake the origin of a security attack.

3. Do you use SAP shortcuts to quickly access the most frequently used transactions or
reports? When you create a shortcut, does it allow you to store the password? If it does
not, run the REGEDIT (Registry Editor) program, search for the key
“HKEY_CLASSES_ROOT\ Sapgui.Shortcut.File\Security”, and set EnablePassword to
a value of “1”. Exit the Registry Editor and try again to create a shortcut. Now can you
create a shortcut with the password stored in the definition? If you initially were not able
to create a shortcut with a stored password,
or you were unable to edit the registry at your Windows workstation, give yourself a
passing grade. However, if you were able to store the password in the shortcut or edit the
registry, then your workstation may not be correctly protected, and you may have a
security problem at the presentation level.

4. If you are an R/3 user that has either SAP_ALL or S_A.SYSTEM privileges, run
report RSUSR009 using standard transaction SE38 or SA38. This report can help
security or system managers discover users with so-called “critical authorizations”. You
may be surprised to learn just how many people have access rights to critical
authorizations. If you find too many individuals who have been granted these privileges,
or discover some surprising or suspect listings as the result of this report, it means
security measures at the application level have not been completely implemented.

5. Log in at the operating system level as user “<sid>adm”. If your database is Oracle,
run svrmgrl (on UNIX systems) or svrmgr30 (on Windows NT). At the prompt enter
“connect internal”. Alternatively, try to connect as user “SAPR3” with password “SAP”
(“connect SAPR3/SAP”). Were you able to connect? Who else can do this? In other
words: Do many
people know the privileged username and password at the operating system or database
level? If this is the case, you may have a serious security problem because standard
usernames and passwords of Oracle and other database engines are well known, and
accessing the database at this level leaves your system highly exposed to the threat of
deleting objects, extracting confidential information, or leaving a database in an
inconsistent state.

6.From an SAP session, run program RSUSR006 (the ABAP report that shows
unsuccessful logon attempts). Do you notice any login attempts that were denied? Many
entries on this report are the result of users making typing mistakes, which is normal and
expected. However, if you discover unexpected users with incorrect logon attempts, your
systems might have been intentionally attacked. This report is included within the basic
set of monitoring and security auditing tools. If you don’t use this and/or similar reports
regularly, give yourself a failing grade here.

7. Copy one of your regular R/3 users (like a financial clerk or a warehouse operator) to a
test user. Log in as this test user. Can you run transactions STMS, SA38, PFCG, and
SU01? If you can run these or similar transactions as a regular user, you have a security
breach at the application level, since regular users should not normally be allowed to
perform operations that are meant to be performed by Basis administrators and/or User
administrators. If your regular users cannot execute these types of transactions, give
yourself a passing grade — otherwise you have a serious security problem at the
application level.

8. Can regular users add or edit system entries when using SAPLOGON? If edit
functionality is disabled, can users edit the SAPLOGON.INI file and change the key
“NoEditFunctionality” to “0”? If this is possible and you work in a company with many
SAP systems, give yourself a failing grade, because it means that users can freely add
new groups or servers to their SAPLOGON, which might enable them to connect to
unauthorized systems. If, on the other
hand, you use SAPLOGONPad or have protected Edit Functionality, give yourself a
passing grade.

9. Log in to an R/3 system with a user ID that has a very simple “display only” profile
(e.g., the profile S_A.SHOW). Then run transaction SE16 and enter “USR02” as the table
name. Can you display this table? Can you download it (System → List → Save →
Local file)? If a user with a “display only” profile can display and download the table
contents, give yourself a failing grade. USR02 is the table that contains master user logon
data, and although not easy, it is possible for a technical expert with access to an SAP
system to use this table for discovering (cracking) passwords. This means there is a
security problem at the application and the presentation level.

10. Did you ever look at transactions SM19, SM20 (Security Audit Log), or SECR (Audit
Info System)? Maybe you don’t even have them enabled. If you don’t know about these
and other similar transactions (like SUIM), give yourself a failing grade. These are core
control and auditing transactions that can help you verify the status of your security.
Security logging
and auditing operates at every layer of a security infrastructure, and therefore is a basic
mechanism to measure your infrastructure elements’ compliance with a security policy.
Did you get any failing marks, or did you pass all the tasks with flying colors? Even if
you got a perfect score, don’t walk away just yet! I made this test very, very simple.
Things like remote administration and debugging of ITS servers, password crackers, and
network sniffers have not been factored into this list, not to mention network services and
firewall configurations. Given their client/server architecture, SAP systems include many
components that exchange information with both SAP and non-SAP components alike.
Each of the elements needed for the communication and exchange of information
constitutes a layer of the SAP security infrastructure. Only with a comprehensive
security plan that encompasses all tiers of the SAP infrastructure can you ensure that you
set in place a security policy that protects the most valuable assets of your company from
intentional or unintentional, and external or internal attacks.

SAP R/3 user ID SAP* and other system user id has been adequately secured.
The production system has been set to productive.
Access Restriction: SCC4 and SE06
S_DEVELOP is secured
Change management is secured and controlled
Transport access to production is restricted
Developer access in production
Change critical number range is restricted
Custom tables has authorization group
Locking of sensitive systems transaction codes
BDC user types should has only required access
Run Program in the back ground
Changes to critical SAP R/3 tables are logged
Scheduling and Monitoring Batch jobs
Access to run reports should be restricted.
Critical and custom SAP R/3 tables are restricted.

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 and SAP_NEW

Execute transaction code SUIM

Click 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 SUIM

Click 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: SE16
Table 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: click here for more deail on profile
parameter

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 steps
Query 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

o 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 systems
Inspect the table TCEDELI which details with SAP systems receive released
transports.

Transport access to production is restricted

Performed the following procedures to verify that the ability to make transports to
production is restricted and access privileges are appropriately assigned based on job
responsibilities:

Risk: The risk here is that users who have this access, have the ability to move code from
the development environment to the production environment.

Executed transaction: SUIM

Authorization object: S_TCODE
Transaction code value: SE11
Authorization Object: S_TRANSPRT
Activity value: 01 OR 43
Request Type: DTRA OR CUST

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
 o Authorization object: S_TCODE
o Transaction code value: SE11
o Authorization object: S_DEVELOP
o Activity value: 01 or 02
o 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: SE38
Authorization Object: S_DEVELOP
Development Object ID: PROG
Activity: 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: SE16

Table 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 SUIM
Authorization object: S_TCODE
Transaction code value: SNRO
Authorization object: S_NUMBER
Activity: 02
Number 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: SE16

Table name: TDDAT
Table 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: SM01

OR
Execute transaction: SE16
Table Name: TSTC
C 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.

o Execute transaction code: SUIM

o S_TCODE: SM01
o 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 SUIM

Click 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 SM35

Enter 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 SUIM

S_tcode: SM36/SM37
Authorization Objects: S_BTCH_JOB, S_BTCH_NAM
Job 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 SUIM

S_tcode: SM35
Authorization Objects: S_BDC_MONI
Batch 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: SUIM

S_TCODE: SE01
Authorization object: S_TRANSPRT
Activity: 02
Field 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, RSUSR002

S_tcode: SM36 (Schedule)
Authorization Object: S_BTCH_JOB
Job Operations: RELE
Summary 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 SUIM
S_tcode: SA38
Authorization Objects: S_PROGRAM
User 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 SUIM

S_tcode: SA38
Authorization Objects: S_PROGRAM
User 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 SUIM

Authorization Object: S_TCODE
Transaction Code: SM31
Authorization object: S_TABU_DIS
Activity: 02 AND 03
Authorization 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.