RE: Security Reporting and Balancing -- MIDRANGE-L

Glad to hear from you, Steve!  Don't know if the following are rhetorical
questions...

>What would it be worth to all of us if a private program fixed the
problem?<
If IBM could not or would not provide the fix, then this would be pretty
valuable.

>What type of damage would be caused if somebody could take our SAVSECDTA
and send us a decryption of all of the passwords?<
You're kidding, right?  

>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?<
Why do backups have anything to do with this?  Are you going to throw away
days/weeks/months worth of work after you discover that your security has
been compromised?  And what if you don't know what's been tampered with by
someone who is using a sniffed user ID & password?

You kinda lost me at the end, Steve.  Of course, brain fade starts to set in
late in the day. <g>

- Dan Bale

> -----Original Message-----
> From: Steve Glanstein [SMTP:mic@aloha.com]
> Sent: Wednesday, June 14, 2000 2:09 PM
> To:   mr
> Subject:      Security Reporting and Balancing
> Importance:   High
> 
> 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
+---