SAPotage - Target: Production

When it comes to IT security in production, many managers first think of protecting control systems and lull themselves into a sense of security if their SCADA systems are not connected to the Internet.

At the latest, when these systems are connected to an intranet, the supposed security is over. But production is not just about controlling an assembly line.

Every manufacturing process is based on the initiation of business processes by authorized persons. To this end, production data is increasingly being tapped at the control systems and forwarded to SAP systems.

Ideally, a dashboard populated with real-time data provides all decision makers with the information they need to manage business processes such as materials procurement and production planning anywhere.

For example, departmental managers direct production logistics by ordering new material, arranging for outsourcing of manufacturing to suppliers, and invoicing. Quality control is also an integral part of an SAP-controlled manufacturing process.

Risk scenarios

This direct dovetailing of production and business processes opens up a wide field for attackers to attack ERP or SCM modules and applications.

Malicious users can first gain central insights into a company's production know-how and processes. SAP-based solutions for production planning as well as ERP and SCM modules thus become a worthwhile target for industrial espionage.

Secondly, malicious users and unauthorized SAP user account owners have extensive opportunities for fraudulent activities.

Once you have gained access to an SAP instance via the transaction layer - i.e., at the SAP NetWeaver or Hana level - you can use simple procedures to circumvent classic SAP security concepts at the application level, such as segregation of duties.

As a consequence, applications are also not protected. For example, a SoD normally provides that a user in a production department can place a material order, but that invoicing may only be performed by Controlling.

A user who creates his own account with extended user rights, hijacks a privileged SAP All account for his own purposes, or creates a new account strips off these SoD restrictions.

He places a fake order, writes a fictitious invoice to a straw man and arranges for the money to be transferred to his account. Small, regularly flowing amounts of money may not be noticed, especially since the company's own production continues unaffected.

Many CISOs often can't even get an overview of such day-to-day security risks due to lack of resources.

Third, sabotage of SAP landscapes endangers production. Malicious providers will stop necessary material orders, perhaps manipulate production data for material costing, for example. At the SAP transaction level, they can paralyze the entire SAP system by shutting it down.

Without production planning, production is then also no longer possible. In practice, this may be less common. A functioning SAP system as a platform for fraudulent activities is usually more lucrative.

Procedures

The increasing connection of production-relevant business processes to the Internet via SAP-based solutions and the integration of external partners are exacerbating the risk situation.

The mobile transmission of data or even the connection of suppliers via the cloud and control systems, for example, increases the attack surface. Mobile apps as part of the SAP mobile platform can become gateways to SAP ERP instances through unauthorized access.

Hackers are specifically looking for ever new ways to gain access. A classic spear phishing on production managers to log the entry of passwords using keyloggers naturally also threatens SAP users and is only the beginning.

Malicious external attackers search for the SAP instances they are looking for via search engines such as Shodan. Internal employees, of course, have an even easier time gaining access to SAP systems.

By exploiting an HTTP verb tampering vulnerability, hackers can create backdoor users in the SAP J2EE User Management module. This gives them access to SAP portals and process integration platforms, as well as related internal systems.

Attacks on databases occur via vulnerabilities in proprietary SAP protocols: hijacked or usurped user rights are used to exploit vulnerabilities in the SAP RFC gateway at the SAP transaction level.

The hacker gains access to any information stored in the SAP database and can read it out. In doing so, external attackers often take the detour via environments that are often not productive and thus frequently not sufficiently protected:

For example, test environments are often forgotten after the corresponding productive system has been set up - and with them the technical accounts that apply to them, which are often only equipped with default passwords.

A hacker can simply use these as a springboard for attacking productive systems. Such frequently observed attack methods can then be used to change and manipulate a great deal of production-relevant information.

For example, the SAP tables LFA1 (Vendor Master Data), KNA1 (Customer Master Data), EKKO and EKPO, or AUFK for purchase orders and KALC for calculating the quantity of production materials.

Protection layer Transaction layer

The protection of SAP-supported production processes starts at the very foundations of any SAP landscape - at the transaction layer. Segregation of duties, GRC measures and special security applications at the application level, as well as the extensive assistance provided by the software manufacturer SAP, are important tools for creating greater security.

But they cannot stand alone. They do not eliminate the dangers at the Hana or NetWeaver level due to the emergence of security gaps, software patches that have not been applied, uncontrolled communication via interfaces for the transfer of incorrect data or unprotected access to administration services.

Comprehensive transaction layer protection can effectively eliminate many of these risks and provides the foundation of ERP or SCM module and application security.

An automated assessment of all SAP instances - including test and development environments - inventories existing security vulnerabilities and identifies potential risks.

Such messages also take into account the context of the infrastructure information provided by the automated assessment. They also register system changes that may make an organization vulnerable. This makes it possible to determine what prospect of success an attack has.

Corresponding analyses describe in detail the probability and impact of threats. Administrators can use detailed instructions to close the gaps according to priority.

Monitoring and user behavior

Advanced solutions also continuously monitor the threat landscape and look for attack patterns to exploit new vulnerabilities.

They report actual new attacks on existing vulnerabilities and analyze corresponding attack methods in real time. Defense mechanisms are automatically triggered and can be executed by those responsible.

In this way, IT departments prevent the exploitation of security vulnerabilities, even if a proper patch has not yet been published and implemented. This speed gain is crucial.

This is because in SAP landscapes, due to the complexity of the systems, it takes up to 18 months on average from the day an attack first occurs to the actual implementation of a relevant patch.

It is also important for a defense against misuse, fraud and espionage to recognize unusual user behavior, which can be an indication of malicious activities by employees.

Security managers are given the ability to respond to threats as quickly as possible and can immediately cash in on the usage rights used to change user privileges or access production data.

A successful SAP security strategy is multi-layered and based on several tools, including firewalls and SIEM solutions.

It is also important that these solutions do not act as isolated applications, but can exchange relevant data via defined programming interfaces (API).

Creating secure foundations

Only those who protect the transaction layer can effectively protect their production applications and ERP modules in SAP. After all, once a hacker gains access to any starting point in the SAP system landscape, all production-relevant SAP components are open to him. ERP and SCM security also needs solid ground under its feet.