Umapathy, I have not seen anything that states what exactly it means to be "SOX compliant" in general, let alone for WMQ systems specifically. What I usually work from are specific criteria that address issues of accountability, traceability, transparency and security. There are a number of ways to achieve these goals with WMQ but they all are built on a foundation of good authentication and authorization. In the WMQ world, that means eliminating anonymous access to the queue managers by making sure every inbound channel has an MCAUSER set. In some cases it is set statically in the channel definition, in other cases it is set dynamically by an exit. But if you allow a connection with MCAUSER unset, then you are trusting that the ID presented in the incoming messages is genuine. If this is an MCA channel and context authority is turned off, you are also trusting that something OTHER THAN the local QMgr is performing authorization.
So, out of the box, you can enable SSL and use the MS0R channel exit to map SSL certificates to user identities for SVRCONN channels. For MCA channels you are limited to placing a low-privileged MCAUSER in the channel or using an exit, either of which can restrict access to the queues. Note that none of these options protect messages at rest. On the queue, they are still in plaintext. If you use a solution like Tivoli Access Manager for Business Integration (a.k.a. TAMBI), it is possible to map certificate credentials down to individual messages. This solution is sold as WMQ Extended Security Edition. When you have message-level authentication it is less important to have transport-layer authentication so TAMBI may reduce requirements to SSL-enable channels. These techniques address accountability. Another thing that you need to address will be auditability. There is some functionality available through enabling and monitoring event messages however these address mainly configuration changes. Something like deleting a poison message from a Production system would not be traceable using event messages. For this you need to track the activities of interactive users. If you administer your QMgrs locally from the command line you can capture all keystrokes of admin-level users and the audit logs are physically protected in a locked datacenter. If you use desktop tools such as WMQ explorer, you would need to use an exit to create a similarly protected audit trail. You can also use a centralized administration/productivity tool which is accessed by a web browser. In this case the audit log for the entire WMQ network is consolidated onto the server where the tool runs. This would probably be in combination with audit logging of admin IDs on the servers themselves since admins always need command-line access. There are many other factors for SOX compliance that are only loosely connected to WMQ and probably many more that are directly on point but these are where I generally start. The "loosely connected" factors include having a secure and compliant server baseline configuration, adequate separation of duties to impose checks and balances, etc. I would be interested to see what your final document looks like. -- T.Rob T.Robert Wyatt, Consulting IT Specialist IBM Software Services for Websphere email: [EMAIL PROTECTED] 704-719-2107 Access Line MQSeries List <[email protected]> wrote on 05/17/2007 09:16:29 AM: > Hello, > > What are the changes need to be done on a WMQ Server to make it > Sarbanes-Oxley (SOX) compliant. Ignore all platform related > procedures and other general user security. Also in what ways we > could be violating SOX if we as MQ Admins not following certain procedures. > > Is there any place where I can get a list and avoid reinventing the > wheel. If not I can create a document and post it to the list in the end. > > Thanks > > Umapathy > -- > --The browser you can trust - Firefox 2 > http://www.mozilla.com/firefox/ > --Please say NO to nuclear weapons > List Archive - Manage Your List Settings - Unsubscribe > Instructions for managing your mailing list subscription are > provided in the Listserv General Users Guide available at http://www.lsoft.com To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
