In article <[log in to unmask]>,
  Gilles Schipper <[log in to unmask]> wrote:
]Subject:      Re: Security and backup tapes
]
]Michael makes an excellent point. Not only is it common practice to mount
]your backup tape every morning, utilities abound whose function it is to
]place dds tapes online - so repeated attempts at scanning the directory of
]a old store tape is routinely available to all users with only default
]capabilities.
]
]Sure,  remedies come to mind, in addition to Michael's suggestion to NOT
]include the ;directory option in the store command. Another would be to
]place an appropriate ACD on the tape device - which would only partially
]address the problem.
]
]However, these solutions are basically workarounds that do not address the
]real problem.
]
]Clearly what is required to solve this serious potentail security breach
]are modifications to store/restore to generate an encrypted directory.
]These enhancements must be included AT NO EXTRA CHARGE - not bundled in
]with an optional product.
]
]Surely an OS as robust and efficient as MPE/iX deserves equally robust
]security.
 
I know times have changed, but . . .
 
I once had to rebuild a system from scratch (the original HP tapes) because
the backup tapes were not bootable.  That was in 1977 on a series II.  I was
able to rebuild the account structure using FCOPY on the tapes (only the
bootstrap was bad - :RESTORE worked after the structure was built) and
dumping the directory structure to the printer in hex.  A very long night.
 
If you choose to encrypt the backup media, be aware that significant effort
may be required to make use of the data in an emergency.  What might be
more useful is to have :STORE simply change passwords to all ?'s while
writing to tape from the directory area.  If :RESTORE checked and prompted
for passwords during a reload, legitimate passwords would be written back to
the directory (or passwords could be made spaces).
 
In the absence of this simple substitution approach, I would prefer to _not_
encrypt the directory, and instead control access to the media.  YMMV.
 
--
Regards  --  Tony B. Shepherd  --  [log in to unmask]