In continuation to my previous post here :

I have been working with several Financial applications, during my current/Past consulting project.
These financial application are bucketed through SQL Server 2000 and 2005.
Making the SQL Server SOX Compliance is a Milestone in itself.
SOX compliance wants to see: your database server is secure and so is the database residing in it, so that it cannot be tampered, by unwanted or invited guests on the Database Server.
I will list some strategies for making a Database Server SOX Compliance and what i have done hands-on with the database server to make them SOX compliant.

1. Check to see unnecessary services are not running (services which are not authorized – Disable).
2. Check Local Accounts and their rights.
3. Check the server Policies.
4. Check permissions for all shared folders. (Remove Unwanted Shares – Specially for Everyone)
5. Check all Group accounts. Check the Groups and associated members and Types.(Remove unwanted)
6. Check user account properties (Account Type/Association with Group/Pass values etc).
7. OS Patch information.

Now let us start with the SQL Server related Auditing:

1. 1. Check syslogins Tables for unwanted logins (Get Rid of the logins which are not required as this possesses potential risks with users who can gain access through un-authorized manners).
2. Regularly change SA password. (30 days or near about)
3. Strong Passwords (min 8 characters Long with a combination of Characters and Numbers with symbols)
4. Logins and passwords should not be the same.
5. Incase of SQL Server 2008 – Use the Built-in Auditing Features. Check Logs at regular intervals.
6. Check you have regular backups and those backups are secured offsite.
7. Drop all sample Databases from your prod environment.
8. Check the Transaction Logs are included in Critical Databases as a backup plan.
9. Try to map all logins to description and use and you will come to know the unwanted logins.
10. Check permissions to Extended Stored Procedures.
11. Check sysusers tables for unwanted users in the database.
12. Check for Orphaned Users in the Databases.(Delete the users not required or correct the mappings) I have a script which can help you do this here:
13. Logins created since last Audit Or current Year.
14. SQL Server Version and Service Pack Information.
15. Check Authentication Modes (Windows or SQL or Mixed) – Auditors will ask Questions if Mixed mode.
16. Check Guest User Access to all databases (Guest user should be disabled in all Databases).
17. Check xp_cmdshell Status and Explain its usage.
18. Check Linked Servers and their usage.
19. Track Unwanted Server Activity: Monitor Error Logs and have them signed off by your Security Manager on a  weekly basis.
20. Explain Allow Remote connection to this Server usage.

There is a UTILITY Called DUMPSEC which can be downloaded here: http://www.systemtools.com/download/dumpacl.zip
All the information Gathering at the OS Level can be Done using DUMPSEC Utility, which was originally DUMPACL

Also Microsoft Baseline Security Analyzer is a great place to Start, which will give you more information about windows as well as SQL Server level security conditions and suggestions.

The SQL Server Related information can be done using Custom Scripts, which i will list down for everyone to use.
1. Check syslogins Tables for unwanted logins
select * from sys.syslogins where sysadmin=1 (All logins who are SA on SQL Server. Get Ready to Explain Who Who and Why they need access.)

2. Check Permissions to Extended SP’s

Select sysobjects.name,sysobjects.id,user_name(syspermissions.grantee) as [Granted to]
from master..sysobjects
Join
master..syspermissions
on sysobjects.id=syspermissions.id
Where sysobjects.type=’X’
order by name

These were some of the scenarios, which deals with core Financial Database Auditing,as well as which should be used to secure your production Database Servers.

The below information has been tapped from here: http://www.planetmagpie.com/itconsulting/complianceconsulting/sarbanesoxleycompliance.aspx Or you can read below.

I Recommend every DBA should download/read this info: http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley.pdf or http://www.mssqltips.com/tip.asp?tip=1300

The Sarbanes-Oxley Act features numerous sections;

However, three of them—302, 404 and 409—offer the greatest potential impact on companies and how the companies conduct business.

Section 404 requires an Internal Control Report to be included in all annual financial reports. Created by a company’s auditor, the document must present management’s assertions about the design and operational effectiveness of internal controls at year end. Management must also evaluate the effectiveness of internal controls over financial reporting and disclosure controls on a quarterly basis.

With Section 302, the CEO and CFO of a company are responsible for the accuracy, documentation and submission of financial reports and internal control structure to the SEC. Certifications signed by those two principal officers must be included in the annual or quarterly reports.

Information must be accumulated and summarized for timely assessment and disclosure in accordance to the SEC’s rules and regulations. When Section 404 compliance is required in about a year, companies must be able to disclose on a near real-time basis—up to 48 hours—any changes in their financial condition or operations.

Section 404 and IT.

In general, Section 404 is the tallest mountain to climb, with key areas regarding IT controls:

Change Management

Companies must provide visibility over changes in the IT environment and enable the ability to initiate, authorize, manage and implement all IT changes through a systematic change process.

Backup

A process must be deployed to identify critical data and to duplicate, store and recover data as needed.

Security

A process must be deployed to ensure the integrity of information and secure applications, databases, operating systems, internal network access and perimeter network.

Documentation

Companies must deliver thorough documentation to cover change management, back up and security policies and processes.

Remediation

Companies must have solutions to fill gaps in change management, backup and security.

SOX for DBA – Part 2