View Full Version : SOX Security Compliance Issues
03-20-2006, 10:34 AM
Perhaps I'm not understanding this. Why can't you give their own user profiles Master Security authority, and *ALLOBJ authority, without giving them the QSECOFR password? Dave
03-20-2006, 10:47 AM
Sarbane Oxley or SOX compliancy issues will not allow us to give anyone ALLOBJ authority. The SOX constraints are very rigid where security is concerned.
03-20-2006, 11:03 AM
Reading in between the lines, it sounds to me that the employee that creates USRPRF's on the system is also able to delete the same user profile that they created. The first question that comes to mind, due to SOX Security Compliance, should this be allowed? The answer to this is that SOMEBODY has to. The way to get around this is to create programs that can create/delete user profiles as well as to be able to run the CHGOBJOWN. Then change the owner of these programs to some profile with QSECOFR power and at the same time, change these programs to adopt owner authority. You should also set up auditing to capture the creation, deletion and change of user profiles. Reports should also be created to show who changed/deleted/created what profiles. Having worked for a bank (where internal and external auditing blows SOX compliance away), this HAD to be in place. Alan
03-20-2006, 06:09 PM
Thanks for your input. I found an article on ZSECOFR that was really helpful. Now all I'm left with is creating a way to report on the tasks performed by IT employees using the ZSECOFR authority.
03-27-2006, 05:54 AM
There are several ways to accomplish this. You can do it yourself for free (and LOTS Of time) or you can pay a modest price and accomplish your goals quickly with very little time. The free method is to use the iSeries' Security Audit Journal. While it is a free part of the OS, it is not for the faint of heart. I would highly recommend some serious study of the rather thick users guide. Basically, you configure it to log various type of actions into a secure auditing journal. From there, you are responsible for finding the records in the journal, converting them into a PF and writing up your own reports. There are two vendors that provide you with much easier solutions, and their prices are reasonable. The first is Tango/04. Here is a MC press article on their solution: http://www.mc-showcase.com/mcpress/showcase.nsf/ListProdUp/A826F25363D897E0862571240062B709 The second is PowerTech. Here is an link to a SOX page on their site. http://www.powertech.com/p_solutions_sox.html I have had experience with both products and I think either both would be worth your exploration and at least a demo. At the very least, you'll get some ideas about how to move forward on your own :) My company used to be a reseller for both products and they proved themselves as good solutions many times.
03-31-2006, 07:05 AM
Due to SOX issues I cannot give my IT employees the QSECOFR password. The employee that creates USRPRF's on the system is unable to delete a user that was created by QSECOFR and is unable to chgobjown on the objects owned by that user. We are a very small shop and need to find the easiest way to deal with the extra SOX issues. I would like to find a way to give my employee the ability to do these functions but not give them full qsecofr authority. I was wondering what the rest of you have done in this situation.
03-31-2006, 07:05 AM
I'd write a PGM or PGMs to do these tasks. CMDs and Menus too if needed for easy of use. Change then to adopt the PGM owner via CHGPGM. Make sure only the user or users need to perform these task have *USE to the PGMs. Also, have the PGMs document the changes via table updates or Emails. And as Joe Baumgarten said use Audit Journaling.
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.