Chris Farris

With the US Government acting in an erratic and hostile manner towards its traditional allies, it makes sense for companies not typically subject to US Jurisdiction to reconsider their threat models when using the big three cloud providers. All of them are US-based companies, and all three conduct a substantial amount of business with the US Government.

Why is this a concern?

• The President has threatened law firms that go against his agenda.
• The President has retaliated against Chris Krebs, the first director of CISA, for actions taken during the 2020 election. This retaliation is not just a legally expensive endeavor for Mr. Krebs, but the President has also revoked the security clearances of all of his co-workers.
• Elon Musk has been granted unprecedented and unsupervised access to vast amounts of US Government data with no regard for any conflicts of interest with his existing businesses.

The US Government has many pressure points it can use. Amazon imports a significant amount of goods and can be pressured by tariffs. Google’s Mandiant division requires access to US intelligence and can’t risk losing security clearances or contracts. Microsoft has lucrative government hosting contracts. It is therefore easy to envision a scenario where Amazon, Google, or Microsoft is compelled to act in a hostile manner towards their customers.

Extending the Universal Cloud Threat Model

Last year, Rich Mogull and I drafted a Universal Cloud Threat Model - it was an attempt to categorize and describe the universe of cloud security issues we’ve seen over the past decade of public cloud.

We summarized the problem with a simple statement:

At the time, I think we made a joke about “those other nation-state threat actors” and referenced the DOJ, SEC, and FTC, as they were engaged in privacy and security-related enforcement actions against negligent companies. However, the UCTM was focused on the 90% of attacks that 90% of organizations would face. While these US agencies may have been in your threat model before the current situation, as they may execute lawful access orders, the attacks were not common and were not faced by most organizations.

How do we look at the UCTM through the lens of a hostile US Government holding hostage the leadership of cloud computing?

The threat actors are not singular. There are many factions within the US Government, often working at cross-purposes. But they can be roughly bucketed into two groups:

1. Agenda of Grievance
2. Accumulation & Preservation of Power

Trump, and to some extent Musk, have been “treated so unfairly”¹ by being held to the same laws as the rest of us, and being forced to make safe products fairly and with respect for labor laws. Their agenda is to burn everything, a modern-day Mad King Aerys. Vance fits well within this group as clearly demonstrated by his leaked Signal messages.

The other group is about collecting and preserving power - this is the Project 2025 cohort. Leveraging Trump’s agenda of grievance to burn the constitutional norms for personal and political gain.

The targets are varied and complex to predict. Random citizens and residents are disappeared to foreign SuperMax prisons. Uninhabited islands are hit with punitive tariffs. Foreign leaders are ambushed and humiliated in the Oval Office. It’s difficult to predict who will be next, but if you compete in any way with Elon Musk, are European, and believe in human rights, you could easily be the next target of this administration.

The bulk of the Universal Cloud Threat Model focused on attack vectors, and this addendum will also focus on those areas.

US Government Specific Attack Vectors

These attack vectors are highly specific - they are methods only available to the US Government, by virtue of the fact that these companies have huge business with the US Government, are publicly traded on US Exchanges, and their executives and employees are US Citizens. Depending on the level of “threat” you pose to the “National Interest²,” the Cloud Service Providers (CSPs) may be compelled to act against you.

We’ll start with the traditional CIA Triad for our threat model: Confidentiality, Integrity, and Availability.

Attack Vector: Denial of Availability

The simplest and easiest would be to fire you as a customer. After the January 6th insurrection, Amazon informed Parler, an alt-right social media platform used to organize the violence, that it had 24 hours to re-platform its services. AWS allowed Parlor to withdraw its data, but the service was offline. If the US Government were to declare your business supports a terrorist cause (like you know, due process), it could easily pressure a cloud provider to cancel your services.

To mitigate the Denial of Availability risk, ensure you have backups of data on a secondary cloud provider. This was important even before the US Government became hostile to Western values. Entire companies have been wiped out by ransom attacks that deleted both the primary and backup copies of data.

However, if you’re branded a threat to “the National Interest,” you’ll have more issues than just your IaaS cloud provider.

Attack Vector: Violation of Confidentiality

There has always been the risk that the US Government could produce a National Security Letter and compel a cloud provider, under a gag order, to produce sensitive business information. That occurred in late 2020, when CNN’s chief legal officer was served with a subpoena regarding Pentagon correspondent Barbara Starr’s email. CNN maintained a hybrid email system, where most employees were in O365, but a select few journalists and executives had on-prem email boxes³. This forced the government to seek out CNN’s IT staff to produce the data, rather than relying on Microsoft. Had CNN put its journalists’ emails in O365, CNN Legal would never even have known about the subpoena or have been able to contest the order.

Mitigation: Keep your most sensitive information on-premises, only use the cloud for storing data encrypted on-premises, or utilize a complete confidential computing architecture.

It should also be noted that the US Government is not the only threat actor here. The UK Government’s “Snooper’s Charter” has been used to demand that Apple break end-to-end encryption, and other European governments are considering the enforcement of backdoors for the use of end-to-end encryption.

Knowing about a Violation of Confidentiality

One aspect of all these confidentiality violations is that the governments exercising them want the violations themselves to remain confidential. US National Security Letters come with a gag order. The UK’s technical capability notice served to Apple was itself secret. Breaking End-to-End encryption allows the government to serve notice to the software or service provider, rather than the user(s) under investigation.

So, the second question in your threat model is: Do I need to keep the data confidential, or do I just need to know if confidentiality has been breached?

When your employees are detained at the border, threatened with a one-way trip to an El Salvadorian supermax prison, all of your security controls and awareness training go out the window. You cannot prevent the breach, but you at least know it occurred.

This is where audit logging comes in. Unfortunately, as we saw with the UK’s technical capability notice, they can ask for almost anything they want. That could include “and none of the access is logged via CloudTrail”.

Yes - in a world of abusive governments, you cannot even trust the basics of CloudTrail anymore.

AWS, at least, has the capability in its encryption service, KMS, to manage your own HSMs within your own data centers. This is known as KMS’s External Key Stores.

Encryption and decryption operations that use a KMS key in an external key store are performed by your external key manager using your cryptographic key material, a feature known as hold your own keys (HYOKs).

With External Key Stores, you control the auditability of cryptographic key usage, allowing you to build detections around abnormal usage should a threat actor (including the US Government) attempt to decrypt all your data for exfiltration. The External Key Store can also be disconnected from AWS, allowing you to prevent the attack, albeit at the expense of normal business operations.

A second, less expensive method is to use KMS with imported key material. This method relies on AWS for auditing unexpected access. However, it enables the removal of keys from the AWS environment, thereby preventing AWS from being compelled to turn over your data to a threat actor.

Of course, you could encrypt your data client-side. And that’s fine for backup storage, but it will prevent you from actually using your data in your cloud provider of choice.

Attack Vector: Attacks on Integrity

These sorts of attacks would be much harder to accomplish and might be better performed by a malicious government at the application level rather than at the cloud provider level. But let’s threat model that a bit anyway.

Any attack on the integrity of your data or business processes would be highly complex and challenging. It’s not something malicious government actors would do from behind the shared responsibility curtain. In fact, with trusted computing controls like Nitro, not even a technical capability order would enable the violation of the customer’s environment.

The simplest method would be to compel the CSP to provide admin-level access to the relevant cloud accounts. AWS provides this via the AWS Root User. By default, the Root User is unbound by IAM Permission restrictions and can perform any action in the AWS account in question.

The AWS Root User also exists at the boundary of the AWS technical infrastructure and the customer account and billing systems. It is the place where there are the fewest technical controls preventing AWS employee access, and thus the most logical method for a government to demand access. Once the government threat actor has root credentials, they can alter and exfiltrate whatever data they want.

How would you detect and mitigate this threat vector?

Several best practices could slow down an attack described above. Leverage AWS Organizations and ensure there are Service Control Policies in place to prevent root usage. Leverage an AWS Organizational CloudTrail and push the events to an external Security Information and Event Management (SIEM) system for detection. Enable Centralized Root Management to remove root users from all your workload accounts and monitor for their recreation.

None of this is foolproof - the governmental threat actor could simply ask for the root credentials for the Organization Management Account. From there, they can re-enable root users, disable CloudTrail, and remove or bypass the service control policies. However, all of these things are noticeable. And the more you force government threat actors to go to AWS for an additional “technical capability”, the more time you have to detect the activity, and the more opportunity AWS has to push back. It also increases the likelihood that this attack will somehow leak to the press.

Ok, this seems pretty bleak. Should we just move off US providers?

There are several benefits the big-three providers have over regional counterparts. If you want a cheap, burstable, event-driven architecture? Can’t beat Google Cloud Functions, or AWS Lambda + EventBridge. Need unlimited storage with multiple pricing tiers? Yeah, you can find S3-compatible object storage elsewhere, but none with the features or pricing tiers of Amazon S3.

This may finally be the moment where multi-cloud and hybrid-cloud make sense. Workloads that would be targets of malicious actors in the US Government are hosted in on-premises data centers, and front-end consumer-facing applications are hosted in a hyper-scaler. It will be more expensive - moving data from one place to another has egress fees and requires bigger pipes. You’ll have to hire staff to handle the undifferentiated heavy lift that comes with HVAC maintenance, swapping failed hard drives, and Kubernetes. You still risk that alt-right wackos will determine that your pregnancy tracker application supports terrorism (i.e., the murder of the unborn), deem you to not be “in the national interest”, and force you to migrate.

Many individuals who conduct business in mainland China have already encountered some of these issues.

There are also the new sovereign clouds. These are intended to decouple the operations (if not the profit margins) of cloud service providers from their parent companies and, by extension, the US Government. As you examine these options, consider how the CSP’s sovereign cloud offering safeguards you and your workloads against these attack vectors.

• Are there Terms of Service protections that let your nation’s laws define what is good or bad?
• Are there operational controls in place that prevent humans operating the sovereign cloud from violating confidentiality or integrity on behalf of a foreign power?
• Does the sovereign cloud have billing and auditing protections that cannot be bypassed?

None of this will help American companies. If you’re a target of the administration or deemed not to be in the “National Interest”, there are many other methods that can be used to compel you to obey - IRS audits, bank account seizures, or arrest and deportation outside of Habeas Corpus. But for organizations outside of the US, you now need to revisit your threat model and demand more from your US-based suppliers. Or move off of them altogether.