In previous article we told a lot about security of ERP systems. Now we want to talk about ways to protect them.

Protection of ERP systems is a challenge. A good comprehensive project may take years to be completed, especially when dealing with large landscapes. However, it is worth investments. Here are some basic steps that will help you to securely design your SAP implementation when you are in the planning stage. You can also apply this methodology to protect your systems from the most common attacks.

1. Protect from external attacks, disable insecure services

Any more or less complex application has a large functionality that is needed in general, but unnecessary in particular cases. Almost all this functionality in a typical ERP system is enabled by default.

As usual, SAP installation includes approximately 1500 various web services, which are available remotely on behalf of any registered user, if the service is enabled by default. Besides, about 40 services are accessible even to anonymous users. Some research papers pointed out 13 critical services. As mentioned above, these ones are only basic services.

We recommend that you apply recommendations from the guideline mentioned above as soon as possible – disable all services accessible to anonymous users, analyze which of the installed services are necessary, and additionally restrict the access by implementing authorization checks.
The architecture of SAP system should include a web-based proxy (SAP Web Dispatcher) that will restrict access to all unnecessary services from outside and allow access only to the necessary ones.
The SAP Web dispatcher lies between the Internet and your SAP system. It is the entry point for HTTP(s) requests into your system, which consists of one or more SAP NetWeaver application servers. The SAP Web Dispatcher therefore contributes to security and balances the load in your SAP system.

Additional information about SAP Web Dispatcher you can find here.

2. Apply SoD principles

SAP solutions have various functional opportunities, which are implemented through programs, transactions, and reports. The access to these objects should be strictly regulated based on the authorization values defining users, methods, and objects, allowed for access. Access to critical actions (e.g., access rights to modify transactions or to read any tables) enables users to perform attacks on SAP systems, escalate their privileges or steal critical data.

Segregation of Duties (SoD) is a security method to prevent conflict of interests, i.e., to avoid two of more access rights which — being granted together — may give rise to a risk of fraudulent actions (e.g., a right to create and to approve a Payment Order).

The first step is to minimize the number of users with SAP_ALL profile or ones having access to critical transactions such as SE16, SM59, and SE38. As the next step, apply SoD controls, at least ones mentioned in the ISACA guidelines.

3. Separate development from test and check for vulnerabilities

To protect from malicious developers, first, design separation between test development and production infrastructure and then control all the transport requests from development to production. It seems easy; however, the matter is what exactly should be controlled. To securely architect separation between test development and production systems, you should be sure that there are no connections with stored credentials from systems with High priority (Production systems) to the systems with low priority (Development systems). These connections are only allowed to store technical connectivity configuration and authenticate the user for each access.

As you may know, OWASP (Open web-application security Project, focused on improving awareness in web application security) provides its top 10 list of the most dangerous vulnerabilities affecting web applications. When we deal with enterprise applications, it is not so trivial task to understand what issues we need to check. Fortunately, there is EAS-SEC (eas-sec.org) – a nonprofit organization aimed to increase awareness in enterprise application security space. EAS-SEC consists of separate projects and one of them covers code security. It is called Enterprise Application Systems Application development guide, or EASAD. This guide describes 9 general categories of source code issues for business languages.

Categories:

• Injections (Code, SQL, OS)
• Critical calls (to DB, to OS)
• Missing or bad access control checks (Missing authentication, mistakes)
• Directory traversal (Write, Read, SMBRelay)
• Modification of displayed content (XSS,CSRF)
• Backdoors (hardcoded credentials)
• Covert channels (Open sockets, HTTP calls, SSRFs)
• Information disclosure (hardcoded users, passwords)
• Obsolete statements (READ TABLE, kernel methods)

These categories are universal and the same for the majority of business applications such as SAP, Oracle, Microsoft Dynamics, and Infor and their custom languages.

A secure developing process should include at least checking for code vulnerabilities of these nine categories.

4. Secure connections

As each system is connected with others, understanding which system can be attacked, how SAP is connected with other enterprise applications, how an attacker can escalate privileges and what asset you should protect at first is essential. We should analyze which system is the most important and start solving issues on that particular system.

First of all, we need to assign severity for each asset. Then analyze connections between assets, whether or not they are secure, and finally prioritize assets by their overall impact on the whole landscape security. For example, you have a low-risk asset, say, a test system without any critical data. This system has a connection with the production system, and this production system, in its turn, has a connection with ICS infrastructure. Taking into account all the connections, this test system may have a high impact on all landscape and we should care about its security.

In addition to mechanisms of an application server, servers may often be connected with a number of other mechanisms. For example, SAP solutions may be installed on Windows servers, which are a part of a single domain and run with privileges of a common account. In this case, getting access to one server almost always means access to all other servers, no matter how properly they are protected at the application level. It is also possible when links or trusted connections are implemented via DBMS. DBMS often store references to other databases with pre-defined authentication data thus making other DBMS accessible. Further, the scope of such mechanisms includes any other possible methods to penetrate neighbour system, which auditors usually use in penetration tests, i.e., an attempt to login into a neighbor system with the same or similar passwords both at OS, DBMS, and application levels, as well as all kinds of search for passwords in plain text in the file system; update, integration, backup scripts, etc. All these options should be checked to eliminate any risk of penetration with one weak link to all systems.

Another risk of insecure connections is data leakage. SAP Systems should encrypt data while transferring it. It’s clear that HTTP traffic should be secured by SSL, but the big part of traffic is transferred using SAP’s proprietary protocols which are insecure by default such as RFC (Protocol to connect SAP systems ), DIAG (Protocol to connect SAP client with SAP Server), and Message Server protocol. Unfortunately, there is no way to secure Message Server traffic; therefore, simply putting this service under the firewall will be the only option. As for DIAG and RFC protocols, encryption can be implemented via SNC.

SNC without single sign-on capability is available to all SAP NetWeaver customers for SAP GUI using SNC client encryption and for all RFC communication between SAP servers. Basic single sign-on capabilities are available in environments where SAP servers and SAP GUI clients run Microsoft.

Summary

The ERP Security is a complex task. However, just taking these 4 high-level steps can significantly improve the security level of your ERP system. Only after implementing the architecture securely, it makes sense to take further steps such as vulnerability management and incident response.