Following an executive order (EO 13984) in early 2021 from former President Trump, the U.S. Department of Commerce has proposed new cybersecurity requirements for infrastructure-as-a-service (IaaS) providers, including cloud service providers (CSPs) such as AWS, Google and Microsoft Azure. While everybody likes the idea of better cybersecurity, it seems clear that EO 13984 won’t deliver that. In fact, as currently framed, it would create new burdens on IaaS providers without delivering real security benefits.
The good news is that right now this regulation, poetically titled “Taking Additional Steps to Address the National Emergency with Respect to Significant Malicious Cyber-Enabled Activities,” is still in the feedback stage more than two years after the EO was issued. Before it goes into effect, there will need to be dialogue about how the industry can best improve cybersecurity and public safety.
In this piece I’ll explain why EO 13984 risks creating new problems while also not actually improving cybersecurity. Plus we’ll look at a few alternative measures that a sensible revision of this regulation needs to include.
What EO 13984 proposes
The EO aims to deter malicious online actors by requiring U.S.-based IaaS providers to establish the true identity of their non-U.S.-based customers. This is similar in its intent to the know-your-customer (KYC) rules imposed on the financial industry that aim to prevent gangsters and terrorist organizations from using U.S. banks to launder money.
The goal is admirable, and it would be nice if somehow this measure could help prevent, let’s say, the use of a CSP to host command-and-control servers to orchestrate some kind of cyberattack on U.S. organizations. But it won’t achieve that, for multiple reasons, which is why CSPs, industry groups and think tanks such as the Information Technology and Innovation Foundation have been at pains to articulate their reservations about this EO.
Why EO 13984 won’t improve IaaS cybersecurity
For starters, the measures intended to better identify customers are neither practicable nor effective. The regulation wants CSPs to require further identification for non-U.S. customers, something beyond the usual name, phone number, email address and payment info they already collect. And, sure, the CSPs could insist that foreign customers supply a government-issued ID, a physical address and so on. But to what end?
Forbes Daily: Get our best stories, exclusive reporting and essential analysis of the day’s news in your inbox every weekday.
Before we go any further, it’s worth noting that it’s not easy to distinguish domestic customers from foreign ones at all. So the regulation would effectively require that the CSPs nail down the identities of all customers, foreign or domestic. Doing that would require time-consuming validation steps well beyond what any of these companies are able to do today, including the evaluation of ID documents from many different countries in a wide variety of languages. And that’s before we get to the legitimate privacy concerns many customers will have about sharing their sensitive personal or business documents.
Unfortunately, it is quite easy for well-resourced people to make themselves look like normal end users when they’re not, and the measures in the draft regulation will be trivially simple to bypass for all but the least sophisticated cybercriminals. Any bad actor with even a little bit of savvy won’t tell you what country they’re actually coming from, and they’ll use IP spoofing, a VPN, a proxy setup, a U.S.-based telephone number and a stolen identity to mask their real location. Also, no bad actor would ever admit to being a non-U.S.-based customer, so they wouldn’t upload any identity card or business registration document, fake or otherwise. There are even simple schemes that allow malicious users to correlate a phony mailing address in the U.S. with the physical neighborhood where their IP address is supposedly located.
So much for identity. When it comes to customer activity, there’s also a lot that CSPs can’t figure out about their users because—for very good reasons—the companies don’t have access to the contents of their customers’ compute or storage environments. Microsoft Azure, Google, AWS and the rest basically provide the cloud-computing envelope, which means they can see only certain external actions like DNS lookups and the flow of packets in and out.
What goes on inside the envelope is none of their business, and in fact all of these CSPs have built fail-safes to prevent anyone, including themselves, from seeing inside. They do this because legitimate organizations like banks, hospitals and government agencies have plenty of use cases where they would be very unhappy, not to mention possibly subject to legal penalties, if their data got into the wrong hands—including the hands of their IaaS provider.
There’s also the issue of IaaS resellers. There are formal resellers who contract with bigger CSPs to sell cloud capacity; these vendors are obligated to inform the CSP who the end customer is, but they face the same constraints for IDing users already mentioned. There are also informal resellers that run a bunch of containers on an IaaS instance and then privately sell access to those containers to whomever they choose. In cases like these, the CSP typically won’t even know that there are end customers separate from whichever entity is paying for the instance.
The U.S. Government is concerned about potential nefarious activity by the end users who are hidden in this arrangement, and rightly so. But there may be no technical means available for the CSPs to enforce a ban against this sort of reselling, because their entire systems are built to prevent any kind of snooping inside containers. The CSPs can revise their terms of service to make such reselling a contractual violation, which means they could evict informal resellers if they do come to light. But that’s about it.
And then there are situations in which legitimate customers of the IaaS providers have their computing environments hijacked by malicious actors. This could be as simple as an innocent customer who misses a critical patch for their WordPress site; a bad actor might take over that site’s virtual server and use it in a command-and-control attack, for example. The CSP might be able to detect this based on a pattern of anomalous activity, in which case it would work with the customer to secure the server. But that would be based on smart monitoring of behavior—more on that below—and KYC-type user identification would be no help whatsoever.
EO 13984 will create new problems
The broader hardships created by this EO go well beyond the extra money and effort required for vendors to go through the kabuki dance of checking the IDs of bad actors who can easily circumvent what they’re trying to do. I’m thinking here of the harm the regulations will do to U.S.-based IaaS providers in the marketplace, to developers looking to innovate and to global privacy concerns.
The rest of the world doesn’t always love that the top three IaaS providers are U.S.-based companies—AWS, Google and Microsoft. These providers, along with their nearest IaaS rivals Oracle and IBM, are already sometimes seen as being too close to the U.S. Government. This EO, with its burdensome ID requirements, will give legitimate foreign organizations even more reason to dislike these vendors and do business elsewhere – all while slowing down developers looking to leverage IaaS providers so they can innovate. It’s not the job of the U.S. Department of Commerce to erode the competitive position of U.S. firms in the global marketplace. In fact, that’s the opposite of Commerce’s job.
That’s before we even get to the big cross-jurisdictional can of worms this EO would open up for U.S.-based companies doing business in the EU and elsewhere. There are already significant differences in regulatory philosophies across these jurisdictions, which have led to big strains between the U.S. and its allies when it comes to enforcement. To take one obvious area of dispute, data collection and data flows between the U.S. and the EU have been delicate subjects for years, and those tensions weren’t helped any by the recent $1.3 billion fine levied against Meta for violations of the EU’s GDPR rules. EO 13984 would only further complicate those issues.
It gets worse, because it’s not even clear exactly which U.S. companies besides CSPs these regs would apply to. What about, say, VPN vendors? Or colocation providers? How far does this reach? The EO needs better definition so that everyone knows exactly which companies are affected.
There’s still time to get this right by focusing on best practices
As I said above, to achieve more robust IaaS cybersecurity, we need to expand the dialogue between the Department of Commerce and the companies affected by the regulation. That dialogue should draw heavily from best practices already being used within the industry, or new ones that are highly feasible to adopt. The best-practices approach has been employed with success in other tech sectors such as wireless telephony, and it works a lot better than imposing rigid mandates that might sound pretty good in a Washington conference room but that break down immediately upon contact with the real world.
One thing the regulators will do well to remember through this whole process is that an online user’s identity isn’t a yes-or-no, black-or-white fact. It’s always tied to a continuum of indicators of truth, any of which can be faked to some degree. If someone’s really determined to misrepresent their identity online, they will. So while of course you want to make misrepresentation harder, that works only up to a point.
When someone signs up for an IaaS account, it makes sense to verify their email address and phone number (maybe forbidding VOIP numbers, which are more prone to abuse), as well as their means of payment. Possibly you check their originating IP address against their purported location to weed out any obvious scams. These are the basics, many of which were put in place over the years to guard against fraudulent users and identity theft. The IaaS providers are already very good at enforcing steps like these, which only helps them achieve broader cybersecurity objectives.
As a new customer begins using an IaaS platform, you start them off with a limited set of resources that they can ramp up over time. In other words, you don’t make it easy for them to quickly light up a lot of infrastructure and misuse resources. The CSPs already have many other measures in place to protect against malicious actions such as email spamming and phishing attacks, reply-address spoofing, amplification attacks and so on. Again, these are very useful links in the chain for effective cybersecurity.
As the new customer gets going, you use automated analytics backed by machine learning models to determine whether their usage patterns match typical behavior. Having covered IaaS companies for many years, I can tell you that their security teams are diligent, knowledgeable and highly proactive in their efforts to prevent any kind of malicious activity. They take these risks seriously, and they’ve put all sorts of measures in place to detect problems and nip them in the bud.
In fact, a best-practices approach tied to EO 13984 may help CSPs ratchet up their security practices based on identifying and sharing the smartest approaches to detecting malicious activity by IaaS customers.
The best regulations balance costs and benefits
The IaaS providers don’t want cybercrime any more than you or I do. But over-regulation won’t help them to do their jobs better, or to keep us all safer. That’s why we need a smart approach to revising this EO—and issuing the rules to implement the EO.
I’m hopeful that the continued cooperation of the CSPs and related industry groups will keep advancing the conversation. Sometime this summer, the White House should also receive valuable input on this topic from the senior tech executives who make up the National Security Telecommunications Advisory Committee (NSTAC). The members of NSTAC are ideally positioned to help President Biden and the Department of Commerce choose a wiser path here.
That definitely needs to happen, because the proposed regulation as it stands today won’t work. It’s one thing to be skeptical about a regulatory measure if the burden seems too heavy and the value is too minimal; you do a cost-benefit analysis and figure out whether the value is worth the burden. But in this case, there is no normal cost-benefit analysis—because there’s just no benefit. We need to find a way forward that helps everyone. That’s why we must do better on EO 13984.