To establish internal controls, you need to define and document security policies and procedures that clearly state what should be done, how it should be done, when it should be done, and by whom it should be done.In an integrated system such as an SAP ERP system, processes are closely related, if not totally interwoven, and information is centrally processed. A security flaw at any stage is capable of undermining the integrity of the system.

SAP security policies are made up of a set of standards and procedures that are required for implementing security and control in an SAP environment. The essence of SAP security policies and procedures is to keep users abreast of their obligations, especially as they relate to transaction processing, access control, management, and system administration in SAP systems.

I’ll point out the 12 key subject areas in which you need to define security policies and procedures in your SAP system.

1. User Management

Owing to the vital role users play in the operation of the SAP system and the fact that they could perpetrate illegal acts, you need procedures that guide the request, creation, and maintenance of user accounts. Tools such as directory services, user management engine (UME), and central user administration (CUA) are designed to ease and centralize user management in several logical systems. You need to pay attention to the type of user in question because it affects the attributes defined for such a user. For example, you should define an appropriate validity period for temporary access requests.

User accounts are subject to maintenance for one reason or another, and the security policy should clearly state what should be done in diverse cases in which a user account becomes inactive — for example, as a result of a resignation or vacation. This is to ensure that users don’t remain assigned to a particular role indefinitely when they don’t need to be. Having a policy that defines naming conventions for user accounts and different user groups is essential. It helps minimize record duplication, thereby enforcing control. For instance, say an employee’s identification number cannot be the same as another’s. This would make it difficult to have duplicate user accounts if the employee identification number is used as the user ID.

The concept of identity management is tightly integrated with user management in the SAP system because it borders on the management of the life cycle of a user account from the creation to the point where the user no longer needs to connect to the system. Single sign-on (SSO) plays an important role in simplifying user management and enforcing security because users need to remember a single password to access all systems in the landscape. Secure Network Communication (SNC), SAP log-on tickets, pluggable authentication services, Secure Sockets Layer (SSL), and x.509 certificates are all SSO technologies that can be implemented for SAP systems. The use of cryptography is legally controlled in some countries, hence, the security policy must not only be clear on the SSO mechanism that should be used, but also make provisions for legal constraints associated with the use of cryptography.

User management in an environment in which you have the employees of your customers and vendors accessing your systems can be challenging. You need to address how user maintenance activities are carried out in such a scenario. To ease user maintenance (e.g., password reset or account unlocking) in such a scenario, it is best practice to leverage an identity federation technology such as Security Assertion Markup Language (SAML), which is an industry standard XML mechanism for data authentication, authorization, and security. You should design appropriate forms to address the various aspects of user management activities and incorporate them into the security policies and procedures.

2. Password Management

The SAP system has a table, USR40, that houses forbidden passwords (Figure 1). The security policy should explicitly state which passwords are forbidden. The idea behind the USR40 table is to prevent the use of easily guessable passwords. The list of forbidden passwords can include your company name, 123, ABC, XYZ, and so on.

Figure 1

Table USR40 shows forbidden passwords

Coming up with passwords, especially in an SAP environment where password complexity can be enforced, can be a little frustrating. There should be security policies in place that help ensure password complexity. You can use a good number of SAP system parameters to enforce password controls such as password expiration time, password history, and character combination.

The fact that user account details should be kept confidential must be emphasized in the security policy. No excuse should be tolerated for fraud committed as a result of user account impersonation. I have seen users give different excuses when they face a disciplinary committee as a result of fraud allegedly committed because they let out their user account details to a colleague to allow the colleague to perform certain tasks for them. The system recognizes the logged-on user so that person is responsible. The security policy can also contain a clause stating that passwords cannot be shared among users.

Because users are centrally managed in the SAP system, security policies and procedures should clearly state how users’ passwords are reset on request and eventually communicated to the requester. It is not good practice to have a generic, trivial, and common password for newly created user accounts because the security of the system can be compromised. The security policy should also address how initial passwords are created. Initial passwords should not be trivial, but instead should be system-generated and sent in a secure and encrypted format to the user.

It is good practice to deploy authentication technologies such as SSO, especially in an environment with multiple SAP and non-SAP systems, with each having its own password policy. Consider a scenario in which users must change their passwords for systems A, B, and C after 30 days, 60 days, and 90 days, respectively with varying password complexity requirements. The consequence is obvious — the users are vulnerable to forgetting their passwords or becoming confused as to which password is for which system. You can implement SSO to allow users to authenticate with a single password for all the systems. SSO reduces security administration tasks such as password reset. You should make provisions for the system parameter, log-on, and password change for SSO.

3. Authorization Management

In SAP systems, access rights are managed using authorization concepts. The objects that drive the authorization concept include authorization objects, authorization object fields, authorization fields, profiles, and roles. For a user to effectively work within the SAP system, he has to be assigned appropriate roles and authorizations. Authorization is an authorization object with values assigned in the different object fields. Security policies in an SAP environment should address the issue of who can maintain users’ roles and profiles. This is important for enforcing segregation of duties (SoD) associated with managing user accounts, which is often not respected by the core IT team. The core IT team sometimes has the notion that user maintenance is a function under system administration, especially in an uncontrolled environment. As a result of this, they assign almost all profiles that have to do with user maintenance to themselves. This can lead to the abuse of these profiles and consequently expose the system to undue security risk and control weakness. Where possible, management should ensure that a security and controls unit exists that is saddled with the sole responsibility of managing user master records.

The security policy should state the frequency at which standard reports such as RSUSR100, RSUSR101, RSUSR102, RSUSR005, audit logs, and audit reports are reviewed and by whom with the aim of managing and controlling SAP authorization. Report RSUSR005 displays users with critical authorizations (Figure 2). Reports RSUSR100 (Figure 3), RSUSR101 (Figure 4), and RSUSR102 display change documents for users, profiles, and authorizations, respectively.

Figure 2

Report RSUSR005 shows a list of users with critical authorizations

Figure 3

Report RSUSR100 shows change documents for users

Figure 4

Report RSUSR101 shows change documens for profiles

It should also state under which conditions these reviews should be done. System maintenance activities such as a system upgrade often bring new security definitions that can serve as a catalyst for the review of existing security policies. For example, parameters such as login/min_password_digits and login/min_password_letters (which I’ll talk about more in the “5. System Security Parameter Setting” section) became available in SAP NetWeaver Application Server 6.10. An upgrade from a lower version to that version or higher requires a review of the security policy as it relates to these parameters. Exceptional conditions might include a review after a system go-live, major system upgrade, major migration activities, organizational restructuring, business process re-engineering, or merger and acquisition. You should address the submission and review of an exception report on what individual users can do in the system in the security policy.

4. Master Data Management

Master data forms the bedrock of transaction processing, analysis, and maintenance. Examples of master data include customer, vendor, material, pricing, and employee. You need to make a conscious effort to ensure that master data is not duplicated and follows a naming convention. The risk of having duplicate business partner accounts is that transactions may be posted into the accounts mistakenly by different users (probably in different departments), thereby leading to unnecessary but avoidable reconciliation of business partner account balances. The security policies and procedures must explicitly state the naming convention adopted by the organization. You should also define a set of approvals before master data is created in the system. This provides an avenue to independently cross-check the details of the master data before it is created.

Modifications to master data are inevitable as master data details are dynamic. There should be policies and procedures that state how to handle a request for changes to master data. You should also encourage a periodic review of modifications to master data. This can be in the form of signing off master data changes request forms and exception reports generated as part of the month-end closing activities. The following reports and transactions provide information about modifications to the master data:

• RFKABL00: Vendor master data (Figure 5)
• RFDABL00: Customer master data
• MM04: Material master data (Figure 6)
• RFDKLIAB: Credit management
• VK12: Pricing master data

Figure 5

Report RFKABL00 shows changes to the vendor master data report

Figure 6

Transaction MM04 shows changes to the material master data report

Furthermore, the security policy should encourage the periodic review of reports that ensure that the master data in the system are current and their details are still relevant for transaction processing. These reports include:

• RFKKVZ00: Vendor master data
• RFDKVZ00: Customer master data
• RMMVRZ00: Material master data (Figure 7)
• VK13: Pricing master data

Figure 7

Report RMMVRZ00 shows a material master data list

5. System Security Parameter Setting

A number of parameters exist that help to enforce control in the SAP system. You can generate the details of each parameter using transaction RZ11. Also, you can access an overview of these parameters by running the RSPARAM report. Some of these parameters have security implications, so you need to include them in your policy. These parameters come with default values and settings that might not be effective based on the SAP environment. For example, the default value for rdisp/gui_auto_logout is 0. This setting means that a user is not automatically logged out of the system after a period of no input at the GUI. However, a recommended value of 1,800 ensures that the system logs out a user if no input is made at the GUI after 1,800 seconds. This represents a laudable security control especially for users who do not log out of the system when they are not using the system.

Some of these system parameters are enumerated below:

• Auth/rfc_authority_check: Defines how object S_RFC is checked during Remote Function Calls (RFC)
• Rdisp/gui_auto_logout: Defines the number of inactive seconds after which a user is automatically logged out of the system
• Rec/Client: Activates or deactivates automatic table logging. Logging changes impairs system performance because it uses a considerable amount of memory resources. You can analyze log data based on who made a change, what was changed, and when the change was made.
• Login/failed_user_auto_unlock: Activates or deactivates the automatic unlocking of locked users at midnight. It is best for the system or user administrator to unlock locked users.
• Login/fails_to_user_lock: Defines the maximum number of unsuccessful logon attempts before the system locks the user. An entry is recorded in the system log.
• Login/fails_to_session_end: Defines the number of times a user may enter a wrong password before the login session is terminated
• Login/min_password_lng: Defines the minimum password length
• Login/password_expiration_time: Defines the number of days after which a password must be changed
• Login/no_automatic_user_sapstar: By default, the SAP system is installed with a super user master record called SAP*. If this master record is deleted, the system allows a user to log on with a password of PASS for the SAP* user.
• Login/min_password digit : Defines the minimum number of digits (0-9) in a password
• Login/min_password_letters : Defines the minimum number of letters (A-Z) in a password
• Login/min_password_special : Defines the minimum number of special characters in a password. These special characters include (), !, , $, %,:,’, “, ;, =, &, #, },],{,[, >, and <.
• Login/min_password_diff : Defines the minimum number of differing characters from previous password

6. SoD

SoD forms part of the requirements of many regulations. The idea is to prevent the concentration of authority to carry out critical activities in the system. SoD is closely interwoven with user management, especially as it relates to roles and profile assignment. When a user who creates a goods receipt for supplied items is also given the profile to create invoices, control becomes a serious issue because the procurement process can be compromised. Ideally, an incompatible SoD matrix should exist as part of security policies and procedures that states which transactions are critical and should not be assigned to a user by virtue of security and control. You can see a sample SoD matrix in Figure 8.

Figure 8

SoD matrix

You should review the SoD matrix at defined intervals. The main tool used to manage and enforce SoD in SAP systems is SAP BusinessObjects Access Control, though third-party tools exist. Regardless of what tool you use to enforce SoD, the use of the tool should be controlled.

The security policies and procedures should state under which circumstances SoD conflict is allowed, the extent, and how it is handled. If you have an SoD issue in which a user can maintain a bank account and can also post incoming payments, there is a potential risk that the user can perform unauthorized maintenance of a bank account and post incoming payments in his favor. The key to developing effective authorization controls into business processes as it relates to SoD is to follow a risk-based approach. This risk-based mechanism involves sequential steps and best practices, including risk identification, rule building and validation, risk analysis, risk remediation, risk mitigation, and continuous compliance. These activities are performed by key players such as business process owners, security administrators, auditors, and SoD rule keepers so the security policy and procedures must clearly state their individual responsibilities.

7. Delegation of Authority

Another provision that has to be made in a security policy is the delegation of authority.When users go on leave, the job does not go on leave. Job functions or roles are delegated to an acting personality. In most cases, profiles are inherited. If not properly reviewed, delegation of authority can lead to SoD conflicts. The rationale behind delegation of authority must be spelled out clearly in the security policy. Because delegation of authority involves profile reassignment, you need to spell out when to assign and remove privileges in the security policy. To control delegation of authority, it is also important to define the number of days of absence under which a user’s responsibilities will be designated in the security policy.

8. Remote Access

SAP routers are configured to provide firewall and security services at the application level. As a matter of fact, SAProuter configuration is mandatory for getting support from SAP. You should also configure a hardware firewall to use in conjunction with SAProuter to strengthen the security of the SAP system. For remote connection, dedicated IP addresses are maintained in the SAPROUTTAB, a configuration file that contains the IP addresses and address patterns that are either allowed or denied access to a network. Because of support issues, support and service organizations are granted remote access to the system. In more critical instances, SAP can request access to the system to resolve some issues.

Note which people or organizations are allowed to provide remote support to the system and the extent of access and support. You also need to control remote connection information such as IP addresses, usernames, and passwords that are divulged to support organizations. Furthermore, security policies and procedures must be clear on the definition and maintenance of SAPROUTTAB, remote and open connection monitoring, and starting up and shutting down of SAProuter.

Aside from making provisions for the security of remote connection for support purposes, it is best practice to implement security infrastructures that allow employees, customers, and vendors to connect remotely and securely. This is important for employee self-service, B2C, B2B, and cross-system scenarios. SAP systems support security features such as Secure Network Communication (SNC), SSL, Secure Store and Forward (SSF), and Digital Signatures and Envelopes.

SNC is an encryption tool that allows you to enhance the security of your SAP system by providing an interface to implement additional security features that are not necessarily provided by SAP, such as smartcard. SSL secures communication between SAP servers (e.g., SAP NetWeaver AS and Internet Transaction Server) by encrypting HTTP protocols, thus allowing the transfer of confidential data over the Internet. SSF allows data and document security before and after dialog transactions such as data transfer via the Internet, electronic ordering, and invoicing. Security policies and procedures should guide the use of these security infrastructures especially as they relate to the encryption mechanism and data transfer.

In a service-oriented architecture (SOA) landscape, in which business processes are service-driven using heterogeneous distributed systems, you need to have a Web services security infrastructure, such as SAML. SAML allows secured authentication and remote connection between service providers and service consumers via a profile used for identities authentication and access rights management.

Security policies and procedures should guide remote connection authentication and remote connection access modes (e.g., VPN, Internet Transaction Server, and remote access server) especially relating to what is allowed and under what condition.

9. Interface Systems

The fact that the SAP system is intended to integrate all functional areas of a system does not undermine the existence of third-party applications that are in most cases integrated with the SAP system. The number of third-party applications integrated with the SAP system varies depending on a number of factors such as availability of funds and complexity of business processes. The integration of an SAP system with third-party applications has its own attendant risks because it often involves the upload of files via interface programs. Uploading external files and data exposes the system to data corruption and inconsistencies, so you need to define a control to guide the upload. For example, consider making policies that state that all files uploaded into the SAP system via interface programs must be in a format that is not editable, such as .csv and not .txt.

10. Disaster Recovery

This involves the processes and procedures on how to get back to work in the event of a disaster. A disaster recovery strategy is intended to guarantee data security and availability at a defined point in time. It entails the setup of a disaster recovery site in a location that is different from the primary operation site. The security policy must make provisions for the documentation, testing, and periodic review of disaster recovery procedures to ascertain its effectiveness and currency. A committed set of individuals should be responsible for the design and implementation of disaster recovery plan.

Furthermore, the security policy should make provisions for the amount of acceptable data loss (recovery point objective) and the amount of time and service level within which business processes must be restored after a disaster (recovery time objective). Appropriate procedures must exist to automatically redirect users to the disaster recovery site in the event of a crash that requires the activation of disaster recovery. You need to clearly define backup policies, procedures, and schedules. You should carry out restore and recovery tests at defined intervals to ensure that backups are logically and physically usable when data loss occurs. You should also state a realistic mean time to recover (MTTR) from failure in the security policy.

11. Change Management

A typical SAP system architecture consists of the development, quality assurance, and production systems. This architecture discourages making modification directly on the production system. The production system should be configured in such a way that direct modification in the production environment is impossible. This setting must be explicitly stated in the security policy. You can perform the configuration for this via transaction SCC4. When there is a request for change, a control process must be in place that objectively reviews the impact of such changes on all dependent business processes and end users. Because modifications affect critical tables in the SAP system, security policies should make provisions for tracing and logging of changes to critical tables. The development and quality assurance systems are also important and need to be secured appropriately. Your security policy should address access rights, modification, and data composition of the non-production systems. Furthermore, it is possible to erroneously delete critical data in the production environment via uncontrolled use of certain reports (e.g., SAPF019, SAPF020, and SAPF023). To guard against this, you should flag company codes that are used in the SAP system as productive. The security policy should address the flagging of productive company codes in the SAP system.

12. Incident Management

A defined incident management system allows the tracking of the user’s issue, thereby enhancing the performance of the help desk function and eliminating productive downtime. When calls are made, they should be logged and tracked until the call is closed. Some calls might require the help desk attendant to ascertain the true person logged in as the user making the call. For example, if a user forgets his password, this is reported to the SAP system administrator for reset, but the administrator needs to be sure it is the right person. In a typical SAP environment, this is usually done through phone calls or email. You should allow the administrator to ascertain the true personality of the user making the claim. It is expected that passwords are sent in an encrypted format as defined in the security policy.

It is recommended to implement password recovery functionality provided by SAP NetWeaver identity center, which allows users to recover forgotten passwords without assistance from the system administrator or help desk attendant. This approach reduces the administrative burden and increases security and control. Furthermore, it is best practice to leverage form-based authentication technology, especially when logging on from a Web browser. Form-based authentication is an authentication mechanism that offers the capability to customize the logon environment based on defined authentication information and requirements. This technology allows users to provide not only their user name and passwords, but other information such as date of birth and email address. The additional information that should be provided must be defined in the security policy where applicable.

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.