Re: Security and SSD

On 2/18/2014 3:21 PM, Matt Olson wrote:

I think most logical people would choose SED drives if they had the choice. All other protection mechanisms like what Tim is stating still apply.

You seem to imply that data encryption at rest is "big whoopee", and would rather leave data at rest UNENCRYPTED.

Hope you don't get PCI audited one of these days :-)

To clarify for lurkers, three scenarios have been discussed in this
thread so far:

1) Hacker has your SSD (like a stolen laptop)
2) Hacker wants unauthorised access to your data
3) Authorised user wants access to your data

If a hacker has your unencrypted IBM i SSD (as in I sold it during an
upgrade) then it is possible, however remotely, that she will extract
PII from it. Encryption at rest helps here, whether implemented via
software or hardware.

If a hacker makes it into your system via QUSER QUSER and public
authority is *USE on all your tables, she will be reading not just
fragmentary PII, but the whole thing. Encryption at rest helps a lot
here, unless your security scheme has public authority *USE on the
decryption blocks (the code used by your authorised users: UDFs, etc).
In which case, your authority scheme has undercut your SED SSDs and your
PII is, well, public.

If an authorised user has access to the decryption code (UDTF, UDF, API,
etc) then she can probably pull a list of customers, etc via her current
UI whether it be green screen or whatever. Encryption at rest doesn't
help secure PII in this scenario. Proper application design and
reasonable authorisation schemes will.

It seems to me that the authorisation scheme is at least as important as
SED; maybe more, given that poor authorisation choices can undermine the
benefits of encryption at rest.
--buck

-----Original Message-----
From: rob
Sent: Tuesday, February 18, 2014 10:53 AM
To: Midrange Systems Technical Discussion
Subject: RE: Security and SSD

Yes there are a lot of vendors selling software based solutions to encrypt your data at rest. However we're talking about two different things here.
One, querying your data from your applications.
Two, being able to use tools to read the disk, even from from another OS, to see the data (like after a disk sell after an upgrade or whatever)

Keep in mind that if you are using 24 disks your data may be spread across all 24. To go "NCIS" on them and read the data from disk independent of the OS, and read the entire data file would require that you can once again string all the drives together. Now, due to blocking, you may be able to get small snippets from a drive here and a drive there. One row from one table may fit into that same block and all be on one drive. And if that row contains your name, SSN, etc, I can understand how you may be concerned. Encryption would help.

But as far as encryption from your applications, that's another matter. I suspect that many people are bombarded from 'regulatory agencies' and other do-gooders who insist upon encryption. So, you use some built in disk encryption tool and, yes, your data at rest is encrypted. Big whoopie. Someone runs this:
select name, mothersmaidenname, ssn, yearlysalary, creditcardnumber from myfile and the hardware disk encryption automatically decrypts it and presents the data.
So, now they go with a more software encryption technique. In which the columns have to be run through something like select name, mothersmaidenname, decrypt(ssn, key), yearlysalary, decrypt(creditcardnumber, key) from myfile (syntax is incomplete, just go with it) so now they need the key. This leaves you with a few choices.
You can bury the key in every application. First person to look at the source now knows the key.
You can externalize the I/O. All the rage from the person who codes externalized I/O. Not so favored by anyone who has to use someone else's externalization routines and can no longer use SQL.
You can create a view that has all the decryption performed automatically.
create view myfileVIEW as (select name, mothersmaidenname, decrypt(ssn, key), yearlysalary, decrypt(creditcardnumber, key) from myfile). So the table is 'encrypted' and now the person can simply do "select name, mothersmaidenname, ssn, yearlysalary, creditcardnumber from myfileVIEW".
Probably gets the regulatory agencies off your back because technically your data is 'encrypted' but is it really that secure?


Rob Berendt

From: Matt Olson
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/18/2014 10:17 AM
Subject: RE: Security and SSD
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I'm purely talking data at rest security here.

Lots of vendors out there selling software based solutions to encrypt your
data at rest. My point is, most of them are worthless IMHO with the
advent of hardware level encryption that is built into SED drives.

If I had my choice between NON-SED drives and SED drives (in any
environment, enterprise or otherwise) I would always pick SED drives
wouldn't you?

Matt



-----Original Message-----
From: Sue Baker
Sent: Friday, February 14, 2014 3:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Security and SSD

Matt Olson wrote on Fri, 14 Feb 2014 16:00:45 GMT:

purchase SED drives (self encrypting drives) and you can just wipe the
drive clean in milliseconds by destroying the crypto key on the drive.
Software based encryption on the host is a dead technology in my
opinion.

This is a false sense of security. Data encrypted at rest simply means
that if someone gets their grubby mitts on a device they cannot read it
without first acquiring the key. Something that is good for personal
devices but not necessarily so good for corporate servers. Most corporate
servers have some level of physical security making it a very low odds
item to have hard drives or SSD take a wander.

What sends chills down my spine is people believing that SEDs or
encryption of data at rest somehow protects the data from individuals who
have no business accessing the data. In other words, the data can be
easily read, downloaded, etc. by anyone who can log on to the system.
Which means in many cases, it can be downloaded to the oh so insecure
laptop and ....... well, I think you get the picture.

--
Sue
IBM Americas Advanced Technical Skills (ATS) Power Systems Rochester, MN