|
|
| Home - Industry Article - Dec 07 Issue |
The Compliance Equilibrium |
By Robert Gardos, President and Founder, GridApp Systems
As compliance standards continue to rise, IT departments are challenged to improve procedures and better prepare for their formal audit. Organizations must equip their database professionals with the resources to understand and implement their new regulatory responsibilities. This article will outline five steps the management can take to better understand the importance of the database tier in meeting compliance requirements and will also provide best practices for equipping these professionals with the tools they need to manage their compliance duties.
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 then implementing them.
The challenge here, of course, is that very few DBAs would describe themselves as security experts. A Forrester study identified that 72% of DBAs interviewed said they felt as though they didn’t know how to implement database security and, from my personal experience in talking with DBAs, almost 100% 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.
Sounds 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.
So what can organizations do to improve compliance?
5 Steps to Managing Compliance in the Database Tier
From a database perspective, there are 5 steps that management can take to better understand the importance of the database tier in meeting compliance requirements.
#1 Why Do I Need to Audit?
Managers should first ask why there is a need to audit and take time to understand the landscape. This includes identifying the infrastructure – how many databases does the
organization have, what types (Oracle, SQL Server, etc.), what are the
differences between the internal tools and what needs to be done to
standardize?
Organizations should also understand what kind of information they need for the audit. What regulations do you need to comply with? What is the purpose of those regulations?
#2 Set Policies
Setting policies is more about groups and concepts than specific rules. Some questions to ask are: “How critical is X group of databases?” and “How critical is Y subset of data in those databases?” Organizations should also create tiers of both database and data criticality, keeping in mind to not over-engineer or mistake policies for permissions.
#3 Create Rules
Rules can be created where permissions must impose control without impacting flexibility. It’s important for auditing to not significantly impact performance for critical systems. Some standard techniques for capturing user activity and changes are – triggers, fine-grained auditing, and network sniffing and analysis. The types of changes to track are: User logins/logouts (failed attempts), schema changes (identify code changes), user access to sensitive data, and changes to user permissions.
#4 Centralize and Secure
All audit events should be centralized in near real-time and copied to multiple places. Organizations can institute measures to control user access to audit records and track proper configuration of auditing rules. Encrypting the contents of auditing records helps with security; this could include storing keys securely on external HSM devices.
#5 Monitor and Maintain
IT teams must ensure that policies are applied to new database environments. This retains the flexibility to increase or decrease the level of auditing for each additional user and institutes changes globally. Scheduling and ad hoc reporting also help monitoring and maintenance. Some examples include generating a regular list of all identified auditing events by user, database, data range, etc., developing alerts for particular events like schema changes and generating weekly/monthly status reports.
Taking these steps will set a framework for organizations to follow when faced with the need to meet new compliance standards. Having a basic foundation creates an environment that is not as complex and can be easily updated.
Compliance Best Practices
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 President and Founder of GridApp Systems, a software company that offers database automation software and appliance technologies. Over the past twelve years, he has held numerous senior management positions in technology-driven organizations. Robert has a wealth of experience developing efficient and cost-effective technology solutions to meet the demands of customers. He was formerly the Chief Technology Officer and General Manager of Register.com (RCOM), an Internet organization specializing in domain name registration. Robert joined RCOM as the ninth employee in June 1998 and helped grow the company to a publicly traded and profitable entity, increasing annual revenues from $1 million to $125 million. At RCOM, he pioneered a new standard in the domain industry, shifting name management to the customer through an easy to use Web-based application. This served to improve consumer satisfaction and reduce maintenance costs, an approach that was subsequently adopted by the entire industry. Robert was Co-Founder and CFO of TouchLink Communications (TLC), a startup company specializing in public Internet kiosks. Prior to that, he worked as a Senior Consultant at Ernst & Young, focusing on system selection and implementation projects. For article feedback, contact Robert at rgardos@gridapp.com
 
|
|
|
