Tuesday, January 19, 2021

What could have prevented the SolarWinds attacks?...the sequel


Yesterday’s post seems to have stirred a lot of interest. Two people I’ve known for a long time, who spent many years on the front lines of the fight to secure the power grid from cyberattacks but who are both now “retired” (a word that has more or less lost its meaning, for a lot of us who might otherwise be considered to be of retirement age), wrote in to comment on the post. I’ll discuss the comments of one of them in this post, and of the other in (hopefully) tomorrow’s post.

The first of those people is newly retired. He’s Jim Ball, former CISO of the Western Area Power Authority (WAPA). He makes some excellent points:

1.      He noted that, while earlier versions of the SNMP protocol had security issues, the current SNMP v3 is considered fairly secure. Of course, devices that are still running an earlier version (and how many organizations update all their UPS’s, building control systems and power distribution units whenever there’s a new version?) will still be vulnerable.

2.      He points out that while there is speculation that SNMP played a part in the disconnection of the Ukrainian UPS that was manipulated during the 2015 Russian attacks on the Ukrainian grid, the main point is that the Russians were able to compromise it because they “completely owned the utility's networks and were operating as trusted insiders- no need for fancy tricks when you have that level of access…The disconnection of the UPS was a supporting event to the main attack, meant to confuse and impede response efforts.”

3.      In discussing the fact that the Sunburst malware (which the Russians pushed out inside SolarWinds Orion updates that they had poisoned) was likely present in most compromised networks for many months, I opined in the post “I would just say that in general, network and server monitoring must have really fallen down – or just not been in place in the first place – in many of the SolarWinds customers who were…attacked…”

4.      Jim pointed out that it would have been extremely difficult for any organization to discover that they were under attack by the Russians because these were insider attacks. The Sunburst malware (that they had planted during development of about six or seven Orion updates) let the Russians operate from “inside” SolarWinds, so any Russian activity would almost inevitably have been dismissed as SolarWinds doing its normal job. After all, network management software is constantly reaching out to network control devices like firewalls and switches – it does no good if it doesn’t do that.

5.      “The hijacking of the SolarWinds accounts was probably just the first stage to lateral movement. A skilled attacker would then harvest credentials from a more plausible identity such as a mail system service account, an endpoint detection and response account, or even an actual admin user.”

6.      Jim says that, in order to detect the Russians after they penetrated your organization through SolarWinds, “You'd have to implement an extraordinary level of scrutiny on account activity.  It’s possible, but it calls for a lot of skill and experience in your cyber engineers and SOC analysts.  That creates its own challenges as it drives costs way up. Those people are hard to find and expensive to acquire and keep.”

7.      I pointed out to Jim that, if organizations are going to protect themselves from compromise due to the SolarWinds attacks and similar attacks that may occur in the future (of course, a lot of SolarWinds attacks are probably still in the future. Since 18,000 customers downloaded, and presumably installed, one of the compromised SolarWinds updates, the Russians might have just planted malware in the great majority of them, so they could come back to it when they have the time. The latest guess I’ve seen for the number of organizations actually attacked by the Russians was only around 250), they need to be able to identify traffic from those attacks. How could they do that? Jim stated that “user behavior analytics” tools exist, “but they require a lot of tuning to work correctly.  You’re looking for unusual activity on the part of existing authorized accounts.  (They require) a lot of smarts just to define that properly.”

8.      I noted in yesterday’s post that the first organization that discovered the SolarWinds attacks was FireEye. Did they run some sophisticated behavioral analytics software that immediately recognized the Russian activity when it happened? They may have run it, but if so it didn’t discover the breach. For one thing, the Russians were probably in their network since at least June, because that was when the last tainted update went out; yet FireEye didn’t discover them until December. And more importantly, FireEye’s big break (in fact, the big break for SolarWinds and all of their customers) in December came through dumb luck: an employee noticed that a device they didn’t know had logged into their account. Had that not happened, we might still not know about the attacks, and the Russians would still be busily packing up files they found on the DoE, DHS, FERC etc. networks and shipping them off to Moscow or St. Petersburg (of course, they may still be doing this in organizations that don’t yet know they were compromised and haven’t disconnected SolarWinds).

9.      Finally, Jim said “I think the answer (to the problem of attacks like SolarWinds) will be an extension of the DOD CMMC (the new DoD cybersecurity certification for vendors) process to anybody who wants to sell to the government.  It may also result in FERC/NERC getting pushed reluctantly into the same sort of mechanism for the energy sector.” While I’d heard about CMMC, I hadn’t actually looked at what it requires. It’s a maturity model (which is a good thing), not a set of primarily prescriptive requirements (like a certain unnamed set of cybersecurity standards for the electric power industry that some of you may be familiar with).

10.   However, when I looked through the set of “domains” covered by the CMMC model (Access Control, Asset Management, etc), I noticed that it includes nothing related to software development. If SolarWinds has taught us anything, it’s that the biggest supply chain cybersecurity risks have to do with penetration of a software developer’s own development environment, since that’s by far the most efficient way to penetrate large numbers of organizations with in effect a single keystroke; after all, the one attack on SolarWinds led to “only” (as SolarWinds notably characterized the number in their SEC filing the day after they announced the attacks) 18,000 of their customers being compromised, a great ROI. Name me one other way in which an attacker could compromise 18,000 organizations in one attack. Whoever suggested this attack should be given a medal for Great Hero of the Russian Kleptocracy.

11.   When I pointed this out to Jim, he replied “My point on CMMC is that it’s the beginning of a clearly spelled out set of hygiene requirements for those desiring to do business.  I suspect that it will indirectly offer some benefit, as DOD is a huge consumer of commodity IT/OT products.”

I’m sure there will be lots of benefits – for DoD as well as all US purchasers of IT and OT products – flowing from implementation of the CMMC; it’s certainly better than what’s in place now, which is mostly voluntary. However, by itself it doesn’t address the most significant areas of supply chain risk: insecure software development practices and inadequate security controls on software development environments. If you added these to CMMC, it would be a good model, IMHO. 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

 

No comments:

Post a Comment