Cybersecurity Risk: Something’s Happening

I was working at my desk last week when the phone rang. At the other end of the line was my friend the cybersecurity auditor. “Dude, we have to talk,” he said. “Our team here has discovered an issue.” 

Ummm, a lot of people in our line of work have issues, I replied. Can you be more specific?

My friend the security auditor then spun out a tale that could indeed be an issue for lots of companies and their risk management teams. This friend works at a cybersecurity firm, and like most such firms, this one has a research group that monitors the Internet for suspicious activity. Two weeks ago, the group found some.

Somebody out there on the interwebs, my friend told me, is trying to attack corporate SAP systems — except, the culprit is launching these attacks using old exploits that the cybersecurity community has known about for years. 

“That’s the strange part,” my friend the security auditor explained to me. “It’s not clear to me why somebody would do that.”

My friend has evidence to support his claim. SAP security analysts have recently noticed attackers using three specific exploits to probe corporate IT systems. Two of those exploits were first found in 2016 and have had patches available for years. The third is from 2021, and also has a patch.

In the immediate term, corporations running SAP should scan their systems to confirm whether or not they’ve implemented the patches for these specific exploits. If you have, you’re safe; if you haven’t, implement the patches right away.

In a larger sense, however, these three old exploits represent a deeper issue for cybersecurity and effective internal control over financial reporting. That’s the part that my friend the security auditor was more worried about. 

Security Risks Are Everywhere

My friend was particularly puzzled by one specific exploit, formally known as CVE-2016-2388. When executed against an unpatched SAP system, it allows remote attackers to obtain sensitive user information via a crafted HTTP request to pages on your website. 

That might sound bad to you, but in the grand scheme of cybersecurity threats, it actually isn’t. NIST, which maintains a database of threats, has given CVE-2016-2388 a threat rating of 5.3 on a scale of 1 to 10. That’s a medium threat.

“That’s the part that worries me,” my friend said. “Like, why would somebody use a 5 exploit? There are plenty worse ones out there.” 

This is true. NIST’s database of Common Vulnerabilities and Exposures (CVE) rates every threat based on two variables: how technically easy it would be for an attacker to use that exploit, and how much damage the exploit could cause if it were indeed executed. 

An exploit CVE with a rating of 9 or 10 is a security nightmare; any idiot with an Internet connection could use it, and the attack could cause extensive damage. For example, when my friend’s firm discovered a threat to Oracle two years ago known as BigDebIT, that threat had a CVE of 9.9. The Oracle community freaked out and issued a patch immediately.

The risk for corporations as a whole, my friend said, is that while we’re all busy looking for threats with high CVE ratings, we are not necessarily paying attention to old exploits with lower CVE ratings. 

That is, a bug with a CVE rating of 5.3 (like our friend CVE-2016-2388) might be easy to execute, but won’t cause much damage; or it could be difficult to execute, but would cause extensive damage. You can’t immediately tell from that 5.3 rating because that number an average of NIST’s two rating variables.  

Too many security teams, my friend said, focus on imminent and enormous threats like a brand new exploit with a CVE of 9.9 — and too many audit teams, he continued, would look at that organization and say, “OK, these guys take a risk-based approach to cybersecurity. Sounds good, see you next year!”

That Might Not Be Enough Any More

Let’s go back to CVE-2016-2388, our middle-aged exploit with a pudgy CVE rating of 5.3. How does a seemingly medium-risk threat like that fit into your risk-based approach to cybersecurity, so busy with the 8s, 9s, and 10s of the world? 

Clearly some attacker group out there believes CVE-2016-2388 is worth the effort, because they’re using it. Maybe they have specific targets in mind, hoping that those companies never patched up CVE-2016-2388 six years ago and the attackers can deliver a sucker punch to the target’s SAP systems. Maybe they’re just on a fishing expedition, looking for any organization that has never patched CVE-2016-2388. We don’t know.

Either way, risk management and audit teams have some questions to ponder: 

• If you work at a highly acquisitive company, how do you know that your acquired business units patched CVE-2016-2388 years ago — or patched any other old exploit, for that matter? 
• If you use NIST’s CVE database to guide your patch management (tackling those exploits with high CVE ratings first), is that adequate? Or can you break down those CVE ratings into their component variables, to identify severe-damage exploits that might need immediate attention no matter what?
• If you’re an auditor, how would you assess whether the client’s patch management addresses the issues my friend raised above?
• If you’re a security or risk management team, how would you document your approach to patch management so that if auditors do ask you questions along these lines, you can send them away happy?

As you can see, there are numerous issues to consider here. Then again, that’s what my friend the security auditor said in the first place.