SAP Cook Book

Top SAP Risks

By

Mr. Frank W. LyonsPresident

OfEntellus Technology Group, Inc.

Copyright Entellus Technology Group, Inc.

Copyright Entellus Technology Group, Inc. 1

Introduction..........................................................................................................................3Objective..............................................................................................................................3Scope....................................................................................................................................3Methodology........................................................................................................................3

Risks................................................................................................................................4Step - 1- Default IDs and Passwords.................................................................4Step - 2 - SAP_ALL...............................................................................................5Step - 3 - SAP_NEW.............................................................................................6Step - 4- Authentication Controls.......................................................................7Step - 5 - Key Transactions..................................................................................8Step - 6 - Customized Objects...........................................................................19Step - 7 - Customized Reports...........................................................................20Step - 8 - Customized Transaction...................................................................21Step - 9 - Customized Tables.............................................................................22Step – 10 - Configuration Risk..........................................................................23Step - 11 - Change Control Risk.......................................................................24Step - 12 - Administration Risks.......................................................................25Step - 13 - SAPStar Account..............................................................................26Step - 14 – Programming Standards.................................................................27Step - 15 – System Production Locks..............................................................28Step - 16 – Job Terminations.............................................................................29Step - 17 – Locked Transactions.......................................................................30Step – 18 – Validate User...................................................................................31Step - 19 – All Transaction Start Authority...................................................32Step - 20 – Authorization Groups.....................................................................33

2

Introduction

SAP is a very comprehensive integrated set of application modules, which are tied together based on a complex technical architecture. There are literary hundred of thousand transactions. Some of these are duplicated in separate modules in the case that you only implement select modules in the environment.

Objective

To mitigate the major risks within SAP that always appear to be present until an initial review is completed. The various functional transactions such as adding a vendor still have to be reviewed from two perspectives. One is verifying who has the authority to execute the transaction and match it up to their job responsibilities and the other is segregation of duties (SODs) that require audit’s attention to comply with regulation such as SOX.

Scope

The preliminary review effort is based upon our 20-step methodology, which looks at key risks in the environment.

Methodology

The 20-step methodology is as follows:

1. Default IDs in the system2. Use of default profile of SAP_ALL3. Use of default profile of SAP_NEW4. Authentication controls5. Control of several key basis transactions6. Controls over customized objects7. Controls over customized programs8. Controls over customized transactions9. Controls over customized tables10. Generic IDs11. Change control12. Obsolete/Inactive users on the system13. Protection of the SAP* account14. Programming standards for customized programs15. System production locks16. Job Termination17. Locked Transactions18. Validate Users19. All Transaction Start Authority20. Authorization Groups

3

Risks

Step - 1- Default IDs and Passwords

Audit Process

There are key defaults user accounts within the system. The most powerful is SAP* as this account is in the kernel with a default password of 06071992 or pass. The other accounts are:

DDIC 19920607 SAPCPIC Admin Earlywatch Support

To change the password of SAP* you have to add a user master record and change the password in all clients within the production instance. If the master account does not exist then the SAP* in the kernel with its password still exist and can be used to compromised the system.

Audit Effort

Run transaction SA38 and enter report RSUSR003 which will inform you if the passwords have been changed.

4

Step - 2 - SAP_ALL

The assignment of SAP_ALL is a powerful supplied profile within the system that provides the assigned user the ability to perform all transactions. This would provide the assigned user the capability to create a vendor, receive an item and make a payment, which does not meet the SOX regulatory compliance.

Another key account is DDIC and this account is used to change the SAP repository during a transport. This account is a dialog account with full power, which means that someone could sign onto this account interactively if they knew the password for this account. The DDIC account should not be used by anyone, as this accounts sole purpose is to update the repository during a transport. Therefore this account should be highly restricted and by changing the account to a system account you can reduce the exposure by not allowing anyone to logon interactively.

Audit Process

Use transaction SUIM and click three times to obtain the input screen for users by complex selection criteria.

Next enter SAP_ALL in the profile line.

Execute by clicking on the clock.

The results should be downloaded into a spreadsheet. The download can be accomplished one of two ways. By using the System menu and clicking on List and then Save or by going to the File menu and performing an Extract.

Risk Level 1 –High

The risk level is high because the assigned user has no segregation of duties and can compromise the system many ways,

Recommendation

Remove SAP_ALL on any production user.

DDIC should be aligned as a system account and not as an interactive user account where someone can sign onto this account and use it interactively.

5

Step - 3 - SAP_NEW

Another profile delivered with the system is SAP_NEW. This profile can be assigned to a user. The profile automatically updates the user’s profile when the vendor adds new authorization checks to the system. This would change the user’s authorities without any action by the Security Administrator or an approval by the Business Audit Process Owner. Therefore the profile SAP_NEW should never be present in the production environment.

Audit Process

Use transaction SUIM and click three times to obtain the input screen for users by complex selection criteria.

Next enter SAP_NEW in the profile line.

Execute by clicking on the clock.

The results should be downloaded into a spreadsheet. The download can be accomplished one of two ways. By using the System menu and clicking on List and then Save or by going to the File menu and performing an Extract.

Risk Level – High

By providing SAP_NEW to a user in the production environment you are effectively relegating your Security Administration to the SAP vendor. This posture could introduce segregation of duties issues as well as providing critical transactions to an unintentional user automatically

Recommendation

Remove all the SAP_NEW profiles from production.

6

Step - 4- Authentication Controls

Audit Process

Run the report RSPARAM that can be executed by first entering transaction code SA38 and then selecting this report. On this report there are many parameters but the login parameters define the authentication setting for the particular environment that you are reviewing. There are two settings for each parameter with one of them being the system default and the other is the user-defined parameter. The user-defined parameters are in force first and if it is not selected then the system default value is used.

Audit Effort

Evaluate the strength of the parameters to ensure good authentication controls.

These would include items such as: Password length Invalid attempts Password ageing Password construction rules

7

Step - 5 - Key Transactions

Several key transactions should be evaluated to see the number of users who are currently assigned to execute these transactions.

Transaction Risk – SU01

Tested the system to determine who has the capability to add or change a user with transaction SU01.

Audit Process

Use transaction SE17 to lookup the transaction code in table USOBT_C. You can use this same technique for any transaction in the system. The output will list all the objects associated with the transaction that you are reviewing. You can pick all the objects and their values but it would be best to pick one object with an activity value field.

Next you will execute transaction SUIM for complex selection criteria for users. You will have to click three times to get the input screen for the selection process after you execute SUIM.

Next you enter in the transaction code in the transaction line and the object under objects. Then click on values for the object and the system will change the input screen to reflect all the fields for that object. You can then enter the values. This is the same value that is required for the transaction to operate. By doing this you will find all the users that have this transaction code and the required objects. Use object S_USER_GRP with activity field value of 1 or 2 for transaction code SU01.

Download the list into a spreadsheet for later comparison to actual users job responsibilities and also for searching for SODs.

Risk Level – High

Someone with this level of authority can add or change a user master record and sign-on with his or her password and compromise the system of internal controls. The perpetrator may even be able to assign the user to a powerful role to further compromise the system.

Recommendation

Review the users that have this capability.

8

Make sure that an automatic audit report is generated to the Security Team and the Business Audit Process Owners to indicate that a user’s authorities have changed. This can be accomplished by running transaction SUIM for change documents or by running transaction SA38 and entering one of the RSUSRxxx reports.

9

Transaction PFCG

This transaction provides the ability to add or change a user’s role definition, which would provide them with their authorities in the system.

Audit Process

Use transaction SUIM and enter the transaction code and object S_USER_AGR with an activity field value of 1 or 2.

Risk Level– High

This transaction should be restricted to your Security Administrators only. Otherwise a user may be assigned inappropriate authorities.

Recommendation

Remove this authority from any other user other than the designative users. By provide an emergency ID that can be used by a special user or group so that in the case of an emergency proper action can take place quickly. The entire emergency user’s activity would be tract and reviewed by the Security Team within a reasonable time frame.

10

Transaction SA38

This transaction allows you to view all the programs in the environment and attempt to execute them by double-clicking the program.

This would include customized programs nomenclated with a Y or a Z. The last thing you would want to do is give someone in SAP the ability to execute a program that they are not authorized to run. Because of the way objects work on the system, you might not assign a specific transaction to a user to execute a program, but instead assign a key object to the user and allow them the opportunity to run a program that uses this object from transaction SA38.

Audit Process

Use transaction SUIM and enter the transaction code and object S_PROGRAM with an activity field value of 2.

Risk Level – High

By allowing someone to use this transaction you are providing a wildcard shortcut to all programs being called by a valid transaction. And you are providing a full inventory of the programs in the system, which a user can try to run by double clicking them.

Recommendation

Restrict the assignment of SA38 in production.

11

Transaction SE38

This transaction is even worse than SA38 because it allows you to not only run the program but you can edit them too. This is really a transaction for developers and Quality Assurance personnel in a pre-production environment.

Audit Process

Use transaction SUIM and enter the transaction code and object S_DEVELOP with an activity field value 1 or 2.

Risk Level– High

This transaction provides a way to potentially execute and edit a production program. If your production system locks ( SE06 and SCC4) are set so no changes are allowed this reduces the risk because edit changes cannot be made directly without going through a transport. But they can still see and execute any program by going around the transaction controls unless authorization groups (Can be set up for programs and tables) are established. The navigate button on the technical help screen also allows someone to run SE38 without being provided the transaction authority.

Recommendation

Restrict unauthorized users from SE38 by revising who currently has this authority.

Restrict the navigation button on the technical help screen,

12

Transaction SM59

The SM59 transaction allows someone to set up a remote destination or a RFC destination. This destination address function is heavily used by SAP in your environment to communicate properly. You can and should monitor all RFC setups and destination calls through the SM20 security log, which has to be set up with SM18 and SM19 and then reviewed by Security Administration.

Audit Process

Use transaction SUIM to check who has this transaction and object S_ADMI_FCD.

Risk Level– Medium

The operating system files for SAP can be inadvertently deleted or changed. All the parameters for authentication, logging and performance are available under the SAP shell prompt. In addition, critical files such as transports and database files are exposed to someone with this transaction authority, which includes a non-shadowed passwd file.

Recommendation

Review the list of users to ensure that they require this level of authority to perform their job responsible.

13

Transaction SE06

There are two key transactions at least that let you lock the production environment from unauthorized changes. These are SE06 at the local level and SCC4 at the environment level. Production locks are effective and they protect the production environment so that only transports can be used to change objects. The lock transactions should be symbolically provided to Security Administration to turn on/off the locks if necessary. It is symbolic in that a good Basis Administrator can easily get around these controls through another program or by directly accessing the database where the locks are stored.

Audit Process

Use transaction SUIM to check who has this transaction and object xxx

Risk Level – Medium

By changing the lock controls, programs can be modified to update any table in the database without effective detection.

Several action items need to be addressed to reduce the risk.

First, there must be a separate Database Administrator to set an audit record on table T000 and T000_0001, which correspond to SE06 and SCC4 locks.

Second, the SE06 and SCC4 need to be moved to Security Administration only.

Third, the Basis Administrators must have an emergency ID to allow them to perform an unlock in an emergency with all activity reviewed afterwards.

Recommendation

Several action items need to be addressed to reduce the risk.

First, there must be a separate Database Administrator to set an audit record on tables T000 and T000_0001, which correspond to SE06 and SCC4 locks.

Second, the SE06 and SCC4 need to be moved to Security Administration only.

Third, the Basis Administrators must have an emergency ID to allow them to perform an unlock in the case of an emergency with all their activities reviewed afterwards by Security Administration.

14

Transaction SM35, SM36 and SM37

These transactions are one of the batch administration transactions for controlling batch jobs. This is a critical area where good controls over the submitting of batch jobs are necessary to help ensure the overall integrity of the system.

Audit Process

Use transaction SUIM to check who has this transaction and object xxx.

Batch users are indicated with a BDC no.

Run RSUSR002 with transaction SA38

Check for transaction SM35

With objects:

S_BDC_MONIo Field BDCAKTI

Values DELE, FREE Lock, REOG

o Field BDCGROUPID Value *

Check for transactions SM64, SM36 and SM37

With objects:

S_BTCH_ADMo Field BTCADMIN

Value Y


With objects

S_BTCH_JOBo Field JOBACTION

Value DELE, RELE

S_BTCH_NAMo Field ACTIVITY

Value *

15


Generate a job log for all cancelled jobs o Ensure that the process owners are aware of the cancellations or the job

has been resubmitted.

Risk Level- Medium

The administration authority should be restricted to prevent unauthorized jobs from running under a special SAP ID that has too much authority.

Recommendation

Review the list of users and ensure that the users need this level of authority to perform their job function.

16

Transaction SM30

This transaction is one of the table maintenance transactions. Other transactions like SE16 or SM31 should also be checked on the system. .

Audit Process

Use transaction SUIM to check who has this transaction and object S_TABU_CLI with activity field and value of 2.

Risk Level - High

Editing tables directly should be restricted at all costs as a normal transaction should be used to perform the activity. If no or incomplete authorization groups are defined in the system, then direct update to tables is possible.

Recommendation

Review the list of users and ensure that the users need this level of authority to perform their job function.

17

Transaction – SM49 and SM69

These transactions allow a user to exit to the operating system and obtain a shell command prompt with command authority running as SAP.

Audit Process

Use transaction SUIM to check who has this transaction and object xxx

Risk Level– Medium

The operating system files for SAP can be inadvertently deleted or changed. All the parameters for authentication, logging and performance are available under the SAP shell prompt. In addition, critical files such as transports and database files are exposed to someone with this transaction authority, which includes a non-shadowed passwd file.

Recommendation

Restrict these transactions to the Basis Administration function.

.

18

Step - 6 - Customized Objects

Customized objects are allowed in SAP. These can be found in table TOBJT. Customized objects would mean that customized programs have been created so they can refer to the objects to see how to access the actual data for a user.

Audit Process

Use transaction SE17 to list off all objects in table TOBJT.

Risk Level - None

None but an indicator that customized programs exists and maybe transaction.

19

Step - 7 - Customized Reports

Customized reports are much more dangerous than objects because they have the privilege of signing onto the database and access to any table without restriction. This is because the programs, both SAP provided and especially the customized programs or reports, can insert, update and delete any table in the database by using the common ID (SAPR3 with the same SAPR3) which may go outside their intended purpose.

Audit Process

Use transaction SA38 to list off all the programs on the system including the customized or Z and Y type program.

Download these for future reference.

Risk Level – High

Customized reports (programs) should have a Quality Assurance review to ensure that the tables, which are declared in the front of program, make sense for the program’s intent. The QA group should also ensure that report programs do not insert, update or delete critical table entries. The QA group should look for programming standards to ensure an authority-check resides in these programs so unauthorized personnel cannot execute them. Test, fix or one-time programs should be removed after they have served their purpose

Recommendation

Set up adequate QA procedures to review and verify custom programs purpose.

All custom programs should be reviewed to ensure that they are still operationally needed.

20

Step - 8 - Customized Transaction

Customized Transactions are not as bad as customized programs and the only risk is the proper classification of exactly what is they purpose according to sensitivity or criticality.

Audit Process

Use SE17 and list off all the transactions on the system including the Y and Z transactions by using table TSTCT

Risk Level – Medium

A custom transaction may be sensitive or critical and the Business Owner should classify of them according to classification standards. Auditing would use the classified transactions to verify who had access to the sensitive or critical transactions.

Recommendation

Review the list of custom transaction for your system and classify them according to the client data classification scheme.

21

Step - 9 - Customized Tables

Customized tables are new tables that are deemed necessary by the client.

Audit Process

Use SE17 and list off all the tables in either table DD02T or DD09L.

Download the results into a file for later reference.

Risk Level – Unknown

The risk of these tables is predicated on the data within the table.

Recommendation

Review the custom tables and their data content to rank them according to the sensitivity or criticality standard and then classify the customized transactions that operate on them.

22

Step – 10 - Configuration Risk

Generic Ids are the curse of the industry. These IDs and their passwords are usually not formally assigned.

Risk Level – High

To deal with generic IDs we would want to eliminate as many IDs as possible. Next we would want to assign a Master Account Owner to the generic ID. This person would maintain a list of all the users that require the password. When someone on the list leaves or is move or promoted, then the password would be changed and the Master Account owner would update the list of authorized user.

Recommendation

Establish Master Account Owners for generic accounts.

23

Step - 11 - Change Control Risk

The change control process is called the transport management system (TMS) and uses transactions SE01 and STMS besides others.

Audit Process

Use SUIM to list off users that have this transaction authority and the object S_Transport with activity field value of 1 or 2.

Risk Level – High

If the system locks with SE06 are properly set then the only way to make a change to production is by using the transport management system. The individuals that have this authority may be the very developers or administrators that we are tying to restrict their change activity.

Therefore, we would want to establish a Transport Administration group. This should be a part of the QA group. The assignment to this group would aide in the setting up of proper segregation of duties.

Recommendation

Establish a Transport Administration group to perform all changes.

24

Step - 12 - Administration Risks

Execute report RSUSR006 with transaction SA38 to determine the number of user that have never signed onto the SAP system.

Users that do not sign onto the system in a reasonable time frame need to be disabled to reduce a potential hacking risk.

Audit Process

Report RSUSR006 should be executed using transaction SA38.

Be careful as the report can limit you hits. Be sure to expand you settings.

Risk Level – High

The reason the risk level is high is due to the assignment of the first time password to a new user. These passwords may be a commonly known for easy establishment to communicate to a new user. Sometimes everyone else would also have knowledge of his or her password since they once were also a new user. The report RSUSR006 displays these users and provides the intelligence to identify and then attempt to compromise the user’s authorities for their own purpose.

Recommendation

Lock users that have not signed on with a week

25

Step - 13 - SAPStar Account

The backdoor of the SAP system is a kernel ID called SAP*. This ID can be blocked by creating a user master record in each client so the password can be changed. And by setting the login/no_automatic_user_sapstar parameter in RSPARAM to 1. This in effect reduces the special privileges of this user account.

Audit Process

Run report RSUSR003 using SA38 to identify if the key account’s passwords have been changed.

Run RSPARAM and evaluate the setting for login/no_automatic_user_sapstar to ensure that it is set to 1.

Risk Level – High

The parameter reduces the powerful attributes of this account.

26

Step - 14 – Programming Standards

The backdoor of the SAP system is a kernel ID called SAP*. This ID is blocked by creating a user master record so the password can be changed and by setting a login/no_automatic_user_sapstar parameter in RSPARAM to 1. This in effect reduces the special privileges of this user account.

Audit Process



Risk Level – High


27

Step - 15 – System Production Locks

The backdoor of the SAP system is a kernel ID called SAP*. This ID is blocked by creating a user master record so the password can be changed and by setting a login/no_automatic_user_sapstar parameter in RSPARAM to 1. This in effect reduces the special privileges of this user account.

Audit Process



Risk Level – High


28

Step - 16 – Job Terminations

Audit Process

Run report RFVBER00 with transaction SA38 to verify that all update terminations are recorded and documented.

Use Detail Log and Only Terminated V1

Risk Level – High

All update terminations should be documented as to the reason why and rerun.

29

Step - 17 – Locked Transactions

Review the Blackout transaction list on the Magic Disk to ensure that sensitive transactions are locked in the production environment.

Audit Process

Run SM01 and review the locked transactions against the Blackout list.

Verify with SUIM that the users that have access to SM01 with object S_ADMI_FCD and field S_ADMI_FCD and value of TLCK. These are the users that can execute the SM01 transaction

Risk Level – High

Individuals with this level of authority can lock or unlock sensitive transactions.

30

Step – 18 – Validate User

Audit Process

List off all the users on the SAP system by using transaction SUIM.

Compare the list to an HR database of valid employees

Risk Level – High

Ensure that all the users on the SAP environment are valid users or consultants.

31

Step - 19 – All Transaction Start Authority

There are two levels of checks in SAP for executing a business process.The first is the transaction start object, which is S_TCODE. The second is the actual object being accessed such as the vendor master file F_LFA1_APP.

The risk is that some users may have access to start all the SAP transactions. This does not mean that they can run each transaction, as they would still have to pass the second authorization check against the actual object being updated.

These users can be checked for by using SUIM and looking for any user that has access to object S_TCODE and field TCD with a value of *. Audit Process

Run SUIM and list all the users with this authority

Risk Level – High

Individuals with all transaction start have segregation of duties issues.

32

Step - 20 – Authorization Groups

Authorization Groups can be assigned to both table and programs to further restrict access to a user or group of users that have the Authorization Group in their role definition.

Audit Process

First identify the key programs and tables on the system.

Second, review what authorization group they have been assigned to.

Use SE17 against tables:

TDDAT table authorization group assignments TBRG program authorization group assignments

Identify with SUIM all users that have update customizable tables with a &NC& authorization group. To accomplish this use SUIM with object S_TABU_DIS or object S_TABU_CLI with field activity with value of 1 or 2.

Then review all authorization groups assigned to critical tables using the same objects and each authorization group identified.

Risk Level – High

Authorization Groups further restricts the transactions such as SM16, SM30 or SM31 to update critical tables.

33

SAP Cook Book

Documents

Transcript of SAP Cook Book