<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Thu, Aug 4, 2022 at 4:14 PM iang <<a href="mailto:iang@iang.org">iang@iang.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>On 03/08/2022 19:31, Phillip Hallam-Baker wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div 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 style="font-size:small"><br>
</div>
<div style="font-size:small">Data at
Rest</div>
<div style="font-size:small">Data in
Use</div>
<div style="font-size:small">Data in
Motion</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">This
gives us the acronym 'RUM'.</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Wow. It's good. How come nobody thought of that before?</p></div></blockquote><div><br></div><div><div class="gmail_default">As with 'Zero Trust', I am not the first person to use the term. There is a Wiki Page.</div><div class="gmail_default"><br></div><div class="gmail_default"><a href="https://en.wikipedia.org/wiki/Data_in_use#:~:text=Data%20in%20use%20is%20an,CPU%20caches%2C%20or%20CPU%20registers." target="_blank">Data in use - Wikipedia</a></div><div class="gmail_default"><br></div><div class="gmail_default">But this is talking about security concerns within a CPU which in the era of SPECTRE, ROWHAMMER, etc, are certainly valid but I don't think it is really getting to the distinction I am making.</div><div class="gmail_default"><br></div><div class="gmail_default">To be clear, the reason I am making this distinction is because I have a good solution for securing static blobs of data that does not apply to web applications, databases and the like. And the more I thought about the problem, the more I realized these are really two separate concerns.</div><div class="gmail_default"><br></div><div class="gmail_default">The distinction also got me thinking about new classes of attack.</div><div class="gmail_default"><br></div><div class="gmail_default">The Mesh can protect a confidential Word document on a USB drive. But that is not going to provide protection if there is a malware virus in the document that causes it to mail itself out to an attacker. Once Word read the document, it was data in use.</div><div class="gmail_default"><br></div><div class="gmail_default">There is quite a bit of writing on Data in Use on the Data at Rest Wiki page as well. But it doesn't seem to have received the systematic attention it deserves.</div><div class="gmail_default"><br></div><div class="gmail_default">Another really useful aspect of this distinction is that Quantum Cryptanalysis is absolutely not a concern for Data in Use. I am starting to think it of less important for data in motion as well. If you think data is so important you care about people possibly encrypting it in 2035 or beyond, then you really need to think about data at rest and full end to end security including storage. Sure, Mallet might collect data to decrypt later but the sheer volume of Internet data makes that utterly impossible to do except on a very limited scale.</div></div><div><br></div><div> </div><div><div class="gmail_default" style="font-size:small">If you go back Bruce Schneier wasn't the first person to say that security is risk management, not risk elimination. But he was the person who provided a book length systematic application of that principle. He established the term in the field.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The only people who seem to have used the term are the folk looking at the CPU level, hardware attacks and trustworthy compute modules. That is important work that is clearly distinct from data at rest. But go up the stack a bit to the database/Web application layer and we have a set of attacks that are being considered as 'data at rest problems' because the data is stored on the server but the reason the data is vulnerable is that it is in active use.</div><div class="gmail_default" style="font-size:small"><br></div><br></div></div></div></div>