DBA Automation and Regulatory Compliance
I decided to blog about this topic after reading a recent article in Compliance Pipeline. In it, the authors reveal this little tidbit:
The rest of the article is interesting and you should take a moment to click on the link and read it. It talks about the difficulty of implementing standard operating procedures and keeping DBMS software up-to-date.
Now these are issues that are near and dear to my heart. I’ve been a proponent of rigorous DBA standards and automating DBA tasks for years (see Intelligent Automation, How Secure are Your Databases?, Keep Your Databases up to P.A.R., and Intelligent Database Management. And I touched on the topic of governance in this blog before when I rooted for jail time for business executives.
The predominant government regulation driving most of these concerns is the U.S. Public Accounting Reform and Investor Protection Act of 2002, or as it is better known the Sarbanes-Oxley Act (or SOX). The goal of this act is to regulate corporations in order to reduce fraud and conflicts of interest, to improve disclosure and financial reporting, and to strengthen confidence in public accounting.
The Sarbanes-Oxley Act is the most significant government legislation affecting accounting and auditing in more than 70 years. Section 404 of the Sarbanes-Oxley Act specifies that a CFO must do more than simply vow that the company's finances are accurate; they have to guarantee the processes used to add up the numbers. Those processes are typically computer programs that access data in a database. And DBAs create and manage that data as well as many of those processes.
So this is a DBA issue! And SOX will bring visibility and additional rigor into DBA practices and procedures. One of the provisions of the Act states that financial data whether live or at rest must be hardened against unauthorized access, invalid transactions, or any other type of modification which invalidates the integrity of the financial reports. How stringent are the security controls on your databases? Do you have automated controls in place to scan databases for compliance and vulnerability exposures? Are practices in place to audit access to your data to report on any unusual activity?
And how robust is your backup and recovery? You may have been operating for years with a backup plan that has never been tested. SOX demands that your company’s financial data must completely recoverable in the event of a logical or physical failure without loss of data that would invalidate the integrity of the financial reports. Do you have an enterprise backup and recovery policy to which you manage? Has backup and recovery been fully automated and tested? Can you demonstrate your ability to recover both locally, and remotely in case of a disaster?
And how do you manage and track database change? SOX contains provisions for that, as well, stating that changes made to the data structures must be done using an authorized process. All impacts and deltas are tracked and reported to ensure that there are no unauthorized changes that could invalidate the financial reporting systems. Do you have a workflow and task approval process in place? And do you track all changes to data structures and catch those that are made outside of the authorized change approval process? What about keeping track of the delta of changes between releases to provide complete summary of data structure changes for compliance reporting?
DBAs have had to deal with security and authorization, auditing change, backup and recovery, and change management as long as databases have been used. But in many cases these tasks were attacked in a low-cost, ad hoc manner. Maybe there was not sufficient capital to expend on DBA processes; maybe the DBAs were capable enough to keep the databases up and running without the aid of tools. This is no longer acceptable. SOX dictates that you must be able to restore or restart the processing in a manner such that it sustains operations and does not lose the integrity and completeness of financial transactions or data.
Today’s modern DBMSs are being extended to provide additional capabilities for securing data, ensuring integrity, and making changes accurately with limited outages. For example, DB2 for Linux, Unix and Windows provides improved monitoring capabilities that make it easier to capture and store every SQL statement for posterity. Such new features are helpful, but probably insufficient to assure compliance with all of the strict regulatory requirements imposed by SOX (and other regulations). In most cases, to completely assure database operations are accurate, sustainable, and on-going, robust third party tools are required. For example, who among us feels comfortable scanning database log records to produce database audit reports? Without a tool that understands log records and formats the data legibly, most DBAs will be unable to glean anything usable from the information-rich logs that are already being produced by the DBMS. Or maybe there is a better approach, such as scanning the network and capturing all access and change requests into a database?
Another “good” thing about these regulations is the required re-birth of data administration. Oh, I know, a lot of you DAs out there are thinking it never died - and perhaps you are correct. But there was a phase there (mid-90s onward) when data administration was not viewed to be as valuable as it once was. At least it seemed that way given the lack of budget and high-level exposure the role was given at many companies. But now with all of the government regulations and on-going compliance projects, it seems that the value of data and metadata is being reconsidered. Acutally, the new positions created by these regulations may not be called data administrators, but they are doing similar jobs (mapping and defining data, ensuring data quality and integrity, data stewardship, etc.) And this is a good thing.
The bottom line of all this is this: now your CEO has to vouch for the accuracy of your company’s data. As such, it is much more likely that you can procure a budget for DBA and data management tools. Now that someone has to stick his or her neck out to vouch for the company’s data, tools that can help to assure data accuracy will suddenly be more important than they were just a little while ago.
So executives now have to take actions that show that data is important, instead of just mouthing platitudes like "data is a corporate asset." And anything that causes actions to be taken that validate the importance of data is good thing in my book!
Additional Resources
Sarbanes-Oxley and the New Internal Auditing Rules
Implementing Database Security and Auditing
