Your SAP system often requires technical and functional system changes due to the dynamic nature of business. The implementation and application of these changes need to be properly controlled, managed, and monitored to avoid the risk of possible data corruption, inconsistency, and inaccuracy. In addressing this challenge of modifying system configuration, objects, and data to suit current business requirements, the SAP system provides a structured process called software logistics in the ABAP environment.

Change request and transport management are an integral part of software logistics processing in the SAP ABAP environment. Change requests are created when you carry out a new activity in customizing or configuration in the system. Transport management is the coordination of the movement of objects and configuration changes from the development system to the quality assurance (QA) system and then to the production system.

These 10 proactive security measures are aimed at safeguarding and protecting change request and transport activities processing in the SAP ABAP environment:

1. Build an administrative team for the software logistics process
2. Adopt and implement a three-tier SAP system landscape
3. Correctly set the system change options
4. Protect the system client maintenance table (table T000)
5. Ensure that only approved change requests are transported
6. Effectively control the use of Transport Management System (TMS) trusted services
7. Activate Secure Network Communications (SNC)
8. Control the extension of the authorization for the default user TMSADM
9. Appropriately maintain table TMSRCRI
10. Refrain from making changes to the current settings table

1. Build an Administrative Team for the Software Logistics Process

It is important to put together a formidable team in charge of organizing and managing change request and data transport processes in your enterprise. The team should consist of persons with technical and functional expertise. It is important to clearly define and document the different roles and responsibilities of the members of this team. You should properly segregate the assignment of roles and responsibilities to ensure that the entire process of making changes and transporting changes is well secured. The individual roles and responsibilities drive their respective authorization object assignment in the system. This administrative team should consist of developers, project manager, transport administrators, and members of the QA team.

• Developers: Responsible for releasing their individual tasks in the workbench organizer. The standard authorization for developers in the SAP system is S_CTS_DEVELO. The S_CTS_DEVELOP authorization disallows the independent creation or release of change requests.
• Project manager: Plays a critical role in the areas of definition and organization of a project. The project manager verifies the composition of a change request before it is released and ascertains that the change request was successfully imported into the target system. The standard authorization for the project manager role in the SAP system is S_CTS_PROJEC. The S_CTS_PROJEC authorization allows a user to create, modify, and release a change request.
• Transport administrator: Responsible for carrying out the transport task by activating change request import via the TMS or transport control program (tp), which is an operating system program that performs export and import for objects between SAP systems. The standard authorization for the transport administrator role in the SAP system is S_CTS_ALL. The S_CTS_ALL provides all authorizations for request administration and change and transport system (CTS).
• QA team: Responsible for carrying out comprehensive functional unit and integration testing of the components for the change request in the QA system.

Furthermore, it is important to state that the assignment of TMS authorizations such as S_TMS_READ (read authorization for TMS), S_TMS_WRITE (write authorization for TMS), and S_TMS_RFC (RFC authorization for TMS) to users should be well controlled.

2. Adopt and Implement a Three-Tier SAP System Landscape

The system landscape consists of a set of systems that share certain attributes such as customizing and repository objects through a transported change request. To ensure data integrity and consistency, SAP strongly recommends that a three-tier system landscape be implemented in a production environment, including the development, QA, and production systems. The need to safeguard business and application data via authorization concepts and client concept drives the three-tier SAP system landscape. Authorization concepts control the capability of a user to create, modify, or delete change tasks and requests. The client concept helps enforce data security by safeguarding business and application data via the separation of business data based on clients.

Furthermore, it is possible for the systems in the SAP system landscape to have more than one client. For example, the QA system can have clients 210, 220, and 230 with a particular client (say client 210) as the master test client. This architecture allows you to have multiple test clients in a test system. You can move data such as customizing, user master records, and authorization profiles from one client to another via the local client copy function available via transaction SCCL. The system landscape helps guarantee the consistency of repository objects and the security and availability of the production system. Furthermore, it is a good security practice to use a common transport directory for all systems in your SAP system landscape and assign all systems that share the transport directory to a dedicated and secured local area network (LAN). A typical three-tier SAP system landscape is shown in Figure 1.

Figure 1

Three-tier SAP system landscape

You should adopt the following measures to strengthen the security of the software logistics process in ABAP via the implementation of a three-tier system landscape:

• Restrict the access of developers to production data. In a scenario in which the developer needs to test a change request with production data, you should copy the needed data into the QA system and test it there. 
• Under no circumstance should you correct errors in the QA system. If you encounter errors during the testing phase (in the QA system), it is a best practice to make the changes in the development system and reimport it into the QA system for testing.
• Effectively control the source and destination of change and transport data
• Comprehensively track changes for tracing and audit purposes
• Effectively monitor when changes are transported into the productive system

3. Correctly Set the System Change Options

The system change option functionality helps protect the system against illegal changes by defining whether repository objects are globally modifiable. Use transaction SE06 to reach the system change option functionality (Figure 2).

Figure 2

System change option settings

If the system change option is set to globally modifiable, you can further define if each software component, namespace, or name range can be modified or not. A software component is a group of dedicated developments classes and its possible system change options include those shown in Figure 3.

Figure 3

System change option for software components

• Modifiable: Permits modifications
• Restricted Modifiability: Permits the creation of only new objects as non-original objects
• Not Modifiable; Enhanceable Only: Does not permit changes, but objects can be enhanced via the enhancement framework only
• Not Modifiable; Not Enhanceable: Does not permit changes and enhancements

The possible values for the system change option for namespaces and name ranges developed by SAP customers and partners are Modifiable and Not modifiable (Figure 4).

Figure 4

System change option for namespaces and name ranges

4. Protect the System Client Maintenance Table (Table 000)

Create and maintain SAP system clients in table T000 and access the entries by entering the table name in transaction SE16. A client is a self-contained entity in the SAP system in terms of organization, business, and data. Changes to customizing tables or objects can apply to a particular client (client-specific) or to all clients (cross-client). Examples of client-specific data are company codes, plants, and storage locations. Examples of cross-client customization settings are public holiday calendar, definition of price list conditions, and printer controls. The entries in this table allow you to define and enforce controls on where changes are made and ensure that the change is recorded to change requests. You can also maintain the entries in Table T000 via table and client maintenance transaction codes such as transactions SCC4, SM30, and SM31. Some of the sensitive and security-critical attributes of this table are shown in Figure 5.

Figure 5

Entries in table T000 (system client maintenance table)

CCCATEGORY (Client Control: Role of Client)

This feature defines the role of the client in your SAP system. You can see the roles of the client, which you can access via transaction SCC4, in Figure 6. The role assignment of a client plays an important role in the security of the client and it is even of high priority for the production system. The production client should be flagged as such because production clients are protected from client copy tools including the copy by transport request functionality that is accessible via transaction SCC1.

Figure 6

Options for client role

CCCORACTIV (Changes and Transport for Client-Specific Objects)

This feature controls whether changes to tables are recorded within the transport system. Possible options for this attribute, which you can view in transaction SCC4, are shown in Figure 7.

Figure 7

Options for changes and transport for client-specific objects setting

• Changes without automatic recording: Permits changes to customizing tables, but the changes are not automatically included in change requests
• Automatic recording of changes: Permits changes to customizing tables and prompts to include the changes in a change request automatically
• No changes allowed: Does not allow users to make changes to customizing tables
• Changes w/o automatic recording, no transports allowed: Permits you to make changes to client-specific customizing tables. However, manual or automatic transport of these changes is not allowed.

CCNOCLIIND (Maintenance Authorization for Objects in All Clients)

This attribute controls the client in which you are permitted to maintain cross-client objects. Possible entries for this attribute, via transaction SCC4, are shown in Figure 8.

Figure 8

Options for cross-client object changes setting

• Changes to Repository and cross-client Customizing allowed: Permits changes to cross-client customizing tables and the SAP repository and prompts to include the changes in a change request automatically
• No changes to cross-client Customizing objects: Permits changes only to SAP repository objects and prompts to include the changes in a change request automatically
• No changes to Repository objects: Permits changes to cross-client customizing tables only and prompts to include the changes in a change request automatically
• No changes to Repository and cross-client Customizing objs: Does not permit cross-client changes

CCCOPYLOCK (Protection Regarding Client Copy Program and Comparison Tools)

This attribute controls the overwriting of the current client by the client copy program or used as the basis for client copy or customizing comparison. Possible entries for this attribute via transaction SCC4 are shown in Figure 9.

Figure 9

Options for client copy and comparison tool protection setting

• Protection level 0: No restriction: The client can be overwritten
• Protection level 1: No overwriting: Does not permit the overwriting of the client by the client copy program 
• Protection level 2: No overwriting, no external availability: This option offers additional protection by disallowing read access from another client during client copy or customizing comparison     

CCNOCASCAD (Client Control: No Client Cascade for Upgrade Import)

This attribute controls whether the client is overwritten during an upgrade exercise. If activated, it is impossible to work actively in the client after an upgrade.

CCIMAILDIS (Client Control: CATT and eCATT Authorization)

This attribute controls the running of Computer Aided Test Tool (CATT) test cases, extended Computer Aided Test Tool (eCATT) test scripts, and eCATT test configuration. It is important to note that executing CATT and eCATT can lead to large database changes and as such should not be allowed in a production client.

CCTEMPLOCK (Client Control: Indicator That Client is Temporarily Locked)

This attribute controls whether the source and target clients are locked against logon attempts during the client copy process. The activation of this setting can help prevent data inconsistency in the target client.

Obviously, illegal maintenance of any of the aforementioned attributes can expose the entire software logistics process to great security risks. Hence, it is a best practice to safeguard this table against malicious maintenance, especially in the production environment, by adhering to the following tight security measures:

• Implement a procedure and policy that guides the creation and maintenance of clients
• Restrict maintenance access via authorization object S_ADM_FCD to only system administrators
• Ensure that the assignment of table maintenance- and client maintenance-related SAP transactions such as SCC4, SM30, and SM31 is well controlled
• Define a value of 02 and 03 for the activity field of the authorization object S_TABU_DIS
• Define a value of SS for the authorization group field of authorization object S_TABU_DIS
• Define a value of X for the client-independent maintenance field for the authorization object S_TABU_CLI

5. Ensure That Only Approved Change Requests Are Transported

The QA approval procedure is a workflow-like control aimed at ensuring that only approved transport requests are forwarded to the production system. To enhance the data quality and ensure the availability of the production system, it is a best practice to implement a TMS QA approval procedure. The QA approval procedure is based on the transport mechanism of a typical three-tier SAP system landscape discussed earlier in this article. Normally, when a change request is released and exported from the development system to the QA system, the import buffer (change requests in the queue) of the QA system is updated.

After successfully importing the change request into the QA system, the import buffer for the production system is then updated. When a QA approval procedure is configured, the import buffer of the production system is deactivated. The implication therefore is that the import buffer is not automatically forwarded to the production system until the change requests are activated by approving the content of the buffer. When the QA approval procedure is implemented in the QA system, it is important to note that for a transport request to be imported into the production system, all the defined QA approval steps must be executed and the request must be approved. If the execution of a QA approval step is not successful, the whole request is not approved.

During the setup of the QA system, the number of QA approval steps to be executed is defined for each request. When requests are imported into the QA system, the QA worklist is updated. All requests in the QA worklist in a system must be checked for each approval step activated in the system. The approval steps in the standard SAP system, accessible via transaction STMS, are shown in Figure 10.

Figure 10

Approval steps in the quality assurance approval procedure

By default, both the approved by department and approved by request owner approval steps are deactivated while approval by system administration is activated.

6. Effectively Control the Use of TMS Trusted Services

Using TMS trusted services, which is standard in the SAP system, helps streamline the logon procedure in the SAP system landscape, but it should be used with security consciousness. TMS trusted services helps prevent multiple logon on different clients when transporting changes. The functionality eliminates the need to log on to the target system after you are logged on to a client in one of the systems in the transport domain, simplifying the management of a large number of SAP systems. When TMS trusted services is implemented in the SAP system landscape, it is activated for the whole transport domain. This capability allows the system to carry out an authorization check in the target system for the logged on user in the source system. A user is only prompted for his logon details in the target system if the user does not have appropriate authorization in the standard client 000 of the target system. You can activate TMS trusted services via transaction STMS in the SAP system acting as the transport domain controller in your SAP system landscape (Figure 11).

Figure 11

Activate TMS trusted services

The downside of implementing TMS trusted services is that a security flaw in any one of the client systems can be a security threat to the entire system landscape. Hence, it is important for you to ensure your security procedure and policy permits you to use TMS trusted services before you implement it. Furthermore, TMS trusted services should only be activated if the user names are identical in all clients in all SAP system of the transport domain. 

7. Activate Secure Network Communications

The communication process between SAP systems in the transport domain is handled by Remote Function Calls (RFC). RFC connections are created when the TMS is configured. For every target system in the system landscape, RFC connections exist for read access and write access. SNC plays an important role in safeguarding the RFC connections used by the TMS by guaranteeing data privacy and data integrity. This ensures that when data is transported between the source system and the target system, it is encrypted and protected against data manipulations. Acting as the transport domain controller, you can use transaction STMS to activate Secure Network Communication (Figure 12).

Figure 12

Activation of Secure Network Communication protection

8. Control the Extension of the Authorization for the Default User TMSADM

The user TMSADM is automatically created when you initialize the TMS. By default, this RFC user has only read access in the TMS and can only perform transport management activities that are not sensitive and security critical. Some of the standard tasks that can be performed by the TMSADM user account include the display of the import queue and the distribution of TMS configuration.

However, certain scenarios might necessitate the extension and provisioning of more authorization to the TMSADM user to perform specific security-sensitive tasks such as scheduling an import in the TMS. The provisioning of more authorizations for the TMSADM user can make the systems in the SAP system landscape vulnerable to attack by an unknown user. Hence, the extension of the authorization of the default user should be properly controlled. Also, you can reset the user TMSADM account to the default authorization for security reasons or due to configuration damage via transaction STMS (Figure 13). The system produces a dialog box asking you validate the request to reset the TMSADM user account (Figure 14). Click the Yes button.

Figure 13

Regeneration of user TMSADM

Figure 14

Confirmation for the reset of user TMSADM

9. Appropriately Maintain Table TMSTCRI

Table TMSTCRI allows you to protect defined objects from changes via import. For objects that have corresponding entries in table TMSTCRI, changes to these objects in transport requests are not allowed by the target system. You can maintain table TMSTCRI via transaction SM30 or SM31 (Figure 15). You can also maintain the table directly via transaction STMS_TCRI (display/maintain table TMSTCRI) in the domain controller system.

Figure 15

Entries in table TMSTCRI

10. Refrain from Making Changes to Current Settings Table

The fact that making changes in the production environment is not encouraged cannot be over-emphasized. However, some customizing changes (data-only customizing changes) do not come as a change request as they are performed directly in the production system. This is because the changes are done frequently and they do not necessarily need to go through comprehensive testing and does not affect the business flow customizing objects. Examples of such data include exchange rates, posting periods, interest rate, and insurance premium. 

The current settings functionality in the SAP system allows you to carry out customizing changes that are not subject to a change request. Even though changes to client-specific objects are not allowed, you can change the current setting in a production client without it being recorded automatically. The standard current settings for an SAP system is defined in the CURSETTING field of table OBJH. You can see it in the view cluster SOBJ. The use of current settings in a production system requires that:

• Client role is defined as production
• Cross-client object changes is activated with the option No changes to repository object and cross client customizing object
• Changes and transport for client specific objects is activated with the option No changes allowed

To ensure optimal security of the software logistics process, SAP recommends that customer changes should not be made to the current settings table (table OBJH).

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.