|
Dear Jim ~ response #2, Response #1 presented overview information about the regulatory environment for IT security. This response discusses BPCS security vs. OS/400 security. Let's start with a narrow look from within the BPCS system and confine our attention to just BPCS. From that viewpoint, authority to use BPCS products, programs, menus, companies, warehouses, and transactions is defined at the User ID level. Now let's shift our viewpoint to the higher OS/400 level. From that perspective, each BPCS user is defined to be part of a group which owns all of the BPCS objects (programs, files, libraries, etc.). The group profile is named "SSA." Each user who is defined to be a member of SSA has the same ownership authority to BPCS objects as the group profile does. Here's a practical implication: Although BPCS user ROGERCOBY has been excluded from item master maintenance by the SYS600 BPCS security system, Roger's membership in the SSA group profile gives him the authority to change the item master file and even delete the entire item master file through DFU, SQL, DBU, etc. That's an acute vulnerability which would attract the attention of competent SOX auditors and which would also be classified as an unacceptable threat by the alphabet soup of other IT standards and regulations described in my earlier response #1. >>>> Here's the message >>>> >>>> >>>> >>>> >>>> >> 100% perfect application of BPCS security functionality (SYS600) does not begin to prepare your company for a SOX audit. Your vault door will still be WIDE OPEN. Our new product performs a risk assessment on every aspect of OS/400 security in full compliance with SOX, PCAOB, 21 CFR part 11, COBIT, and the rest of the alphabet soup of regulations and standards. Introducing ..... Bill of Health (tm) Security Diagnostics and Rx for iSeries http://www.unbeatenpathintl.com/BOH/source/1.html When Bill of Health ran for the first time on an iSeries with BPCS, the resulting security diagnostics report printed a giant warning signal about group profile SSA. The report then explained the acute nature of that security vulnerability and provided a recommendation on how to mitigate that risk. Please see these subsequent responses for BPCS/SOX topics: #3 ~~ more about the 'ROGERCOBY' example plus five other OS/400 vulnerabilities nominated by BPCS experts as "eye-openers." #4 ~~ learn about dozens of other OS/400 security risks identified by Bill of Health software. #5 ~~ information about a much more SOX-friendly idea than BPCS' clunky SYS600 security system. #6 ~~ learn how the PCAOB interpretation of SOX compels external auditors to look at the details of each BPCS business processes to identify internal control deficits and the consequent BPCS data integrity issues. #7 ~~ information about our award-winning Stitch-in-Time (tm) Data Integrity software that enables you to respond to SOX auditor inquiries about the integrity of DB2 information. #8 ~~ introduction to several other clever and affordable Stocking Stuffers (tm) for SOX products designed to help enterprises prepare for Sarbanes-Oxley. God bless, Milt Habeck Unbeaten Path International Toll free North America: (888) 874-8008 International voice: (262) 681-3151 European contact: (44) 1-737-824248 mhabeck@xxxxxxxxxx www.unbeatenpathintl.com ++++++++ +++++++ +++++++ +++++++ +++++++ +++++ From: Reinardy, James To: bpcs-l@xxxxxxxxxxxx Sent: Wednesday, June 09, 2004 3:17 PM Subject: DB2 Users Hello All, We are running BPCS 6.04 on iSeries. I am trying to understand the relationship between iSeries users, BPCS users and DB2 file access. The concern is arising because of Sarbanes-Oxley. Our auditors are suggesting that we need to lock down file privileges against the BPCS database, but we are a little unclear about what user BPCS uses for data access against DB2. Is it the individual user that is logged into BPCS, that user with a changed profile (SSA perhaps vs. *PUBLIC), or some other generic user? The idea here is to restrict access on a file by file basis for AS400Query, SQL queries, ODBC connections, etc. However, we want to be sure if we lock things down that we don't break BPCS screens and batch jobs. Any suggestions on how to improve our understanding in this area would be appreciated. Regards, Jim Reinardy Director-IS Badger Meter, Inc.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.