Professional Documents
Culture Documents
&RQWHQWV
Overview ................................................................................................................11–2
Audits .....................................................................................................................11–4
Security Layers .....................................................................................................11–6
Operational Security...........................................................................................11–25
Audit Tools ..........................................................................................................11–37
Audit Tasks..........................................................................................................11–57
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
&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.
([DPSOH
([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
)LQDQFLDO$XGLW
:KDW
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
: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
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.
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
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
'DWD6HFXULW\
This layer is closely knit to the material in chapter 2, because disaster recovery is an integral
part of data security.
:KDW
:K\
+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\
+RZ
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.
: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
Release 4.6A/B
11–12
Chapter 11: Security Administration
Security Layers
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.)
&OLHQW,QGHSHQGHQW&KDQJHV7UDQVDFWLRQ6(
*XLGHG7RXU
Release 4.6A/B
11–14
Chapter 11: Security Administration
Security Layers
&OLHQW,QGHSHQGHQWDQG&OLHQW'HSHQGHQW&KDQJHV6&&
*XLGHG7RXU
3. To continue, choose .
Release 4.6A/B
11–16
Chapter 11: Security Administration
Security Layers
9HULI\LQJWKDW'DQJHURXV7UDQVDFWLRQV$UH/RFNHG
:KDW
: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.
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
Release 4.6A/B
11–18
Chapter 11: Security Administration
Security Layers
Release 4.6A/B
11–20
Chapter 11: Security Administration
Security Layers
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.
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.
+RZ
*XLGHG7RXU
Release 4.6A/B
11–22
Chapter 11: Security Administration
Security Layers
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.
7R/LVW/RFNHG7UDQVDFWLRQV
1. In the Command field, enter transaction SECR and choose Enter.
2. Select Complete audit.
3. Choose .
Release 4.6A/B
11–24
Chapter 11: Security Administration
Operational Security
2SHUDWLRQDO6HFXULW\
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
Your external auditors should help you define these risky combinations. Testing for
segregation of duties is a standard audit procedure.
:K\
+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\
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.
([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
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.
: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
: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.
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.
Release 4.6A/B
11–32
Chapter 11: Security Administration
Operational Security
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.
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
*XLGHG7RXU
3
4
Release 4.6A/B
11–34
Chapter 11: Security Administration
Operational Security
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
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,;
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
&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
Release 4.6A/B
11–38
Chapter 11: Security Administration
Audit Tools
6\VWHP$XGLW
Release 4.6A/B
11–40
Chapter 11: Security Administration
Audit Tools
%XVLQHVV$XGLW
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
9. Choose .
10. Choose . 8
Release 4.6A/B
11–42
Chapter 11: Security Administration
Audit Tools
12
13
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
+RZ
1RWH You cannot set both parameters. You have to choose the method by which the
audit files are created.
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.
Release 4.6A/B
11–46
Chapter 11: Security Administration
Audit Tools
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.
*XLGHG7RXU
Release 4.6A/B
11–48
Chapter 11: Security Administration
Audit Tools
'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
'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
Release 4.6A/B
11–50
Chapter 11: Security Administration
Audit Tools
19
21
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.
8VHU6HFXULW\$XGLW-REV
Many of these reports are included as part of the AIS.
:KDW
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
6$²$%$3([HFXWH3URJUDP
6(²$%$3(GLWRU
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
2. Choose .
For additional information on how to “lock” a user, see chapter 12, User Administration.
5HYLHZLQJ3URILOHVIRU$FFXUDF\DQG3HUPLVVLRQ&UHHS
:KDW
:K\
Your external auditors may have an audit step to check for permission creep.
+RZ
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.
Release 4.6A/B
11–60