HP3000-L Archives

March 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Mon, 8 Mar 1999 11:50:04 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
X-no-Archive:yes
Jerry, you describe being between a rock and a hard place, where a decision
maker decides that if he can do one thing with one tool, that all tools have
to do something very much like that. I am reminded of the story about the
animal school, where they enrolled the rabbit in tree-climbing, the squirrel
in swimming class, the duck in track....

I am not in a position to address whether MPE needed what RACF provided, and
wouldn't expect that everyone else would agree if I did. But you do raise
the questions, and provide your answers to them; is it necessary to do so,
and what do you do if someone tells you to make it so? We MPEers have seen
this more than once, and just had a discussion about modifying the contents
of a program in memory, and how well that works on a Sun system.

-----Original Message-----
From: Jerry Fochtman [mailto:[log in to unmask]]
Sent: Monday, March 08, 1999 10:58 AM
To: [log in to unmask]
Subject: Re: Attacking HP3000 from behind a large private global network

<snip>
Yes, however, many corporate security auditors come from an IBM background
with ACF2/RACF skills.  Given that many corporate security policies are
developed around this area as a basis, knowing what one is being measured
against allows one to better interpret what the auditor is asking and
place things in this perspective.  I always found that relating MPE-type
issues to those in the MVS/VM environment helped during the audit process
and bostered our creditability in the mind of the audit staff. While one
may disagree that this is appropriate, this is simply a fact of reality...
<snip>
I agree with Mike, providing the box is never plugged-in.... :-)  Once you
start using the system, any system, you start opening yourself/business
to potential risks.  So in that regard I agree with Lee's perspective, which
tends to be that of larger corporate centers with higher standards.
Certainly
one can use features in MPE to secure things and minimize that risk.  And
depending upon your level of acceptable risk, basic MPE security features
may
be sufficient.  However, MPE alone cannot address all the issues that some
organizations require, hence the nich for the security products, such as
SAF/3000 and SECURITY/3000.

I disagree that it is all marketing hype.  I've seen where a user abused
knowledge of a product shipping system and was only caught by the use of
information provided by a 3rd-party security product.  And I do know
of situations whereby 3rd party security tools helped support retaining
HP3000 technology in an environment where many in IM Mgmt (who wore
blue underware...) wanted to eliminate the technology.  Showing that
the technology coupled with the added tools could meet/exceed what was
in the IBM environment helped justify continued use of HPs.

All of this boils down to simply adequate security is defined by the
end-business and is comensurated with the business risk.  It's
requirements are different given the differences in business needs.
However, I disagree with MPE basic security being deemed adequate
without really understanding the requirements of the
end-user.....sorta like Henry Ford's Model-T only coming in black because
he felt that was all the customer needed....
<snip>

ATOM RSS1 RSS2