× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 :-)



-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
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
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Matt Olson <Matt.Olson@xxxxxxxx>
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 [mailto:sue.baker@xxxxxxxxxx]
Sent: Friday, February 14, 2014 3:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Security and SSD

Matt Olson <Matt.Olson@xxxxxxxx> 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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.