OpenVMS Encryption and Standalone Backups

[Mike Zinni]

Hi,

We were notified that we are now required to encrypt every piece of media that leaves our site. We usually do an Image backup of our system disk's shadow disk. Regarding a standalone backup, I have read that it will not understand the /ECRYPT qualifier with the BACKUP command. In the event that we lost a system disk in a disaster scenario and needed to restore at a Hot Site, would the only work around be to install OpenVMS then restore that encrypted image backup to another disk and then boot from that disk?

Thank you.

[Robert Gezelter · Accepted solution]

Mike,

Please note that this posting did not mention which architecture or OpenVMS version was in question.

However, assuming that the standard standalone BACKUP does not support encryption, you are faced with two choices:

- the possibility that was mentioned in the post, namely a reinstallation followed by a decrypt and restore; or
- create a custom bootable CDROM (DVD) that includes everything needed to restore the encrypted save set (excluding the decryption keys).

You will still need to make (secure) arrangements to store the encryption/decryption keys OFFSITE. Even if you create the custom CDROM, you will likely need a scratch pack (or memory disk) to store the decryption keys. Thinking about this, you could also possibly generate a self booting CDROM/DVD that required the separate loading of an encryption key.

Interesting possibilities. I have not been asked to explore these possibilities by my clients, but a well functioning procedure is likely eminently feasible.

- Bob Gezelter, http://www.rlgsc.com

[EdgarZamora_1]

Initialize a small disk volume. Create a "standalone" backup on this small volume using SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM. Backup this volume to tape unencrypted. This volume will not contain any company data since it is freshly inited and hopefully will be allowed as an exception to your policy. You could do this once and just store this tape backup and the standard VMS CD in your hot site.

When you have a disaster situation, in your hot site, boot from the standard VMS CD and restore this small volume. It shouldn't take long at all. Boot the system using this restored volume. You can then use BACKUP/ENCRYPT to restore your encrypted backups including your regular system disk.

I just thought that up so feel free to punch holes through it. I think it's fast and fairly simple. Good luck.

[Robert Brooks_1]

Please note that this posting did not mention which architecture or OpenVMS version was in question

--

Bob's point is quite relevant, as there is no such thing as "standalone backup" for either
Alpha or I64. Moreover, recent (V8.3) versions have enhanced options for encryption algorithms for BACKUP.


-- Rob

[EdgarZamora_1]

There is no longer the old standalone backup. What I was referring to is the SON of standalone backup (AXPVMS$PCSI_INSTALL_MIN.COM), which I referred to as "standalone" backup. Sorry if I confused people. It sure DOES exist and I just ran it today on an 8.3 Alpha system I am building. I don't know if it exists on Integrity though.

I did a lot of backup and encryption testing on VMS 8.3 and am familiar with the "new" developments. However, we eventually decided to go with hardware encryption due to performance reasons.

[EdgarZamora_1]

Oh it seems it works for I64 too:

After reading the information in the manual, you may wish to use

SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM on OpenVMS Alpha, or

SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM on OpenVMS I64

to install OpenVMS without any optional features on one or more of
your "data disks".

[Hoff]

Get a standard OpenVMS V8.3 distro disk to the hot site. Install it, if you really want to. (I would, if for no other reason than testing the full-path sequence.) Ship a copy of your encrypted disk. Decrypt your "real" disk as part of an image saveset restoration. V8.3 has DES and AES built in, and licensed.

Burning your own CD and DVD disks is an option here, too. You can stage these locally for testing purposes. You can then create an ISO image of these disks (and encrypted), transfer the ISO file as required, and decrypt and replicate the ISO at the target site. The HoffmanLabs topic http://64.223.189.234/node/28 has recording info.

[Robert Gezelter]

Mike,

A very important point.

Encrypting the backups is ok, and laudable. Keeping the keys separate from the backups is also a good idea.

Keeping the keys locally. A VERY BAD VULNERABILITY.

Please check with your senior management as to the need to keep a set of the encryption keys offsite. Keeping the keys onsite (and the backups offsite) is not an option. Consider what happens in the event of a whole building contingency. If the keys get destroyed or lost, the offsite backups are useless.

- Bob Gezelter, http://www.rlgsc.com

[Siobhan Ellis]

I know I'm late in here, but for future note, I thought I'd jump in. I note a hardware solution was chosen for performance reasons and there was mention of key management. The key management is especially important.

I'm assuming these were backup tapes so you could use a backup product that supports encryption at source. I'm actually testing NetWorker 7.3.2 at the moment which, I think, includes that. However, this doe snot resolve the performance issue and it also makes it impossible to compress data to tape - encrypted data, essentially, is uncompressable. This has the effect of slowing down backups even more.

What a company is trying to do, with encryption of tapes, is to make sure that no-one can read them unless they have the key. Usually they think of external threat, but the risk of internal hijack is still there (Someone internally getting the tapes who knows the key). To do restores, there has to be "knowledge" of the key to un-encrypt the data.

The appliance solutions from Neoscale, my personal favourite, and Decru (owned by netapp) provide key management. They do do it in different ways. Neoscale has "clusters" of appliances that share the same keys and, so, once set up, no-one needs to know what the keys actually are. You can even distribute the key amongsta number of people and require a minimum number of people to re-create the key should it be lost. the appliances also do compression first and then encrypt at near zero latency guaranteeing backup throughput.

Hope that helps

Siobhan

[Steven Schweda]

> [..] it also makes it impossible to
> compress data to tape - encrypted data,
> essentially, is uncompressable. [...]

Of course, some encryption schemes compress
data _before_ encryption. For example, a VMS
FAQ before and after GnuPG (1.4.7a)
encryption:

alp $ dire /size vmsfaq

Directory ALP$DKA0:[SMS]

VMSFAQ.TXT;2 1596
VMSFAQ.TXT-GPG;1 395


This tends to obviate additional compression
after encryption. I don't know what the
BACKUP encryption scheme does, however.


I'll note again that it pays to reserve the
phrase "Standalone BACKUP" for the _real_
Standalone BACKUP program on a VAX.

[Thomas Ritter]

Interesting idea encrypting a system disk. Why bother ? A well set up system disk should be basically read_only. We have all our site specific data on a common disk. Even then only a few directories would need to be encrypted.
Tell me...do you send your tapes offsite in a sealed box ? Do you apply your own seals and ensure that no one tampers with them and if a seal is broken how to deal with such a situation ? How secure are the tapes at the holding place ?

[Ross Smith_1]

We've been told that we're required to have encryption in place that is certified as FIPS 140-2 compliant for protecting our clinical research data. Does VMS's encryption (for backup and encryption at the command line) meet that requirement?

I'm very new to all this, I hope I've formulated the question appropriately.

Thanks!

[Mike Zinni]

Thank you everyone for your responses! Sorry about the delay.

[Jan van den Ende]

@Ross Smith:

>>>
I'm very new to all this, I hope I've formulated the question appropriately.
<<<

So, first of all: WELCOME.

And yes, you formulated it OK, but since it is your question, you should start your own thread.
That way you can get notified of any answers, and you can put value to them.
(but a pointer to this thread certainly will not hurt!

Proost.

Have one on me.

jpe

[Anton van Ruitenbeek]

Mike,

If you have a multiple site etc. setup for disaster etc. then you will not have the problem of costs for a disk more or less. If you setup your site with a systemdisk, clustercommon datadisk, program disk, other data disks you can backup de systemdisk without encryption because there are no company data on it. De clustercommon data configuration will contain all the specific (not HP) data eq SYSUAF, RIGHTSLIST, ip configuration, AGEN$*-files. So you can restore the systemdisk (including the encryption!) and after that start restoring the other disks.
We do this for a long time and because we are a realy disaster-tollerent environment we didn't have any clusterdowntime and we do backups of the 3rd disk of all the shadowsets (yes we have shadows of three). When we have to regenerate the environment for testing/demo facilities we do use the backups of the productionsite and by this we direct test or the backups are correct and usefull. And all the tests were OK. So its for sure that the backupmethod we use is trustworthy !

AvR

[Mike Zinni]

AVR, Bob, Edgar, Hoff, Sibohan, Steven, Thomas, JPE thank you for all of your responses! I think that I have enough information now to complete this. Much appreciated.