SQL Server SOX Compliance

[Catadmin]

Hey, All!

It's been a while since I've been around, but I'm looking for a bit of help. The company I work for is gearing up for a SOX audit and it occurred to my boss that we don't have SQL Server documentation regarding who has access to what and what sort of rules we follow to grant people access to SQL. Well it's been left up to me to write this document and I've never written a document for SOX (the federal Sarbanne-Oaxley law) before.

Has anyone had to deal with SOX compliance yet? If so, what sort of things are you documenting and is there a template out there for things to consider or are you just throwing together a MSWord doc or something?

Any advice you can give me regarding such a thing would be greatly appreciated. This is my first encounter with SOX.

Thanks!

Catadmin

Catadmin - MCDBA, MCSA
"If a person is Microsoft Certified, does that mean that Microsoft pays the bills for the funny white jackets that tie in the back???

 

[yetanotherjo]

I need to find out about this too...will let you know how I go in the next day or so.

 

[LuserNo1]

Here's a pretty good article by IIA (Institute of Internal Auditors.) It's about Auditing SQL Server Security. I hope this helps a bit.

http://www.theiia.org/ITAudit/index.cfm?act=itaudit.archive&fid=5611

 

[Catadmin]

LuserNo1,

Unfortunately, all it really talks about is how to secure your Server. That's all fine and dandy, but we have that part covered. What we're trying to figure out is what SOX auditors are looking for, how we should document all our processes for the SOX auditors and what additional stuff is going to come back and bite us in the rear end because we didn't consider it before the SOX auditors came.

I've heard a horror story or two about SOX auditors coming into the workplace and wanting to audit the DBA sysadmin team, knowing which DBA did what in the system, and failing the IT team because SQL doesn't audit which individual with Sysadmin rights did what, it just tracks that the Sysadmin account did X. Well, if you have more than 1 person with Sysadmin rights, the auditors start screaming ... You see what I mean?

Oh, well. We're trying to get ahold of our corporate auditing team to see if they can send someone down for a day or two to tell us what they're expecting us to do. I.E., "here's the paperwork you need to fill out", "these are the particular things we want you to monitor", etc.

In the meantime, if anyone else has any thoughts, I'd love to hear them. And if I hear back from our corporate auditors before someone replies, I'll post a tip on the group for anyone else who might need the information.



Catadmin - MCDBA, MCSA
"The only stupid question is the one that *wasn't* asked.

 

[yetanotherjo]

Well I drew a blank with my client's IT team. All I got after a blank look was a vague comment about they're only interested in who has access to the actual network. I'm not convinced that is the whole story so I'm all ears if anyone finds out anything....

 

[Catadmin]

The biggest problem is that even the Feds don't know what they want with SOX. They keep changing the requirements and nowhere in the actual law is details on HOW someone is supposed to comply.

ARGH! @=)



Catadmin - MCDBA, MCSA
"The only stupid question is the one that *wasn't* asked.

 

[Catadmin]

Just an update for those of you who are interested. Here is some of the preliminary work we're doing for SOX compliance (Sarbanes-Oxley). We don't have it all done yet, and some of it may have already been done previous, but we decided in our meeting to triple-check everything because all of the below actually is affected by SOX:


Use Reporting Services to generate bi-weekly audit report (one for each Production server) of all Server Logins & Roles, then each Database's logins/DBRoles and specific Select/Execute/etc. permissions on individual objects. The idea is to set up a subscription and send the report to the senior DBA and myself along with a copy to our manager so we can continually audit backend database security.

Create a database job which monitors database access and activity, especially for those with Sysadmin and dbowner rights. Create notifications for certain senior members of the team and certain managers.

Document the process for requesting and granting backend SQL Server access. Document procedures for removing users when they are no longer in a position to require their current permissions or have left the company. Demonstrate this is a repeatable process and is being followed 100% of the time and what we will do if we find someone has not followed this procedure or gotten access they shouldn't have.

Locate and automate any manually generated financial reports so no user intervention is required. This is to avoid someone "fudging" the figures.

Document the process for requesting and granting client end security access as above with backend security, etc.

Create legal document for external customers who use our website tool that makes them responsible for removing their employees' access when said employee(s) leave their company. Get them to understand the process and to sign the document.

Hope this helps someone else out with their SOX work!!!



Catadmin - MCDBA, MCSA
"The only stupid question is the one that *wasn't* asked.