How SaaS Companies Avoid Compelled Access With Encryption

This blog takes an in-depth look at compelled access and how to keep it from being applied to data indirectly via service providers. Hang in there for the defense mechanisms later in the post.

Trust is the currency of Software as a Service (SaaS). More than money. The value of SaaS is that we have no day-to-day hassles in using software. The dark side of SaaS comes when we hand over our data and lose all control of who can access it.

If you think this overstates the case, ask yourself this: Can you name the people or even the titles of the people who have the power to view your data? Will you know if they exercise that power?

Before any SaaS vendor can make a sale, they need to convince the customer they deserve this power and will use it wisely.

“But,” I can hear you thinking, “no one actually cares that much about privacy.” Facebook keeps breaching the trust of its users and oversharing their data, but they still have 2.5 billion monthly active users.

You’re right. For many consumers, free trumps private. I concede the point. But only in the context of consumers.

Businesses Value Privacy

Businesses, as it turns out, care about the privacy of their data a great deal more than your average Facebook user. To these businesses, data is power and must be guarded closely. Loss of data can mean loss of business, lawsuits, large regulatory fines, and diminished competitive advantage. It can also tarnish a brand’s reputation.

So for a B2B SaaS company that wants to hold sensitive data, trust is paramount. And breaking that trust is doubly costly.

Categories of Data Access

When your customer is evaluating your SaaS company and how you will handle their data, they have three types of access to consider when evaluating trust. Here are the types and the questions they must ask themselves:

• Authorized Access: When a system processes data as expected, or when a customer accesses their own data, or — and this is where it can get interesting — when an employee of the SaaS company accesses the data for a legitimate purpose. Pretty much all Terms of Service agreements with SaaS companies allow their employees to access customer data for support and service delivery purposes.
  But is it okay for employees of this company to be authorized to see that data? If those employees may be citizens of countries that have a reputation for intellectual property theft, this can cause concern. It’s not uncommon for large Enterprises to insist that only XYZ citizens ever be able to access their data or for other authorized access constraints to be added.
• Unauthorized Access: When a system or user accesses data but does not have a legitimate purpose. Most people will associate this category with hackers and the compromise of systems or credentials. But it can also be a curious employee of the SaaS company with legitimate access but without a legitimate reason. 
  In evaluating trust, a potential customer must ask, ”How comprehensive are the SaaS company’s security measures? Are they doing all the right things to keep attackers out? How are they monitoring and auditing internal access to make sure internal access is legitimate?
• Compelled Access: When law enforcement or a national security agency for a government demands access to data (metadata or content, depending on the case) via legal means like a subpoena, national security letter, or warrant. Or in civil scenarios where a court orders data to be turned over in the course of litigation.
  Companies need to ask what jurisdictions may have access, what opportunity they get to fight the request, whether the request will be fought on their behalf if there’s a gag order, and whether this is even something to worry about.

The first two are somewhat obvious and well covered, but compelled access is a surprisingly hot button for large companies today. The rest of this post will look more deeply at compelled access, trends, and why it matters.

What’s Wrong With Compelled Access?

Why wouldn’t everyone just hand over their data if asked by a government — their own or one in which they do business? It’s a good question. Law enforcement needs court-signed warrants, subpoenas, or court orders to get access to data, and these theoretically have built-in checks and balances. Valid government requests for data are an important part of a functioning society.

So why are companies concerned?

1. Warrant Overreach

Not many SaaS companies pledge to push back against warrants and subpoenas, and even fewer provide transparency stats on this. But Google, Amazon, and Microsoft do push back and do provide stats, and these stats paint a picture of frequent government overreach.

Google, Amazon, and Microsoft each pledge to redirect government requests directly to their customer. If that fails, they pledge to tell the customer about the request so the customer can fight it if desired. If they aren’t allowed to tell the customer, they pledge to push back against overreaching warrants including ones that are overly broad, under specified, or where there’s a question of valid jurisdiction.

Across these companies, more than 1 in 4 of all compelled access requests are invalid. This is stunning because it means that warrant overreach is pervasive and systemic. Here are the stats from the most recent 12-month periods at each company:

• Amazon in 2019: 5,041 requests, 30% rejected
• Google mid 2018 to mid 2019: 138,517 requests, 30% rejected
• Microsoft mid-2018 to mid-2019: 45,618 requests, 22% rejected as not meeting legal requirements and another 15% rejected because the requested data was not found.

Google Compelled Access Requests Over Time

2. The CLOUD Act and Data Residency

Espionage is a worry for some companies — especially those who sell to the defense industry, which can include telecommunications companies, software companies, car companies, and many others.

After the Patriot Act was passed following 9/11, a lot of non-U.S. companies became very wary of storing their data in the U.S. Many SaaS companies had to stand up European and Canadian data centers to handle these concerns. Some of this was company policy, but in other cases countries passed data sovereignty laws forbidding citizen data from leaving the country. This was driven by the fear that the U.S. would abuse its powers to peek at everyone’s data.

A decade later, Edward Snowden proved these fears accurate.

In the same year that Snowden dropped his bombshells, the U.S. tried to use its power to access data on Microsoft servers in Ireland. Microsoft fought that request, won on appeal, but then had the case declared moot by the Supreme Court after the passage of the CLOUD Act. A new warrant was issued under that act and, we presume, the U.S. finally got what it wanted.

Google’s CEO of Cloud (GCP and G-Suite), Thomas Kurian, has been writing a lot about why Google is trustworthy and why customers shouldn’t worry about the CLOUD Act:

The CLOUD Act and the recently announced U.S./UK Agreement do not change our position and have not changed how we at Google address government requests to disclose enterprise customer data. Our team reviews and evaluates each and every one of the requests we receive for legal validity and appropriate scope, as well as for compliance with international human rights standards, our own policies, and applicable law. We do not provide “backdoor” direct access to any government and we do not hesitate to protect customer interests.

That last sentence is a reflection of what they are hearing from some security-sensitive customers. The worry is that certain governments, and especially the U.S., can easily and secretly gain access to data held by Google.

Amazon is similarly battling perceptions around the CLOUD Act. A recently released policy paper arguing against data residency laws addresses it extensively:

The CLOUD Act provides a new framework for challenging law enforcement requests when there are executive agreements in place between the U.S. and another country, and it also confirms, under principles of comity between nations, the right of service providers to resist disclosure of any data if doing so would conflict with another country’s laws, even in the absence of an executive agreement.

So Amazon effectively says, “yeah, we might get requests from various countries, but we don’t have to respond back with data.” At the same time, because they’re arguing against data residency, they point out that these agreements are bidirectional so it doesn’t matter what jurisdiction the data actually lies in (note: CSP = Cloud Service Provider):

The MLAT, Letters Rogatory, and Executive Agreements under the CLOUD Act all provide reciprocal international legal mechanisms for law enforcement access to data stored overseas. … Restricting CSPs to one jurisdiction does not better insulate data from governmental access.

That’s an interesting point, but let’s see how it works in practice:

• Amazon response rate for U.S. data requests: 70%
• Amazon response rate for non-U.S. data requests: 1% (6/498 in 2019)

So it appears that the U.S. has a huge advantage in compelling data from U.S. service providers and the bidirectionality, in practice, is mostly for show.

3. Not Everyone Pushes Back

While Amazon, Google, and Microsoft all have legal teams who regularly push back against warrants and court orders that are overly broad or exceed the authority of the requester, there are many SaaS companies that make no such public promises and that don’t publish transparency reports.

Salesforce is one such company.

As far as I can tell from their website and privacy policy, they respond to all law enforcement requests:

We process your Personal Data when cooperating with public and government authorities, courts or regulators in accordance with our legal obligations under applicable laws

If Salesforce were a smaller company, this wouldn’t be surprising. But Salesforce is one of the largest SaaS companies in the world. And they’re conspicuously silent about how they deal with law enforcement and court-ordered requests for data. They don’t even publish transparency reports.

In this regard, unfortunately, Salesforce is more the norm than the exception. But before you accuse us of hating Salesforce, read on to see how they end up being exceptional.

4. Few Technical Protections Available

Many companies talk about giving customers control of their data. The earlier blog post by Thomas Kurian is titled, “Advancing customer control in the cloud.” But in the context of compelled access, “control” really means a mechanism by which governments seeking data must go to the originating company instead of the service provider.

Google and Amazon don’t hesitate to make the points that you can always encrypt data before sending it to them and then you’re fine. But as great as client-side encryption is (and we’re both fans and vendors of this technology), it isn’t always feasible unless the service provider has features to support it. And these don’t.

The one large SaaS company that has a technical solution to resist subpoenas is the same company we just shamed for not pledging to push back on compelled access requests: Salesforce.

Salesforce Shield is a premium security and privacy offering that includes Platform Encryption, which gives companies the ability to encrypt certain fields in the database at the application layer. Salesforce has possession of the encryption keys that can unlock the data, but they store the keys outside of the main database storage.

According to a source who used to work there, when Salesforce receives a subpoena, they clone a customer’s main database data into a clean room and then extract the requested data parts from there. But that clean room does not have access to the key management servers. So if column B is requested and that column is encrypted, the requesting law enforcement agency gets random looking and useless data for that column.

If the agency seeking the data should complain about it being useless, Salesforce explains that it would require software changes to produce the data and that would leave audit trails and be generally known. But, if they want, the agency can still compel the data directly from the company that owns it.

Salesforce doesn’t publicly claim subpoena resistance, but they have it. And to my knowledge, this makes Salesforce the only major platform with technical protections that put their customers in control of their own data.

Note: Platform Encryption is a premium feature sold for a 20% of net upcharge. The full Shield suite is a 30% upcharge. Not all customers have this option and these protections.

Compelled Access Is Manageable With Encryption

The goal for companies who are concerned about compelled access is to have those requests go directly to them instead of their service providers. It isn’t about rejecting a request so much as making sure it isn’t invisible and unchallenged, if appropriate.

Salesforce, Box, and Slack all offer premium encryption options where customers can hold their own keys. If done right, this provides customers of those platforms with control over their data for compelled access requests by encrypting the data at the application layer and by separating the keys from data.

Because these are all server-side encryption solutions, curious administrators can still potentially see data, but the audit trails are strong and revocation is in the customers’ hands.

A stronger security model comes with client-side encryption where the service provider is unable to decrypt the data they hold. Google and Amazon recommend this to their customers who are data sensitive. I’m not aware of any large SaaS companies that have built this capability into their software instead of putting that burden on their customers.

A Quick Plug for IronCore CMK and Zero Trust SDKs

At IronCore, we’ve talked to many large companies who want these features from their SaaS vendors, but the vendors tell them it’s too hard to build. And if they were to build it themselves, that would likely be true. This is what we do at IronCore and we have solutions that accelerate privacy and security features on the roadmap.

For the server-side encrypt model used by Salesforce and others, IronCore offers a packaged solution for SaaS providers called IronCore CMK. It’s easy to integrate, so the excuse that it’s too hard or not feasible doesn’t hold water.

And for those who want zero-trust options or client-side encryption, IronCore has a solution for that, too. SaaS vendors can integrate IronCore’s Zero-Trust SDKs to give customers ultimate control of their data.

Conclusion

SaaS is a beautiful thing. It requires trust, but trust, like risk, is hard to quantify. Not everyone has the same trust needs, risk tolerance, or threat model.

Data-sensitive companies who worry about things like compelled access requests should stop asking nicely for the features they want. These features are proven to increase security and privacy. The excuse that it’s too hard is weak.

Salesforce Shield has been around since 2015, but the rest of the SaaS industry is lagging.

It’s time to make data control a standard feature in enterprise tiers of SaaS offerings, but the only way this will happen is if large SaaS customers force the issue and vote with their wallets. To the SaaS companies that offer these features go the dollars. Renewals and new sales should be tied to promises to deliver. I’m not unbiased here, of course, but I truly believe the time has come for companies to be able to control their data even when it lives beyond their borders.

Please join me in making this a reality.