Media Coverages
Database Automation: Your Only Protection from Data Theft
By Robert Gardos February 2006
So you think your company and customer data are secure? If you are like most IT managers, you are doing what you can to stay on top of the latest compliance, monitoring and encryption trends. You've heard the horror stories. You've dealt with SarBox and HIPAA auditors. And you've certainly spent enough money on security-related solutions during the past three years. So now you're pretty confident. You've looked into it, and you've taken care of it. Right?
Chances are three out of four that you're wrong. In all fairness, that statistic is not based on a rigorous statistical analysis, but on my experience working with a wide spectrum of companies and organizations. From the most innovative to the most change averse, from Fortune 1000 giants to the most under-resourced not-for-profits, companies are likely experiencing the same problem when it comes to data security. They forgot to secure the database.
Why is this problem so pervasive? It's the nature of the database beast. Databases remain the last frontier of manual fiddling, requiring DBAs to engage in highly specialized processes to perform many key management tasks. Chances are the DBAs in your organization have full and unobstructed power over the databases they work on-unaccountable and detectable to no one. A "rogue DBA" can do much damage.
One particularly high-profile case highlighting the extensive damage a DBA can do was the widely covered Pick Six scandal, in which an administrator was able to bilk the New York Horse Racing Association out of $3 million in rigged horse-racing bets before regulators even noticed. Winning the Pick Six requires bettors to accurately pick the winners of six consecutive horse races. The administrator took advantage of his proprietary access to the database, as well as the time-delay in reporting horse-racing winners, to falsify tickets purchased by an accomplice to reflect the winning combinations.
The scariest aspect of this story is just how sloppy the DBA had to behave to have his actions detected. While most Pick Six bettors buying multiple tickets will choose different combinations of horses to maximize their chances of winning, the DBA in question altered all six winning tickets purchased by a single accomplice to list the same six horses. Obviously, this error was not detected through any routine monitoring of changes to the database. If he had simply falsified one ticket instead of six, it is likely he could still be rigging bets today.
Rogue activity aside, even the most well-intentioned and capable database teams are facing the mounting challenge of increased complexity. Most organizations are currently running more than one type of database, with the average Fortune 1000 organization running at least four relational database management systems (RDBMS) products at the same time, according to Gartner. Oracle DBAs work with the Oracle databases-period. Sybase administrators work on Sybase. DB2 database administrators only know DB2. And so on. There's no way to see across a heterogeneous database landscape.
As a result, implementing standard operating procedures across the entire organization is extremely challenging, and keeping databases up-to-date with new patches is practically impossible. One of the largest financial institutions in the world was having trouble addressing the gross inefficiencies in managing its Oracle database infrastructure. While it had more than 500 DBAs managing its 30,000 Oracle databases, it found that more than 80% of its DBAs' time, on average, was spent fixing and managing problems.
Many of these problems centered on inconsistent patching. With Oracle recommending an average of two patches per month per database, even their large team experienced challenges keeping up with the 720,000 patches that needed to be installed yearly-many of which required downtime. Because of the complexity and time associated with this task, many patches simply didn't get installed. This not only contributed to an increase in database "firefighting," but potentially compromised the security and stability of their entire system. With database instances growing at a rate of 50% per year, these problems are set to get significantly worse during the next 36 months, further stretching the already limited DBA resources within IT departments and further compromising security.
Plugging the Hole-Database Automation
But what options do we have to get a handle on this growing data beast? The one currently most favored is to throw more bodies at the problem, lowering the DBA/database ratio to realistically ensure proper maintenance. Theoretically, this can help ensure security and compliance. If everyone serves as a watchdog and monitors everyone else, legitimate and illegitimate mistakes can be identified and averted. Unfortunately, this is an increasingly expensive approach that is still error-prone.
What the enterprise needs is a centralized, automated mechanism to track DBA behavior that is both manageable and irrefutable. When DBA and database monitoring is systematized and automated, data integrity can be reliably ensured, even as the IT architecture grows in size and complexity. The good news is that databases are already capable of providing users with just the sort of information they need to ensure compliance and monitoring, so addressing this problem is simpler than most CIOs-or even DBAs-may realize.
One case-in-point involves a bio-pharmaceutical company that relied heavily on advanced electronic recordkeeping for scientists engaging in state-of-the-art modern drug discovery methods. In their dynamic environment, capturing, organizing, communicating and securing information was critical to their success. As part of the company's annual compliance audit, external auditors requested a comprehensive record of all database configuration, information and schema changes during the past year. In response, the company had the DBA write a report that put together all the relevant scripts and submitted this document to the auditors.
The auditors then asked a critical question: "Did the DBA who supplied the report have the power to edit, delete and otherwise alter the information he was tasked with auditing?" The company had to admit that the answer was 'yes.' In spite of their extensive efforts to meet compliance standards, its auditors found the company to be lacking-and rightly so.
All this company needed was externally verifiable protection for the audit trail. Database events can be logged and tracked by using existing information already available within the existing RDBMS system. From there, database automation software can automatically apply global practices and define key policies.
Too Much Information
Proper management of this data is paramount, since simply gathering information is really just the tip of the iceberg. The real work lies in processing it and making it into a powerful tool that can be effectively monitored and audited. In many cases, too much unstructured information is worse than no information at all.
With the institution of HIPAA and other data protection requirements, hospitals are under more pressure than ever, not only to protect their patient data, but to institute demonstrable controls over the dissemination of sensitive patient information. In response to HIPAA, one large California-based hospital instituted procedures for gathering information on any alterations to its systems, which included records of any and all modifications to its IT infrastructure.
Over the course of just a few months, the hospital accumulated terabytes of data, the weight and complexity of which was so hard to manage and analyze that the entire auditing exercise was rendered futile. The fact that databases often are configured to store their auditing records on the database itself, leaving the audit trail stranded within each host, further exacerbated the audit aggregation problem.
How did they handle the situation? They didn't, according to their IT executives. They just had far too much information, and they didn't know where to begin in terms of how to order and analyze it into anything useful.
Using an overarching database automation solution, this hospital could have taken this useless data and used it not only for compliance, but to enhance the efficiency of its operations. There is great value in cross-referencing configuration, patching, monitoring and auditing. If a database appears buggy or sluggish, information about who did what to it-and when-can be called up in a matter of seconds.
And because it's automated, that information cannot be erased or compromised. Manual policies can be simply tracked by associating a user and a set of objects, then specifying what actions should be logged. The result: The DBA continues to have the power to do his or her job, but you now have a mechanism in place to enforce best practices for the company, as well as watch the watcher.
Ultimately, it comes down to the fact that organizations must have one reliable and automated source of irrefutable truth at the database level to ensure compliance, security and efficiency. Without it, true compliance is close to impossible, effective auditing is elusive, and security will be forever compromised. So the question is: How important is your data?
Robert Gardos is CEO of GridApp Systems, 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. www.gridapp.com