Media Coverages
January 2007, pgs 8-9
How DBAs Can Ease the Compliance Burden
DBAs often are not security experts and don't understand the regulations.
By Rob Gardos
Over the past few years, many DBAs have been talking about a common concern - they're being asked to understand and implement more and more of their organization's regulatory requirements. The most obvious driver for this is Sarbanes-Oxley, but other regulations, such as HIPAA, SB 1386 and FDA 21 CFR Part 11, can all add a significant amount of additional responsibility on the DBA as auditors and security teams seek to implement regulations at the data level.
Why is this burden falling on the DBA? A great deal of it has to do with the unique complexities, challenges and requirements of the database space. Security engineers may understand network and server security, but it's unlikely they'll understand the specifics of GRANT privileges in a database or how database auditing can or can't catch certain types of information. DBAs are responsible for understanding the standards and requirements and implementing them.
The challenge here, of course, is that very few DBAs would describe themselves as security experts. A Forrester study identified that 72 percent of DBAs interviewed said they felt as though they didn't know how to implement database security and, from my own personal experience talking with DBAs, almost 100 percent feel as though they don't fully understand these regulations and their implications for the database.
Different Regulations
Different regulations require different things for the database tier. Some regulations, such as HIPAA and SB 1386, are very clear about what is required for compliance. In the case of HIPAA, there is a set of guidelines about who has access to patient medical data, and how to manage that access - typically it requires such actions as limiting access to critical personnel, not allowing developers to have access to patient data, etc.
SB 1386 is a California regulation that says that any organization that has a breach of 'sensitive' customer or patient data must publicly disclose that breach. 'Sensitive data' is defined as credit card numbers, social security numbers, home addresses, etc. - basically all of the standard customer information organizations store in relational databases. Even though SB 1386 is a California regulation, it applies to any company doing business in California, even if the company is based elsewhere. In addition, many other states are looking at implementing similar laws, and even the U.S. government is currently discussing a similar law.
Sarbanes-Oxley, on the other hand, is extremely general about what is required for compliance. While Sarbanes-Oxley has a number of different components, the key part that applies to DBAs is Section 404, which introduces the concept of 'controls.' A control in IT would be any process that interacts with a system that could have an effect on the company's financial reporting. Examples of these controls could be changing the schema of the general ledger database, rolling out a patch to the servers that run the Oracle 11i environment, or even backup and restore testing for the inventory and supply-chain systems.
For each one of these controls, there must be documentation, and someone must walk an auditor through the process. The auditor is looking out for 'material weakness,' which is loosely defined as, ' how easily could this process fail or be manipulated?' If the auditor feels there are weaknesses in any of the controls, they can only inform you of the weakness - they cannot assist in fixing the weakness, as that would be deemed a conflict of interest.
Sound complicated? Many large companies going through Sarbanes-Oxley compliance discovered they had upwards of 10,000 controls, each taking one or more hours to complete, and with over a third of those controls having material weaknesses. Considering that organizations must recertify with Sarbanes-Oxley every year, responsible database compliance seems at best an expensive and resource-draining exercise and, at worst, an impossibility.
Areas of Responsibility
That said, from a database perspective, there are three general areas DBAs and DBA managers can focus on to help with regulatory compliance. They are: controlling access to data, documenting and automating processes for managing data, and tracking user activity associated with data.
Controlling access to data means that you need to have policies, procedures and technology around those users who have privileged access to databases. This extends beyond production systems to development as well - for example, if you're duplicating the production database to development along with the data, are you obfuscating the social security numbers of the patients from production?
Process documentation is something that should be part of the day-to-day management of your databases. Once a process is documented, you can automate that process to guarantee compliance, ensuring that if a DBA runs a script to execute a given process, it is guaranteed to be compliant.
User activity tracking is the thorniest piece of this puzzle, due to the complexity. There are a number of different ways to track database user activity, from mining transaction logs, to packet sniffing, to database-level auditing. All of them have their particular strengths and weaknesses, but the key goal is to be able to provide a 360-degree view of everything that is happening in the database. This is critical, as it can shore up problems elsewhere. For example, if all user activity is being logged, developers who make unauthorized changes in production can be identified easily, reducing the possibility for a material weakness in that area. A key part of a good user activity tracking strategy is to make sure the central log of user activity is read-only to the DBA. This will prevent auditors from getting nervous about DBAs being able to modify the audit trail that their own activities created.
In the end, DBAs are uniquely positioned to help their organizations not only ensure compliance with regulations, but use those regulations to provide security and more effective management around their data and databases. However, in order to do that, DBAs need to wear yet another hat. This would effectively expand their already considerable responsibilities, and managers and directors need to consider this when setting expectations for their DBA teams.
Robert Gardos is CEO of GridApp Systems (www.gridapp.com), a leading provider of database automation and management solutions that help simplify and manage critical database operational tasks such as deployment, patch management, auditing and replication.