More on Cybersecurity, Compliance Risk

We have another report on cybersecurity threats this week, one that demonstrates just how difficult it is for large organizations to address this risk effectively — because while the vulnerabilities themselves are squarely a CISO’s concern, the damage they can cause is very much a regulatory compliance problem.

The report comes from Onapsis, a cybersecurity firm that studies vulnerabilities in SAP systems. Researchers there studied how cyber thieves are trying to exploit vulnerabilities in SAP software. Their primary conclusion is that contrary to wishful thinking among CISOs and other business executives, plenty of criminals out there have the motivation, means, and expertise to exploit these vulnerabilities. Which creates a host of concerns for financial audits and regulatory compliance.

For example, Onapsis found that once SAP releases a software patch to fix a vulnerability, businesses have as little as 72 hours to implement that patch, before attackers have developed an exploit to take advantage of it. See Figure 1, below.

Figure 1 is no hypothetical, by the way. It’s an actual vulnerability discovered by Onapsis last summer commonly known as RECON, which allowed attackers to execute unauthorized transactions in a company’s SAP system. SAP released a software patch for RECON on July 14, 2020 — which also meant that SAP was announcing the vulnerability to any attackers who didn’t already know about it. 

By July 16, attackers were already scanning businesses around the world to find SAP systems hadn’t yet patched the RECON weakness. By July 17, they had developed an exploit for RECON and were using it against those targets. That’s how little time a business had to implement its SAP software patch.

Why is all this important? Because more than 90 percent of the Fortune 2000 companies worldwide use SAP, to manage mission-critical functions such as financial reporting, supply chain management, human resources, and business intelligence. If you aren’t patching SAP vulnerabilities promptly, attackers could exploit those weaknesses to enter your SAP system and cause all sorts of trouble. 

Where It Gets Sticky for Audit & Compliance

The important point to grasp here is that two types of cybersecurity threat exist. In the first instance, attackers impersonate an authorized user to execute transactions through the IT applications we all use every day. That’s why we see attackers trying to dupe your employees with phishing attacks, or buying user IDs and passwords on the dark web, and so forth. It’s also why your organization responds with user access controls such as password change policies, multi-factor authentication, canceling the credentials of departing employees, audit logs, and so forth. 

That type of threat is not what Onapsis examines. Instead, Onapsis looks at the other type: weaknesses in SAP software code that would let attackers gain access to your data without impersonating an authorized user. In that scenario, the attacker never needs to log into your IT systems — so all those user access controls we mentioned above are useless. The attacker evades them entirely.

Ponder the compliance risks here. Attackers could view employee or customer data in transaction records, causing a privacy violation. They could enter new vendors on your master vendor list without due diligence, causing a Sarbanes-Oxley violation, an FCPA violation, or both. They could wire money to an overseas account, causing your CFO to have a coronary when he or she discovers the money is gone three days before filing the 10-Q. 

And all of it could happen even if your user access controls and segregation of duties are great, because these attacks don’t rely on user access and roles. 

Once more, for emphasis: this is a cybersecurity problem. The solution to this risk is effective patch management for software systems, and that is the CISO’s responsibility. But the consequences of this risk are the internal auditor’s or compliance officer’s problem, so you need to collaborate closely with the CISO to assure that patch management is effective.

My fear is that such collaboration isn’t happening enough, because this is such an esoteric threat. Lots of people would even dismiss this as a significant compliance risk, believing that unauthenticated attacks at the SAP layer are too much hassle for attackers to bother using. The Onapsis report shows this is very much not the case.  

And a Word on Risk Assessments

I’m also curious what this sort of threat means for risk assessment, mitigation, and how auditors would address the matter. 

For example, the risk is that you’ve failed to patch an SAP vulnerability and attackers will exploit that point of entry. You don’t need to “assess” that threat, as much as you simply need to compare all known SAP vulnerabilities against your existing SAP systems. However many unpatched vulnerabilities you have is the risk, and patching them is the mitigation plan. 

So can you just show auditors that laundry list of vulnerabilities and call it a risk assessment? Can you show the installed software patches and call that the remediation work? Are your IT general controls then effective? (Or half-effective, at least. We still have that first type of cybersecurity threat, where attackers steal user credentials.)

My point is that the audit world already has a sophisticated infrastructure to perform risk assessments of, and to test controls for, user access, audit logs, segregation of duties, and so forth. We don’t have the same level of audit standards and infrastructure for this type of cybersecurity threat, even though this threat is very much an audit and regulatory compliance problem. 

So how do we solve it? Send your thoughts to [email protected].

(Disclosure: I’ve done paid work for Onapsis in the past, but not lately; and the company had no idea I would be writing this post.)