From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: VMS Computer Security
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Wed, 13 Jan 1993 03:07:17 GMT

In article <10047722@MVB.SAIC.COM>, Burchianti@Fwva.Saic.Com writes:

|>My company is interested in putting a medical information system on the
|>Internet but is concerned about privacy restrictions of the data.  Most of
|>the
|>computer information on the Internet seems to deal with Unix systems but not
|>VMS.  Does anyone have any information that may be useful? 

Well thats the same effect as looking in a hospital to find ways of staying
healthy. Most of the people who arive their are sick.

I'm not sure if you are asking for a comparison to base a purchasing decision on
or looking for VMS info for an existing system. If its the later then
comp.os.vms is probably most likely to be of use.

The primary source of data on VMS security is the VMS Security Manual. This
explains all the various levels of security you can set. In it's basic
configuration VMS *starts* as secure as most UNIX systems ever get.

In addition to the normal security mode their is the "complete paranoia"
operating mode. This will do things like erase areas of the disk with
alternating paterns of 1s and zeros when you delete files and such like. You can
also stop individual users from knowing what anyone else is up to - you can even
prevent users from ever knowing which machine they logged on to (!) However very
few sites need such security and a performance hit is unavoidable.

What you get for free in VMS is:-

Shadow passowrds, VMS password file is not world readable by default.

Secondary and generated passwords.
	Adding a second password to an account prevents certain network operations and
makes random guessing exponentialy harder. You can also set up dictionaries to
check the password against and if you are really being paranoid force the use of
a password generator which chooses a gobledegook password for the user. You can
set your own encryption algorythm if you don't want to use a system chosen by
CIA spooks.

Breakin database, If someone tries to hack the system all sorts of
	alarms start ringing, for instance if you simply try to log
	in to the same account with random passwords, VMS in default mode
	goes into a "breakin" state and prevents the suspected breakin
	attempt.

ACLs.
	In VMS files may be protected using ACLs. These may be used to finely control
the level of access you give to each user. For instance one user might be
allowed to read a certain file but not write it, another might be able to write
it. This is much more powerful than the standard System Owner Group World
scheme. You can also set acls which register illegal attempts to read the file.



The main problems with VMS on the internet would be the TCP/IP. Since the
standard network for VMS is DECnet you have to get TCP/IP separately, this is
now impossible for DEC to change without an anti-trust suit. It depends on the
access methods you intend to provide. If you are paranoid about security and
want to prevent an internet breakin at all costs I would not enable the telnet
or SMPT deamons and only provide ftp (or WAIS, World Wide Web or whatever
server). I would set up the export data on a separate disk and install the ftp
client with a rights identifier denying it execute access to the root
directories of all the other devices. Alternatively you can take advantage of
the simplemindedness of most ftp clients which assume that the reader must
always have read access to all the directories in the current path to produce a
dummy container style device.

Or alternatively again you could use a UCX container file to emulate the UNIX
file system and attach it to the ftp client.

If you provide your own server set the ACLs and rights in the same way.

Whatever you do though, either get UCX 2.0 (now renamed TCP/IP services) or TGV
Multinet. UCX 1.0 is an abomination. 


Another thing to consider is whether your security needs would justfy the use of
a separate machine as a firewall. Personaly I have never regarded this as
necessary for a VMS system. Although I have always ensured that we could
disconnect from the internet entirely and just run TCP/IP on a local subnet. We
move 200 odd tonnes of Uranium under control of a system running VMS and TCP/IP.
One of the reasons why we use VMS is that we want to make sure that the system
does not rely entirely on the system manager. Of course if the system manager is
really stupid there is no real solution, but a good operating system should
never allow a hacker to exploit a subtle mistake.

--

Phill Hallam-Baker
Newsgroups: alt.security