security admin

System Administration Made Easy 11–1

&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

Chapter 11: Security Administration

Overview

Release 4.6A/B 11–2

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.

:KDW�LV�6HFXULW\"��

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.

.HHSLQJ�8QDXWKRUL]HG�3HRSOH�RXW�RI�WKH�6\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.

.HHSLQJ�3HRSOH�RXW�RI�3ODFHV�:KHUH�7KH\�6KRXOG�1RW�%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.


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.

6DIHJXDUGLQJ�WKH�'DWD�IURP�'DPDJH�RU�/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\LQJ�ZLWK�/HJDO��5HJXODWRU\��DQG�2WKHU�5HTXLUHPHQWV�

: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.


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


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


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:

< Access security � Physical security � Network security � Application security

< Operational security < Data security

Access security

Operational Security

Data Security


Security Layers


$FFHVV�6HFXULW\�

3K\VLFDO�6HFXULW\�

: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.


Security Layers


1HWZRUN�6HFXULW\�

: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.


Security Layers


$SSOLFDWLRQ�6HFXULW\�

: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)

2SHUDWLRQDO�6HFXULW\�

: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


Security Layers


'DWD�6HFXULW\�

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


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.

$SSOLFDWLRQ�RU�5��6HFXULW\�

&RQWUROOLQJ�$FFHVV�WR�5��

Also see the Password section in this chapter.

3UHYHQW�0XOWLSOH�8VHU�/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�&KDQJHV�LQ�WKH�3URGXFWLRQ�6\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.


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.


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.

6HWWLQJ�WKH�3URGXFWLRQ�6\VWHP�WR�´1RW�0RGLILDEOHµ��7UDQVDFWLRQV�6(��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.)


Security Layers


&OLHQW�,QGHSHQGHQW�&KDQJHV��7UDQVDFWLRQ�6(��

� *XLGHG�7RXU�

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 .

4. Under Global setting, choose :

a. To lock the system, select Not modifiable.

b. To unlock the system, select Modifiable (selected in this example).

5. Choose .

5

2

4

3


Security Layers


&OLHQW�,QGHSHQGHQW�DQG�&OLHQW�'HSHQGHQW�&KDQJHV��6&&��


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 .

2

3


Security Layers


4. Select the client number (for example, 500).

5. Choose .

To Lock a Client (Not modifiable):

6. Under Changes and transports for client-dependent objects, select 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.

9. Choose Save.

6

7

9

8

4

5


Security Layers


To Unlock a Client (Modifiable):

6. Under Changes and transports for client-dependent objects, select 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.

9HULI\LQJ�WKDW�'DQJHURXV�7UDQVDFWLRQV�$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.

6

7

8

9


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 doc

X

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 (delete transaction data)

X

OBZ7 Maintain Users: Initial Screen X

OBZ8 Profiles: Initial screen X


Security Layers



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": Overview

X

OOSP Change View "Authorization Profiles": Overview

X

OOUS Maintain Users: Initial Screen X

OP15 Profiles: Initial Screen X

OP29 Maintain Users: Initial Screen X

OPCA Maintain Users: Initial Screen X


Security Layers



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





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


Security Layers



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.


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 Classes

X

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.


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.


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) in the search field at the bottom of the TCode column.

3. Choose .

2

3


Security Layers


4. Use the locked checkbox: < To lock a transaction, select the

transaction. < To unlock a transaction,

deselect the transaction.

5. Choose .

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.

4

5 6


Security Layers


7R�/LVW�/RFNHG�7UDQVDFWLRQV�

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 Transactions: Display.

5

3

2

4




6. Verify that the following are selected: < Locked < Transactions < Menu transactions < Parameter transactions < Report transactions

7. Choose .

This screen shows the list of locked transactions.

2SHUDWLRQDO�6HFXULW\�

This section describes selected operational security issues.

6HJUHJDWLRQ�RI�'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

6

7




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�$FFHVV�WR�6$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.




+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*.

&KDQJH�0DQDJHPHQW�

: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?

6KDULQJ�RI�8VHU�,'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.




� ([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�,VVXHV�DQG�7DVNV�

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.




6HWWLQJ�3DVVZRUG�6WDQGDUGV�8VLQJ�7UDQVDFWLRQ�5=��

: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).

(OLPLQDWLQJ�6RPH�(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�

By maintaining the table of prohibited passwords.

0DLQWDLQLQJ�D�7DEOH�RI�3URKLELWHG�3DVVZRUGV�

: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:




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>

5HFRUGLQJ�6\VWHP�3DVVZRUGV�

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.




5HFRPPHQGHG�3URFHVV�

< 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




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





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*).

4. In Password, enter the current password.

5. Choose New password.

6. Enter the new password twice in

the popup window.

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.

6

7

2

3 4

5




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).

2SHUDWLQJ�6\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

0LFURVRIW�64/�6HUYHU�

< See SAP note 28893 < sa < sapr3

2UDFOH�81,;�

User IDs: < SAPR3 < SYS < SYSTEM

8VHIXO�6$3�1RWHV�IRU�2UDFOH�81,;�

SAP Note # Description (Release)

117736 4.5A

101318 4.0B

086857 4.0A


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.

2UDFOH�17�

< system < sys < op$<sid>adm < ops$sapservice<sid> < sapr3

$XGLW�7RROV�

$XGLW�,QIRUPDWLRQ�6\VWHP��7UDQVDFWLRQ�6(&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


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 .

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

1

2

3


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.

1

2

3


Audit Tools


4. When the transaction executes, you will see this screen.

From here, you will execute the transaction normally.

5. Choose Back.

5


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.

4. Choose next to Profit and Loss Projection.

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

report then choose .

6. Choose Back.

1

2

3

4

6 5


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 .

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.

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.

We want to include all the procedures for a system audit in this view.

8. Select System Audit.

9. Choose .

10. Choose .

2 3

7

6

5

10

8

4

9


Audit Tools


The message in the status bar indicates that the generation was successful.

11. Choose Back.

12. Choose Display to check the view of this structure.

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

11

12

13


Audit Tools


These are all the procedures for the Audit_All structure with a ZVUE view.

�

6HFXULW\�$XGLW�/RJ��60��

: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


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.


Audit Tools


5XQQLQJ�WKH�$XGLW�/RJ��


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).

b. Under Audit classes, select: < Dialog logon < Transaction start < Report start

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 line and choose .

2b

2a

3

4


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.

6HWWLQJ�6HFXULW\�$XGLW�/RJ�3DUDPHWHUV��60��

: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.


Audit Tools



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

2

4


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.

10. Select Filter active.

7 8 9

6

10


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.

14. Under Events, select Severe and critical.

15. Deselect Filter active.

This setting allows you to save the filter settings 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.

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

18. Choose .

12 13 14

15 16

11

17

18


Audit Tools


19. The general categories are cleared indicating that settings were browsed or defined at the detail level.

20. Choose Save.

21. A message at the bottom of the screen notifies

the user that the profile was successfully saved.

22. Choose .

20

21

22

19


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. To dynamically change the selection criteria for one or more application servers in a running 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 inactive.

26. Choose .

23

24

25

26

25


Audit Tools


5XQQLQJ�DQ�$XGLW�RQ�D�'LIIHUHQW�8VHU�


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).

2. Under Audit classes, select Report start.

3. Under Events, select All.

4. Under Filter 1, select Filter active.

5. Choose .

6. Choose Yes.

1 2 3

4

5

6


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.

8VHU�6HFXULW\�$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

7

7


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��([HFXWH�3URJUDP�

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

2. In Program, enter the report name.

3. Choose .

3

2


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 .

1RWHV�IRU�6SHFLILF�5HSRUWV�

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)

3

2


Audit Tasks


$XGLW�7DVNV�

5HYLHZ�WKDW�DOO�1DPHG�8VHUV�DUH�9DOLG�

: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�


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 .

2


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.

5HYLHZLQJ�3URILOHV�IRU�$FFXUDF\�DQG�3HUPLVVLRQ�&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


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.


Audit Tasks


security admin

Documents