&KDSWHU 6HFXULW\$GPLQLVWUDWLRQ

&RQWHQWV

Overview ................................................................................................................11–2
Audits .....................................................................................................................11–4
Security Layers .....................................................................................................11–6
Operational Security...........................................................................................11–25
Audit Tools ..........................................................................................................11–37
Audit Tasks..........................................................................................................11–57

System Administration Made Easy 11–1

Chapter 11: Security Administration
Overview

2YHUYLHZ

The purpose of this chapter is to make you aware of your responsibilities as the R/3 system
administrator(s) for security. These responsibilities include:
< Protecting the R/3 System
< Preparing you for a computer security audit
When an audit is performed on an R/3 System, the administrator(s) will be responsible for
responding to the audit findings. This chapter is an attempt to prepare you for these audits.
Each auditing firm has their own audit procedures and may look at many different items, so
we cannot prepare you for everything. However, we will try to prepare you for the core
group of items that all firms normally look at.

This chapter is only an introduction to computer security and its importance. Although an
entire book can be written on this subject, even that would be insufficient. We recommend
that you contact and work with all the parties (external auditors, internal auditors, finance
department, legal department, and others) who might be affected by system security.

:KDWLV6HFXULW\"
Security is more than the R/3 authorization (or keeping “undesirables” out of the system).
It is concerned with the following issues regarding data:
< Protecting it from hardware problems
< Maintaining its integrity
< Restoring it in the event of a disaster
Security is a broad topic and can be organized in many different ways. Some of the areas
covered include:
< Keeping unauthorized people out of the system
< Keeping people out of places that they should not be
< Safeguarding the data from damage or loss
< Complying with legal, regulatory, and other requirements
Each of these areas can be further divided.
.HHSLQJ8QDXWKRUL]HG3HRSOHRXWRIWKH6\VWHP
This area is what we usually think about as security and includes the R/3 authorization
concept, operating system and network logon security, and physical security.
.HHSLQJ3HRSOHRXWRI3ODFHV:KHUH7KH\6KRXOG1RW%H
This area covers users having access to more parts of the system and to more data than they
need to perform their job. The data may not be damaged but accessing and revealing this
data could be equally damaging.

Release 4.6A/B
11–2
 Chapter 11: Security Administration
Overview

Examples of this sensitive data include:

< Your company’s customer list, contacts, and sales volume.
This information could be used by a competitor.
< Your employees’ personnel data.
There are privacy laws that protect this type of data.
< Financial performance data, such as quarterly financial statements.
There are strict SEC rules governing insider trading (see below for a definition of insider
trading).
< Items specified in contracts with customers, vendors, or other parties.
6DIHJXDUGLQJWKH'DWDIURP'DPDJHRU/RVV
There are two major sources of damage:
< Accidental, such as:
ΠLoading test data into the production system.
This situation happens, unfortunately, more often than people admit.
ΠA hardware failure.
ΠA fire that destroys the data center.
ΠArson
ΠA flood, hurricane, earthquake, tornado, or other regional natural disasters.
< Deliberate, such as:
ΠA disgruntled employee who deletes or damages files from the system.
ΠA hacker who deletes or damages files from the system.

&RPSO\LQJZLWK/HJDO5HJXODWRU\DQG2WKHU5HTXLUHPHQWV

:KDW

Other reasons for security are defined by laws, contracts and other parties.
Security is a sensitive issue, and it has legal implications. One good example of security is
insider trading. Before defining insider trading, we have to first define insider knowledge or
inside information. Insider knowledge or inside information means you have information,
which is not known or available to the general public. If the information is known to the
general public, it could affect the stock price. Insider trading is using inside information to
buy or sell stock and make a profit or reduce a loss. Even if you do not profit from the sale,
you could be held liable.

System Administration Made Easy

11–3
Chapter 11: Security Administration
Audits

 ([DPSOH

In one company, an employee’s spouse passed on inside information to a relative, who

purchased the stock, then sold the stock at a profit after the earnings announcement.
That relative made a profit by buying the stock before the earnings announcement
(insider trading). The SEC fined the spouse and the relative. The spouse was guilty of
providing insider information to the relative, who then made the profit on the sale of the
stock. Both, therefore, were guilty of insider trading.

 ([DPSOH

The IS director of a company asked for authorization to log into the production R/3
System. This request raised the concern of the accounting/finance department. Access to
financial information is typically on a “need-to-know” or “need-to-access” basis, and the
IS director did not need to access the production R/3 System. “Red flags” went up when
he started asking about financial performance information (quarterly earnings), well
before this information was made public. He was asking for insider information.


+RZ
You will need the assistance of your company’s legal department.

$XGLWV

As a system administrator, you will be affected by two audits:

< Security
< Financial

)LQDQFLDO$XGLW
:KDW

A financial audit is a review of your company’s financial statements by a Certified Public

Accountant (CPA) in the U.S., or their equivalent in other countries. The purpose of the
audit is to issue an opinion on the company’s financial statements. This opinion essentially
states that the financial statement represents fairly the financial position of the company. A
financial audit is usually not an option. If your company’s stock is traded on the stock
market, the audit is required by the Securities and Exchange Commission (SEC) in the U.S.,
or its equivalent in other countries. If your company is private, a financial audit could be
required by creditors.
As a part of the financial audit, the CPA will typically do a security audit of R/3 and the
associated systems. The purpose of the security audit is to determine how much reliance can

Release 4.6A/B
11–4
 Chapter 11: Security Administration
Audits

be placed on the data in the R/3 System. Your external auditors will evaluate your system
security to determine what audit tests to perform and how much testing they will have to
do.

:K\

If their evaluation results are not good, they may need to increase the scope of their audit.
This increased scope also increases the cost of the audit, and the extra work could delay the
completion of the audit. In a worst case scenario, they could determine that the security is so
weak that they cannot issue an opinion on the company’s financial statements. This
situation is really bad.
Because of the effect on the stock price (down) that this inability to issue an opinion will
probably cause, the chief financial officer (CFO), and likely the president, will be quite
upset. Is your resume updated?

6HFXULW\$XGLW
:KDW

A security audit is performed specifically to test the security of the R/3 environment. This
audit is usually done as a part of the financial audit or to comply with government or other
regulatory agencies. It can also be done by your company’s internal audit group.

:K\

As a security audit.
As a part of the financial audit, the CPA will typically do a security audit of R/3 and the
associated systems. The purpose of the security audit is to determine how much reliance can
be placed on the data in the R/3 System. Your external auditors will evaluate your system
security to determine what audit tests to perform and how much testing they will have to
do.
The audit is also done to test the security of confidential data, such as:
< Financial information
< Customer data
< Product information
< Company personnel data (from the HR module)

$XGLW&RQVLGHUDWLRQV
:KDW

Audit considerations are the things that auditors will look at when they do the financial
audit, or a computer security audit.
Some of these considerations are:
< Physical security
< Network security

System Administration Made Easy

11–5
Chapter 11: Security Administration
Security Layers

< User administration procedures

ΠAdequate segregation of duties
ΠProper training
ΠPasswords
< Data security
ΠProtection from hardware failure; mirrored drives, RAID, fail-over, HA, etc.
ΠBackup and recovery procedures
ΠProtecting the production system from unauthorized changes
ΠLocking dangerous transactions

:K\

These tasks are done to support the financial or security audit. Without knowing what the
auditors will look for, you cannot properly prepare yourself, and protect the system.

 1RWH This section is not an all-inclusive SAP security audit. It is only to make you
aware of some of the things that could be reviewed as part of a security audit. We
recommend that you work with your auditors before the financial audit, to review your
system and bring it up to acceptable standards for the audit.

6HFXULW\/D\HUV

To make security more manageable, we have chosen to use the security layer model, one of
the many existing security models. It uses the following three major layers of security:

Data
Security

Access
security

< Access security

Operational
ΠPhysical security Security
ΠNetwork security
ΠApplication security
< Operational security
< Data security

Release 4.6A/B
11–6
 Chapter 11: Security Administration
Security Layers

$FFHVV6HFXULW\
3K\VLFDO6HFXULW\

:KDW

Physical security controls the physical access to R/3 and network equipment.
Like the graphic on the previous page, to get to the inner circle, an intruder must penetrate
the outer circles as follows:
< Onto the property or site
< Into the building
< Into the areas of the building where the users are or where the equipment is located
ΠFinance
ΠMIS
ΠComputer operations
< Into the specific equipment rooms within these areas of the building
ΠServer room
ΠWiring closet
ΠNetwork room

:K\

This layer is probably the most important. If an intruder can physically access your
equipment, all your other security layers can be bypassed.
When this layer is bypassed:
< Equipment can be physically damaged or destroyed.
< The system can be accessed from the operators console (and could bypass strong
network security).
< Equipment can be removed.
< Data could be hacked.
Without physical access to the equipment, the intruder must electronically access the system
through the network.

+RZ

The R/3 equipment should be located in a secured room. Access to the room should be only
through a locked door. It is crucial to control who is allowed access to the server room.

If you have electronic card key access, periodically audit the access log for the server room.
The periodic review of the access log may be an item for which auditors will test.

System Administration Made Easy

11–7
Chapter 11: Security Administration
Security Layers

1HWZRUN6HFXULW\

:KDW

Network security also has sublayers of security. The goal of this security type is to control
the following types of access to the network:
< External
< Logon
This type controls on-site and remote access and where on the network users can go
once they gain access.

:K\

If intruders access your network, they could have an electronic link to your computers.

+RZ

Use network security specialists to properly configure the various access points into your
network and, once users are on the network, control their movements.
Some of these points of control are:
< Outside access
ΠDial-in access
ΠInternet access
ΠOther remote access methods, such as VPN
< Network login access
This access method is the actual logon to the network (for example, the NT domain).
< Access to portions of the network.
ΠNT domains


1RWH We recommend that you have:
< A dedicated SAP domain where only the administrators are allowed to directly log
onto.
< Other domains where users will log onto, trust the SAP domain, but the SAP domain
does not trust other domains.

ΠRouter tables
This table can be used to control (by IP address) which users can access the SAP
servers.

Release 4.6A/B
11–8
 Chapter 11: Security Administration
Security Layers

$SSOLFDWLRQ6HFXULW\

:KDW

Like the other layers, application security has sublayers of security, which controls:
< The ability to log into the application, such as logging into R/3
< Where a user can go in the application
< What a user can do in the application
< What a user can do based on the system data in the application [such as the R/3 System
(for example, limiting the user to company 001 and cost center 200)]
R/3 security functions at this layer.

:K\

This layer provides the fine or specific security of what a user can do [for example, read (not
change) accounting data for only cost center 200 in company 001].

+RZ

Using R/3 application tools such as:

< Profile Generator (transaction PFCG; for more information, see Authorizations Made Easy)
< Audit Information System (transaction SECR; see page 11–37)
< Security Audit Log (transaction SM19/SM20; see page 11–44)
< Delete Old Audit Logs (transaction SM18)

2SHUDWLRQDO6HFXULW\
:KDW

This layer is security at the operational or user level. Because it is primarily procedures and
control, there are few computer or systems issues related at this level.

:K\

These are organizational and people issues, which are always a problem, because people
need to comply with guidelines and rules. The problem is, of course, that some people never
want to comply with guidelines.

+RZ

Some of the methods of operational control are:

< Segregation of duties
< Preventing sharing of user IDs
< Password standards
< Log off when away from the computer, such as during lunch or at the end of day

System Administration Made Easy

11–9
Chapter 11: Security Administration
Security Layers

'DWD6HFXULW\
This layer is closely knit to the material in chapter 2, because disaster recovery is an integral
part of data security.

:KDW

Data security is the protection of the data.

< Data on the servers
Here we are protecting the data on the server from damage or loss. This protection is
accomplished in various ways. The goal is to prevent or minimize loss of data in a
disaster.
< Backup data
The goal of this security layer is to preserve application data (usually on tape) so that the
system can be recovered.
The backup tapes must be stored safely to:
ΠPreserve the backup tapes in the event of a disaster
ΠProtect the backup tapes from theft
< Disaster Recovery
For more information on disaster recovery, see chapter 2.

:K\

It is easier to be proactive and prevent a problem than to recover from it.

To remain proactive:
< Reduce the chances of losing data.
The first place to do it is on the server.
< Protect backup data from damage or loss.
< Ensure that, if there is a disaster, the system be completely recovered.

+RZ
< Data on the servers
The goal is to prevent or minimize loss of data in a disaster. Some of the items below can
be referred to as High Availability (HA) items:
ΠRAID arrays for drives
ΠRedundant equipment
ΠUsing reliable equipment and vendors
ΠPremium hardware support agreements for the production system
The following are facilities-related items:
ΠUninterruptible Power Supplies (UPS)
ΠFire detection and prevention devices

Release 4.6A/B
11–10
 Chapter 11: Security Administration
Security Layers

ΠIntrusion alert
ΠEnvironmental alerts
< Backups
ΠBackup tapes should be sent to a secure, off-site data storage facility.
This step protects the backup data from damage or destruction a disaster.
ΠTapes at both the off-site backup and the on-site tape storage facilities must be
secured to prevent the theft of the backup tapes.
If the backup tapes were stolen, the data can be restored and hacked. Using database
tools, most R/3 security could be bypassed by directly reading the tables.

$SSOLFDWLRQRU56HFXULW\
&RQWUROOLQJ$FFHVVWR5
Also see the Password section in this chapter.
3UHYHQW0XOWLSOH8VHU/RJLQV

:KDW

This process prevents users from logging onto the system multiple times. Multiple user
logons is when several users are sharing a user ID, or someone is using a user’s ID without
the user’s knowledge. Preventing multiple user logons is not allowing more than one R/3
logon from one user ID.

:K\

If several people share a user ID:

< You do not know who created a problem.
< This situation is an audit security issue.

+RZ

Set the disable multi-login parameter (login/disable_multi_gui_login) in the system profile.

You can “allow” specific users to log on multiple times by entering their user IDs in the
parameter login/multi_login_users separated by commas and no spaces.

3UHYHQWLQJ&KDQJHVLQWKH3URGXFWLRQ6\VWHP
:KDW

The production system should be set to Not modifiable. The “locks” on the system should be
set so that configuration changes (client-independent and client-dependent) cannot be made
directly into the production system. The purpose for this setting is to ensure that all changes
are completed in a controlled manner.

System Administration Made Easy

11–11
Chapter 11: Security Administration
Security Layers

In the development pipeline, changes are:

1. Made in the development system
2. Tested in the development system
3. Transported from the development system to the test system
4. Tested in the test system
5. Transported from the test system to the production system
This procedure ensures that changes are properly tested and applied to the systems in the
pipeline. (A pipeline is the environment where development is moved from the
development system to the quality assurance system, and finally to the production system.)

:K\

Configuration changes should not be made directly into the production system. This
restriction maintains the integrity of the production system. If changes are made directly
into the production system, it may “break” because the change:
< Was not tested
< Is not the same as the one made in the development system
The goal is to protect the production system from changes, without the changes being
properly tested and to preserve the integrity of the pipeline. If changes are made into the
production system, the development and testing pipeline could become out of sync with the
production system. If the pipeline is out of sync, it get difficult to develop and test with any
certainty that things will not be different in the production system.
All changes should be made in the development system and then transported through the
pipeline into production. In this way, all systems get the same changes. A common excuse is
that making changes directly into the production system, “takes too long to transport the
fix.”
By making changes directly into the production system, you:
< Create an “out of sync” landscape, where the change made to the production system is
not the same as the changes made to the development or test systems.
< Allow emergency transports to occur at any time, with coordination.

([FHSWLRQV

Infrequent exceptions occur when:

< There is no mechanism to transport the changes.
< An SAP note requires the direct change.

Release 4.6A/B
11–12
 Chapter 11: Security Administration
Security Layers

When a change cannot be transported, the following procedure should be used:

1. Verify that the change cannot be transported.
Some objects may use an ABAP program to transport the object.
2. “Unlock” the system (to make it modifiable).
3. Make the change.
4. Immediately re-lock the system.
5. Make the same changes to all other systems.
Use this procedure only if a change cannot be transported.

Manual entry always increases the chance of making an error.

6HWWLQJWKH3URGXFWLRQ6\VWHPWR´1RW0RGLILDEOHµ7UDQVDFWLRQV6(6&&

:KDW

There are switches that prevent changes from being made in the system. In the production
system, these switches should be set to Not modifiable. The purpose of this setting in the
production system is to make sure that changes are made using the development pipeline.
With this procedure, changes are properly tested and applied to the systems in the pipeline.

:K\

Objects should not be modifiable in the production system. This rule protects the
production system from object and configuration changes before being tested. By setting the
production system to Not modifiable, before the integrity of the pipeline is preserved.

+RZ

There are two transactions (SE03 and SCC4) that you will use to set the system to Not
modifiable. (These transactions can also be used for other tasks.)

System Administration Made Easy

11–13
Chapter 11: Security Administration
Security Layers

&OLHQW,QGHSHQGHQW&KDQJHV7UDQVDFWLRQ6(


*XLGHG7RXU


1. In the Command field, enter transaction SE03 and choose Enter.

The menu path to access this screen is extremely complicated, which is why it is not included.
2. Select Set System Change Option.
3. Choose .
3

4. Under Global setting, choose :

5
a. To lock the system, select Not
modifiable.
b. To unlock the system, select
4
Modifiable (selected in this
example).
5. Choose .

Release 4.6A/B
11–14
 Chapter 11: Security Administration
Security Layers

&OLHQW,QGHSHQGHQWDQG&OLHQW'HSHQGHQW&KDQJHV6&&


*XLGHG7RXU


1RWH This method also locks the client-dependent changes.

1. In the Command field, enter transaction SCC4 and choose Enter

(or from the SAP standard menu, choose Tools → Administration → Administration → Client
administration → SCC4-Client maintenance).
2. Choose .

3. To continue, choose .

System Administration Made Easy

11–15
Chapter 11: Security Administration
Security Layers

4. Select the client number (for

example, 500).
5. Choose .
5

To Lock a Client (Not modifiable):

6. Under Changes and transports for
client-dependent objects, select 9
No changes allowed.
7. Under Client-independent object
changes, choose and select No
changes to Repository and client-
independent custom obj.
8. Under Protection: Client copier and
comparison tool, choose and select
Protection level 2: No overwriting, no
external availability.
6
9. Choose Save.

Release 4.6A/B
11–16
 Chapter 11: Security Administration
Security Layers

To Unlock a Client (Modifiable):

6. Under Changes and transports for
client-dependent objects, select 9
Automatic recording of changes.
7. Under Client-independent object
changes, choose and select Changes
to Repository and client-ind.
Customizing allowed.
8. Under Protection: Client copier and
comparison tool, choose and select
Protection level 0: No restriction.
9. Choose Save. 6

9HULI\LQJWKDW'DQJHURXV7UDQVDFWLRQV$UH/RFNHG
:KDW

“Dangerous transactions” could:

< Damage or corrupt the system
< Present a security risk
< Adversely impact performance

:K\

If users accidentally access these transactions, they could corrupt or destroy the R/3 System.
< In a production system:
Access to dangerous transactions is more critical in the production system than the
development or test systems. This criticality is because of live data and the company’s
operational dependency on the R/3 System.
< In a developmental system:
Certain transactions should be locked in the production system, but not in the
development, test, or training systems. Standard security normally prevents access to
these transactions, but some administrators, programmers, consultants, and functional
key users could access them depending on which system they are. In these cases, the
transaction lock provides a second line of defense.

System Administration Made Easy

11–17
Chapter 11: Security Administration
Security Layers

There are over 48,000 English transaction codes in the R/3 System. To manage such a large
number of transactions, lock only the critical ones. Your functional consultants should
supply you with any additional critical transactions in their modules.
The table below is organized with input from Basis consultants and users and lists
transactions that we recommend you lock. The transactions are categorized by the following
risk categories:
< Dangerous
< Security-related
< Performance impact

Transaction Description Dangerous Security Performance

F040 Document Archiving X

F041 Bank Master Data Archiving X
F042 G/L Accounts Archiving X
F043 Customer Archiving X
F044 Vendor Archiving X
F045 Document Archiving X
F046 Transaction Figures Archiving X
GCE2 Profiles: Initial screen X
GCE3 Maintain Authorizations: Object Classes X
KA10 Archive Cost Centers (all) X
KA12 Archive cost centers (plan) X
KA16 Archive cost centers (line items) X
KA17 Archive admin: cost centers (line items) X
KA18 Archive admin: completely cancelled X
doc
KA20 Archive admin: cost centers (all) X
O001 Maintain Users: Initial Screen X
O002 Profiles: Initial Screen X
O016 Maintain Authorizations: Object Classes X
OBR1 Reset Transaction Data X
(delete transaction data)
OBZ7 Maintain Users: Initial Screen X
OBZ8 Profiles: Initial screen X

Release 4.6A/B
11–18
 Chapter 11: Security Administration
Security Layers

Transaction Description Dangerous Security Performance

OBZ9 Maintain Authorizations: Object Classes X

OD02 Maintain Authorizations: Object Classes X
OD03 Profiles: Initial screen X
OD04 Maintain Users: Initial Screen X
OIBA Maintain Authorizations: Object Classes X
OIBB Maintain Users: Initial Screen X
OIBP Profiles: Initial Screen X
OMDL Maintain Users: Initial Screen X
OMDM Profiles: Initial Screen X
OMEH Maintain Users: Initial Screen X
OMEI Profiles: Initial Screen X
OMG7 Maintain Authorizations: Object Classes X
OMI6 Maintain Authorizations: Object Classes X
OML0 Maintain Users: Initial Screen X
OMM0 Profiles: Initial Screen X
OMNP Maintain Authorizations: Object Classes X
OMSN Maintain Users: Initial Screen X
OMSO Profiles: Initial Screen X
OMSZ Maintain Authorizations: Object Classes X
OMWF Maintain Users: Initial Screen X
OMWG Profiles: Initial Screen X
OMWK Maintain Authorizations: Object Classes X
OOPR Profiles: Initial Screen X
OOSB Change View "User Authorizations": X
Overview
OOSP Change View "Authorization Profiles": X
Overview
OOUS Maintain Users: Initial Screen X
OP15 Profiles: Initial Screen X
OP29 Maintain Users: Initial Screen X
OPCA Maintain Users: Initial Screen X

System Administration Made Easy

11–19
Chapter 11: Security Administration
Security Layers

Transaction Description Dangerous Security Performance

OPCB Profiles: Initial Screen X

OPCC Maintain Authorizations: Object Classes X
OPE9 Profiles: Initial Screen X
OPF0 Maintain Users: Initial Screen X
OPF1 Maintain Authorizations: Object Classes X
OPJ0 Maintain Users: Initial Screen X
OPJ1 Profiles: Initial Screen X
OPJ3 Maintain Authorizations: Object Classes X
OSSZ Maintain Authorizations: Object Classes X
OTZ1 Maintain Users: Initial Screen X
OTZ2 Profiles: Initial Screen X
OTZ3 Maintain Authorizations: Object Classes X
OVZ5 Maintain Users: Initial Screen X
OVZ6 Profiles: Initial Screen X
OY20 Maintain Authorizations: Object Classes X
OY21 Profiles: Initial Screen X
OY22 Maintain Users: Initial Screen X
OY27 Maintain Users: Initial Screen X
OY28 Maintain Users: Initial Screen X
OY29 Maintain Users: Initial Screen X
OY30 Maintain Users: Initial Screen X
SARA Archive Management: Initial Screen X
SCC5 Client delete X
SE01 Transport Organizer
SE06 System Table maintenance X X
SE09 Workbench Organizer
SE10 Customizing Organizer
SE11 Data Dictionary maintenance X
SE13 Maintain Storage parameters for table X
SE14 Utilities for dictionary tables X

Release 4.6A/B
11–20
 Chapter 11: Security Administration
Security Layers

Transaction Description Dangerous Security Performance

SE15 Data Dictionary Information System

SE16 Data Browser X
SE17 General Table display X
SE38 ABAP workbench X
SM49 External OS commands X
SM59 Maintain RFC destinations
SM69 External OS commands X
ST05 SQL trace X
SU12 Delete All Users X X

The following table shows dangerous transactions that probably cannot be locked because
they are (or could be) used regularly. These transactions may have other valid reasons for
use in a production system—but because of the potential danger, need to have restricted
access.

Transaction Description Dangerous Security Performance

RZ10 Edit System Profiles X

SA38 ABAP Workbench X
SM04 User Overview X
SM12 System Locks X
SM13 Update Terminates X
SM30 Table Maintenance X
SM31 Table Maintenance X
STMS Transport Management System X
SU01 User Maintenance X
SU02 Profiles: Initial Screen X
SU03 Maintain Authorizations: Object X
Classes

Table TSTCT contains the transaction codes and the name of the transaction. The current
content is over 93,000 entries in the table, with over 48,000 in English.

System Administration Made Easy

11–21
Chapter 11: Security Administration
Security Layers

+RZ

Create and maintain a list of the following information:

< Which transactions were locked?
< Why are they locked?
< Who locked them?
< When were they locked?

Maintaining the above-mentioned information will be important, because someone will

invariably want to know who locked the transaction and why it was locked.

*XLGHG7RXU


1. In the Command field, enter transaction SM01 and choose Enter

(or from the SAP standard menu, choose Tools → Administration → Administration →
SM01 Transaction Code Administration).
2. Enter the transaction code you
want to lock (for example, SE14)
3
in the search field at the bottom of
the TCode column.
3. Choose .

Release 4.6A/B
11–22
 Chapter 11: Security Administration
Security Layers

4. Use the locked checkbox:

< To lock a transaction, select the 5
transaction. 6
< To unlock a transaction,
deselect the transaction.
5. Choose .
4
6. Choose Back.

Check which transactions you are locking. You could accidentally lock yourself out of a
key transaction, which would prevent you from unlocking this or other transactions.

Access to transactions can also be controlled by building security authorizations on the

security object S_TCODE under Cross application authorization objects.

System Administration Made Easy

11–23
Chapter 11: Security Administration
Security Layers

7R/LVW/RFNHG7UDQVDFWLRQV
1. In the Command field, enter transaction SECR and choose Enter.
2. Select Complete audit.
3. Choose .

4. Expand the following menu path:

Audit Information System (AIS) →
System Audit →
Development / Customizing →
Transactions →
Locked Transactions: Display.
5. Choose next to Locked 4
Transactions: Display.

Release 4.6A/B
11–24
 Chapter 11: Security Administration
Operational Security

6. Verify that the following are

selected:
< Locked
< Transactions 7
< Menu transactions
< Parameter transactions
< Report transactions
6
7. Choose .

This screen shows the list of locked

transactions.

2SHUDWLRQDO6HFXULW\

This section describes selected operational security issues.

6HJUHJDWLRQRI'XWLHV
:KDW

There are standard audit guidelines that cover job or task combinations that are considered
“risky” or that reduce internal controls.
Some of these combinations are:
< Accounts Payable and Check Generation
< Accounts Receivable and Cash Receipts
< ABAP development and transport control

System Administration Made Easy

11–25
Chapter 11: Security Administration
Operational Security

Your external auditors should help you define these risky combinations. Testing for
segregation of duties is a standard audit procedure.

:K\

Accounts Receivable and Cash Collection

The purpose is to separate the person who collects and handles the cash from the person
who keeps the records of what a customer owes. In this combination, the cash received from
the customer could be pocketed and the amount written off the customer’s account. This
separation explains why, in a restaurant, the waiter is not also the cashier, or why a
mechanic must get spare parts from a storekeeper.

+RZ

The review of segregation of duties should be completed with the various user owners (key
users of each functional area).

Out of necessity, smaller companies must assign multiple functions to a single person. Be
aware of the potential security risks in this situation. If you must combine functions,
combine them in a way that minimizes risks.

5HVWULFWLQJ$FFHVVWR6$3 RU'',&
:KDW

These are system user IDs that have restricted uses for specific purposes.

:K\

There are certain functions that can only be performed by SAP* or DDIC. If an R/3 user
requires similar functionality, they should have a copy of the SAP* profile. These users
should be grouped as “super users,” with the appropriate security approvals.

The security profile for SAP* is SAP_ALL. This profile is extremely powerful because it
grants the user complete access to the system. For more information, see chapter 12,
Recommended Polices and Procedures: System Administration.

A user with user administration rights cannot change the password to gain access to a user
ID and then change it back to the original password. Passwords are not visible to the
administrators, so they cannot restore the original password if they do not know it. At the
next logon, the owner of the user ID will know that the password has been altered because
they will be unable to log on with their current password.

Release 4.6A/B
11–26
 Chapter 11: Security Administration
Operational Security

+RZ

1. Log on using SAP* and DDIC to determine if someone has changed the password.
2. Periodically change the password for these users in all:
< Systems
< Clients in those systems
This step prevents a person who knows the password from accessing the system.
3. Update the secured password list.
4. Verify that the system profile parameter login/no_automatic_user_sapstar has been
configured, to prevent the use of the automatic user sap*.
If the user ID has been deleted, this step prevents the “backdoor” usage of user sap*.

&KDQJH0DQDJHPHQW
:KDW

Change management is the process of controlling what changes are made to the system. In
this context, “system” refers to the entire system environment, not just R/3.

:K\

One aspect of security is to control and know what changes are made to the system.

+RZ

Item of concern:
< Is there a change management procedure for changes being made to the R/3 System?
< Is a QA testing process in place?
< Are reviews and approvals required to move changes into the production system?
6KDULQJRI8VHU,'V

:KDW

This process occurs when more than one person uses a single user ID.

:K\

This issue is a security concern because:

< There is no way to tell who is doing the activity.
< If there is a training problem, you do not know who needs training.
< If there is a deliberate security breach, there is no way to track the responsible party.

2WKHU

Despite the cautionary statements above, there are a few situations where it is not practical
to have individual user IDs. These situations must be treated individually and with
management and internal audits review and approval.

System Administration Made Easy

11–27
Chapter 11: Security Administration
Operational Security

 ([DPSOH$:DUHKRXVH

In a warehouse, there is one computer and several employees who use that computer to
post their warehouse transactions such as goods issued, goods received, etc. This process
occurs because the user ID is used to log on, not at the individual transaction level, but
the R/3 System. For each transaction that the warehouse employee access, it is
impractical to log on to R/3, access transaction, and log off from R/3. The alternative is
to have a computer for each warehouse person, although this step may not be
economically justified.

+RZ

To prevent a user ID from being shared, the system profile parameter

(login/disable_multi_gui_login) can (and should) be set.
Parameter values are:
< 1 (to block multiple logins)
< 0 (to allow multiple logins)
We recommend that this value be set to “1” to prevent multiple logins under the same user
ID.

3DVVZRUG,VVXHVDQG7DVNV
The password is the users key to accessing R/3. Like the key to your house, safeguarding
this key is important to keep “undesirables” out. Your company should have a clear and
practical company password policy, which should be distributed to all users informing
them not to use easy-to-guess passwords.

A password policy that is too restrictive or difficult to comply with could defeat the
purpose of this policy. Users will write their passwords down and leave it in an easily seen
place, which means you have lost your security.

Release 4.6A/B
11–28
 Chapter 11: Security Administration
Operational Security

6HWWLQJ3DVVZRUG6WDQGDUGV8VLQJ7UDQVDFWLRQ5=

:KDW

There are security parameters for the user’s password (for example, the minimum password
length, the time interval that the user must change their password, etc.).
The following is a list of the most important password parameters:
< Minimum password length: login/min_password_lng
A longer password is more difficult to break or guess, so the standard is usually five (5)
characters.
< Password expiration time: login/password_expiration_time
This time period is the limit before users must change their password.
ΠAuditors usually recommend 30 days.
ΠA practical number that customers use is 90 days.
< Password lockout: login/fails_to_user_lock
This parameter locks out users who, after a specified number of times, try to logon with
an incorrect password. Users are usually locked out after three failed attempts.

:K\

Properly assigned parameters will make it more difficult to break into the system.

Your external auditors may check to see if you have set the security parameters.

+RZ

To set up password parameters, maintain system profiles with transaction RZ10 (for more
information on this transaction, see chapter 20).

(OLPLQDWLQJ6RPH(DV\3DVVZRUGV

:KDW

There are certain passwords (for example, 123, QWERTY, abc, sex, sap, <your company name>)
that are well known or easy to guess. You can prevent these passwords from being used by
loading them into a table (USR40) that the system checks when the user attempts to save a
new password.

Table USR40 is only a basic level of password security and is maintained manually.
There are third-party password security programs that can be integrated into R/3.

System Administration Made Easy

11–29
Chapter 11: Security Administration
Operational Security

:K\

A password is the key to enter the system, similar to the key you use to enter your home. If
users choose easy-to-guess or well-known passwords, security is compromised and your
system is potentially at risk.

Your external auditors may check to see if you have a mechanism to secure against users
with “easy-to-guess” passwords.

+RZ

By maintaining the table of prohibited passwords.

0DLQWDLQLQJD7DEOHRI3URKLELWHG3DVVZRUGV

:KDW

A table of prohibited passwords is a user-defined list of passwords that are prohibited from
being used in the R/3 System. This table is not a substitute for good password policies and
practices by the users. Interaction occurs between a system profile parameter and the table
of prohibited passwords.
If the minimum password length is set to five characters, there is no reason to prohibit
passwords like “123” or “SAP,” because these passwords would fail the minimum length
test. However, if company security policy requires it, you could include all passwords that
are considered “risky” in the table.
The following is a list of easily guessed passwords that cannot be put into any table:
< <your name>
< <your spouse’s name>
< <your child’s name>
< <your pet’s name>
< <your car’s license plate>
< <your driver’s license number>
< <your social security number>

:K\

There are many lists circulating of commonly used user passwords. If one of these
passwords is used, the chances of an unauthorized person accessing a user’s account
increases.

+RZ

Changes will be made to table USR40 using transaction SM31, the general table maintenance
transaction. (For more information on this transaction, see chapter 19, Change Management:

Release 4.6A/B
11–30
 Chapter 11: Security Administration
Operational Security

Table Maintenance.). This change creates a transport that can then be transported throughout
the landscape.

Keep a log of changes made to this table in your security log.

A few suggestions for table entries are:

< SAP
< GOD
< ABC
< QWERTY
< SEX
< XYZ
< PASSWORD
< 123
< 12345*
< 54321*
< *12345*

Other table entries include:

< Days of the week
(Monday*, Tuesday*, Mon*, Tue*, etc.)
< Months of the year
(January*, February*, Jan*, Feb*, etc.)
< <your company name>
< <your product names>
< <competitors names>
< <competitors products names>
5HFRUGLQJ6\VWHP3DVVZRUGV
We recommend that you never write down passwords, except for the:
< Critical nature of the R/3 System.
< Many systems, clients, and all the other areas where passwords are required.
< Need to access the system if the SAP system administrator(s) is not available.

System Administration Made Easy

11–31
Chapter 11: Security Administration
Operational Security

5HFRPPHQGHG3URFHVV
< All passwords for all system IDs should be:
ΠRecorded
ΠPlaced in a sealed envelope
ΠPut in a company safe (possibly both an onsite and offsite safe) that has restricted
access.
Only a select list of company personnel should have access to this information.
< User IDs that are used or needed to maintain the R/3 System include:
ΠSAP*
ΠDDIC
ΠSAPCPIC (see note 29276)
ΠEarlyWatch (client 066)
ΠAll user-created administrative IDs
ΠAny other non-SAP user ID that is required to operate the system, such as for the
operating system, the database, and other related applications.
< The password list should be updated and replaced whenever passwords are changed.

Two people should prepare the list, change the password, and verify the new password—
one user ID at a time. If the recorded password is wrong, those “keys” are lost, and you may
not be able to log on to the system.

Following are sample password tables:

Server SID Client User ID Password

SAPR3T TST 000 SAP* Newpass

DDIC Newpass
<SID>ADM Newpass
SAPCPIC Newpass
001 SAP* Newpass
DDIC Newpass
<SID>ADM Newpass
SAPCPIC Newpass
066 SAP* Newpass
<SID>ADM Newpass
Earlywatch Newpass
100 SAP* Newpass
DDIC Newpass

Release 4.6A/B
11–32
 Chapter 11: Security Administration
Operational Security

Server SID Client User ID Password

BATCH1 Newpass
<SID>ADM Newpass
SAPCPIC Newpass

All systems should have entries for clients 000 and 001. In addition, the production system
should have an entry for client 066. Clients 000 and 001 are default clients in all systems,
and client 066 is the EarlyWatch client and may not exist in every system.

Where User ID Password

NT Finance/DEVADM Newpass
Finance/PRDADM Newpass
SQLserver sa Newpass
sapr3 Newpass
UNIX root Newpass
<SID>ADM Newpass
Oracle system Newpass
SYS Newpass
OPS$<SID>ADM Newpass
OPS$SAPSERVICE<SID> Newpass
SAPR3 Newpass

System Administration Made Easy

11–33
Chapter 11: Security Administration
Operational Security

*XLGHG7RXU


To change the password for a user ID:

1. In each instance and each client, log on under the user ID to change the password.
2. In Client, enter the client number
(for example, 500).
3. In User, enter the user ID you
want to change (for example,
sap*).
5
4. In Password, enter the current
password.
5. Choose New password. 2

3
4

6. Enter the new password twice in

the popup window.
6

Be careful when you enter the

new password. It is easy to enter
the password incorrectly or to
make the same error twice (for
example, user versus users and
the versus teh).
7. Choose .
At this point the logon will
proceed as normal.

Release 4.6A/B
11–34
 Chapter 11: Security Administration
Operational Security

8. Record the new password in the password table.

9. Log on using the new password to verify it.

At this point, if the new password fails, use another administrative user ID to reset the
password. This reason is why password changes should be made one user ID at a time.

This process must be repeated for every system and client in which the user ID has an entry.
With Central User Management, you can manage users across all systems (for more
information, see Authorizations Made Easy, Release 4.6).
2SHUDWLQJ6\VWHP/HYHO
At the operating system level, the following user IDs should have their passwords changed:
17
In some places, NT is case sensitive (for example, at the initial login screen).

8VHU,'V
< <SID>ADM
< SAPService<SID>

6HUYLFHV
< SAP
These services will either use user ID <SID>ADM or SAPService<SID>
ΠSAP<SID>_<instance>
ΠSAPOsCol
ΠSAProuter
< Oracle
ΠOracleService<sid>
ΠOracleTNSListener80
The default user that the Oracle services runs under is system
< SQLserver
ΠMSSQLServer
ΠSQLServerAgent
The user ID that they run under is either <SID>ADM or SAPService<SID>
< Informix
ΠINFORMIX-OnLineDynamicServer
ΠINFORMIX-OnLineMessageService
< DB2
DB2-DB2DA400

System Administration Made Easy

11–35
Chapter 11: Security Administration
Operational Security

81,;

8VHU,'V
< <sid>adm
< root

6HUYLFHV
ora<sid>
'DWDEDVHV
For the databases, the following user IDs should have their passwords changed:
'%
NT/DB2 (see SAP note 80292)
,QIRUPL[
See note 15399
0LFURVRIW64/6HUYHU
< See SAP note 28893
< sa
< sapr3
2UDFOH81,;
User IDs:
< SAPR3
< SYS
< SYSTEM

8VHIXO6$31RWHVIRU2UDFOH81,;

SAP Note # Description (Release)

117736 4.5A
101318 4.0B
086857 4.0A

Release 4.6A/B
11–36
 Chapter 11: Security Administration
Audit Tools

Use the program chdbpass to change the passwords. This program automatically updates the
SAPUSER table and enables the user <sapsid>adm to access the database.
2UDFOH17
< system
< sys
< op$<sid>adm
< ops$sapservice<sid>
< sapr3

$XGLW7RROV

$XGLW,QIRUPDWLRQ6\VWHP7UDQVDFWLRQ6(&5
:KDW

The Audit Information System (AIS) is designed for the system and business audits and will
likely be requested to be run by internal or external auditors. It puts into one place many of
the R/3 security tools. The center of the AIS is the Audit report tree. AIS uses standard R/3
reports and transactions to conduct the review and is a standard component in Release 4.6A.
However, you can import the AIS into your system back to Release 3.0D or higher. AIS also
provides an interface to export data to an external auditing system that analyzes financial
statements.

:K\

Auditors examine the results of automated and manual financial and system procedures to
ensure that there is a checks-and-balances infrastructure to prevent fraud, etc. AIS enables
the auditors to test transactions and run reports during the inspection.

+RZ

There are two ways to conduct an audit:

< Complete
< User defined

System Administration Made Easy

11–37
Chapter 11: Security Administration
Audit Tools

&RPSOHWH$XGLW
In the Command field, enter transaction SECR and choose Enter
(or from the SAP standard menu, choose Information Systems → SECR-Audit Info System).
1. Select Complete audit.
2. Choose .
2

A complete audit consists of a system audit and

business audit. The structure on this screen is
Audit_All with a standard view.
3. Click the node (+) to expand the following:
< System Audit
< Business Audit
3

Release 4.6A/B
11–38
 Chapter 11: Security Administration
Audit Tools

6\VWHP$XGLW

The following example shows how to use the AIS.

1. Under System Audit, click the node (+) next to
Repository / Tables.

2. Click the node (+) next to Table Information.

3. Choose next to Data Dictionary display.

System Administration Made Easy

11–39
Chapter 11: Security Administration
Audit Tools

4. When the transaction executes, you will see this

screen.
5
From here, you will execute the transaction
normally.
5. Choose Back.

Release 4.6A/B
11–40
 Chapter 11: Security Administration
Audit Tools

%XVLQHVV$XGLW

1. Under Business Audit, click the node (+) next to

Closing (FI-GL).
2. Click the node (+) next to Balance Sheet/ P&L/
Balances.
3. Click the node (+) next to Balance Sheet/ P&L.
You can execute different reports to inspect the
financial balances.
1
4. Choose next to Profit and Loss Projection.
2

5. On this screen, you can enter criteria for your

report then choose .
6
6. Choose Back. 5

System Administration Made Easy

11–41
Chapter 11: Security Administration
Audit Tools

8VHU'HILQHG$XGLW
You can also conduct a user-defined audit by creating a view or subset of a complete audit.
1. In the Command field, enter transaction SECR and choose Enter
(or from the SAP standard menu, choose Information Systems → SECR-Audit Info System)
2. Select User-defined audit.
3. Under User-defined audit, enter a view name (for
example, ZVUE).
4. Choose .
4

2
3

View names must start with “Y” or “Z.”

5. In Name, under New view, enter the name of the

view (for example, ZVUE).
6. Under Select using, select Manual selection. 5
You will select the procedures that will be
included in the view.
7. Choose .
When you are creating a view and you entered a
different name in Name, the name of the view is
what was entered in the main screen.
6

We want to include all the procedures for a

system audit in this view. 9
8. Select System Audit. 10

9. Choose .
10. Choose . 8

Release 4.6A/B
11–42
 Chapter 11: Security Administration
Audit Tools

The message in the status bar indicates that the

generation was successful.
11
11. Choose Back.

12. Choose Display to check the view of this

structure.

12

13. Click on the System Audit node (+) to expand it.

13

System Administration Made Easy

11–43
Chapter 11: Security Administration
Audit Tools

These are all the procedures for the Audit_All

structure with a ZVUE view.

6HFXULW\$XGLW/RJ60
:KDW

The Security Audit Log records the security-related activities of users in the system. These
activities include successful and failed:
< Dialog logon attempts
< Report and transaction starts
< RFC/CPIC logons
Other events written into the log are:
< Locked transactions or users
< Changed or deleted:
ΠAuthorizations
ΠAuthorization profiles
ΠUser master records
< Changes to the audit configuration
The log is created each day, and previous logs are neither deleted nor overwritten. The log
files can become numerous and large, so we recommend that the logs be periodically
archived before being manually purged. An audit analysis report can be generated from the
audit logs. You can analyze a local server, a remote server, or all the servers in an R/3
System.

:K\

Based on certain criteria, the information in the security audit files can be manipulated to
tailor the audit analysis report.
The report assists the administrator:
< Reconstruct or analyze incidents
< Improve security by recognizing inadequate measures

Release 4.6A/B
11–44
 Chapter 11: Security Administration
Audit Tools

< Trace unusual user activities

< Understand the impact of changes to transactions or users

+RZ

To start a security audit, you can do one of the following:

< Set the profile parameter rsau/enable to 1
(For more information, see the section on RZ10 in chapter 20.)
< Dynamically start it using transaction SM19.
The number of audit logs created by the system depend on the following:
< You may choose to set the maximum space for the security audit file in parameter
rsau/max_diskspace/local.
When the limit has been reached, logging will end.
< You can define the size of an individual security log file to fit in the chosen archiving
media.
This definition means that the system produces several log files each a day and these
files can be, for example, archived periodically into CDs. The profile parameter is
rsau/max_diskspace/per_file, and the maximum size per file is 2 GB.


1RWH You cannot set both parameters. You have to choose the method by which the
audit files are created.

System Administration Made Easy

11–45
Chapter 11: Security Administration
Audit Tools

5XQQLQJWKH$XGLW/RJ


*XLGHG7RXU


This procedure assumes that the audit has been running for some time and that audit logs have been
created.
1. In the Command field, enter transaction SM20 and choose Enter
(or from the SAP standard menu, choose Tools → Administration → Monitor → Security Audit log →
SM20-Analysis).
2. Complete the steps below:
a. In From date/time, enter a time and a date (for
example, 13:00). 3
b. Under Audit classes, select:
< Dialog logon 2a
< Transaction start
< Report start
2b
3. Choose Re-read audit log.
This button is used to read a log for the first
time.

The security report is displayed.

4. To see the details of an audit message, select a 4
line and choose .

Release 4.6A/B
11–46
 Chapter 11: Security Administration
Audit Tools

5. Documentation for the message and

technical details are revealed. This
screen is most useful when
displaying negative messages such as
failed logins or locked transactions.

6HWWLQJ6HFXULW\$XGLW/RJ3DUDPHWHUV60
:KDW

The audit log parameters are the criteria used to write the types of audit messages into the
audit log file. The parameters are grouped into audit profiles that can be activated at the
next system startup (configuration status) or applied “on the fly” (dynamic configuration).

:K\

Audit profiles need to be first created before audit logs can be written. These profiles limit
the amount and type of data written into the security audit files, which makes the
subsequent security reports more meaningful to the administrator.

+RZ

Decide what to audit and set selection criteria at the database level or dynamically at the
application server level:
< If the audit configuration is permanently stored at the database level, all application
servers use the identical criteria to save events in the audit log.
The settings take effect at the next application server start.
< At the application server level, however, dynamic changes can be set to individual
application servers and distributed to the entire system.
The new criteria will remain in effect until the server is brought down.
You can define up to 5 sets of selection criteria or filters. The system parameter,
rsau/selection_slots (that defines the number of filters has a default value of 2). You can
activate an audit in the dynamic configuration using transaction SM19.

System Administration Made Easy

11–47
Chapter 11: Security Administration
Audit Tools

*XLGHG7RXU


1. In the Command field, enter transaction SM19 and choose Enter

(or from the SAP standard menu, choose Tools → Administration → Monitor → Security Audit log →
SM19-Configuration).
Configuration status refers to the storage of the parameters in the database.
2. Choose .

3. Enter a profile name (for example, audprof1).

4. Choose . 3

Release 4.6A/B
11–48
 Chapter 11: Security Administration
Audit Tools

5. In this screen, you may specify two filter groups

and define the types of audit messages that will
be written into the log.

'HILQH)LOWHU*URXS
6. Choose Filter 1.
7. Under Selection criteria, in:
< Client, enter *
< User Names, enter *
8. In Audit classes, select:
< Dialog Logon
< Transaction Start
9. Under Events, select All. 6
10
10. Select Filter active.
7 8 9

System Administration Made Easy

11–49
Chapter 11: Security Administration
Audit Tools

'HILQH)LOWHU*URXS
11. Choose Filter 2.
This filter traces the reports started by one user.
12. Under Selection criteria:
< In Client, enter *.
< In User Names, enter a user ID (for example,
GARYN).
13. In Audit Classes, select Report start. 11
14. Under Events, select Severe and critical. 16
15
15. Deselect Filter active.
This setting allows you to save the filter settings 12 13 14
but does not activate them.
16. Choose Detail setting to drill down the audit
class and event class categories.

17. Scroll down to Report start.

18
Notice that the category is automatically chosen
based on the earlier selection of Event type and
Audit class type.
18. Choose .

17

Release 4.6A/B
11–50
 Chapter 11: Security Administration
Audit Tools

19. The general categories are cleared indicating

that settings were browsed or defined at the
detail level. 20

20. Choose Save.

19

21. A message at the bottom of the screen notifies

the user that the profile was successfully saved.
22. Choose . 22

21

System Administration Made Easy

11–51
Chapter 11: Security Administration
Audit Tools

23. The profile name is now in the Active profile

field, and the message in the status bar indicates
that the profile will be activated when the
application server is restarted. 24
24. To dynamically change the selection criteria for
one or more application servers in a running
23
system, choose the Dynamic configurat (Dynamic
configuration) tab.

25. In this example, the audit has been running for

some time (indicated by the current file size
greater than zero) before being stopped briefly.
The red square indicates that the audit is 26
inactive.
26. Choose .
25
25

Release 4.6A/B
11–52
 Chapter 11: Security Administration
Audit Tools

5XQQLQJDQ$XGLWRQD'LIIHUHQW8VHU

*XLGHG7RXU


In this procedure, we will run an audit on a different user and check on all the reports that were started.
1. Under Selection criteria, in:
< Client, enter *.
< User names, enter a user ID (for example,
Patricia).
5
2. Under Audit classes, select Report start.
3. Under Events, select All.
4. Under Filter 1, select Filter active.
5. Choose .

1 2 3

6. Choose Yes.

System Administration Made Easy

11–53
Chapter 11: Security Administration
Audit Tools

7. A green dot appears in the Stat

(Status) column and the message
at the bottom of the screen
indicates that the configuration
was activated.

8VHU6HFXULW\$XGLW-REV
Many of these reports are included as part of the AIS.

:KDW

There are several predefined SAP security reports, including:

< RSUSR003 Checks for default password on user IDs SAP* and DDIC
< RSUSR005 Lists users with critical authorizations
< RSUSR006 Lists users who are locked due to incorrect logon
This report should be scheduled to run each day, just before midnight.
< RSUSR007 Lists users with incomplete address data
< RSUSR008 Lists users with critical combinations of authorizations or transactions
< RSUSR009 Lists users with critical authorizations, with the option to select the
critical authorizations
< RSUSR100 Lists change documents for users and shows changes made to a user’s
security
< RSUSR101 Lists change documents for profiles and shows changes made to security
profiles
< RSUSR102 Lists change documents for authorizations and shows changes made to
security authorizations
Some of these reports have parameter tables that need to be properly maintained. Review
and analyze these reports based on your knowledge of the company. However, be aware

Release 4.6A/B
11–54
 Chapter 11: Security Administration
Audit Tools

that security issues may exist. If you have a small company, these issues cannot be avoided
because “one person often must wear many different hats.”

:K\

Your external auditors may require some of these reports to be executed as part of the
annual financial audit.

+RZ

You can use either of the following transactions:

< SA38 (ABAP: Execute Program)
This transaction only allows the program to be executed.
< SE38 (ABAP Editor)
With this transaction, if the user has the security authorization, the user can execute and
change the program.

6$²$%$3([HFXWH3URJUDP

1. In the Command field, enter transaction SA38 and choose Enter.

2. In Program, enter the
report name. 3
3. Choose .

System Administration Made Easy

11–55
Chapter 11: Security Administration
Audit Tools

6(²$%$3(GLWRU

1. In the Command field, enter transaction SE38 and choose Enter.

2. In Program enter the
report name .
3. Choose .

1RWHVIRU6SHFLILF5HSRUWV
RSUSR008 (lists critical combinations of authorizations or transactions):
< These combinations are maintained on table SUKRI.
< Dangerous combinations include the following transactions:
ΠRZ02 (with anything)
ΠRZ03 (with anything)
ΠSE14 (with anything)
ΠSU01 (with security, users, and profiles)
ΠSU02 (with security, users, and profiles)

Release 4.6A/B
11–56
 Chapter 11: Security Administration
Audit Tasks

$XGLW7DVNV

5HYLHZWKDWDOO1DPHG8VHUVDUH9DOLG
:KDW

All users who have left the company should have their R/3 access terminated immediately.
By locking or deleting these user IDs, you limit access to only those users who should have
access to R/3. Periodic review assures that the task of locking or deleting has been
completed.

:K\

Proper audit control requires that a user who no longer has a valid business need to access
R/3 should not be allowed to do so.
Deleting or locking these user IDs also prevents anyone who had been using the terminated
user ID from accessing the system with that ID.

One of the audit procedures that your external auditors will use is to test whether a person
who does not need to access R/3 has a live user ID.

+RZ

*XLGHG7RXU


1. In the Command field, enter transaction SU01 and choose Enter

(or from the SAP standard menu, choose Tools → Administration → User maintenance → SU01-Users).

2. Choose .

System Administration Made Easy

11–57
Chapter 11: Security Administration
Audit Tasks

Review the active users and

verify that these users are
valid.

In a large company, you

should do a random audit on
at least 20 users. The
minimum number should be
determined by your auditors.

For additional information on how to “lock” a user, see chapter 12, User Administration.

5HYLHZLQJ3URILOHVIRU$FFXUDF\DQG3HUPLVVLRQ&UHHS
:KDW

A “permission creep” is an incremental increase in permission and is given to a user over

time. If left unchecked, increased permissions may grant a user more authority in the system
than is required or intended.

:K\

Users may have undesirable authorization(s) or combinations.

Your external auditors may have an audit step to check for permission creep.

+RZ

You can conduct a spot audit of:

< Individuals
1. Review the security forms for a user
2. Compare these forms to the activity groups and profiles assigned to that user
3. Investigate inconsistencies

Release 4.6A/B
11–58
 Chapter 11: Security Administration
Audit Tasks

4. Review the activity groups and profiles assigned to the individual for reasonableness.
Reasonableness is defined as, “Does it make sense?”
5. Review the individual profiles assigned for content and check to see if the profile has
been recently changed.
< Profiles (transaction SU02) and authorizations (transaction SU03)
Check if the change date is recent.
You can also execute the following audit reports:
< RSUSR100 (user changes)
< RSUSR101 (profile changes)
< RSUSR102 (authorization changes)
For additional information on these reports, see the User Security Audit on page 11–54.

System Administration Made Easy

11–59
Chapter 11: Security Administration
Audit Tasks

Release 4.6A/B
11–60