I hope this can be of some help to get people going:
- Control access to the database environment.
- Only give people the bare minimum rights necessary.
- Have access authorized (you may need an approved list of authorizers), and keep copies of the authorization.
- Review access regularly, and have it re-authorized.
- Treat generic or service accounts like people, and don't give them too much access. Control who knows their credentials, and keep a catalogue of these accounts and functions.
Segregation of Duties- This is a tough one, but make sure that no one has too much access such that they can modify the production system without having to ask anyone for permission.
- Try to keep control over the production and test environments separate. This forces people who prepare a change or new release to seek approval, and show their homework is done before they can release their change.
- There will always be someone with full control over a system, so make sure their actions are monitored (i.e. Idera).
- Review segregation of duties regularly. Consider it for every process or rights assignment you have.
Change Management- Don't let anyone authorize and/or implement changes they initiate.
- Allow the DBA the right to refuse any implementation that does not have proper documented authorization.
- Do not make record level changes to application data unless fully authorized, justified and documented. These kinds of changes often help users out of a jam, but they go completely around the application controls. Denying users this ability might lead to better business process in the end, and get you off the hook for problems that might crop up from such changes.
- Document the day-to-day configuration changes you make.
Monitoring- You may be able to trade off some segregation of duties concerns if you are able to provide strong monitoring of actions.
- The DBA though should not administer any software that monitors his or her own actions for obvious reasons. This should ideally reside with a security group.
- Follow-up all issues discovered in the monitoring process. This can be tiring for the DBA if he/she is being regularly asked questions by the person in charge of monitoring (i.e. "Why did you do this?", "How does this work", etc.), but that's the new normal. It will be tiring for the person asking the questions too.
Backup/Recovery- Have processes written for both. Test them regularly. Document the testing.
- Review backup logs, and document the reviews to show that you're looking at them. You don't want to be caught saying I check them every day, and they're fine. If the auditor finds an unreported error, their trust in what you say will take a hit.
- Review backup schedules, and make sure they represent current agreements with your business units.
SQL Code- Make sure access to SQL code (triggers, stored procedures, anything additional used in DTS packages) is controlled. Do not make the code or schemas accessible to anyone who does not have a legitimate need.
You have probably noticed that auditors in general (there are exceptions) do not currently seem to have a great deal of depth where IT knowledge is concerned. This may mean that they are not necessarily digging deep. That is likely to change over the next few years though as SOX is having them beef up their skills. If you want to know what they're learning about your field check out http://www.isaca.org/Template.cfm?Section=IS_Audit_and_Control_Training_Week&Template=/ContentManagement/ContentDisplay.cfm&ContentID=22705, specifically the Database Security and Audit course.
If you want to see additional SOX documentation from an auditor's point of view go to http://www.isaca.org. I recommend starting with the "IT Control Objectives for Sarbanes-Oxley" pdf. It's about 100 pages long, but it's a surprisingly quick read.
Work with the auditors as much as you can. They usually want to see you succeed even though the process can be painful from time to time.
Good luck.