Yesterday, I put up a post about the first of two articles in different news sources,
that seemed to point to a similar problem: Attacks (probably by the Russians,
according to the article) on third-party resellers of cloud services. The Washington
Post article I wrote about yesterday described how at least 40
organizations, including CrowdStrike, had their Microsoft Azure cloud accounts
penetrated, although at least in CrowdStrike’s case, the attack did not succeed
in even reaching any sensitive data.
The attacks occurred through a
third-party reseller of Azure services; the attackers were able to steal
customer credentials to their Azure accounts. Note that the ultimate targets of
these attacks were the customers using Azure services, not Azure or Microsoft
itself. Of course, the attackers weren’t able to get into Azure directly, so
they pulled off a supply chain attack to do so.
Note: While I didn’t realize it
until I started writing this post, both articles are discussing the same
incident, although WaPo goes into much more depth. They both mention CloudStrike
as a victim, although the Times identifies
the “third-party reseller” as a reseller of Office 365 services. However, I’m
sure this same attack could have been launched against lots of other companies
that resell cloud services, so I decided to leave the description general in
this post, as the WaPo article did.
This means this was a two-level supply
chain attack (which has always been theoretically possible, although I know of
no example of one occurring in practice before this):
Just as in the SolarWinds attacks,
the attackers wanted to get into data owned by organizations that might have
information useful to the Russians; Azure was going to be their entry point to
those organizations. It’s highly unlikely that the Russians were targeting any
specific organizations in these attacks, just as it’s highly unlikely that the
Russians attacked SolarWinds specifically in order to get into particular
government agencies. They knew SolarWinds was used by all sorts of
organizations, public and private, that probably stored a lot of important data.
They just planted their malware in a patch under development and waited for the
malware to start contacting them on their C&C server. I can only imagine
the rejoicing in St. Petersburg and Moscow when they realized they had
penetrated NSA, the Pentagon, DHS (including CISA), DoE, the National Nuclear
Safety Administration, FERC, and other juicy plums.
However, when the Russians attacked
the Azure reseller, their ultimate goal wasn’t Azure itself, but the data in
the Azure accounts created by the reseller, for their customers. Had they
succeeded (the article only says they didn’t succeed in the case of
CrowdStrike, but it doesn’t say whether they had any success with the other “at
least 40” customers of the reseller), they would have been able to get into whatever
data those customers had stored on Azure through that reseller. That data might
have then provided them with credentials to access data stored by the customer
in other locations, such as on their own network or perhaps with other cloud
providers.[i]
Why is it important that this was
a two-level supply chain attack? It has to do with Microsoft’s role in the
attack. As the WaPo article points out, two days after Microsoft
had notified CrowdStrike that they’d been breached through the reseller,
Microsoft’s president Brad Smith stated that they knew of no customers that had
been attacked through Azure or Microsoft in general. But of course, he didn’t
say anything about Microsoft resellers being a possible vector.
And here’s the problem:
SolarWinds was obviously the main
actor at fault for the attacks that came through them. If they had properly
protected their software development environment (air gapped it from the IT
network with separate authentication, as well as other controls), it’s possible
the Russians would never have been able to attack any of their customers – just
SolarWinds itself. Obviously, the value of whatever data SolarWinds stored on
its own network was miniscule compared to the value of the data that the Russians
probably got from the federal government targets who were compromised.
But you can’t blame the Azure
reseller entirely for the fact that CrowdStrike and 40 of their other customers
were compromised. In fact, I put most of the blame for this attack on
Microsoft. What kind of vetting were they doing of these resellers? They need
to make sure they follow certain basic security practices.
And more importantly, they need to
make sure both their customers and their resellers understand that securing
cloud- based networks isn’t the same thing as securing on-premises networks. This
was, in my opinion, the big problem revealed by the Capital One breach, which
turned out to be only one of close to 30 breaches of AWS customers by Paige
Thompson, a former AWS employee. She had bragged online that she breached all
of these customers through one particular AWS service – metadata - that the
customers were charged with configuring, but which she said none of them
understood.
I stated in a post in August 2019 that Amazon should offer free training to all customers, to make sure they understand what they need to do to secure their AWS environment. I'm told they do that now, and Microsoft does it for Azure customers and resellers. But it's obviously not enough. I think the cloud providers should be required to identify say the top 20 security mistakes that customers and resellers make, and do external testing to determine whether any customer or reseller has made any of those mistakes. If they have, they should work with the customer/reseller to fix the problem - and if that party doesn't want to be helped, their access to the cloud should be discontinued.
Of course, the cloud providers also need to require resellers to follow more general security practices, like employee background checks and strong authentication. They’re presumably doing a lot of that already, but clearly what they’re doing
now isn’t enough.[ii] They should have the right to audit the reseller (of course, they can put that in their contract) and to exercise it whenever they suspect the reseller is falling down on security.
Moreover, I think there needs to
be regulation of cloud providers, as well as critical product and service providers
like SolarWinds. As I said in this
post last week, these vendors are really critical infrastructure providers,
meaning they’re not simply selling a product or service of their own creation
to users who are free not to buy it.
When US government agencies and
large corporations choose to rely on SolarWinds or Microsoft to provide secure
services and products to them, the American people aren’t given any choice in
that decision, and in any case are in no position to determine for themselves
whether or not these are trustworthy vendors. However, the American people ultimately
pay all the bills when these huge breaches happen, and there’s little question
that, when all the costs arising from the SolarWinds attacks are added up (if
they ever are), every man, woman and child in the US will have a substantial sum
to pay, in one form or another.
In the same way, residents of a
city are not given any choice (except perhaps a very superficial one) in the
decision of who transmits and delivers their electric power, gas or water. They
rely on regulators to make sure the utilities are following appropriate safety
and security guidelines.
However, I’m not in favor of
direct regulation of these entities, which would of course require years of
wrangling in Congress. Instead, this could be done following the same structure
as the recently approved IoT
Cybersecurity Improvement Act. That act calls on NIST to develop “standards
and guidelines” for security of IoT devices, and on Federal agencies to require
suppliers of any IoT devices that they buy to follow those standards and
guidelines (with muscle from DHS behind this).
I see no reason that the same
approach wouldn’t work in this case as well. No supplier would even think of
dividing themselves in two, with the “safe” part just selling to the Feds and meeting
all applicable safety and security requirements, and the “unsafe” part just
selling to non-Federal entities and only following requirements from CPSC,
OSHA, etc. They will definitely bring their entire organization up to whatever
standards NIST develops.
Of course, the requirements placed
on the “critical cyber infrastructure providers” (catchy phrase, no? And I like
the acronym: CCIP) will be vastly different from those placed on IoT suppliers.
Of course, they now need to comply with standards like FedRAMP and ISO 27001/2,
which are almost exclusively aimed at protecting data in the possession of these
organizations. In fact, I see no need to recreate these certifications in the CCIP
standards. The certification standards can continue as they are.
Those standards are great at protecting
data already in the possession of the cloud provider or service vendor. But they’re
not so great at making sure the cloud provider goes beyond their own legal
confines to ensure that their customers, and especially third-party service
providers, also have good practices in place, and most importantly that they
understand what’s really required for security.
As we have seen recently.
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.
[i] Note that, if CrowdStrike or any of the other customers of the Azure reseller had other accounts on Azure, the Russians wouldn’t have been able to get into those accounts automatically, since they would of course had different credentials and protections than their accounts created by the reseller.
[ii] And
the courts don’t necessarily seem inclined to buy arguments from the cloud
providers that their customers are responsible for breaches. The WaPo
article said “When hackers stole more than 100 million credit card applications
last year from a major bank’s cloud, which was provided by Amazon Web Services,
customers sued the bank and AWS. In September, a federal judge denied Amazon’s
motion to dismiss, saying its ‘negligent conduct’ probably ‘made the attack
possible.’” In fact, this bank sounds a lot like Capital One.
No comments:
Post a Comment