Re: Bad Auditor Requests (Was Re: Hardware Alerts)
Long ago I was brought in to help the consulting company where I worked audit a government agency's VM system. The agency was running multiple levels of classified work under VM, claiming it was secure. The folks doing the security audit wanted to talk about all sorts of technical penetrations but I suggested something simpler: Look at Execs on public system disks, see what minidisks they linked to, examine what was on those disks, look for more Execs with links, rinse, repeat, etc. A couple days later they put a printout of the system directory on the director's desk with a note that security wasn't as tight as claimed. Don't neglect the ability of morons to make a secure system insecure... Thomas Kern said: My favorite was an auditor that wanted a printout of our /etc/passwd. This was a VM/SP system. When we stopped laughing at him and told him we didn't have such security holes, he went away. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042[EMAIL PROTECTED] -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
this is no joke - we had an govt-approved audit program that attempted to check for 'user-id as password' by attempting to login as that user with his/her userid as password (and noting where the login was successful) - reasonable - right? - WELL - someone decided to run this program twice in the same day - and of course 100+ folks (who had previously failed on their last logon attempt and temporarily given up or those who subsequently mistyped their passwords) got ACF2 suspended. When asked - the auditors reply was wow - does that knock out users on the mainframe too? we stopped running this on (whatever non-mainframe platforms) months ago . go figure . Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 [EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
snip- I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. ---unsnip- You would be STUNNED at the number of shops that don't think of something that simple. I could have named three large banking-related institutions here in Greater Chicago that never thought of it until I pointed it out to them. (Business-related discussions, when I was still working.) -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip There is no easy way to counter such a one and done approach - unless you either improve your database's physical security (don't let it get into the wrong hands) or also require the cracker to physically possess something presumably uniquely identifiable. (Like a physical key but usually electronic.) It isn't so much that good guys are getting harder to find as it is that bad guys are getting a little bit sneakier. unsnip Securing the RACF DB and all its backups will go a LONG way toward blocking these bad guys. Amazing how many shops don't take those simple steps. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Rick Fochtman wrote: snip- I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. ---unsnip- You would be STUNNED at the number of shops that don't think of something that simple. I could have named three large banking-related institutions here in Greater Chicago that never thought of it until I pointed it out to them. (Business-related discussions, when I was still working.) Let me ask this question - although this is not directly related to RACF - but to any access control system that locks out people upon failed access attempts.. Isn't locking out or revoking someone because of unsuccessful access attempts a wonderful denial of service attack opportunity ? You wait for your good friend in the next cubicle to go on a coffee break.. log him off (it he hasn't already done so) - and attempt to log in with bogus passwords 3 times.. and while you are at it, do the same for some other userids of some highly ranked officers from HIS terminal.. There is going to be some embarrassment for a LOT of people and a lot of time lost.. (your co-worker, the locked out people, the person responsible for security).. I am of course not saying anyone should do that.. But isn't it a potential problem with user name lockouts ? --Ivan -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
-snip-- Let me ask this question - although this is not directly related to RACF - but to any access control system that locks out people upon failed access attempts.. Isn't locking out or revoking someone because of unsuccessful access attempts a wonderful denial of service attack opportunity ? You wait for your good friend in the next cubicle to go on a coffee break.. log him off (it he hasn't already done so) - and attempt to log in with bogus passwords 3 times.. and while you are at it, do the same for some other userids of some highly ranked officers from HIS terminal.. There is going to be some embarrassment for a LOT of people and a lot of time lost.. (your co-worker, the locked out people, the person responsible for security).. I am of course not saying anyone should do that.. But isn't it a potential problem with user name lockouts ? ---unsnip The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Rick Fochtman wrote: ---unsnip The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! I know... But we are talking security issues here. Maybe a disgruntled employee who is about to get a pink slip or about the send a resignation letter anyway.. doing those kind of actions could make considerable damage to the company if the timing is right - while someone succeeding into breaking into a critical account by brute force seems to me more unlikely. I am going on the premise that someone caught attempting to circumvent or abuse security measures is at risk *anyway* ! What I am hinting here is that account locking COULD (in certain situations) be a security *risk* rather than a security enhancement to a system - because although brute force cracking of account credentials is possible, abusing a userid lockout is far easier and accessible to implement (it doesn't even require any skill) ! And don't ask me about those 'secure' systems that ask you to change your password every 2 weeks - with passwords that must be at least 32 characters long, with no dictionary words, a mix of upper/lower/digits/special chars - which invariably get written on post-it(tm)s and hidden under the keyboard. Just my .02€ --Ivan -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
---snip- The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! I know... But we are talking security issues here. Maybe a disgruntled employee who is about to get a pink slip or about the send a resignation letter anyway.. doing those kind of actions could make considerable damage to the company if the timing is right - while someone succeeding into breaking into a critical account by brute force seems to me more unlikely. I am going on the premise that someone caught attempting to circumvent or abuse security measures is at risk *anyway* ! What I am hinting here is that account locking COULD (in certain situations) be a security *risk* rather than a security enhancement to a system - because although brute force cracking of account credentials is possible, abusing a userid lockout is far easier and accessible to implement (it doesn't even require any skill) ! And don't ask me about those 'secure' systems that ask you to change your password every 2 weeks - with passwords that must be at least 32 characters long, with no dictionary words, a mix of upper/lower/digits/special chars - which invariably get written on post-it(tm)s and hidden under the keyboard. -unsnip-- You're still quite accurate. Here's what I did to avoid an extended outage: (Keep in mind that this was quite some years ago, before additional controls were implemented in RACF vis-a-vis started tasks): 1. I installed an exit which would allow all started tasks to run, whether they supplied valid passwords or not. The Systems Programming staff had complete control of Started Tasks, and any parmlibs that they might use. 2. I installed a Started Task that would RESUME selected userid's, with pre-determined passwords, based on parms provided in a tightly-controlled PARMLIB. 3. Access to the RACF DB, and its backups, was tightly controlled so that a brute-force approach, by unloading the RACF DB, wasn't possible outside the Security Administration staff (Me and one other System Programmer). 4. LOGON and Attempted LOGONs were audited, whether successful or not. A regular report of that information was generated, both for security admin staff and senior management. Information included was, among other items, USERID, number of attempts and TERMID (Thank you, VTAM). 5. If any DOS attempt was made for production userid's, the Operations staff had instructions to Run this Started Task and notify the ENTIRE security admin staff ASAP. We could then run some RYO reports to try and pinpoint the issue and/or offender. IIRC, there's been a modification to RACF such that a started task will never be denied LOGON access; what happens after that depends on the various profiles in the RACF DB. We had a job scheduling package in place and we used the propogation features for USERID and password, so NO production job contained either form of information. Another exit, for TSO SUBMIT, disallowed any USERID and/or password information to be submitted via TSO SUBMIT commands. A very few people were allowed to supply USERID information, via the SURROGATE mechanism of RACF. NOBODY was given SURROGATE authority for Started Tasks; even the security folks didn't have it. And STC Production passwords were unknown. The job scheduler had SURROGATE access for the various production ID's, so providing a password was not needed. Sooner or later, you'll have to invest a certain amount of trust in a selected, and trusted, few employees. If you can keep that to a minimum, you can minimize the risks of an extended outage because of security abuse; you just have to decide who you trust. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip-- Well.. I know (or at least it, so it appears - since I don't *KNOW* you) you are indeed a thoughtful security officer.. (And.. err.. started tasks bypassing authentication is definitely a solution - yet - doesn't it give people with access to the console an awful lot of power ? (just a question.. I'm not a z/OS guy ! maybe I'm getting this all wrong !). unsnip You can definitely control what can be run as a started task. You need to understand JESS2 JCL and control statements but controlling STC access is definitely possible. And I tried very hard to be a good, thoughtful security officer. I sometimes P***ed off my management because I refused to reveal certain passwords, etc. to management or even to security auditors. snip--- The message I am sending is that a 'three strikes and you're out' solution is not a panacea. I wasn't sending the message to you - but rather - to *everyone* out there who may be confronted with the evil 'know it all' auditor/consultant who is going to *instruct* people to implement these sort of measures indiscriminately (because that's what is on his checklist !)... And maybe to those who hadn't thought of some of implication of such a policy (if it isn't implemented correctly). ---unsnip-- Nothing is a complete solution in this area. But auditors like to see some form of reasonable limitation in this area. Negative implications don't interest most auditors; they have, in most cases, their own pre-conceived ideas. And unfortunately, management is more likely to listen to them than you, because they paid some (outrageous) fee for the auditor's opinion. --snip Actually a 100 strikes and you're out (or some quite large number) may be a possible solution : it avoids brute force attack through some TN3270 API - yet - someone doing this will be easily detectable - AND it avoids the CEO with a bad hair day to be locked out - and starting firing people by the dozen (because eveyone knows the CEO will *have* a bad hair day[1] on the critical day). --unsnip- See above comment. If the CEO gets hit, that's tough. If he's not security conscious, then make him set the standards, in writing. He can live (or die) by his own pronouncements. Wait'll the auditor sees it, then watch the fertilizer hit the Westinghouse. ---snip Then again, a script kiddie may be able to lock out people that way.. (but it does lower the risk).. unsnip The more chances you give that script kiddie, the better his chances of success. 'nuff said?? ---snip--- And about the password aging problem and complexity.. My (personal) recommendation is (mind it, I am NOT a security officer.. just an aging sysprog) : allow passwords to remain unchanged for a long period of time - yet - force somewhat complicated passwords : This way : people won't have to write them down, however, they are hard to crack (through bruteforce attacks on hashes) and - furthermore - once they are accustomed to their passwords, they will type them fast at the keyboard (mitigating the 'over the shoulder' attack). My usual password isn't very long - 8 chars.. but I can type it in a matter of ~500 ms. ---unsnip Password aging and complexity can be good things, provided they aren't carried too far. Because of business functions, our users had to logon at least monthly, on the first business day of the month. So we gave them 36 days. But if a password had leading or trailing digits, we required at least two digits and we didn't allow a password to be a anagram (scramble) of the user id. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 10:06:33 -0500, Bass, Walter W [EMAIL PROTECTED] wrote: I recall the password encryption algorithm for IDMS back in the late 80's worked by repeatedly multiplying and then discarding the upper byte of the result. We actually duplicated this logic in COBOL so that we could hash user entered passwords and compare them to the stored values in the data dictionary. This algorithm was considered irreversible because there was no way of knowing the value of the bits that got discarded at each repetition and a single hash could not decrypt to one unique password. If I wanted to crack this, I would start with: http://en.wikipedia.org/wiki/Linear_congruence_theorem -- gil -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. DC -- 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
Re: Hardware Alerts
On Wed, 21 May 2008 09:01:04 -0500, Hal Merritt [EMAIL PROTECTED] wrote: If possible, I would be using the phone system PBX for this. Find out the numbers that the IBM equipment is dialing, and then have the PBX handle the rest. Send emails or call someone telling them that the evil piece of IBM equipment is phoning that number. Put the burden of this audit point on the phone system guys. Or put in your own open source PBX (I use Asterisk a lot) in the machine room and run all of the IBM equipment through it. Handling this request after that is trivial. It logs phone use for you and send emails or call folks when something happens as I described above. Does anyone know if there some way IBM could generate an email upon a phone home event? -- Gary Eheman http://www.funsoft.com -- 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
Re: Hardware Alerts
Good idea, but the z/boxes make routine 'heart beat' calls as well as (in our case) usage reporting calls. Even so, that suggestion has been percolated. Maybe a PBX guru could see a way to tell the difference. Thanks!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gary Eheman Sent: Thursday, May 22, 2008 9:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Hardware Alerts On Wed, 21 May 2008 09:01:04 -0500, Hal Merritt [EMAIL PROTECTED] wrote: If possible, I would be using the phone system PBX for this. Find out the numbers that the IBM equipment is dialing, and then have the PBX handle the rest. Send emails or call someone telling them that the evil piece of IBM equipment is phoning that number. Put the burden of this audit point on the phone system guys. Or put in your own open source PBX (I use Asterisk a lot) in the machine room and run all of the IBM equipment through it. Handling this request after that is trivial. It logs phone use for you and send emails or call folks when something happens as I described above. Does anyone know if there some way IBM could generate an email upon a phone home event? -- Gary Eheman http://www.funsoft.com -- 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 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I recall the password encryption algorithm for IDMS back in the late 80's worked by repeatedly multiplying and then discarding the upper byte of the result. We actually duplicated this logic in COBOL so that we could hash user entered passwords and compare them to the stored values in the data dictionary. This algorithm was considered irreversible because there was no way of knowing the value of the bits that got discarded at each repetition and a single hash could not decrypt to one unique password. However, since the original encryption algorithm was known, I believe that the passwords could have been broken by a brute force decryption program that simply substituted all 256 possible values in place of the discarded byte and create a list of all possible passwords that could have encrypted to the current hash. Once that list of possibles is created, you just look for the one that consists entirely of EBCDIC characters and you have your password. Bill Bass United Health Care Greenville SC -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Cartwright Sent: Thursday, May 22, 2008 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts) On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. DC -- 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 This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip--- I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. -unsnip-- I'd sure like to see his mechanism. Security is one of my hot buttons, having been a RACF administrator for many years. My RACF database files were also RACF protected. When I was asked for an unloaded copy, I had a special little program, using UPDAT I/O, that set all password fields toX'00 values so nobody could even try to decypher passwords. At least, not with any hope of success. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 09:17:34 -0500, Dave Cartwright [EMAIL PROTECTED] wrote: On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. No, it's not an urban myth. Properly configured (to use DES (the default), rather than masking), RACF does not store a user's password on the DB. It encrypts the user ID using a slight modification of the password, and saves the encrypted result. All you can do, assuming you can read the DB to extract the encrypted value, is a brute force attack where you propose a password, encrypt the user ID, and see if it matches. That's a significant amount of work, though of course: (a) machines are getting faster, and the work can perhaps be split across many machines. (b) overly restrictive password rules can reduce the amount of work. Note, though, that this kind of attack requires either the ability to run an APF-authorized program on the system, or physical access to a copy of the database, in order to retrieve the encrypted value. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Heck, Nigel Pentland has two utilities that look for weak passwords (DOS- based) that I'ved used for quite some time to ensure a client is using strong passwords - CRACF and WEAKWORD. One just checks the USERID or DFLTGRP name, and the other uses a dictionary list. WEAKWORD (the dictionary list one) doesn't display the password. So yes, the passwords are recoverable - after a fashion. On Thu, 22 May 2008 11:18:13 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: --snip--- I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. -unsnip-- I'd sure like to see his mechanism. Security is one of my hot buttons, having been a RACF administrator for many years. My RACF database files were also RACF protected. When I was asked for an unloaded copy, I had a special little program, using UPDAT I/O, that set all password fields toX'00 values so nobody could even try to decypher passwords. At least, not with any hope of success. -- 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 -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 11:46:18 -0500, Walt Farrell [EMAIL PROTECTED] wrote: On Thu, 22 May 2008 09:17:34 -0500, Dave Cartwright [EMAIL PROTECTED] wrote: ...snipped... I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. No, it's not an urban myth. Properly configured (to use DES (the default), rather than masking), RACF does not store a user's password on the DB. It encrypts the user ID using a slight modification of the password, and saves the encrypted result. All you can do, assuming you can read the DB to extract the encrypted value, is a brute force attack where you propose a password, encrypt the user ID, and see if it matches. That's a significant amount of work, though of course: (a) machines are getting faster, and the work can perhaps be split across many machines. (b) overly restrictive password rules can reduce the amount of work. Note, though, that this kind of attack requires either the ability to run an APF-authorized program on the system, or physical access to a copy of the database, in order to retrieve the encrypted value. Ray assures me that he did not say that he can recover passwords. He did say that when he finds he has READ access to the RACf database, that he retrieves the encrypted data and breaks the encryption. That specifically means a brute force password guessing attack such as I described above. His purpose in mentioning that was to make sure that people understand that giving users READ to the RACF database is not a safe thing to do. We have had discussions with z/OS security administrators who have felt that since the password itself is not saved, that there's no reason to prohibit reading the database, and Ray was pointing out the flaw in that thinking. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- 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
Re: Hardware Alerts
2008/5/22 Gary Eheman [EMAIL PROTECTED]: If possible, I would be using the phone system PBX for this. Find out the numbers that the IBM equipment is dialing, and then have the PBX handle the rest. Send emails or call someone telling them that the evil piece of IBM equipment is phoning that number. Put the burden of this audit point on the phone system guys. There are dialer boxes available very cheaply (Google on Mitel PAV or Smart-1 for a popular example) that used to be used for the old-style dial-around long distance services in the 1980s and 90s. These boxes analyse input digits and modify the output in various ways, which can be quite subtle, and could include dialing multiple calls, one of which could be to a pager or a mail server. They also have an RS232 logging output, which could drive all sorts of computerish (rather than phonish) things. Or put in your own open source PBX (I use Asterisk a lot) in the machine room and run all of the IBM equipment through it. Handling this request after that is trivial. It logs phone use for you and send emails or call folks when something happens as I described above. This is a very neat approach, if you can make it fly in the corporate world. Who knows - there may be a niche you can fit in, where the phone guys believe it's mainframe stuff so they don't care, and the mainframe hardware people (including IBM) believe it's phone stuff so they don't care either. Asterisk *is* a very cool piece of software, though you do have to watch out for consultants and such people trying to sell you things that are free. This all assumes we are talking about phone home literally. If the call is over the Internet then all you need is a proxy of some sort. Tony H. -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. Eric Doc Farmer [EMAIL PROTECTED] wrote: Heck, Nigel Pentland has two utilities that look for weak passwords (DOS- based) that I'ved used for quite some time to ensure a client is using strong passwords - CRACF and WEAKWORD. One just checks the USERID or DFLTGRP name, and the other uses a dictionary list. WEAKWORD (the dictionary list one) doesn't display the password. So yes, the passwords are recoverable - after a fashion. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 14:23:53 -0500, Eric Bielefeld wrote: I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. If you have been successful in obtaining and cracking the RACF database (or a database copy) then you will only need 1 try -- it ought to be successful. There is no easy way to counter such a one and done approach - unless you either improve your database's physical security (don't let it get into the wrong hands) or also require the cracker to physically possess something presumably uniquely identifiable. (Like a physical key but usually electronic.) It isn't so much that good guys are getting harder to find as it is that bad guys are getting a little bit sneakier. -- Tom Schmidt -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. This has been discussed many times on RACF-L. If you can get at a copy of a RACF D/B, you can do a 'brute force' attack on the passwords, especially if you know the encryption algorithm, which is not a secret. Hence, IBM (and most security experts recommend protecting both the D/B and all copies. - Too busy driving to stop for gas! -- 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
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. Brute force against a copy of the RACF D/B. Solution: protect the D/B and all copies. As for the 3 strikes rule, I agree. It's deja vu for the very first time. This discussion thread has been done over on the RACF-L. - Too busy driving to stop for gas! -- 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
Hardware Alerts
Our auditors are asking us if there is any way we can receive automatic email alerts when the gear phones home. I am aware of some email features on devices such as the DS8100, but we don't currently allow any external exposure to those devices. Does anyone know if there some way IBM could generate an email upon a phone home event? Thanks!! 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware Alerts
Of what value is that to an auditor? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/21/2008 10:01:04 AM: Hal Merritt [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 05/21/2008 10:01 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Hardware Alerts -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Hal Merritt [EMAIL PROTECTED] Subject: Hardware Alerts --- Our auditors are asking us if there is any way we can receive automatic email alerts when the gear phones home. I am aware of some email features on devices such as the DS8100, but we don't currently allow any external exposure to those devices.=20 =20 Does anyone know if there some way IBM could generate an email upon a phone home event? =20 Thanks!! =20 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 mess= age,=20 together with any attachment, may contain confidential and/or privileged in= formation. Any unauthorized review, use, printing, saving, copying, disclosure or dist= ribution=20 is strictly prohibited. If you have received this message in error, please=20 immediately advise the sender by reply email and delete all copies. -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: Hardware Alerts
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, May 21, 2008 9:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Hardware Alerts Our auditors are asking us if there is any way we can receive automatic email alerts when the gear phones home. I am aware of some email features on devices such as the DS8100, but we don't currently allow any external exposure to those devices. Does anyone know if there some way IBM could generate an email upon a phone home event? Thanks!! This is just an ignorant thought. But we have a central problem system, called CA-Unicenter. It can do SMS paging, via email, to our phones. It can also receive SNMP traps to generate those. Can your hardware be connected to your LAN and set up to issue SNMP traps to something like CA-Unicenter? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Hardware Alerts
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel McLaughlin Sent: Wednesday, May 21, 2008 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Hardware Alerts Of what value is that to an auditor? Daniel McLaughlin Who knows? It is likely on some check list somewhere. Many auditors, the poor kind, love those don't-have-to-think-about-it check lists! I once got a request from an auditor along the lines of: List all possible exists in all software for which you are responsible and what they could be used for. I pointed him to about 30 different manuals and said something like: You really should use a primary source and not depend on me because I might overlook something. He went away sorrowful for the books contained great riches. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Hardware Alerts
One of my favorite requests was for a vendor doing a conversion. He wanted all the passwords for user accounts in RACF. After being told three times that it was encrypted and not obtainable he went away muttering. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/21/2008 10:19:38 AM: McKown, John [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 05/21/2008 10:19 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Hardware Alerts -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: McKown, John [EMAIL PROTECTED] Subject: Re: Hardware Alerts --- -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel McLaughlin Sent: Wednesday, May 21, 2008 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Hardware Alerts Of what value is that to an auditor? Daniel McLaughlin Who knows? It is likely on some check list somewhere. Many auditors, the poor kind, love those don't-have-to-think-about-it check lists! I once got a request from an auditor along the lines of: List all possible exists in all software for which you are responsible and what they could be used for. I pointed him to about 30 different manuals and said something like: You really should use a primary source and not depend on me because I might overlook something. He went away sorrowful for the books contained great riches. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: Hardware Alerts
This is an internal auditor and high availability is a high priority to our management. Actually, I'm lead to believe that such email alerts are becoming a de facto standard. Many monitors across many platforms are offering that feature. We have had more than one occasion where a phone home occurred and IBM's attempt to contact someone to coordinate repairs failed. More, we manage our production environment by sending emails about exception events. We feel like it works well for us. Extending that to hardware management is a small step. Right now, we feel that the known risks associated with interconnecting these machines to the company LAN outweigh the potential benefit. But this is all a living process and ya just gotta keep up to remain competitive. My task is to explore the issue and present management with options. And thanks for all the replies so far!! Keep 'em coming. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel McLaughlin Sent: Wednesday, May 21, 2008 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Hardware Alerts Of what value is that to an auditor? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/21/2008 10:01:04 AM: Hal Merritt [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 05/21/2008 10:01 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Hardware Alerts -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Hal Merritt [EMAIL PROTECTED] Subject: Hardware Alerts --- Our auditors are asking us if there is any way we can receive automatic email alerts when the gear phones home. I am aware of some email features on devices such as the DS8100, but we don't currently allow any external exposure to those devices.=20 =20 Does anyone know if there some way IBM could generate an email upon a phone home event? =20 Thanks!! =20 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 mess= age,=20 together with any attachment, may contain confidential and/or privileged in= formation. Any unauthorized review, use, printing, saving, copying, disclosure or dist= ribution=20 is strictly prohibited. If you have received this message in error, please=20 immediately advise the sender by reply email and delete all copies. -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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 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 [EMAIL PROTECTED
Bad Auditor Requests (Was Re: Hardware Alerts)
My favorite was an auditor that wanted a printout of our /etc/passwd. This was a VM/SP system. When we stopped laughing at him and told him we didn't have such security holes, he went away. /Tom Kern On Wed, 21 May 2008 10:32:27 -0400, Daniel McLaughlin [EMAIL PROTECTED] wrote: One of my favorite requests was for a vendor doing a conversion. He wanted all the passwords for user accounts in RACF. After being told three times that it was encrypted and not obtainable he went away muttering. Daniel McLaughlin -- 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
Re: Bad Auditor Requests (Was Re: Hardware Alerts)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Wednesday, May 21, 2008 10:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Bad Auditor Requests (Was Re: Hardware Alerts) My favorite was an auditor that wanted a printout of our /etc/passwd. This was a VM/SP system. When we stopped laughing at him and told him we didn't have such security holes, he went away. /Tom Kern What? You didn't give him your USER DIRECT? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Bad Auditor Requests (Was Re: Hardware Alerts)
Our instructions were to give them EXACTLY what they ask for or nothing. If he had asked in a more general way for a listing of user definitions, I would have prepared a sanitized USER DIRECT, but he was explicit and insistent on getting /etc/passwd. That was what was on his unix checklist. /Tom Kern On Wed, 21 May 2008 10:54:49 -0500, McKown, John [EMAIL PROTECTED] wrote: -Original Message- My favorite was an auditor that wanted a printout of our /etc/passwd. This was a VM/SP system. When we stopped laughing at him and told him we didn't have such security holes, he went away. /Tom Kern What? You didn't give him your USER DIRECT? -- John McKown -- 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
Re: Hardware Alerts
---snip--- One of my favorite requests was for a vendor doing a conversion. He wanted all the passwords for user accounts in RACF. After being told three times that it was encrypted and not obtainable he went away muttering. ---unsnip--- I would have sent his bleeding body back to the vendor in a garbage bag, with a demand for someone who knew what he was doing. Asking for passwords is ludicrous and he should have learned that early in his training (if he had any!) And if the vendor can't make the cut-over without breaching security, then it's time to find a new vendor! -- 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
Stupid requests (was:RE: Hardware Alerts)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Wednesday, May 21, 2008 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Hardware Alerts ---snip--- One of my favorite requests was for a vendor doing a conversion. He wanted all the passwords for user accounts in RACF. After being told three times that it was encrypted and not obtainable he went away muttering. ---unsnip--- I would have sent his bleeding body back to the vendor in a garbage bag, with a demand for someone who knew what he was doing. Asking for passwords is ludicrous and he should have learned that early in his training (if he had any!) And if the vendor can't make the cut-over without breaching security, then it's time to find a new vendor! Right up there with vendors whose products must have RACF OPERATIONS or UNIX root authorities in order to work correctly. Of course, I don't even like giving out APF authorization. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Hardware Alerts
I do like the idea of the alert when there is a failure. Our carbon based life form interactive units tend to miss these things and call when it's too late. Case in point - POR and IPL this past weekend. Operator IPL'd three times, and who knows why, before calling for help at 4:30 AM. I also understand the original poster's need at this time. I really am not very fond of those notes that start out the auditor needs... when it's some BizSchool grad who don't know MOSFET from core. But I digress. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: Hardware Alerts
On Wed, 21 May 2008 10:11:54 -0400, Daniel McLaughlin [EMAIL PROTECTED] wrote: Of what value is that to an auditor? ... Our auditors are asking us if there is any way we can receive automatic email alerts when the gear phones home. ... I suspect hearing about the phone home capability raises a spyware flag to some auditors. In fact, that sounds a whole lot like how I react when I catch something on my PC automatically connecting to its home. But more to the point, the auditor may be suggesting that anything serious enough to warrant notifying home base is also serious enough to notify the local folks. I think it's pretty reasonable for an auditor to want to know more about this. And it doesn't sound unreasonable that he would want someone local to be notified when a phone home happens. In fact, that sounds like something our operations staff and maybe the MVS system programming staff might want here. If that's the worst the the auditors have come up with, that's a pretty good set of auditors. They might be worth having around. Pat O'Keefe -- 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
Re: Hardware Alerts
Of what value is that to an auditor? Who knows? It is likely on some check list somewhere. Many auditors, the poor kind, love those don't-have-to-think-about-it check lists! I disagree. Auditors do not set standards, nor do they enforce them. Subject Matter Experts (SMEs) set standards (possibly with checklists). Auditors check to see which ones are being followed, and (if properly done) report to compliance officers. Compliance Officers enforce standards, or, at least, report to management who is not following standards. So, the correct question is: Of what value, did the SME think that was? - Too busy driving to stop for gas! -- 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
