Sorry, I just wanted to add my comments, as this is a subject I spent a lot
of time dealing with in the 80's.

At 11:57 AM 3/5/99 -0800, Michael D. Hensley wrote:
>Lee Courtney plugged:
>> 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.)

Sorry, but I maintained both MPE and ACF2 security for a period in the
early 80's, and the basic security aspects that MPE provides can't hold a
candle to the granularity and verstility provided by ACF2/RACF.  This is
why we ended-up spending so much time defending the HP3K platform in
a predominently mainframe environment. Those that wore blue underware
worked hard at killing it because it couldn't meet the same level of
security as the 'corporate systems'.

>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).

As with any new technology, there will be implementation bugs. Just look at
the DDX bugs that came to light almost 2 years after this IMAGE feature was
released.  The issue with AIFs during the logon process is the fact that
the environment these are invoked in during the logon process is not yet
a fully-established user environment.  Only specific aspects of the user
main process are setup, just enough to validate the logon.  If one
programmed their use of AIFs given a normal user environment they could
attempt to utilize/access user structures/etc that were not yet setup,
causing system aborts.  HP themselves did not have any documentation about
the state of the process when various AIFs were invoked during logon and
as such, people that attempted to use this mechanism were left to
uncover much of this themselves.  This is probably why there aren't more
products that use the logon AIFs....


>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".

And if you look at the DOD standards, this too, must be protected by default,
not by explicit action.  So if these services are started for any reason,
they too are protected from attack, both internal and external.  Access is
to be explicitly granted, not allowed by default.  As such, relying only
on logon UDCs leaves a potential risk here, even though some may deem it
as small because the likihood that these services won't be used.  Part of
the issue is the assumption of security through lack of knowledge. If a
end-user wasn't aware that logon UDC type security didn't apply to these
access paths, then the risk is even greater for these features could be
enabled without this knowledge and the user would not know of the
potential risks.


At 07:35 PM 3/7/99 -0800, Michael D. Hensley wrote:
>bit.listserv.ibm-main?  Why would I ask them about an MPE security mechanism?
>
>Just because some IBM OS has a mechanism that is superficially similar to
>LOGON UDCs doesn't mean it's the same.

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...


>Been there, done that.  One of my projects at VESOFT was to take
>SECURITY/3000 through the C2 certification program.  We didn't complete the
>process for a number of reasons (probably a lot of the same reasons HP has
>for not re-certifying new versions).

It indeed is expensive to obtain certification.  As with most governmental
things there is a tremendous amount of documentation that needs to be done.
Also, from a software perspective, whenever changes are made the new version
must be re-certified.  This is another reason HP didn't do seek additional
certifications, simply because it was way more costly to do this with each
patch release of the OS than was needed based upon customer needs.

>The mechanism by which identity is verified at logon time is just one small
>part of a "well developed computer security practice" -- a whole lot of
>security has more to do with company policies and practices, etc.

Yep, and a thorough review of policy and procedures along with auditing
what occurred prior to the audit visit is a part of any audit, right down
to the details about an application along with diaster recovery plans as well.
In addition, it is the business application owner that it ultimately
responsible, not the IM organization, who basically are 'custodians' of the
end-users data.  This is a difficult issue, for most everyone tags IM
as the application/system owner because we manage the technology.


>My point is: the third-party packages are quite valuable.  But I still
>consider it a myth that you can't adequately secure an MPE system without one
>of them.

Sorry, but the term 'adequate' depends upon one's yard stick.  If it happens
to be achieving the C2-level of certification, even without going through
the formal certification process, MPE falls short in terms of the level of
granularity needed in reporting along with the issues surrounding management
of ownership.  Furthermore, regardless of any part of the DOD standards, one
still may have audit reporting requirements which cannot be met by what
MPE provides, hence the 3rd party tools.

As a simply example, certification requirements require logging of changes
to IDs, including such things as changes of capabilities.  In this manner,
the actions of the security person can be independently reviewed.
Basic MPE security does not provide this type of reporting.  It can only
be achieved through the use of other tools (SAF/3000, SECURITY/3000 and
if still available, HP's add-on security product SecurityMonitor).

Some of us who have been responsible for maintaining access controls and
reporting in both HP and IBM environments have an appreciation for the
differences.  And when one is held accountable to the level of control
that is available in the other, whether you agree or disagree, you
still have to work toward compliance.  If you can't find solutions, upper
mgmt in Information Mgmt is more willing to dump the technology than try
and explain an unsatisfactory audit evaluation to business mgmt.  And I've
seen this happen....  So it's not myth that standard MPE security
provisions are inadequate, I've seen some large corporations shift
technology focus, and security happened to be one of the major contributors
to the change in strategy.  Fortunately its not as prevelant as it was
10-15 years ago...  And again, this is also based upon what it on the
measurement yard stick....


>My main point was to disagree with Lee's contention that an MPE system, "out
>of the box", can't be made secure.  I very strongly disagree.  The various
>third-party packages (sometimes even used in combination) provide a great
>deal of added value, but (IMNSHO) it's nothing less than marketing hype (of
>the FUD variety) to claim your data is insecure without them.

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....

By the way, for those that may not yet realize, Michael worked on VESoft's
security product features (amoung other things..:)).  I spent a lot of
time talking/working with Eugene on some of the issues. Lee use to work in
CSY and when HP was being battered by large companies (I know, I did my
share if battering...) about lack of security features (which HP chose not
to provide), left HP and started Monterey to provide a tool modeled after
mainframe tools.  Both are good tools with many similar as well as different
features, depending upon your business needs. Users have a choice as to
what they need to meet their own requirements.  And some have blended both
tools as a means to meet their requirements....


/jf
                              _\\///_
                             (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                       Monday, March 8th

Yesterday (Sun) in 1876 - Alexander Graham Bell received 1st patent
                          for the telephone.
          Today in 1841 - Jurist Oliver Wendell Holmes, Jr. was born.

___________________________________Oooo_____________________________________
                            oooO  (    )
                           (    )  )  /
                            \  (   (_/
                             \_)