Security Documentation -- BPCS-L

I got the term BACK DOOR from the movie WARGAMES & I have been using it ever
since because even though ways around security are usually not there due to
nefarious reasons, the concept is very easy for non-IT to identify with.
FRONT DOOR is when you take menu option & run BPCS software & you get data
integrity, everything working in synchronization.  BACK DOOR is when you get
at BPCS data by some other means & update stuff, that your BPCS security
prohibits you from touching, without anyone gaining a thorough understanding
of the record interdependencies & there is a high risk of messing stuff up &
there is no audit trail on how this got messed up.

BPCS does have BACK DOORS from this perspective, that in my opinion are best
addressed through: overall security - OS/400 & who has command line authority
for what purposes; and proper training of power users who need the kind of
access that coincidentally gives them BACK DOOR access, to make sure they do
not abuse it.

Who should be the Security Officer Persons?  I suspect that across companies,
whether this role is inside IT or there are multiple such individuals, this
has a lot to do with the size of the operation in terms of facilities &
personnel.

You have to trust someone & for most of my IT career, I have worn the Security
hat along with programming & operations & other stuff, but sometimes it is
difficult to extract from user departments what they want - who should be
looking at this stuff, who should be allowed to change this stuff - when MANY
departments say to me "Our people should be able to do the following & other
folks should not be able to update our stuff" - these requests are in conflict
across department boundaries & this is a NORMAL situation at many companies.
There are also MANY departments that are not security conscious.  It is
IMPOSSIBLE to get from them any kind of sense of who is supposed to have what
access, until we have a serious security breach with their stuff, and
sometimes not even then.  SOMEONE has to decide on their behalf & often that
is a best guess by IT.

There is also the issue of changing duties within a company - a person is
given more responsibilities, they need access to more stuff, there is a
request to give them more access.   Every time I comply with such a request I
also inform my boss, the CFO, that I did so, so if this is blatantly invalid,
he lets me know promptly.  

I also inform the department that traditionally handles the maintenance of
some type of record, that I have been told to add a certain person to security
so that they also can maintain that information ---- purpose is to remind that
department that they may wish to verify that the new user has received
appropriate training so as not to add to the headaches of the data that gets
updated by them.

Most places I have worked there are end users who interact directly with the
computer system & they report directly to managers who have at most only the
most peripheral hands on, so I cannot communicate with the department managers
on security concerns any deeper that very vague depictions of a person's job
responsibilities.

Thus, it is helpful to have never-used User Profiles for the purpose of
Templates.  We just had a new hire in dept X for job function Y.  Copy Profile
XY to that person's name & it is ready for their end user training.   I
deliberately leave some User Profiles in our system, deactivated, on former
employees who have not yet been replaced, because when they are, I just rename
& re-use the old profile, knowing it will work for the person in that
department - IT is not going to get enough information through channels to
figure out what is correct.

I wish BPCS Security had options similar to OS/400 security for copying a
user's security or changing the user name.  TOM used to do this job.  Now
HARRIET does it, so just change TOM to HARRIET - sorry, BPCS does not have
that option.

There is a need to add some combination Security Reports from the perspective
of various corporate departments like Accounting & Engineering & --- who all
can access / update the kinds of information that is most relevant to our
responsibilities - are these appropriate individuals from perspective of
normal operations & who does what when someone is sick or on vacation?

I often find myself torn between the roles of making Corporate Security
decisions that I do not believe are IT responsibility, or trying to fob the
Security Management responsibility off on an upper management that will
understand WHAT we want in terms of inter-departmental responsibilities but
that is not going to be able to cope without heavy help from IT because
Documentation on Security is often hidden & obscure for security reasons.

Security Persons, in my opinion, need to have some IT understanding of
security from both the BPCS structural perspective and relative to
configuration issues of the individual platforms that your software is running
on.  Interaction between platforms can become very complex, and some risks
vary greatly by type of platform --- hackers & phreakers & viruses are unheard
of outside of the PC world, while I have only encountered pirate stations with
multi-platform pass-thru emulations.  As we move into platforms that are new
to us, there may be security pitfalls well known to regular users there, but
unknown to the newcomers.

IBM AS/400 comes with great manuals on Security, but some are clear as mud
until you take an IBM class on Security, such as S-6019 Backup & Security 

I cannot reccommend too highly IBM's manual = Tips & Tools for securing your
AS/400 SC41-3300  It has sections on types of environments: interactive; pass-
thru; internet; simple PC access --- various types of concerns are defined
(suspicious programs, types of mischef, carelessness), you are told what your
company can do about it, and some trade-offs.

BPCS also comes with documentation, some of which is on Security, but it is
poorly cross-indexed in that we might be looking at SOME information & need
more, but not know if there is any more & where to find it in the tons of BPCS
documentation.

If you have not previously, or recently, looked at SSA's documentation on
Security, I suggest you start with the vanilla short-cut DOC (you need SYS
access, or your application security setup specific to support your access to
DOC & a handful of related DOC options) and first look at 100% of what is
there (access via defaults) then it might be smart to print out SSARUN92
(System Functions in general) SSALOG00 (internal structure) and construct your
own Security document since the data that is relevant to managing Security is
kind of scattered throughout many different places.

Your security might not let you get into this through the front door, but
there are several back doors for anyone with command line authority.  As you
gain an understanding of front & back doors by application, you need to ask
what is common knowlege, what is secured by the hope that most people are
ignorant of that, and is your security appropriate for both sets of doors.

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---