On April 6, enterprise resource planning (ERP) software stalwart SAP and cloud consulting firm Onapsis released a warning about vulnerabilities in unpatched SAP systems. Onapsis, which provided the research, identified hundreds of automated exploitation attempts over the past year. These attempted break-ins were on unpatched customer systems in their own data centers or their own public or private clouds—not in the SAP-hosted cloud environments. Sound familiar? This same scenario played out in early March as Microsoft announced the same issues with unpatched customer-hosted Exchange Servers.

Such attacks shouldn’t be surprising. After all, there are millions of servers running software from SAP on the cloud. SAP releases dozens of small patches every day. However, as the announcement highlighted, the unapplied patches were ones that SAP released weeks, months, and in some cases, years ago.

Keeping Up With Cybersecurity Patches

Keeping the various SAP system landscapes up to date on patches takes time and often extensive regression testing. Many large companies exercise multiple levels of patching, taking vulnerabilities as they come while prioritizing key functional service packages on a monthly or quarterly basis (some even follow an annual schedule to avoid disruptions).

MORE: Spotlight On Cybersecurity: How Oil & Gas Companies Can Prevent Major Data Breaches Within Their Net

A key difference between these attempted hacks and the Microsoft issues in March is that Onapsis has indicated that these appear to be criminal in nature and not nation-state attacks. That could change if nation-states realize how many key targets could be vulnerable—utilities, militaries, and other important industry players. As IT professionals determine how to best deal with the latest slew of attempted breaches, what can system users do to shore up their defenses?

Obviously, users cannot simply patch their own systems to resolve these issues, but they can help their support organization regression test supplied patches. Because there were a limited number of systems observed, we don’t know exactly how widespread the potential vulnerabilities are. One of the key observations was that the hackers would often patch the backdoor they used for entry.

This served to mask their exploits while giving a false sense that the threat was completely addressed. It’s possible that the infiltrators found other ways to leave behind vulnerabilities after their hack. Imagine if an attackers’ code sat undisturbed for 30-45 days before being triggered—restoring the backup from yesterday or last week would not resolve the issue.

MORE: Spotlight On Cybersecurity: Protecting The Systems That Control Our Infrastructure

Should ordinary users be worried? Any disruption could affect most users of a system. It would also likely affect users of other integrated systems given that SAP is generally the system of record where it’s installed, feeding dozens of other systems. If a data breach were to occur—corruption, encryption, or simply deleting all the data—day-to-day users would be scrambling to recover, possibly even more than their IT support groups. If they’re not yet worried, SAP users should be requiring answers from their SAP support groups on the status of their core systems.

Mitigating Cybersecurity Incidents

How can the SAP Community mitigate the risk of a widespread cybersecurity incident involving their SAP systems? There are three key areas where users and system support can work together:

• Develop real-time observation and categorization of incoming patches from the vendors.
  • Don’t limit the review to only SAP-provided patches.
  • Most HANA systems run on Linux-based systems and on network devices that all need regular updates and patching.
• Patch the highest priority items quickly
  • Many large companies must schedule downtime 2-3 days in advance—that’s too long (Onapsis identified some attacks as little as 72 hours after a patch was released).
  • Even if systems require downtime, such as a server reboot, have a process in place to get the approvals rapidly.
• Have a review of system audits at least quarterly to determine any outstanding patch and security requirements.
  • Monthly is better, if possible.
  • This announcement was not simply patch-related but also about customer security and authorization settings.
  • Many customers retained their SAP* and DDIC users with default passwords and Super User settings.

The best defense is good communication and good planning. Don’t keep users in the dark when they hear about the issues. Some of them will think only about the worst-case scenario. Business users and technical support must work together to identify attacks, patch vulnerabilities, and keep the core business systems secure.