Security Reporting and Balancing -- MIDRANGE-L

Ok folks:

I've read with interest many of the arguments about reporting vs.
non-reporting.

Let's outline the different scenarios:

1.      Kiss and tell all people.

        Pros: It may get fixed very quickly.
        Cons: Those who don't fix it are at risk.
                Embarrassing to the vendor even if they are pro-active.
                The messenger becomes a target, may get shot, i.e. fired, etc.

2.      Keep it quiet people.

        Pros: It gets fixed without being disruptive to the user community.
                The vendor's reputation is preserved.

        Cons: It may not get fixed.
                Security exposures that are not fixed can damage all of us.

Balance these actions against the types of exposures:

1.      Exposures that would require extreme system changes. For example,
hardware storage protection of program objects on the CISC computer with
corrupted validation.

2.      Exposures that would require major (but not extreme) system changes. An
example is vendors who have multiple ownership, QDFTOWN ownership, etc. in
their application and just perform AUT(*ALL) for everything.

3.      Exposures that would require minor system changes. (I know this is in 
the
eye of the beholder) For example, taking authority to DMPSYSOBJ away from
programmers and system operators. The older example we used was locking down
the AS/400 message files so break programs couldn't be added.

3.      Exposures that would require user and/or security officer awareness. For
example, changing the DST password, securing QSRV, etc.

The problem is to balance these exposures against the necessary action. No
one size really fits all.

The people on this list AND some IBM PERSONNEL have struggled with the
balancing of these exposures against the appropriate corrective actions for
some time now. I sure did when I refused to sign a non-disclosure with the
Security Task Force many years ago. (I was never on the S.T.F., I just
helped them after the famous meetings in COMMON.)

Here's a real case for you. Remember my one word answer on AS/400 passwords?
Hackable...yes. (1) Has anybody formally reported this to IBM? (2) When will
the problem be fixed?

What would it be worth to all of us if a private program fixed the problem?
What type of damage would be caused if somebody could take our SAVSECDTA and
send us a decryption of all of the passwords?

Is this really an exposure? After all, if I secure my SAVSYS tapes,
SAVSECDTA, etc. and minimize the number of QSECOFRs, then where's the
exposure?

I hope this posting provides some perspective for all...

Steve Glanstein
mic@aloha.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---