Lee Courtney plugged:

[SAFE/3000 only has two competitors that I know of: HP Security Monitor and
VESOFT SECURITY/3000.  The thrust of this post seems to be to imply things
about SECURITY/3000 which aren't true.  I don't work for VESOFT, and have
financial interest in their products, but I hate misleading information being
posted to HP3000-L in the form or marketing literature.  Hey, you want to
plug your products here, you have to expect a higher level of criticism!]

> o MPE/iX with Logon-UDC based security mechanisms - basically still
> vulnerable since Logon-UDCs don't see a login until AFTER it has been
> completed.

Execution of the OPTION LOGON UDC(s) is part of the login process; the login
has not been completed until the OPTION LOGON UDC(s) have been executed (by
definition).

> As a matter of fact Logon-UDCs are never even executed during
> many network connections.

True.  VESOFT's SECURITY/3000 has provided security for ftp and telnet
connections for many years, but not by using the OPTION LOGON UDC.

> o $PLUG on$  MPE/iX with AIF based security intercepts (ala IBM's RACF)
> are the best since they see connections with the system (e.g. HELLO)
> before MPE/iX even parses the logon command. This allows these types of
> attacks to be prevented AND logged.

I'd rather trust my own code than the AIF code -- it's shown a tendancy to
lag behind MPE advances by quite a bit.  I personally believe the best
solution is to use OPTION LOGON UDCs when you can (and test them on each new
version of MPE) and AIFs when you must (and test them on each new version).

> Yes, this is the implementation that
> SAFE/3000 has used since MPE V up through MPE/iX. $PLUG off$

No you haven't.  AIF's didn't exist on MPE V!  :-)

> The problem is that ALL 3000s have is that ALL passwords are passed
> across the network in the clear, except for the physical console.
> Doesn't matter if you're going through the DTC or using TELNET across the
> Internet.

I know of one solution to this problem: use the SECURID card from Security
Dynamics, Inc.  Even if you intercept the "password", it changes every 60
seconds.

> The philosophy used on mainframe systems that use RACF and ACF2 is to not
> only provide secure authentication (login), but also make use of controls
> which validate and maintain an audit trail for file/database access by
> authorized users.

MPE does this on it's own (another advantage over mainframes, Unix, PCs, etc.)

> Actually the emphasis on 'hackers' and external threats
> is misplaced since the vast majority of security incidents (>80% according
> to a RCMP study) are actually perpetrated by users authorized to use the
> system. The HP3000 has always seemed to take a head-in-the-sand approach
> to security issues related to authorized users, when the evidence
> indicates that that is actually a much greater threat than security
> breaches from outsiders.

The HP 3000 approach has traditionally been that end-users don't need access
to the command interpreter.  Most real production sites use some kind of
security built on OPTION LOGON UDC's (a logon menu, or a single program that
the user is locked into).  Implemented properly, LOGON UDC's actually provide
quite strong security.  And it's *much* easier to implement LOGON UDC's
properly than to use the AIF's correctly (there are a lot more system aborts
related to AIF's than to LOGON UDC's).

People can only gain access to your system via FTP or TELNET if you start the
FTP and/or TELNET services -- which isn't done by default "out of the box".

Also, if you are using AIF's to intercept all file system calls (in order to
do your logging), the CPU overhead can be quite high (not as high as the MI,
perhaps...).  Since MPE can already log all file accesses for you, I'm not
sure what you'll gain in return for the extra performance penalty.

---
Michael D. Hensley       | mailto:[log in to unmask]
Allegro Consultants Inc. | Visit scenic http://www.allegro.com
408/252-2330             | "Support Bill of Rights Enforcement"