[kwlug disc.] Protecting confidential data on a server

[unsolicited]

Richard Weait wrote, On 08/28/2008 11:17 PM:
> On Thu, 2008-08-28 at 19:18 -0700, Paul Nijjar wrote:
>> Dear Ann Landers, 
>>
>> I have a bad feeling about asking this question, but here goes: I have
>> some data on a Linux server that needs to stay confidential even if
>> the computer in question is stolen.
> 
> First, evaluate.  "Needs to stay confidential" as in what?  What if it
> doesn't stay confidential?  Will this cost you time, money, standing
> among your peers?  Or prison time?  Will people die?  Can you back it
> up?  If the bad guys get the machine but can't read the data, and you no
> longer have access to the data, is that "bad"?  As bad as disclosing the
> data or worse?  Is it better for everybody if you just shred the data
> and don't have it at all?  
> 
> Second, secure a raise.  Not kidding.  Really.  Remind your boss that
> you are responsible for building and maintaining the system that will
> keep her out of prison.  Get small non-sequential bills.  Count them.   
> 
> Third.  Get good locks for all of the doors and control the keys with
> signatures and death lasers.  Okay, you can skip the signatures.  
> 
> Fourth.  Why is the data on a remote server and how will it be used?  Is
> it read from one of your local devices periodically?  How is it
> protected on that device when read?  How is the confidential data
> updated?  Remotely?  How is it protected on the origin when it is sent
> to the server?   
> 
> Fifth.  I'm thinking remote encrypted filesystem owned by a remote user
> who can only log in with a certificate.  Lock the certificate with a
> password.  So now you are two-factor for the connection, then password
> to the encrypted fs.  
> 
> But it might just be better to plain-text it on a USB drive and lock it
> in the safe.

Richard really ISN'T over the top here.

Do you have encrypted backups too? How about stuff people store 
locally? Why was it allowed to get there? What about while the data 
travels over the wire, even on the internal network?

Your questions and concerns are most certainly valid.

Is, perhaps, the solution to have each record encrypted? The app, or 
whatever, perhaps local certificates, kicks in at each read/write?

For sure, the DoD has something it considers the ultimate in security, 
presumably the first step is to prevent it from being stolen in the 
first place. Who has the keys to the server room doors? If it's not a 
physical Medico key, when was the last time the access code was changed?

It all probably goes back to the cost / benefit risk analysis? If your 
data gets into the hands of the wrong people at the wrong time, what 
is the worst that can happen? Dollar wise. So how much are you willing 
to spend to protect it?

Probably you have insurance coverage - probably the best place to 
start is to ask them what they consider adequate / appropriate 
practices. Then ask what it would take to lower your premium, security 
/ hardware / software / practice wise.

Surely there's a best practices or white paper out there that someone 
can point Paul towards.

Surely the encrypted file system people understand these barriers are 
present, and most probably have some solutions.

But the best solution would seem to be - don't let it get stolen in 
the first place. Perhaps it auto shuts down if a bluetooth request 
doesn't get returned with a certificate? Long before SQL starts up.

You can't assume if they steal the server they won't be stuffing the 
disks in a different computer. The encryption must be at the disk / 
file / record level.