Re: RACF password & id checking
Absolutely agree. Robust software is hard, darned hard. And, to repeat myself, all software has bugs. But I think most would agree that the level of difficulty and risks are generally somewhat greater on the system level as opposed to the application level. Of course, YMMV ;-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, March 10, 2009 12:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking >Exits are hard to write, hard to stress test, and introduce a level of risk. >You need extraordinary measures in place to protect the code. You could say exactly the same thing about application code. I've worked in many a shop where the application source code had been missing for years. And, many were hard to test in any way. - Too busy driving to stop for gas! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
>Exits are hard to write, hard to stress test, and introduce a level of risk. >You need extraordinary measures in place to protect the code. You could say exactly the same thing about application code. I've worked in many a shop where the application source code had been missing for years. And, many were hard to test in any way. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
2009-03-06 Hal Merritt wrote:
> IMHO: exits as a subspecies are evil critters. They become an ongoing
> maintenance challenge and tend to attract unwelcome attention from auditors.
> Exits are hard to write, hard to stress test, and introduce a level of risk.
> You need extraordinary measures in place to protect the code.
This is kind of amusing... Twenty years or so ago, the big controversy
was over IBM removing the source code to its products. IBM's argument
then was that too many shops were modifying their systems, and thus
delaying the move to newer OS versions, and that exits would be the
stable way for customers to make the systems behave the way they
wanted. The big shops at the time argued that IBM provided far too few
exits, and with too low functionality to duplicate what they did with
mods.
So now that there are lots of exit points, using them has become the
new evil? What's next on the list - config files? Parmlib options?
Local naming conventions that don't match the defaults?
[...]
> I once worked in an exit happy shop. Getting the exits updated and tested
> tended to be the single biggest bottleneck in rolling out new operating
> system levels.
Perhaps so. But SHARE showed fairly clearly back in the 1980s that the
most heavily modified ("modification happy"?) shops were also those at
the newest OS releases. In some cases updating the exits is worth the
resources.
> Of course, if you have a compelling business/technical need, then lock and
> load.
Using exits, just like modifying source code, or choosing build vs buy
for an application, is a business decision, that has to be taken with
awareness of all the costs, risks, and benefits. If you have a
business requirement that is best and most cost effectively addressed
by using an exit, then do it. If you have programmers running around
writing and installing exits on production systems for fun, then you
have a management problem.
Tony H.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
On Tue, 10 Mar 2009 09:25:08 -0600, Roach, Dennis (N-GHG) wrote: >Try FIPS 112 or ADS 545 for starters. > Does IBM provide at least a sample exit supporting these "industry recognized best practices"? (Though I'd prefer "default" or at least "optional" over "sample".) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Try FIPS 112 or ADS 545 for starters. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Tuesday, March 10, 2009 9:28 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: RACF password & id checking > > Ah, the (in)famous "industry recognized best practices". > > Which industry? Where is this Written? Are we talking about the data > security 'industry' or the IP audit 'industry'. > > Who is 'industry'? Do they have a web site? Where can I find these > publications? > > Sorry. You do what the customer wants, of course. As we all do. > > Love your disclaimer tag. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Roach, Dennis (N-GHG) > Sent: Friday, March 06, 2009 3:26 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: RACF password & id checking > > I have had to do exactly what is being discussed in z/OS and Linux. > > When you are a government contractor and the Inspector General's office > says do it or the certification for the facility > is canceled (along with your contract), you need no more business > justification. > > As or security justification, all of the OIG requirements in this area > are industry recognized best practices. > > Dennis Roach > GHG Corporation > Lockheed Martin Mission Services > Flight Design and Operations Contract > Address: >2100 Space Park Drive >LM-15-4BH >Houston, Texas 77058 > Mail: >P.O. Box 58487 >Mail Code H4C >Houston, Texas 77258 > Phone: >Voice: (281)336-5027 >Cell: (713)591-1059 >Fax:(281)336-5410 > E-Mail: dennis.ro...@lmco.com > > All opinions expressed by me are mine and may not agree with my > employer > or any person, company, or thing, living or dead, on or near this or > any > other planet, moon, asteroid, or other spatial object, natural or > manufactured, since the beginning of time. > > > > NOTICE: This electronic mail message and any files transmitted with it > are intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or > privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, > please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Ah, the (in)famous "industry recognized best practices". Which industry? Where is this Written? Are we talking about the data security 'industry' or the IP audit 'industry'. Who is 'industry'? Do they have a web site? Where can I find these publications? Sorry. You do what the customer wants, of course. As we all do. Love your disclaimer tag. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roach, Dennis (N-GHG) Sent: Friday, March 06, 2009 3:26 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking I have had to do exactly what is being discussed in z/OS and Linux. When you are a government contractor and the Inspector General's office says do it or the certification for the facility is canceled (along with your contract), you need no more business justification. As or security justification, all of the OIG requirements in this area are industry recognized best practices. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
I check the following web site and it shows z/os R9 that already support this REXX... http://www-03.ibm.com/servers/eserver/zseries/zos/racf/downloads/rexxpwexit.html On Sat, Mar 7, 2009 at 12:50 AM, Walt Farrell wrote: > On Sat, 7 Mar 2009 00:12:16 +0800, Tommy Tsui wrote: > >>I saw the REXX code and it's quite simple. Just turn it on...I will try it .. >>thanks all of your help > > Do remember that it works only on z/OS R10 and later, though. > > -- > Walt Farrell, CISSP > IBM STSM, z/OS Security Design > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
I have had to do exactly what is being discussed in z/OS and Linux. When you are a government contractor and the Inspector General's office says do it or the certification for the facility is canceled (along with your contract), you need no more business justification. As or security justification, all of the OIG requirements in this area are industry recognized best practices. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Friday, March 06, 2009 3:09 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: RACF password & id checking > > In my 40+ years, exits tend to be politically motivated. That is, the > business/technical issue is really easily solvable some other way. > > For the case in point, someone just wants the system to work > differently. There is no technical justification, no business > justification, and arguable security grounds. > > Of course, there are a few exists that make perfect business/technical > sense. But the fewer the better. And certainly never, ever, to satisfy > an audit requirement. > > Just my $0.02 > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Schwarz, Barry A > Sent: Friday, March 06, 2009 1:09 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: RACF password & id checking > > How do any of these "considerations" differ between an exit and the key > applications the business depends on and without which they wouldn't > need a computer system at all (or even be in business)? > > -Original Message- > From: Tony B. > Sent: Friday, March 06, 2009 10:55 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: RACF password & id checking > > Exits are a good alternative when: 1. The skillful author never > retires, > finds a better job, gets laid off, is transferred, gets fired, wins the > lottery, or ages. 2. The company never is merged, acquired, downsizes, > asks > for a government bailout, acquires another RACF company. 3. The source > is > never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS- > prior > flavors. > > Else, the term exit should be renamed to "future headache for its > inheritors." 5% of my experiences involved exits where the original > author > was still available... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > NOTICE: This electronic mail message and any files transmitted with it > are intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or > privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, > please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
In my 40+ years, exits tend to be politically motivated. That is, the business/technical issue is really easily solvable some other way. For the case in point, someone just wants the system to work differently. There is no technical justification, no business justification, and arguable security grounds. Of course, there are a few exists that make perfect business/technical sense. But the fewer the better. And certainly never, ever, to satisfy an audit requirement. Just my $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Friday, March 06, 2009 1:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking How do any of these "considerations" differ between an exit and the key applications the business depends on and without which they wouldn't need a computer system at all (or even be in business)? -Original Message- From: Tony B. Sent: Friday, March 06, 2009 10:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking Exits are a good alternative when: 1. The skillful author never retires, finds a better job, gets laid off, is transferred, gets fired, wins the lottery, or ages. 2. The company never is merged, acquired, downsizes, asks for a government bailout, acquires another RACF company. 3. The source is never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS-prior flavors. Else, the term exit should be renamed to "future headache for its inheritors." 5% of my experiences involved exits where the original author was still available... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Now you need to talk about documentqation. It's like sex. When it's bad, it's still better than nothing and when it's good, it's really great. Tony B. wrote: Exits are a good alternative when: 1. The skillful author never retires, finds a better job, gets laid off, is transferred, gets fired, wins the lottery, or ages. 2. The company never is merged, acquired, downsizes, asks for a government bailout, acquires another RACF company. 3. The source is never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS-prior flavors. Else, the term exit should be renamed to "future headache for its inheritors." 5% of my experiences involved exits where the original author was still available... Jaded. :-( -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, March 06, 2009 12:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking -- - IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. -- I disagree, Hal. Exits CAN be overused and poorly coded; no argument there. But they often provide the only mechanism of tayloring function to fit business or technical needs, or sometimes arbitrary mandates from senior management. Testing a new installation or upgraded level of the OS need not be excessively delayed by the presence of exits; you just need to have good, solid code and a good testing methodology in place. But you need that anyway, don't you? As far as auditors are concerned, if they know what they're actually auditing, then they will understand reasoned arguments in favor of the appropriate exit. And of course you're going to protect ANY exit as carefully, or more carefully, than any other piece of APF-authorized code. Right? -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.8/1985 - Release Date: 03/06/09 07:20:00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
'cuz the RACF ones I have to deal with... :-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Friday, March 06, 2009 1:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking How do any of these "considerations" differ between an exit and the key applications the business depends on and without which they wouldn't need a computer system at all (or even be in business)? -Original Message- From: Tony B. Sent: Friday, March 06, 2009 10:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking Exits are a good alternative when: 1. The skillful author never retires, finds a better job, gets laid off, is transferred, gets fired, wins the lottery, or ages. 2. The company never is merged, acquired, downsizes, asks for a government bailout, acquires another RACF company. 3. The source is never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS-prior flavors. Else, the term exit should be renamed to "future headache for its inheritors." 5% of my experiences involved exits where the original author was still available... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.8/1985 - Release Date: 03/06/09 07:20:00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
How do any of these "considerations" differ between an exit and the key applications the business depends on and without which they wouldn't need a computer system at all (or even be in business)? -Original Message- From: Tony B. Sent: Friday, March 06, 2009 10:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking Exits are a good alternative when: 1. The skillful author never retires, finds a better job, gets laid off, is transferred, gets fired, wins the lottery, or ages. 2. The company never is merged, acquired, downsizes, asks for a government bailout, acquires another RACF company. 3. The source is never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS-prior flavors. Else, the term exit should be renamed to "future headache for its inheritors." 5% of my experiences involved exits where the original author was still available... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Exits are a good alternative when: 1. The skillful author never retires, finds a better job, gets laid off, is transferred, gets fired, wins the lottery, or ages. 2. The company never is merged, acquired, downsizes, asks for a government bailout, acquires another RACF company. 3. The source is never misplaced. 4. zOS is never upgraded from OS390, MVS/ESA, MVS-prior flavors. Else, the term exit should be renamed to "future headache for its inheritors." 5% of my experiences involved exits where the original author was still available... Jaded. :-( -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, March 06, 2009 12:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking -- - IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. -- I disagree, Hal. Exits CAN be overused and poorly coded; no argument there. But they often provide the only mechanism of tayloring function to fit business or technical needs, or sometimes arbitrary mandates from senior management. Testing a new installation or upgraded level of the OS need not be excessively delayed by the presence of exits; you just need to have good, solid code and a good testing methodology in place. But you need that anyway, don't you? As far as auditors are concerned, if they know what they're actually auditing, then they will understand reasoned arguments in favor of the appropriate exit. And of course you're going to protect ANY exit as carefully, or more carefully, than any other piece of APF-authorized code. Right? -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.8/1985 - Release Date: 03/06/09 07:20:00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
--- IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. -- I disagree, Hal. Exits CAN be overused and poorly coded; no argument there. But they often provide the only mechanism of tayloring function to fit business or technical needs, or sometimes arbitrary mandates from senior management. Testing a new installation or upgraded level of the OS need not be excessively delayed by the presence of exits; you just need to have good, solid code and a good testing methodology in place. But you need that anyway, don't you? As far as auditors are concerned, if they know what they're actually auditing, then they will understand reasoned arguments in favor of the appropriate exit. And of course you're going to protect ANY exit as carefully, or more carefully, than any other piece of APF-authorized code. Right? -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Yikes, Should I be scared of this? Externalizing the password rules in REXX? Seems to make it too easy to "collect" passwords. You can always use RACF to prevent anyone reading the REXX dataset. ;-) -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
--- Is there any RACF password rule that can validate the password cannot be a part of USERID? or only write a user exit to implement it? - I used an exit to prevent the password from being a ANAGRAM (scramble) of the userid. I used the USERIDS to fill in a translate table with non-zero values for each character of the USERID. Then I did a TRT on the password using that table. If the TRT completed, I rejected the password. I also used this exit to require that passwords could not start or end with a single numeric digit and enforced a minimum length of 6 characters. You can basically implement any rules you like using the password validation exit, and the code isn't really all that difficult. If I can find it, I'll send you a copy of my exit's source code, privately. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
On Sat, 7 Mar 2009 00:12:16 +0800, Tommy Tsui wrote: >I saw the REXX code and it's quite simple. Just turn it on...I will try it .. >thanks all of your help Do remember that it works only on z/OS R10 and later, though. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
I saw the REXX code and it's quite simple. Just turn it on...I will try it .. thanks all of your help On Fri, Mar 6, 2009 at 11:46 PM, Walt Farrell wrote: > On Fri, 6 Mar 2009 08:48:18 -0600, Hal Merritt wrote: > >>IMHO: exits as a subspecies are evil critters. They become an ongoing > maintenance challenge and tend to attract unwelcome attention from auditors. > Exits are hard to write, hard to stress test, and introduce a level of risk. > You need extraordinary measures in place to protect the code. >> >>On the well proven fact that there is no software that is completely bug > free, why would you want to introduce -more- bugs into your most sacred of > processes: authentication? >> >>There is another pretty interesting argument that as the complexity of your > solution package increases, so do the opportunities for holes. Perhaps put > there intentionally (the largest risk is internal) or intentionally (bugs). >> >>I once worked in an exit happy shop. Getting the exits updated and tested > tended to be the single biggest bottleneck in rolling out new operating > system levels. >> >>Of course, if you have a compelling business/technical need, then lock and > load. > > Those are some of the reasons that we provided the REXX part of the exit, > too, with code that implements some commonly requested functions. Ideally > all you have to do is set some switches to enable the functions we've > already written. > > -- > Walt Farrell, CISSP > IBM STSM, z/OS Security Design > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
On Fri, 6 Mar 2009 08:48:18 -0600, Hal Merritt wrote: >IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. > >On the well proven fact that there is no software that is completely bug free, why would you want to introduce -more- bugs into your most sacred of processes: authentication? > >There is another pretty interesting argument that as the complexity of your solution package increases, so do the opportunities for holes. Perhaps put there intentionally (the largest risk is internal) or intentionally (bugs). > >I once worked in an exit happy shop. Getting the exits updated and tested tended to be the single biggest bottleneck in rolling out new operating system levels. > >Of course, if you have a compelling business/technical need, then lock and load. Those are some of the reasons that we provided the REXX part of the exit, too, with code that implements some commonly requested functions. Ideally all you have to do is set some switches to enable the functions we've already written. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. On the well proven fact that there is no software that is completely bug free, why would you want to introduce -more- bugs into your most sacred of processes: authentication? There is another pretty interesting argument that as the complexity of your solution package increases, so do the opportunities for holes. Perhaps put there intentionally (the largest risk is internal) or intentionally (bugs). I once worked in an exit happy shop. Getting the exits updated and tested tended to be the single biggest bottleneck in rolling out new operating system levels. Of course, if you have a compelling business/technical need, then lock and load. My humble $0.02 US (before taxes). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Friday, March 06, 2009 7:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking Yikes, Should I be scared of this? Externalizing the password rules in REXX? Seems to make it too easy to "collect" passwords. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Friday, March 06, 2009 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking On Fri, 6 Mar 2009 12:17:49 +0800, Tommy Tsui wrote: > Is there any RACF password rule that can validate the password >cannot be a part of USERID? or only write a user exit to implement it? You would probably need an exit to do that. You can find a sample exit on the RACF downloads page (http://www-03.ibm.com/servers/eserver/zseries/zos/racf/goodies.html ) that should simplify that. See REXXPWEXIT. It works on z/OS R10 and later, and provides an ICHPWX01 exit that invokes a REXX exec via System REXX, and a sample REXX exec that you can tailor easily. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
On Fri, 6 Mar 2009 08:05:30 -0500, Jousma, David wrote: >Should I be scared of this? Externalizing the password rules in REXX? >Seems to make it too easy to "collect" passwords. System REXX execs run APF-authorized, and the libraries containing them must be protected the same way as any other APF-authorized library. If someone could update that REXX exec to collect passwords, he could also update an assembler exit to collect them, too. True, it requires a little more knowledge to create a program in assembler language that would collect a password and open a data set to record it, but that knowledge is wide spread enough that it's really the same concern whether you deal with REXX or assembler exits. So, no, you should not be scared of it. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
Yikes, Should I be scared of this? Externalizing the password rules in REXX? Seems to make it too easy to "collect" passwords. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Friday, March 06, 2009 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: RACF password & id checking On Fri, 6 Mar 2009 12:17:49 +0800, Tommy Tsui wrote: > Is there any RACF password rule that can validate the password >cannot be a part of USERID? or only write a user exit to implement it? You would probably need an exit to do that. You can find a sample exit on the RACF downloads page (http://www-03.ibm.com/servers/eserver/zseries/zos/racf/goodies.html ) that should simplify that. See REXXPWEXIT. It works on z/OS R10 and later, and provides an ICHPWX01 exit that invokes a REXX exec via System REXX, and a sample REXX exec that you can tailor easily. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
On Fri, 6 Mar 2009 12:17:49 +0800, Tommy Tsui wrote: > Is there any RACF password rule that can validate the password >cannot be a part of USERID? or only write a user exit to implement it? You would probably need an exit to do that. You can find a sample exit on the RACF downloads page (http://www-03.ibm.com/servers/eserver/zseries/zos/racf/goodies.html ) that should simplify that. See REXXPWEXIT. It works on z/OS R10 and later, and provides an ICHPWX01 exit that invokes a REXX exec via System REXX, and a sample REXX exec that you can tailor easily. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF password & id checking
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Tommy Tsui > > Hi all, > Is there any RACF password rule that can validate the password > cannot be a part of USERID? or only write a user exit to implement it? That functionality requires an exit routine. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
