Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: m19940@mwvm.mitre.org (Emily H. Lonsford)
Newsgroups: comp.virus
Subject: Mainframe attacks
Message-ID: <0005.9006291346.AA11905@ubu.cert.sei.cmu.edu>
Date: 28 Jun 90 19:17:05 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1.BITNET>
Lines: 63
Approved: krvw@sei.cmu.edu

Chuck Hoffman of GTE Laboratories, Inc., writes:

"   That also was about two years before the time that the Security group at
SHARE formed, which developed the specifications for the product which became
ACF2 in 1978.  Simultaneously, IBM was secretly developing RACF."

My recollection is that RACF came before ACF2.  David Chess can probably
clarify the exact date.  Barry Schrager of SKK (the original developers of
ACF2) was a member of the SHARE committee that wrote the first security white
paper, on what an access control system should do.  IBM's response, RACF, fell
far short of the mark - for one thing, in early releases it protected BY
EXCEPTION rather than BY DEFAULT.  SKK decided they could do a better job, and
went off and wrote ACF2 on London Life's computer in Toronto.  I did a survey
of the two packages in the 78-79 time frame and ended up choosing ACF2 for my
employer, an energy company.

"it became much more difficult for hackers who were not in the systems
programming groups to make significant intrusions into MVS systems. "

I think you meant to say that it requires knowledge of MVS.  True, the
controls are there with ACF2, RACF and TopSecret to prevent non-sysprogs from
hacking into MVS.  but how _well_ are they implemented?  All it takes is one
privileged ID with a trivial password, or one unprotected APF library,
installation ID with the default password, etc. etc.

And you have to be cautious about the sysprogs.  They have the knowledge and
the power to do lots of damage, just by accident.

"Computer Associates is in the process of raising the rating of ACF2 and Top
Secret from C2 to B1."

Is that what CA is telling you?  I just looked in my April 1990 "Information
Systems Security Products and Services Catalog", a government publication, and
CA is not in the list of vendors in the evaluation process.  The process
normally takes at least 2 years.  Interestingly enough, IBM _is_ listed in the
evaluation process for MVS-ESA/RACF, aiming at a B level evaluation.
Currently MVS/XA with RACF, ACF2 or TopSecret is rated at C2.  You might want
to get a copy of the catalog from your local GPO Bookstore.  It has some
interesting information in it about lots of security products.

And just because the OS is evaluated at B1 doesn't mean _in your implemen-
tation_ that it's B1 secure.  For one thing, any OS modifications (SVCs exits
etc.) invalidate the rating. Can you imagine MVS without add-ons?

"On Digital VAXs, the VMS system technically is C2, but in my opinion the
architecture is so cumbersome that systems managers have somejustification
when they say that you need system privileges all the time just to do a job.
Yes, it's C2, but so many people end up with privileges that it hardly
matters."

I agree that it's difficult to manage the privileges on VAX/VMS.  But at least
DEC included C2 level protection in the OS, rather than making the user buy an
ADD-ON package to get security.  Let's face it:  without ACF2, RACF or
TopSecret, "MVS security" is an oxymoron.

To me, the worst problem is with UNIX's root account; there it's all or
nothing when it comes to privileges.  There's no such thing as "separation of
duties."  And so far the "more secure" versions of UNIX really haven't
addressed that.

As always, my opinions are my own, not necessarily those of my employer.
*        Emily H. Lonsford
*        MITRE - Houston W123  (713) 333-0922