Configuration errors and other missteps, many of them well known for years, continue to undermine the security of enterprise SAP environments. The burgeoning complexity of SAP footprints is a big reason for the situation. Over the years, SAP applications have morphed and evolved and these days are connected to myriad other systems and applications.
The typical SAP environment consists of a lot of custom code and bespoke components communicating with each other and to external systems through various APIs and interfaces cobbled together over time. New code and protocols interact with legacy environments and inherit their security vulnerabilities and defects, says Juan Perez-Etchegoyen, CTO of Onapsis, a security vendor in the ERP space.
Changes to profiles, parameters and configurations are constantly being made to accommodate new business processes—but with little understanding of the underlying security implications, he notes. The sheer complexity of these environments has left them rife with security vulnerabilities.
The issue came into sharp focus earlier this year with the public release of a set of exploits targeting well-known configuration errors in two major SAP components. The exploits, collectively dubbed 10KBlaze, gave attackers a way to gain complete remote administrative control of SAP environments, and prompted an advisory from the US-CERT
Here are some of the most common configuration errors and security failures within enterprise SAP environments.
1. Misconfigured ACLs
Access control lists (ACLs) control connections and communication among different SAP systems and between SAP and non-SAP environments. They also determine user access to SAP systems.
Very often the ACLs controlling connections between an SAP system and an external system, or among SAP systems, are poorly configured and porous and allow someone on one system to easily access another, Perez-Etchegoyen says. In penetration tests, misconfigured ACLs almost invariably show up as giving attackers a way to move laterally in a SAP environment, he says.
The 10KBlaze exploits that Onapsis disclosed in May, for instance, were designed to take advantage of poorly configured ACLs in SAP Gateway and SAP Message Server. The exploits gave attackers a way to gain complete control over an SAP environment to view, delete or modify data, to shut systems down and take other malicious actions.
Other components in SAP environments that frequently have insecurely configured ACLs include SAP Internet Communication Manager (ICM), SAP Dispatcher, SAP Management Console for remote monitoring and management and SAP Host Agent ACL for OS monitoring, the Onapsis CTO says.
SAP itself has long warned organizations about the danger from improperly configured ACLs. Newer versions of its apps are far more secure in this regard than older versions, and ACLs are far more strongly set by default Perez-Etchegoyen says. Even so, insecure ACLs remain one the biggest avoidable vulnerabilities in the SAP world.
2. Weak user access controls
Most SAP software has one or more default user accounts with highly privileged and administrator level access. A malicious user with access to such an account can wreak substantial damage. Examples of such accounts include SAP* and DDIC and the SYSTEM user account in SAP HANA says Jonathan Haun, senior director at Enowa LLC, a consulting company that specializes in SAP systems.
"Hackers know that these accounts exist and will try to attack them first," Haun says. "Organizations need to either disable such accounts until needed or use very complex, randomly generated passwords that cannot be guessed," he says. In some cases, there are even software products that allow administrators to securely and temporarily use these accounts.
SAP environments, especially those that have grown over time, have a lot of accounts in them that can be easily abused to give a malicious user full administrator and even super-admin access to everything in the environment, Perez- Etchegoyen says. "This is an area of SAP security hygiene that definitely needs improving for a lot of organizations."
3. Insecure custom code
The custom code and functionality that organizations build around their SAP environments can often by buggy and contain security vulnerabilities says Gert Schroeter vice president of security communications at SAP Global Security. "We really see a lot issues in terms of software development lifecycles," Schroeter says.
Development organizations that are under pressure to release software quickly can often pay little attention to security fundamentals like code vulnerability analysis, code scans and bug hunting when software is being built and deployed. "We are talking about security by design and security by default," Schroeter observes. "At the end of the day that is not the case" at many organizations with SAP footprints.
4. Sloppy patch management
Because of the mission-critical nature of most SAP environments, administrators are often hesitant or unwilling to do anything that might disrupt availability. One result is that security patches and updates—even for the most critical vulnerabilities—tend to be rarely applied quickly, and sometimes not at all.
Applying a patch in a SAP environment means understanding its impact through the landscape—from development, QA, pre-production and all the multiple other layers, Perez-Etchegoyen says. The time needed for administrators to make sure a patch won't break existing process or interfaces can often result in needed patches not being implemented even years after they first become available he says.
Many organizations have a hard time identifying and implementing needed patches on on-premises SAP systems because of a lack of information, Schroeter adds. Administrators need to keep a regular watch on vulnerability disclosure sites and databases and subscribe to resources that can keep them regularly updated on patching information, he notes.
5. Unprotected data
SAP environments are connected to pretty much everything these days and accessible from almost anywhere either directly or indirectly. A lot of SAP workloads have also begun moving to the cloud.
Yet, often the actual data itself—as mission critical as it is—is not protected. Few companies encrypt the data either in transit or at rest and in the process expose it to risk of improper access and misuse. "For cloud and hosted situations, they incorrectly assume that the provider is implementing network encryption and other security standards," Haun says.
When your SAP database is hosted by a third party especially, the data at rest should be encrypted to prevent untrusted users from accessing the data. "With many organizations leveraging hosting and IaaS cloud platforms, encrypting the data, transaction logs and backup files is highly recommended," he says.
6. Poor password management
ERP systems and the applications connected to them contain critical information yet are often protected by weak passwords and password management practices. It's not unusual to find access to highly privileged accounts protected by default passwords or the same passwords being used across accounts. Weak passwords are of course a problem across applications, but especially problematic in critical SAP environments.
Some organizations do not enable basic standards for passwords and this can lead to accounts being compromised and hackers creating undetected damage with a valid user account and password, Haun says. "SAP systems should be configured so that user account passwords require complexity and are changed several times each year," he advises.
Super-user and admin passwords should not be available to ordinary users and be locked away in a digital safe. Instead of relying on macros and text-based authentication, organizations should implement stronger controls including SSO, two-factor and context-based authentication, Schroeter recommends.
7. Failure to have an emergency response plan
One big issue for many organizations is the lack of an adequate crisis management plan. Few have a process in place for responding to an unfolding attack or have a chain of command in place for a crisis, Schroeter says.
A survey that SAP conducted showed organizations are concerned about data loss and about disaster recoverability and business continuity in their ERP environments, he says, but few have a plan for dealing with a crisis.
8. Inadequate logging and auditing
Logging and auditing is essential to enabling the visibility needed for monitoring system activity across the SAP environment. It can help administrators keep an eye on privileged users and monitor access to applications, data and databases and any identity changes to them.
Yet, most organizations do not enable sufficient audit policies to track critical actions within their SAP systems, Haun says. This includes both the application server layer and the database layer. "Auditing data can be used to proactively detect attacks and can also provide forensic data following an attack," he says.
SAP itself has been adding a lot of security functionality to its products and has been shipping them in secure default configurations for years, Schroeter says. The company has provided guidance around key topics like configuration drift and how to deal with security patches and add security functionality around their software. "Customers need to start dealing with it and start addressing cybersecurity in a holistic manner," he says.
The same way that SAP applications are complex, so is addressing the security issues. Organizations need to implement a security plan, prioritize risk and figure out a formal approach to mitigating threats to their SAP environments, Schroeter notes.
A study that SAP conducted with a security vendor last year shows heightened interest among criminals in SAP applications, he says. Companies that continue to underestimate or ignore the threat are making a mistake. "10KBLAZE is the best example I can find in terms of why organizations need to start dealing with this thing," Schroeter says.