You already know enough about SAP ERP Security and realize a real impact of having insecure SAP implementation.
Recently, Crowd Research Partners have released ERP Cybersecurity Survey 2017 conducted across almost 2000 respondents of different roles from various industries. According to this research, 89% of security professionals predict that the number of attacks on SAP systems will increase. Moreover, the average damage of an SAP Security breach is estimated at $5 million. It’s unthinkable, isn’t it?
Take a glance at the statistics:
Then, what about real-life incidents?
If you still do not believe that SAP is a juicy target for hackers and suppose there were no incidents concerning this area, I’m sorry, but I have to disappoint you. In fact, there were.
I’ll tell you about 5 most notorious ones happened in the last 5 years.
SAP Security Incident in Greek finance ministry
The earliest infamous cyberattack on SAP systems occurred on October 30, 2012, when perpetrators from the so-called Anonymous group allegedly leaked the confidential files and credentials belonging to Greek Ministry of Finance. The document from AnonPaste declares that the motive behind the attack was protesting against the Greek economic conditions, which were becoming worse. The group posted a compressed file with credentials purportedly valid and said they had accessed IBM servers and possessed an SAP 0-day exploit. Although this attack wasn’t approved or declined by any authority, there are no reasons not to believe them. Whether or not the attack was actually performed, the incident indicates that hackers are interested in exploiting SAP systems.
Lessons learned from Greece finance ministry attack
Such attacks should be viewed thoroughly since the sensitive information of all types is kept in SAP Systems (e.g. credit card data, clients and partners lists, trade secrets, bank account numbers). Find the examples of espionage attacks on SAP and don’t underestimate their severity.
SAP Malware Incident
A noteworthy SAP incident took place in November 2013, when a new Trojan program variant addressing online banking accounts seemed to contain code meant r to discover if the infected computers had SAP client applications. It implied that malicious actors might target SAP Systems later on.
To get pricing information, the program applied a traffic analyzer, a system monitoring web banking activities, and a screen grabber. Sending the data obtained from window forms and secure workflow systems to the hackers’ server was considered an objective. It revealed that the workstation had an SAP client installed after having accessed the infected workstation, therefore, it gained access to the SAP server. The malicious software could make screenshots of logins into the SAP System, collect sensitive system data, and steal passwords input during login. The gathered information allows carrying out malicious actions on an SAP server. What is more, perpetrators could sell the information on the black market.
Lessons learned from SAP Malware
Here comes the second lesson: the secure perimeter is not a panacea. In the new cloud and mobile devices realm, a company’s perimeter turned out to be more transparent and less secure as a result. To implement a firewall has been sufficient until recently. You have to accept the idea that your perimeter is insecure by default. There are other ways for hackers to break into SAP Systems, besides Trojan programs, for instance, to implement an attack on SAP Internet-based services (e.g. SAP Portal, SAP CRM or SAP SRM) that either fully or partially available for remote access. Vulnerabilities in these systems may be used to get access to company’s internal infrastructure. Another way is to exploit vulnerable SAProuter installations or other administrative SAP services exposed to the Internet. Scan your SAP Systems for unnecessary services and configure strict access control to protect them.
SAP Security Incident with South West One
November was notable for yet another curious incident. The review of South West One AP IT Controls (a company, which runs IT and other services for Commercial and Government companies) revealed that auditors identified severe security issues. Weaknesses in SAP Security controls would permit non-police staff members to access the force’s administrative database. The three authorities shared an SAP database, and users with administrative rights were able to directly access the database or OS. For administrators, it may be the simplest implementation option but is definitely insecure one. “It is likely to be the lowest cost model because of this,” says Grant Thornton. “However, it is the least secure method to manage legal entities that have no relation to each other.”
Lessons learned from South West One audit
The lesson is the following: access separation between systems. Separating data could be achieved through several methods. It’s not recommended to store information about different organizations in a single application server. Furthermore, there is an additional layer of data separation, so-called Production, Test and Development system. There should be at least 3 systems with strict access control inside one company. Even admins should not have any access to critical commands in SAP, such as access to OS. It’s recommended that you disable the transactions at all.
SAP Security Incident with NVIDIA
What else was remarkable in the world of SAP hacks? In January 2014, NVIDIA customer service website was allegedly attacked. A man who found the drawback was from China. Finger, as he called himself, said that notified NVIDIA of the issue on November 21, 2013 (almost simultaneously with the 3 previous cyberattacks happened), however, did not receive any reply from the company and decided to draw attention to this issue.
The description was posted on the Chinese vulnerability forum WooYun.org on January 5, 2014 and reposted on Fulldisclosure. The status of the bug was “unable to contact the vendor or actively neglected by the vendor”. 3 years prior to the incident the NetWeaver loophole was patched by SAP; nonetheless, NVIDIA didn’t implement the fix. The customer service website was taken offline for a two-week period for investigation on January 8, 2014, and the company never commented on the incident. Although data was not supposedly leaked, the fact of Customer Care Portal shutdown affected the company image.
Lessons learned from NVIDIA attack
The new lesson: Patch Management is essential. As dramatic as this may be, not only NVIDIA didn’t patch the issues. Numerous companies consider patching process to be time-consuming and expensive thus don’t implement SAP Security Notes. SAP released almost 4000 SAP Security Notes during the period when the hacking attack could happen in order to close SAP vulnerabilities, most of which can be exploited only with an access to the corporate network. However, some of them are remotely exploitable over the web. Therefore, it’s recommended to update them in due time if a company uses web-based systems. In addition, keep in mind that SAP Systems are very complex having thousands of different web services (i.e. Portal, CRM, SRM), and applications with unauthorized access, as well as multiple technologies (i.e. JSP, Web Dynpro, BSP, HANA XS applications, Portal iViews). All of them have their own set of security mechanisms. Analyze web services and disable unnecessary ones.
SAP Security Incident with USIS
Now be ready for an impressive incident. Compared to it, other attacks are like fairy tales for kids.
It happened on May 11, 2015, and the news about a USIS breach blew up the media. As it was claimed, the attack was conducted by China-sponsored hackers via a vulnerability in SAP software.
USIS used to be the largest commercial provider of background investigations to the federal government. It had more than 5,700 employees providing services in all 50 states of the U.S. territories and overseas.
In 2013, USIS was hacked through an exploit in an SAP system controlled by a third party finally compromising more than 27,000 employees. A similar breach also affected servers of the Office of Personnel Management, which holds information on security clearance investigations.
As the result of this breach, USIS lost contract with OPM as its main client as well as $3 billion and cut 2500 jobs (almost half of all the stuff). The owner of USIS filed for bankruptcy. Imagine, just one vulnerability in an SAP System can lead to such dire consequences.
Lessons learned from USIS attack
What lessons can we learn from this unfortunate experience?
We should care about the security of all connections between business-critical applications both inside the company and with external stakeholders. To automate business processes, different SAP modules have to be interconnected. ERPScan’s research discovered an average of 50 connections in a typical SAP System, 30% of which store credentials. Perpetrators will be able to access all the synced systems in case they infiltrate the weakest SAP module. Therefore, all kinds of connections between SAP Systems should be reviewed.
This is how the connection map looks like for a small landscape. Imagine how complex it can be.
The typical connection called RFC is not the only possible way. There are at least 20 other options how different SAP Systems can interact with each other: shared passwords, trust connections, industry-specific applications (e.g. xMII or Plant Connectivity) that can be used to get unauthorized access from one SAP System to another.
So, what about the USIS incident? The most remarkable fact revealed in June 2015 is that it may hit other government agencies – customs and border protection, US Capitol Police and even OPM. The reason for that is a single vulnerability in SAP System of a contractor, which might cause espionage, sabotage, and fraud. You should pay attention to the interconnections and remember that a single insecure component may ruin the whole business.