Hi,
I did a presentation at Collaborate 2005 entitled 'Putting on your SOx one code change at a time' (how embarrassing - what was I thinking with that title
).
Anyhow - here's an excerpt from my notes from that presentation - with a few changes to hopefully answer some specific points that have come up in previous posts.
We have done this (CNC Inquiry only in PD) and it wasn’t as painful as you might think. Though we do have the luxury of having lots of people – enough to check on each other.
From a SOx viewpoint, you should try to segregate CNC, Developers and Security Admin.
I think most shops have CNC and Security Admin as the same people? What we do is we have a Business department that does security – and we call them System Admin. This group does E1 security, except for themselves.
All 3 groups have ‘Inquiry Only’ access in Production, except for specific applications, such as OMW and Package Builds (CNC only). So this is a lock down, grant back exercise.
For those of you with two accounts for your Developers (or anyone else), the access can be different in PD than elsewhere for the same group if you split the F00950 between PD and other environments. There is a white paper somewhere that tells you how to do this but it is quite straightforward – create another F00950 and use OCMs to point your non-PD environments to that table.
Developers should not be able to use any security or configuration tools in any environment, except with View access.
Lock down OMC and all Security Apps and other ‘scary’ apps – OCMs, DSs, Package Mgmt,etc.
Specifically for the Security Apps, we have put row level security on the Sys Admin people so that they cannot do their own or their own group’s security.
They must come to CNC for their own security, which isn’t a frequent occurrence.
Audit reports show what activity CNC has done on the security files so Sys Admin audits CNC by reviewing these reports weekly.
Recommend Audit Reports of Security Files:
F98OWSEC – User Password and System ID
F0092 – User Group
F0093 – Environment Access
F00950 – Security Workbench
We do this with DB journaling but you could use CFR21 Part 11 functionality.
In effect CNC and Sys Admin are each other’s controls.
So CNC does not have update access to any ‘end user’ apps. They do have access to grant themselves access but it will be caught and questioned by Sys Admin. In our case, that would include Address Book maintenance. I would suggest that your CNC folks try to pass that responsibility back to the Business – adding AB records is a big exposure that CNC shouldn’t be doing. I am not comfortable in documenting in an open forum the possibilities that exist here but I'm sure you can use your imagination.
If you don’t have the luxury of being able split CNC and Sys Admin perhaps an audit report of security changes that someone else reviews would be sufficient. This would only work after you can prove that whoever can do the security changes (say CNC) only has inquiry in production to everything other than chng mgmt tools - no business apps. Then the person reviewing the report will know to focus on the CNC group or ids showing up as making changes for themselves.
As for database access – this is controlled with the ‘system id’, not the logon id. If you are still using ‘JDE’ as the system id for all of your users, not much can be done there. We have individual system ids per user so have a lot more control.
The same 3 groups are the only ones with access to the database directly. Otherwise, access is controlled with application security. SQL access, particularly update access directly to files is very limited. CNC is the exception – and similar to Gregg’s story – their Manager must sign off on their access quarterly. SQL updates are also audited with DB2 journals so there is a record of all updates.
Hope this helps.
Sue Shaw
Shell Canada Ltd
Xe SP23J1 coexistent, System i V5R2
