Where Can a DBA learn More about SOX
-
I'm totally new to this stuff. I'm told that the actual SOX "defining document" is thousands of pages and not practical for me to read through. I'm also told that SOX, in practice, is what our auditors tell us what we need to do. (My company is already talking to auditing companies that profess SOX expertise.)
Any idea where a DBA can start to learn about SOX?
TIA,
Bill
P.S. Around our company, our frontend applications control authentication. Often the application talks to the database using a single account, for all users, using the app. We can't begin to trace at the database level who is doing what. I'd bet SOX will have something to say about this approach.
-
We are going through SOX as well. Have already implemented a lot of "SOX" items. SOX for our company includes but is not limited to:
SOX, HIPAA, Segregation of duties, Plain ole common sense, Bill 481 (reporting security breaches), etc...
We have already locked down access to SQL data by role. Each role is associated with an AD (windows) group. Direct access to write to tables is via the application account BATCH and real-time WEB transactions. Direct access is also available via "emergency accounts".
Code management is also a biggy. Can code be installed into production without getting tested, approved, source code stored, etc...
Proper testing is/has been/will always be around nuff said.
Written approvals from the asset owner, project manager, etc... for good ole CYA and accountability.
Auditing is also HUGE. Can you track who dun what, when, why, how? If not WHY not and will your CIO signoff on it? If not looks like somebody is adding code to applications. It is VERY easy to capture Environ$("COMPUTERNAME"), Environ$("USERNAME"), etc...
These are a few of many FAVORITE
things...
Good Hunting!AJ Ahrens
webmaster@kritter.net -
I don't think anything is documented. We are implementing SOX too and I am guessing most of these "rules" are coming from someone's hiney. It's all subjective at this point.
AJ makes some great points though. I think if you follow what he is saying, you will survive any SOX audit.
-
If you are look at different SOX applications and are thiking of buying one i use to work for a compnay that developed SOX software so i can put you in touch with them.
-
Sox docuemnt is actually a group of practices that specific to different kinds of companies and the departments in the company.
As far as auditors, they get to make up the rules of what needs to be audited and at what level. This is where management gets involved. We 3 sets of auditors. Internal, External Consultant, External Audit. The consultant was suppose to help us formulate our own rules and practices (since the external can not make direct contributions, only tell us if we pass or fail). What gets my goat, is we went through this and ended up with 380 items for evaluation from the consultants. Our first audit (2 years ago), the external auditors said more than 1/2 were unacceptable or not needed. We not have 92 items. Each item contains 3 to 25 questions/lines.
Long and short, work with auditors, when they are unreasonable, it up to management to push back.
Most practices are easy to do and after you been through it, the quarterly stuff does not take long. We only have 1 item that is not acceptable. Protecting the systems from the DBA's (thats me). We have eveluated several products. Each would satify audit, but I showed them how I can get around them (I am not a good hacker), and each cost $100,000 plus.
Good luck,
Joseph
-
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.
-
Interesting reading Junkmail.
We had to go through SOX recently. Fortunately, I didn't have to read a whole lot of information. I just got a bunch of files from the auditors telling us exactly what requirements were required on our servers and I just followed those.
-
Here's some of the things we do to ensure SOX compliance:
Have an owner for each application who is responsible for approving any changes to the application.
Each database should have an owner for the data. This may be differnet than the owner of the application, if there ar emultiple databases associated with a single application. Data owners approve access to teh data.
Document the risks associated with each system, and have the application owner sign the risk assessment.
Document the controls that mitigate the risks for each system. The application owner should sign the list of controls
Where possible, track which ID made changes to data, particularly on tables with critical data.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply