23

I work as a solutions architect for web-based systems on AWS. As part of this role, I often respond to Information Security questionnaires. Nearly all questionnaires request information about data encryption at-rest and in-transit. However only a much smaller percentage ask about other security aspects, such as password policies or common web application security issues, as published by OWASP.

I wonder how common/likely accessing of clients data is within a public cloud provider such as AWS, Azure and GCP. It seems a very high barrier to pass for an external party, even data centers of small local web hosting companies seem to have very good physical access security. And informal conversations with bank employees tell me that accessing someone's bank account without reason leads to instant dismissal, so surely public cloud providers would have similar controls in place?

This is not to challenge the value of encryption at rest, it is very cheap to access, so there is no reason not to enable it, but where does it sit in terms of priorities?

schroeder
  • 123,438
  • 55
  • 284
  • 319
jdog
  • 355
  • 2
  • 7
  • 1
    Can you clarify what you mean by encryption at rest? If it's "with the key stored right beside the data" (or in the physical possession of the same party), it's entirely snake oil and has no security value whatsoever. If you can arrange for the key to live somewhere else you have more control over, though, it has extremely high value, and essentially mitigates all the badness of "somebody else's computer" (the definition of "cloud"). – R.. GitHub STOP HELPING ICE Sep 13 '20 at 18:10
  • 2
    @R..GitHubSTOPHELPINGICE My experience with these sorts of questionnaires is that they contain no guidance, only boxes to be ticked, and that those boxes can indeed be ticked by systems that keep the encryption keys right next to the data. Systems that keep the encryption keys far away from the data are better (and of course also tick the box), but can be hard to orchestrate, especially if part pf the key lives in a human's head, and new servers need to be provisioned automatically (e.g, for autoscaling) – James_pic Sep 14 '20 at 08:44

2 Answers2

37

Your threat model is focused on external parties breaking in. But the threats are broader than that.

Low-level hardware backups, VM snapshots, and disposed hardware can all contain data. And because these things tend to be seen to have lower risks, they are often mishandled. So, it's not a "Mission Impossible" style of threat that is likely. It's the "eh, the drive is old, just toss it" style of threat that's the problem. Even for large cloud providers.

And because, as you say, it's cheap and easy to implement encryption-at-rest, to not implement it is its own cause for concern and follow up questions.

Human factor issues, like password policies and secure coding practices, are also very important, but difficult to assure, insure, and be consistent. So, technical controls tend to be the focus, regardless of the overall priority.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 2
    Thanks! I had not thought of disposal – jdog Sep 13 '20 at 21:38
  • I have a case on archive of a hosting provider that implemented encryption at rest so badly when we had a new SAN provisioned we had somebody else's backups on it. I only discovered it when trying to find why the disk filled up too soon. – Joshua Sep 14 '20 at 04:10
  • 6
    'It's the "eh, the drive is old, just toss it" that's the problem. Even for large cloud providers.' - I do not know what they do at Amazon, but I can assure you that this is Not Done at Google. See [discussion here](https://cloud.google.com/security/deletion#ensuring_safe_and_secure_media_sanitization). – Kevin Sep 14 '20 at 08:42
  • @Kevin could you post that as an answer? – James_pic Sep 14 '20 at 08:47
  • 2
    @Kevin yeah sure, but that's a multi-step process that must be followed exactly. There is room for errors and mistakes. The fact that Google has such a robust and complex process only highlights the problem I mentioned. The fact that process exists *supports* the idea that the problem exists, is a risk, and needs mitigation. – schroeder Sep 14 '20 at 08:53
  • 4
    @schroeder: I agree with you that customers should (probably, in most cases) use encryption at rest on top of the cloud provider's (presumed) full-disk encryption. In some cases there may be compliance issues (PCI-DSS, HIPAA, etc.), and it is unrealistic to suppose that you're immune to insider risk, application bugs, side channel attacks, and the like. I'm simply stating that, in general, large cloud providers do *not* take an "eh, whatever" approach to hard drives, as your answer's current wording suggests. – Kevin Sep 14 '20 at 08:58
  • 4
    @kevin My wording does not suggest that. I'm saying that the risk, in general, is more likely to be media mishandling than an unauthorised person gaining physical access, which is what the OP focues on. – schroeder Sep 14 '20 at 09:00
  • 1
    It's not necessarily "just toss it". It may be planned to dispose off properly, then a box with a thousand disks would accidentally fall off the truck. – sharptooth Sep 15 '20 at 10:50
4

This is not to challenge the value of encryption at rest, it is very cheap to access, so there is no reason not to enable it, but where does it sit in terms of priorities?

It is cheap when you use the lower layers to do the encryption (disk for instance). It gets expensive (in terms of architectural and code design) when you want to encrypt data at rest by the application itself (especially for multi-user accesses).

Lower-level encryption is good against physical theft and media mishandling but from the perspective of the application, it accesses plaintext data. This data is also available as plaintext to the cloud company administrators (or not - it all depends on the features of the storage service)

If you have an application that takes care of its own encryption and does not rely on the cloud provider at all you can go for more "hostile" environments (where you are not sure the administrative operations are reliable). I am not versed well enough in memory-based attacks to know whether it is feasible to completely protect the credential there but I suppose that this is not possible when everyone is against you.

In summary: the more you manage your encryption, the more independent you are, and provided that encryption is done right - the more secure your data is against direct snooping.

so surely public cloud providers would have similar controls in place?

I was discussing recently with one of the providers you mentioned. To the question "will you log the access of your administrators to our data?" the answer was "no" (plus a lot of chit-chat on how they would never access the data without authorization yada yada yada - the point was that they do not know who accessed what in the first place).

It was not even that the logs can be manipulated by administrators, or extreme demands are made we would not know about (based on governmental requests that must keep from us), or other similar scenarios - it was just that there was no logging full stop.

WoJ
  • 8,957
  • 2
  • 32
  • 51