RE: iSeries Security in Computerworld

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.