> From: Dan Hollis
> Subject: Re: Security Software for the HP3000?
> Date: Wednesday, May 08, 1996 10:32AM
> >> Andreas Schmidt writes:
> >> > I am interested in finding out what types of security software all of
> >> >you are using...
> >[...]
> >All that aside, the top contenders for MPE security add-ons are VESOFT's
> >Security/3000 (with VEAudit as a verification tool) and Monterey
Software's
> >SAF/3000.  I'm admittedly a little biased towards Security/3000 after
having
> >STD disclaimer: thoughts and opinions expressed are my own and do not
> >neccessarilly reflect the opinions of any current (or former) employers
>
> You know, none of these products seem to address network security. Anyone
> with an ethernet sniffer can get around these security products quite
easily.
 
In Security/3000's defense, I'd like to point out that recent versions of
Security/3000 (2.5 and later) DO provide network-centric security.  In the
past, VESOFT has always discouraged the use of the AUTOLOGON feature of
DSCOPY simply because it circumvents even normal MPE security, however,
version 2.5 (better known as 25.nnnnn or simply 25) lets you ALLOW or
DISALLOW auto-logon attempts from DSCOPY and FTP through the use of
procedure exits.  I believe SAF/3000 has a similar capability, and I would
venture to guess that the other players in the security game will have that
feature soon, if not already.
 
But, you are absolutely right -- anyone with an ethernet sniffer, who can
gain access to the computer room to install said sniffer between the DTC and
the CPU on today's XL systems can then read, in the clear, ANY password for
ANY user, including third-party add-on passwords.  There is one possible
exception, (unfortunately the exact name of the company eludes me at this
point), but they provide a handheld hardware device keyed to a program
running on the HP.  When a user logs on, this program generates a random
"challenge" request (a theoretically one-time transmission), which the user
enters into their calculator which processes the challenge and returns a
response.  This response (also a one-time transmission) gets re-processed on
the HP to determine access to the system.  Since the
keys/challenges/responses are only sent over the wire once in their
lifetimes, it is theoretically impossible to use a sniffer since that
password combination will never come up again.
 
Note that this "sniffing" ability works even if the computer isn't logically
"connected to a network".  This is because the point at which users enter
the system, the DTC, is actually connected to the CPU by way of a network
cable and uses TCP/IP-like protocols.
 
> I'm still waiting for HP to implement (at the minimum) firewalling and
SSL.
> Until then, we're going to have to continue propping up our HP3000's with
> Unix machines, to provide security the HP3000 lacks.
 
Now I'll step out on a limb and wait for you to cut it out from under me,
but isn't Unix security generally regarded as rather poor, even compared to
standard MPE security?  What features does unix provide that will stop a
sniffer in the above scenario?  (i.e., a "telnet only" terminal, sending
in-the-clear data packets containing password information).  Also, while a
userid/password combination is the primary means of defining security (and,
by extension, breaches of security), there are numerous other ways that
system security can be compromised.  (leaving terminals unattended is a good
example of what I mean).
 
I'm also willing to hide in my shell and say, "It's precisely BECAUSE of
Unix systems and 'the internet' that security issues on MPE machines even
exist".  In a single HP3000 shop, the only access to the system is through a
terminal or modem connected to a DTC port.  With multiple HP3000's, the
complexity is increased slightly since it is now possible to "come in" from
another machine rather than a terminal or modem, but the methods available
(until now) have been limited to DSLINE-type connections, which, at the very
least, require MPE passwords for the remote machine.  In effect, there is no
difference between connecting to the "local" machine or the "remote" machine
since both machines will attempt to validate your existence on that system.
 The only exception to this relatively trouble-free situation is what I
alluded to earlier -- using the ;LOGON= feature of DSCOPY allows a user to
perform file transfers without regard to addtional third-party security
tools, but this is a "feature" that can be easily shut off at the source.
 
With the advent of "the internet" and the plethora of Unix machines and ODBC
access, security has become a nightmare.  HP-UX machines, at least, have an
HP-UX version of DSCOPY that allows users to circumvent third party tools
for file copies.  Similarly, FTP and ODBC "get around" additional logon
restrictions because the user never really "logs on" to the target system.
 Instead, (at least in the case of ODBC), users connect via RPC and SOCKET
calls to a background process, which, in turn, accesses files or databases
as appropriate.  Again, this is limited to "just mpe security", if that
much.
 
Well, I see it is getting late, which is probably an indication I've begun
to ramble, so I'll leave you to chew on these thoughts for a while.
 
Tom Emerson