1

I stand before the following task: A VMWare "template" (based on SLES11) with custom software, that is to be distributed to some clients. They will receive a client specific copy of the template and should import it to their local ESX server. BUT! they should not get any local access!

There are two parts to consider:

1) If the image itself is not encrypted, it could opened while not even running and the data could be extracted or worse: changed. Or somebody could just alter the boot process and start up a SLES rescue image and then mount the image partitions

2) The obvious solution would be to encrypt the virtual disc, and ask for a password at the boot loader (e.g. truecrypt) - but the client should not know the password and I will not enter it on every boot ;)

So the question is: How to encrypt/secure this VMWare image?

Kaffee
  • 111
  • 5

2 Answers2

3

With contractual agreements and the withdrawl of support if you find out that they have ever logged into the system and changed anything. There's very little you can do when the potential attacker (your clients) have "physical" access to the system. It's not like you can lock them out of their own VMware system.

To help give you a better, more targeted answer : what specifically do you not want them to be able to do? What actions could they take that are giving you agita? Make changes inside the OS? Use something like Tripwire to audit any changes (and then deny support if you find changes.) Read the config files that contain your secret passwords, that are the same for every device at every customer? That might be a little tougher.

For the first point - patient data. If you're in the US under HIPAA, you need an answer specific to your company from a qualified source, not some internet Q&A site. Honestly. That being said, is the patient data being generated/stored by you/your company? Probably not - I imagine it's being generated/stored by your customers, just happens to be on your device. It's their butt, so that they need to protect this device.

For the second point - Jeebus. As far as "not changing the config", something like Tripwire would help determine if that happens. Preventing the end-users from doing it? Manufacturers of hazardous equipment can't prevent customers from using a cutter and removing safety bars, but as long as the documentation says "Don't ever do this; risk of death", then the liability is typically on the customer for doing the stupid thing. IANAL of course.

mfinni
  • 36,144
  • 4
  • 53
  • 86
  • I absolutely agree with the contract agreements. It's just that I wanted to make sure that there is not a totally obvious solution to the problem that I did not know. Also i like the idea of a big sticker, maybe in the boot or login screen :) – Kaffee Apr 08 '13 at 13:56
1

Essentially you do not. Do not think that virtualisation holds a magic solution to this issue - you should treat your security exactly the same as though you were handing a physical machine over to the customer.

In other words, if you pass them a VMDK/OVF you must presume that they have full access to the console and to the hard disk.

How you deal with this is up to you, but the solution is almost certainly not a technical one. Given that far bigger organisations than you are sending out virtual appliances now, and generally with a root password, I'd suggest that you're simply approaching this from the wrong angle. What exactly are you trying to protect?

mfinni
  • 36,144
  • 4
  • 53
  • 86
Dan
  • 15,430
  • 1
  • 36
  • 67
  • Two things are to be protected: the data itself - in this case clinical patient data of a hospital. And the second thing would be the way they are used. If the client would mess up the configuration and the wrong data handling would end up in a dead person because of bad treating, that would be awfully – Kaffee Apr 08 '13 at 13:43
  • @Kaffee If this is healthcare related, you should be securing your image to a particular standard. Harden the OS, protect the boot loader, encrypt the VMDKs. Distribute as an OVF/OVA. – ewwhite Apr 08 '13 at 13:48