> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Rick Fochtman > Sent: Wednesday, June 06, 2007 10:14 AM > To: [email protected] > Subject: Re: mainframe acces using shared id > > -------------------------------<snip>------------------------- > We have an issue in one our project. The project is deveopled to see who > are using the system using the shared mainframe id. > > scenario. > > 1. There are some users who logon to the mainframe using the sharedid > and common password and do some inquiry going to the cics region. To see > who are using the sysytem in this way ,we have developed a new screen > and where the shared users will be entering their individual id & > individual password , then only the system will allow to enter to the > application in the cics region. > > Problem: > > The problem here is that say suppose the user 1 using the shared id and > common passord login from terminal 1 and after some time while this user > is logged in , say a user 2 is logging in teminal 2 using the shared id > and common password , the other user will be automatically kicked out, > but still the online cics region will be active & for the 2'nd user the > cics region will not ask their individual password and the new screen > will not be thrown. > > Here there is a security issue/flaw involved. we need to control this > and this loophole in the design has to be tackled. could some one give > us suggestion how to take this? > ---------------------------<unsnip>----------------------------- > Using a Shared ID is a seriously bad idea, both from a security > standpoint AND accountability. > > This is the sort of thing that drives auditors screaming to/at management. > > Each user should have a unique userid for ALL accesses to any part of > the system. By using a shared ID, you're allowing a disgruntled > employee, or former employee, potential access for mass destruction. The > risks are tremendous; the benefits are nonexistant. Even though the > users SUPPOSEDLY are only doing inquiry work, a sharp user may know of > other CICS transactions that are potentially very damaging. NOT WORTH > THE RISKS!
High security environments are becoming increasingly more common with recent LEGISLATION requiring security, auditing, accountability. The new security trend is to prohibit shared-ids and move to multiple ids per person. Each id has a distinct set of access authorities. If the user must "change hats", then they must change ids. Each id is tied to a distinct "security label" that restricts the access authority to a limited set of resources. If you want the gory details about RACF Multi-Level Secure (MLS) operations and security labels, try reading these: SA22-7683 "Security Server RACF Security Administrator's Guide" SG24-6480 "Securing DB2 and Implementing MLS on z/OS" GA22-7509 "Planning for Multilevel Security and the Common Criteria" I suggest that whatever "solution" is chosen should be carefully reviewed for legal compliance. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ see my résumé at my website (yes, I am looking for employment) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
