Don’t Wait Until It’s Too Late

ERP systems contain an organization’s most sensitive and mission-critical information, so it’s no surprise that they are a prime target for cybercriminals. Traditionally, ERP systems were built with proprietary protocols and kernels that made it difficult for hackers to exploit them, says Gary Prewett, practice lead at NIMBL. “Customers for a long time have used that to their advantage,’’ he says, “but now, hackers are getting more sophisticated and they’re application-aware and able to reverse engineer a lot of the system features.” In fact, the threat has become so great that in July 2018, the US Department of Homeland Security issued a warning about the increasing risk of attacks on ERP systems.

Despite this present and growing threat, many enterprises often fall behind in applying security patches to address identified vulnerabilities in their systems — in fact, around 90% of the systems assessed by ERP security services firm Onapsis have outdated patches, according to Juan Perez-Etchegoyen, the company’s CTO and cofounder. Outdated security patches increase the susceptibility of ERP systems to cyberattacks, and for SAP customers this is especially true for those migrating to SAP S/4HANA, which introduces a wide range of new security considerations. So why do organizations struggle when it comes to applying them?

Why Patching Is a Challenge

A significant factor that contributes to delayed patching is the way in which customers implement SAP software — in particular, customizations of the software, such as custom coding, which can have unpredictable effects when patches are applied. “If you apply a patch, the chance that things could go wrong are not low because of the complexity and customization organizations implement,’’ says Perez-Etchegoyen. Large organizations typically perform a significant amount of sophisticated customization, agrees Selvaraj K, development manager for SAP’s product security response team. This makes patching technically difficult, because “anything that is not standard is hard to patch and leads to more disruption,’’ he says. “For this same reason, SAP cannot deploy automatic patching.”

Additionally, many companies do not have standardized change processes and efficient testing procedures in place, according to Selvaraj. When it comes to their software, businesses tend to want few to no vendor-triggered changes — instead, they often make changes to their software on an ad-hoc basis and test manually, which Selvaraj says is expensive and is usually done by customers that typically can, but do not, allocate sufficient resources to security patching. Adding to the challenge is that, in many organizations, SAP security is siloed from corporate security. “Security guys manage patches and firewalls for other systems, but they sort of hope patching happens on the SAP side,” says Prewett. “Lots of CISOs I meet aren’t really sure about how SAP security is managed in the weeds.”

So, although SAP issues software patches every month to address vulnerabilities, “the majority of SAP customers I’ve worked with do not apply patches every 30 days,” adds Prewett. “In fact, a surprising number will only patch their ERP system once a year.” Infrequently patched systems — especially those that are patched every few years and older releases — are among the most challenging systems to patch, according to Selvaraj.

Considerations When Migrating to SAP S/4HANA

Large organizations that are planning to migrate to SAP S/4HANA on premise will have to adapt the software to their business processes, which adds another layer of complexity to patching, according to Prewett. This complexity, combined with the number of patches organizations need to keep up with, means that companies need to perform a return on investment (ROI) assessment to determine whether they need to apply each one, and whether a patch will break something and affect uptime, he advises. Otherwise, he says, “It’s going to be a real issue as people make the move to these new releases.”

As part of making this assessment, organizations must define their biggest risks, their appetite for risk, if a patch is critical, and if so, how quickly they need to apply it, adds Perez-Etchegoyen. “Key to any scenario is to have the right processes for understanding what is the risk of applying the patches and not applying them,’’ he says. “The latter is the biggest — if you don’t apply the patch, you need to understand the potential risk because of the technology and criticality of the information stored in SAP S/4HANA.”

Another consideration is that, with SAP S/4HANA, SAP has made a commitment to migrating a lot of its core functionality to SAP Fiori apps, which essentially exposes that functionality in a way that is easily accessible for mobile devices, according to Prewett. This becomes problematic when these apps are integrated with “semi-trusted devices’’ and security controls are not adjusted accordingly, he says — then the likelihood of risk goes up by orders of magnitude. NIMBL educates customers both on the need for patch management and the implications of porting SAP functionality to these types of apps. He adds, “Once they understand the risk when applications are exposed to the outside world, they’re choosing not to allow SAP Fiori apps to be accessible outside their internal network.”

Best Practices for Building a Security Patching Framework

So, what steps can SAP customers take to help lay the groundwork for a secure system and a successful security patching framework?

When it comes to making sensitive data available to mobile devices, there is a host of controls besides patch management that organizations can use to defend against external threats, including configuration management, secure software development, and tracking and monitoring access to data, according to Prewett. However, organizations need to consider whether the cost of these controls will be more than the added business value, in which case it may not be worthwhile. “So if you get $1 million additional business value, but it costs $10 million to provide that, it’s not worth exposing that functionality,” he says. “At the end of the day, keeping services internal is an easy way to manage risk.”

In addition, Prewett strongly recommends that on-premise users deploy Business Process Change Analyzer, a feature available within SAP Solution Manager that reports on what an organization needs to do for regression testing. Companies should be regression testing their entire ERP system, according to Prewett, noting that customers have experienced outages when they don’t. “They always should test to ensure the patches aren’t affecting core functionality their business processes depend on,’’ he stresses.

Regression testing takes several weeks, and since SAP releases patches every 30 days, Prewett says that companies could conceivably do regression testing all the time. “If they can use Business Process Change Analyzer to scope what they need to regression test, they will save an enormous amount of time,” he says.

Likewise, SAP Solution Manager can be used to monitor an enterprise’s SAP infrastructure and provide system recommendations on the patches a company should be applying. “It contains reports that tell you all your missing patches on all your monitored SAP systems,” Prewett says. ‘This requires time and effort, and already IT has this mandate to keep systems up and running, and now you’re telling them to add one more thing to the list —but it is an important add.”

Perez-Etchegoyen’s biggest recommendation is to just “start dealing” with patches. He says, “We need to start creating the process and understanding that failing to patch is a risk similar to other risks that could happen in an organization, but this potentially is the most critical application in the organization.”