Security & Closing BPCS Users Back Doors -1-

I hope you are finding my "S e c u r i t y" series to be constructive
references.  I sent out a much longer e-mail to some folks on this topic &
included some of their insight here.  Thanks to Bob Mack & Dean Asmussen for
ideas.  What I want to try to focus on are the problems needing security hole
plugging without getting overly verbose (my biggest failing).  

Fear of PC Viruses

We are not heavy on PC connectivity yet, so a fear I have which I do not know
how likely it is, includes COMPUTER VIRUS INFECTION from individual PC to LAN
managed by AS/400 host to the virtual PC disk space run by the AS/400 to all
connected PCs to ...   

The last time the company had a major computer virus infection was due to end
users who had no comprehension of what a computer virus was, and a general
lack of corporate policies to prevent infection risks.  Our in-house PC Guru
was overwhelmed with work - one site had several infected PCs.  He spent a
weekend on the job & got all PCs cleaned except one, which will have to be
solved on a later visit.  He walks around the office first thing Monday
morning & tells EVERY USER that you MUST NOT USE THE PC in the remaining
office for ANY reason until he gets finished fixing it.  What he should have
done is padlocked the office door, or taken the PC off the premises.

One of the users who had been told this, also was without a printer, because
it was broken & off for repairs, so she needs to print something, so she has
her word processor software on diskette & her data, so she walks around the
office with her diskettes looking for a compatible available printer & lo,
there is a PC not being used by anyone & it is totally out of her mind what
the PC Guru said Monday morning.  So the next time the PC Guru comes to the
office, what he finds is this user not only re-infected her PC, but she had
this problem (due to the virus) with her PC that she did not understand, and
while waiting for the PC-Guru to come look at it, she took her diskettes
around the office to beg or borrow time on other people's PCs which were now
re-infected.

When I heard this story, my first thought was "Hey, she also uses Carbon Copy
to call corporate ... can that virus go through Carbon Copy?"

BACK DOORS = a way to get into an application & change the data without the
customary security or audit trails or data integrity consistency maintenance. 

I wear many hats at my employer, one of which is Security Officer.  I often am
aware of humongous holes in overall security, but I carefully make sure that
the only people I tell about the holes are on the basis of business need to
know, such as the management control of budget that might include tools to
help manage our security a bit better.  There are locked offices & padlocked
areas that are real easy to get into, without leaving any traces, if you think
"outside the box" but I don't need to point out to people how to do that who
do not have the need to know.

When a new boss takes over, one of the things I brief him on is the state of
our security - overall the good & the bad.  Thanks to our Y2K conversion from
BPCS/36 to BPCS/400, that picture has gone through a radical shift & many of
us are still learning what is practical & wise.  My boss is right in the
middle of that re-education, but there may come a time that I may feel the
need to do a review of this kind of thing - how has it changed from the old
environment?

Audit Trails - My challenge is when something gets messed up, and users ask
MIS how that could have happened, so we can prevent that happening again,
without an audit history, we are lost, and many applications lack good history
tools.  I gave example in another posting of the difficulty of figuring out
what all got changed in volatile Customer Orders.  A common scenario is COSTS
being updated - tons of different activities update our costs but is there an
audit trail or good filters to back track everything that influenced costs we
know are incorrect?  Dream on.  

At Central the challenge is more often the APPEARANCE of something messed
up,.but it might be that we truely do not understand what we are seeing.  I
have worked at places where there was the appearance of Embezzlement & I think
that is more difficult to accomplish through BPCS, but not impossible.

Data Integrity is my primary interest - are the numbers in the different files
in synchronization with each other, because our users changed the numbers
using official programs that do not have any bugs, or have people gone outside
of the system to change stuff without a thorough understanding of the
consequences of their actions, or perhaps there are some bugs.  My job is a
thousand times easier when the files are in synchronization with each other.

So far, in my work with BPCS 405 CD, I have encountered SEVERAL categories of
Security Back Doors via OS/400 Command Line access to BPCS data in which all
the breaches I have uncovered were someone who knows enough to be dangerous &
does not understand where it is safe to experiment & forgets any warnings from
MIS about what is appropriate & what is inappropriate.  

One big risk today is that I have found it expedient to often tell end users
to contact SSA directly for help with some glitch.  They used to tell MIS
their problem, and the story had holes, but MIS did not understand the
application well enough to see the holes, then MIS calls SSA & it takes a
while to reach appropriate connection, and SSA asks questions MIS can't
answer, so original user must be consulted, and back & forth we go.  This
approach takes an eternity to get a solution, but at the end of the journey
only MIS knows how to do the fix under the covers using one of SSA's back
doors.

When the person with the problem communicates with SSA Help Support, the
problem is resolved rapidly.  I have supplied my users with Fax Back forms
that identify what our version numbers are - OS/400 & BPCS & various other
technical number crunching that no one outside MIS is going to remember, and
shown them how to get at appropriate data to illustrate whatever their problem
is.

SSA's solution is sometimes to use a DFU to change some flags within some
file.  Now that user knows how to use DFU but does not know when it is
inappropriate to use it.  I have been addressing that by getting the fix
information from the user into a collection of fixes for when this happens the
next time & re-iterating that we should never use these tools for any other
purpose except to fix exact scenario as described by SSA Help.

When we ever have spare disk space, we could track all cases of people using
certain OS/400 tools to update BPCS data under the covers.  When that day
comes, I will be asking for guidance here or on one of the AS/400 forums.

I am considering adding some special Message Queue just for exception fixes.
Every time I run the CIC over-ride or some other fix outside BPCS, it would
send a message there saying WHO ran WHAT with what parameters, and people who
use OS/400 commands to do this would also be asked to add to the log of
exceptions, then we could correlate who did stuff behind the scenes without an
explanation to this log.  This would also give us an audit trail on how often
we have to run various kinds of fixes legitimately.

We did something like that on BPCS/36 to track who was looking at General
Ledger outside of BPCS software, and prior to BPCS we had Payroll on our S/36
& we tracked who accessed Payroll data, outside of the Payroll dept personnel,
because during a long union strike, data was being smuggled out & management
wanted to know who was extracting the info.  I also sometimes thought it was
suspicious that some people would print out a complete list of our customer or
vendor master files who do not even work in the sales or purchasing
departments.

With Query able to access just about anything, and often users able to over-
run at run-time what is included, I am thinking that a smart move might be to
dump the Query Definition Data into a work file for a Query to print a report
showing which files are accessed by which Queries.  We have our security setup
so that while many many people can run Queries, that someone else has created,
they do not run them from the command line, rather they are run from a BPCS
User Menu.  This lowers exposure to the good judgement of the minority that
creates Queries.

Lessons here:

Understand OS/400 Security as well as SSA's

Who needs Command Line Authority Why - we have to provide those people
training so as not to abuse dangerous tools AND corporate needs tracking of
the usage of dangerous tools AND there needs to be some kind of POLICY about
priorities.  I have managers who are not security conscious who tell me some
new hire, whose training will be provided when practical, has to have Command
Line Authority but are unable to tell me Why, but that manager reports to
someone at the same level as my boss.  I believe that Command Line Authority
should NOT be granted anyone until AFTER they have been educated in how not to
abuse it.

I also need to figure out better ways of explaining to management how critical
this is.  They give the keys to the building & grounds to a very small handful
of people.  Command Line authority is like giving people the keys to
everything in our computer.  If you can't trust someone with a key to the
building alarm system, why do you trust them with Authority to Change Anything
on the Computer without Any Audit Trail of their actions?

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
+---