Hmmm - we had consultants with similar dumb decisions at my previous employer during a BPCS installation. They were having problems programming and running into authority issues. Well freakin' a - we had a secure system. They came to me said I needed to run GRTOBJAUT *All/*All and then they would be OK. I said "You've GOT to be kidding ? No way. Let's work together to figure out solutions to the problems you are having." Seemed logical to me. But he didn't like that and went to my boss who comes to me and asks me why I won't do what they were asking. This was a VERY sensitive political mess because the BPCS installation was replacing a home grown system. I came into the home grown system way late and didn't write NEAR as much as others had. So anyone mentioning ANYTHING that could be construed as "negative" to BPCS, even it I was a legitimate concern, got a bad rap/branded. So I told him my concerns and the holes something like that would open up and that I had offered to help them figure out their problems and that he had said no, do it. And my boss said to do it. And I said, "OK I want something in writing that says you said to do this despite my being against it" - and he did it. Unreal. True Dilbert moment. I bet I can guess these who these consultants were... Chuck -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac Sent: Thursday, November 09, 2006 3:07 PM To: Midrange Systems Technical Discussion Subject: RE: iSeries Security in Computerworld Any time some new package is implemented, or we go through a conversion to different platform, etc. there ought to be some consideration given to the security rules. However, in any implementation or conversion, people tend to be swamped ... IT, project team, testers, management, everyone. In our Y2K conversion, we were going from BPCS/36 to BPCS/400, and our project team got an education in choices on 400 and in BPCS. They saw that it was possible to run this with no security whatsoever, and that's what they called for. Normally I did everything the project team called for, going to management for occasional help on prioritizing, and getting help where some things were going to take forever. With what I considered to be bad security decisions, I went to management to try to make the case that we ought to have on the new system a level of security commensurate with what we had before, then as time permits, study the new security capabilities to see what bars ought to be raised. I was particularly annoyed when our consultants took security off of the system without first checking with me, and I told management that if you ever want to have security in the future, that all the testing to date could be for naught. The consultant's explanation was that they had a lot of work to get done, and the security was getting in the way, so instead of diagnosing the problem, they killed the security. In any conversion, everyone is swamped, including management. So they made a ruling to compromise between what I was calling for (such as a minimum of 4 characters in the passwords, and blocking ordinary users from running end-fiscal stuff that could not be reversed) and what the project team was calling for (no passwords). Management made a perfect compromise. Two characters minimum for passwords. We still that way today. As new managers come on board, I tell them that when they get familiar with our system, I would like to brief them on what I consider are some of our problem areas, such as poor security. Many opt out on this briefing, but quite a few have been told about the 2 character password minimum, and have consciously decided to continue that rule.
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact