[cryptography] Questions about crypto in Oracle TDE

Kevin W. Wall kevin.w.wall at gmail.com
Thu Nov 8 23:53:57 EST 2012


On Thu, Nov 8, 2012 at 11:25 PM, ianG <iang at iang.org> wrote:
> On 9/11/12 15:00 PM, Kevin W. Wall wrote:
>
>> I was only considering it because it seemed like it was the easiest way
>> to get from point A (plaintext SSNs) to point B (encrypted SSNs). Been
>> trying to get that done for almost 2 yrs. They've been putting it off
>> because
>> of the supposed effort and using TDE should minimize their development
>> effort. The question is whether TDE leaves us with acceptable risk,
>> hence my attempt to better understand it.
>
>
> my 20c
>
> I think this one of those compliance traps that we frequently allow
> ourselves to fall into.  "We encrypt our data" means it is secure.  The more
> nuanced risk expression that "we took reasonable mitigation steps to address
> the risk of data compromise" but what is reasonable?
>
> The false premise here is that encryption will secure the data.  That's only
> true in the public mind.  In reality, we discover that the data is so
> difficult to deal with that simple encryption just obfuscates it. E.g., the
> simple approach of ECB leads to salting which breaks indexing.
>
> In effect, SQL tables are mostly incompatible with straight encryption.
> However you explore this rabbit hole, you're still down deep inside it.
>
> The better answer is more like an architectural approach that provides a
> more holistic model.  But this is too radical to contemplate, as it might
> result in things like "SQL databases can't be secured..." which impresses
> no-one, least all vendors who pay salaries.
>
> So what to do?  One thing is to keep in mind that encryption isn't the
> answer, although it may be the compliance requirement.  Another thing is to
> keep firmly in mind that you're in a risk game - you are mitigating things,
> not removing them.  Whereas, Compliance means you tick boxes, and this is
> followed whether you decrease risks or increase them.

There is no "compliance" requirement per se, except our own corporate
requirements.

Looking at it from a risk perspective, we see the biggest concern as a
class action
lawsuit should a data breach of the customer SSNs occur. Hence the need to
do due diligence and follow "best security practice" which is
generally recognized
as encryption or hashing. (In this case, the SSNs need to be sent to
credit bureaus,
so hashing is not going to work.)  Lots of security turns out to be
CYA even when
it doesn't really do much other than help protect you from possible
litigation. That's
the way the world works. Try to explain to a jury that you didn't
encrypt the customers'
SSN because encryption doesn't really effectively mitigate risk and
the prosecutor
will be all over you. Keep in mind that juries are not made up of
fellow security peers,
but more from members of the blinking 12 club.

So yeah, are compliance checklists a crock? Mostly. The only value that I
see from them at all is without them, we would be hard pressed to get some
dev teams to do any mitigation.

> Maybe a partial solution will pop out that does a little bit of encryption,
> and a lot of separation, and a bit of governance...  Or note Morlock's post
> to use asymmetric crypto.  This works, but it does have surprising
> ramifications, such as making backups rather less scrutinisable.

Probably. Given that they are finally doing this at all, we certainly will
take the opportunity to check their application for the usual suspects of
SQLi, XSS, CSRF, etc.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein



More information about the cryptography mailing list