<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Data at Rest</div><div class="gmail_default" style="font-size:small">Data in Use</div><div class="gmail_default" style="font-size:small">Data in Motion</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This gives us the acronym 'RUM'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Separating the two buckets means that we can tell people that they should apply the principle of least data separately to both. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Is this data we need to collect and store at all?</div><div class="gmail_default" style="font-size:small">2) Is this data that we need to access in this particular Data-in-Use system?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So basically the approaches to securing the different parts of the triad are:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">Data at Rest: Cryptography</div><div class="gmail_default">Data in Use: Audited process, Least privilege, Single point of control, some cryptography</div><div class="gmail_default">Data in Motion: Cryptography</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Comments?</div></div></div></div>