[Cryptography] Data in Use

[Phillip Hallam-Baker]

So I got into a Twitter argument with Kenn White about the value of 'Data
at Rest' security and I think I came up with a more general insight. In
short, the traditional Data-in-Motion / Data-at-Rest diad is insufficiently
descriptive. What we really have is a triad:

Data at Rest
Data in Use
Data in Motion

This gives us the acronym 'RUM'.

The reason for making the distinction is that if you have a Web application
or a database actively reading and modifying your data, it is really not
'at rest' in any useful sense. It is something different that is going to
require us to take a very different approach.

Data in motion covers all bits on the wire concerns. So SSH, TLS, S/MIME
and OpenPGP are all Data in Motion security controls. Data in motion
breaches are pretty rare because we are pretty good at encrypting bits on
the wire.

Data at rest covers all security concerns for fixed blobs of data. Storage
level encryption provides one layer of protection, document level security
another. S/MIME and OpenPGP are also Data at Rest technologies because
email is not just the SMTP transmission protocol, it is also IMAP which is
a storage infrastructure.

Data in Use comprises all the security concerns that arise from bridging
the gap between the data and a network with some form of application. This
includes databases, Web applications, etc. etc.

Currently Data in Use is the one we have not solved. So you can accuse me
of a cop out, defining the types of breaches the Mesh does not address as
'something else'. But I don't think that is fair because distinguishing a
very difficult problem we can't solve from the problems we can provides us
with the starting point for a solution.

One very powerful technique for securing Data in Use is to reduce the
amount of tate in Use to the absolute bare minimum. So often we see
breaches of databases containing PII, names, addresses, social security
numbers, credit cards. And only very rarely is this PII actually required
by the application itself. To reduce the amount of data in use, we take
this data out of the database itself and turn it into Data at Rest, storing
it as chunklets of encrypted data whose use can be strictly limited to the
applications that have actual need to access it.

I am still massively skeptical of the practicality of homomorphic
encryption and so for me the solution to Data in Use is going to lie in
concepts like Separation of Roles, Least Privilege, Audit, Accountability,
etc. etc. And we should probably add 'least data' into that mix.


Least data didn't make much sense as a slogan when we considered Data in
Use and Data at Rest as the same thing. Much of the time it is impossible
to get rid of the PII completely. It is needed to make the system function.

Separating the two buckets means that we can tell people that they should
apply the principle of least data separately to both.

1) Is this data we need to collect and store at all?
2) Is this data that we need to access in this particular Data-in-Use
system?

If the answer to (1) is no we just get rid of the data. If the answer to
(2) is no, we require that the data only be encrypted at rest and not be in
the in-use system. If the answer to (2) is yes, we have to ask it again of
every in-use system we create.

So basically the approaches to securing the different parts of the triad
are:

Data at Rest: Cryptography
Data in Use: Audited process, Least privilege, Single point of control,
some cryptography
Data in Motion: Cryptography


Comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220803/6ec4e954/attachment.htm>