[kwlug disc.] Protecting confidential data on a server

[Paul Nijjar]

--- On Thu, 8/28/08, Richard Weait <richard at weait.com> wrote:

> 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? 

This is health-related data. 

The threat scenario is more like a laptop loss than like a data-server
breakin. I am more worried about somebody taking the hardware for drug
money than about a blackhat hacking into the system for fun and
profit.

Losing confidentiality could get us in trouble with the law, I think. 

Losing the data could conceivably make people die, but scrapping the
project out of data security fears means that more people definitely
die. 

Backups are important, and they obviously need encryption as well. But
that is a separate concern that could be handled in another way. The
real issue is how to keep this server up and running and useful while
keeping the data secure. 

> Second, secure a raise.  Not kidding.

Very funny. 

I would prefer avoiding responsibility to more money anyways. 


> Third.  Get good locks for all of the doors and control the keys
> with signatures and death lasers.  Okay, you can skip the
> signatures.  

The physical security is okay, but we did have a similar breakin with
a similar degree of security. "Don't let the server get stolen" is
advice I am taking to heart, but I think that encryption is a good
additional layer. 


> Fourth.  Why is the data on a remote server and how will it
> be used? 

It's database data, so it has to be live when people are using the
system. 

As for location: it is a reasonable point. There is a possibility we
could keep the server local, maybe. I will have to think about that.

As for Chris's point about not letting the server go down: the
physical machine has had reasonable uptime, although the application
in question has not. UPSes are definitely part of the equation, but
total failover-redundancy is not. 

> 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.  

I am unclear as to how this lets the server boot without needing a
password. Or is that not the goal?

Also: do you have specific buzzwords/technologies in mind here?

- Paul



      __________________________________________________________________
Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/