Re: User transactions tracking in BPCS v4 -- BPCS-L

>From Al Macintyre - programmer, security officer, computer janitor, etc.

>  From:    saadaoui.z@pg.com (Zahouani Saadaoui-Z)

>  Al,
>  thanks for your input. I am going to try to be more specific on the needs 
I 
> have and explain the context.
>  In fact I am IT auditor and I would like, during audits, to be able to 
know 
> for certains critical transactions (like posting invoices, creating 
customers...)
> who has created the document (like who has posted the invoice number 999999 
> the 22/09/1999...).

When a person posts invoice 999999 on that date, it writes transactions to 
various files, one of which is ITH inventory history, with a "B" Billing 
Transaction Code, and has a field containing the user-id from which the 
billing was run, and you can run a Query/400 report or SQL SELECT to see who 
is the person who posted it ... in fact you can work with IT to get an 
inquiry in which auditors in general key in any invoice number or date range 
& get the identity of who created it.

However, I have two problems with this perspective.

1. If the site being audited has granted command line authority to users, 
someone could create a bogus invoice, which captures THEIR identity, then 
they go in with DFU or SQL and change the identity of the perpetrator to some 
innocent party.  Thus, you need to chat with the CEO CIO Computer Security 
Officer etc. to review how wide spread command line authority has been 
granted, how many people happen to know the IBM security officer passwords, 
etc.  In other words does the company, that you are auditing, take computer 
security how seriously?

2. Depending on the nature of the business, the person who generates invoices 
is doing merely a clerical function, in which the billing creates invoices 
for alleged shipments that have been setup by ORD590 whose data is stored in 
the ES* files by document, or special charges setup in ORD500 whose data sits 
in ECS until billed.  Thus the invoicing clerk could be a totally innocent 
patsy to some bogus information entered that that person has no knowlege of, 
but that person is who the history says created the invoice.

I think it would be extremely helpful for you to get a briefing from a BPCS 
security officer regarding how a site can control who may have access to what 
kinds of  applications ... a security audit should precede the kind of 
questions you are asking ... if BPCS security is being used thoroughly, and 
command line authority is not generally granted, and people's password 
sharing is sensible, then there are only certain people who may create 
customers, vendors, issue money, create expenses, etc.  

There are also some great manuals from IBM that look at areas of possible 
exposure ... like BPCS V4 will not work above security level 30 (unless you 
pay to have it upgraded) while IBM firewalls will not work below security 
level 40, and various employees with PCs connected to the AS/400 & also some 
deal where THEY (and unauthorized individuals that THEY are unaware of) can 
dial in through that PC.  There's ways to protect against all of that, but 
one has to know what the threat is to do a competent job of protecting 
against it.

Now you as IT auditor need to know in advance of asking the kinds of 
questions above, to what degree the site has secured itself against a 
diversity of spoofing the data that you might be using to answer your 
questions & perhaps this discussion should be taken off BPCS_L before I say 
too much for the ears of the purveyors of fraud.

>  Now in case of fraud for instance, it is not possible to find out who 
keyed 
> the transactions in BPCS.

There are some kinds of transactions secured so that not even someone with 
IBM Master Security Authority can muck with them ... I might suggest that you 
attend the IBM classes in how Security functions, then talk with someone in 
the IBM security biz how practical it is to add other activity to that kind 
of audit trail.  But in general, you are right, BPCS has not been designed 
from the perspective of serious security.

>  What I would like to work out is a tracking mechanism that would add a 
user 
> ID to the document created for critical transactions, and that would not be 
too 
> much resource consuming.

I suggest that you make an inventory of the documents you want to track ... 
you might not want to track reporting of production, or QC inspections of 
RMAs etc..  Then I suggest that you look at the transaction effects & the 
files created when those documents are created ... an awful lot of stuff does 
create a history record that identifies the user who was signed on doing the 
transaction involved ... this is ALREADY in most of BPCS V4.

There may be cases where you want to track who did that in which the BPCS 
files do not have such a user-id field.  I suggest you look at the layout of 
the file & consult with the company to be audited regarding which of those 
fields they do & do not use.  In essence I am reccommending against making 
any changes to file structure, because of the cascade effect of other 
hassles, rather if you can find a field that is either not being used, or has 
a chunk of blank unused space, then you decide to use that spot for this 
other purpose.

Then the program that does the activity you want to track, needs some 
modification to plug user-id into the space you selected to get that info.  
This is a relatively minor modification in most cases - the work is in 
researching where to put the info.  However, my hands are tied because I do 
not have AS/Set.

The resource impact would be minimal, because when the program sends data to 
the history file, you have added one field to a large number of fields in one 
record.

> From: KLChilds@aol.com
>  
>  Hello.
>  
>  We had just the same requirement and evaluated the level of change 
necessary 
>  to support that in BPCS.  Instead of doing that many modifications, we 
opted 
>  to use the AS/400 journaling function.  
>  
>  Hope this helps  !!
>  
>  Lynn

At Central, I have been hurting for disk space, so I have not yet got 
involved in journaling, however, I suspect the extra copies of the programs - 
vanilla & modified, may be contributing to our disk space hurt.

> From: cpapp@merck.com.ar
>  
>  Zahouani,
>  I'm been working with BPCS for some years,  and transactions tracking is
>  something I always should like to have, but it was not possible. Only a few
>  files registers what had happened (like ITH ).
>  What I know is that the only way is to have this is with a 'Journal' of the
>  file, but I've never implemented this because it consumes to much
>  resources. May be you could evaluate this for some critical files.
>  
>  claudia

Since ITH has the info on a LOT of transaction types, then you might journal 
the cases you need that info on ... now depending on who needs the info when, 
like an annual audit, or the auditing firm using a different AS/400 than the 
firm being audited, you might look at archiving the journal off-line, and 
getting a copy of the ITH file on the eve of EOM when chunks of it get purged 
according to the rules in SYS800.  & that is another security issue ... who 
all can get into SYS800 to change the BPCS rules, between episodes of 
possibly fraudulent behavior?

>  From:    saadaoui.z@pg.com (Zahouani Saadaoui-Z)
Just to keep the threads somewhat clear on who said what.

>  Any idea on how to do that? Thanks for your help.
>  
>  Regards,
>  - Zahouani.

In my prior posting 

>  Some tracking is built-in ... take a look at the layout of the BPCS files.
>  Either DSPFFD ITH to *PRINT
>  or WRKMBRPDM QDDSSRC BPCS405CDS or wherever your base source is

and Bill Robins identified THUSER field in ITH file.

<< snip >>

>  Many jobs generate some kind of audit trail of what was changed, like 
ORD500
>  INV100 etc. ... we generally delete ours without printing ... you could
>  transfer yours to a PC, clean out a lot of data & just save what you need 
to
>  track which customer orders were updated today & by whom, and by item # who
>  was the last person to update it.

Some of that can be automated.  You might check out what ROBOT/400 from HELP 
SYSTEMS has to offer.
http://www.helpsystems.com

>  Have you been to IBM/400 classes with "DB2" in the title?  
>  Business rules can be established at the file level ... 
>  Any time ANYONE updates this file by ANY
>  means (BPCS program, DFU, interactive SQL, you name it) 
>  capture some particulars about who is doing what.

Hope I have continued to be helpful.
 
Al Macintyre
http://www.cen-elec.com
(812) 421-0231 - I work swing shift into the evening
fax # = (812) 424-6838
+---
| 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
+---