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