Deadbolts for databases

As if federal security managers didn’t have enough trouble sleeping, now they have to worry about the health and well-being of their databases. For years, agencies reasoned that if they kept intruders outside the firewalls by buttoning up their networks, everything inside remained safe. But a series of high-profile database breaches in the last couple of years have shown the danger of this reasoning.

Last year, up to 40 million credit card records maintained by CardSystems Solutions were exposed to hackers. Reminding federal officials that such attacks are not limited to financial services firms, the Defense Department reported in April that an intruder infiltrated one of its servers and riffled through the confidential health insurance records of more than 14,000 people.

Why the interest in hacking databases? That’s “where the gold is,” said Ted Julian, vice president of strategy and marketing for Application Security Inc. (AppSecInc), a database security tools vendor. “Why bother with other parts of the infrastructure if in the database you can get it all?”

But experts worry that the security features that come standard with database management systems (DBMS) don’t do enough to protect against today’s data thieves.

“The basic database measures are not good enough,” said Noel Yuhanna, lead database analyst at Forrester Research. “You need advanced security to protect your private data. [Database management systems] are not sophisticated or intelligent enough.”

For many organizations, the answer is third-party tools that work directly with a DBMS to provide custom vulnerability assessment, intrusion detection and prevention, data monitoring, and auditing capabilities.

Hackers aren’t the only reason federal agencies want tighter database security. Insiders with valid authorization can also succumb to the temptation to sell private information.

“Pretty consistently over the last eight years, data theft has shown itself to be an insider problem,” said Adrian Lane, chief technology officer at IPLocks, a security tool provider. “It’s insider threats that are really driving security purchases nowadays.”

Adding to concerns are security holes inadvertently opened by third-party contractors and suppliers. To facilitate closer business collaboration, agencies routinely use virtual private networks to connect employees at private companies to agency contacts. But vulnerabilities in partner networks can unintentionally provide a hidden door for cyberthieves to enter federal systems.

Regulations add to database worries
On top of security worries, managers also grapple with mountains of regulations, ranging from those mandated by the Federal Information Security Management Act (FISMA) to health care privacy laws, notably the Health Insurance Portability and Accessibility Act (HIPAA). The regulations require auditing of best practices and regular reports about database activity.

According to a 2005 survey of federal chief information security officers by systems integrator Intelligent Decisions, federal security officers spent 23 percent more time than the previous year on compliance reporting for FISMA.

Add-on security tools address both DBMS security shortcomings and compliance burdens. Although such systems can keep unauthorized people away from sensitive information, they do little to control what happens once someone gains entry. An untrustworthy insider or the recipient of a stolen password could easily copy all the personal financial files held in an accounting database without raising concerns. A third-party intrusion-detection tool comparing the activity against agency best practices could alert security officers to the anomalous act. Add-on auditing software would also record the relevant times, dates and computers used in the activity.

Other advantages of add-on tools include separation of administrative and auditing duties, a requirement spelled out in FISMA rules. Under those regulations, the system that audits the changes being made to the database can’t be managed by the same people who have privileged access to the database. The intent is to prevent a database administrator from covering up intrusions.

“If you are using the native auditing functions of a DBMS, all of the information gets stored in the database itself, and anybody with privileged access to that database can then go in and change it,” said Phil Neray, vice president of Guardium, another tool vendor.

Finally, instead of learning and managing a number of discrete tools from each of the systems within a large agency, a single third-party management console can direct and audit a mix of databases from IBM, Microsoft, MySQL, Oracle, Sybase and others.

The opportunity to obtain all of these capabilities within a single suite of products was a prime selling point for Dennis Heretick, chief information security officer for the Justice Department, when he purchased security software from AppSecInc.

“Our philosophy is one of building security into the operational process and building our validation testing into the implementation process,” he said. “Tools such as AppDetective allow you to look for vulnerabilities in the [database] application and then verify that we have corrected them. And then the feedback to oversight folks is a copy of the results so they can see our progress in reducing vulnerabilities.”

Because of the range of tool choices, managers need to understand the role of each module to match the right technologies with their organization’s needs.

Start with vulnerability assessments
Vulnerability assessment tools create a baseline portrait of the database and surrounding IT infrastructure to help monitoring software spot atypical activity and provide a point of comparison for application directories and files. The assessments also can expose existing vulnerabilities, such as overly broad access privileges, outdated user accounts and easily cracked passwords.

They provide an inventory of databases, sometimes highlighting ones set up unilaterally by individual departments without the knowledge of IT managers. Once it completes an assessment, the tool should be able to create a graphical representation of the database environment, so managers have an easy way to see all the database servers and the people who access them.

Experts say the first consideration when shopping for an assessment tool is platform support. Since large agencies typically run database management systems from a range of vendors, the tools must support not only current implementations but any that might be added in the future. Also, because each DBMS offering has particular vulnerabilities, such as the Oracle Voyager or SQL Slammer worms, prospective vendors should be able to demonstrate timely updates for identifying new vulnerabilities.

Intrusion detection spots the infiltrator
Systems that detect and prevent intrusions provide ongoing monitoring of database activities to alert managers when unauthorized accesses or unusual usage patterns arise. For example, if a service representative with valid database access privileges suddenly starts viewing many more records a day than normal, the system may send an e-mail alert to a security officer.

Most systems can also be set to take preventive action automatically, such as blocking transactions, in addition to passively sending alerts. However, Yuhanna said many managers still aren’t comfortable with the proactive approach because they fear false alarms. “The maturity level [of the tools] is still evolving,” he said. As they evolve for database protection in the next couple of years, more organizations will use automated responses, he said.

Monitoring and audit tools complete the suite
The Database Security Technical Implementation Guide (STIG), a compendium of security advice for DOD released by the Defense Information Systems Agency late last year, recommends regular database monitoring to catch unauthorized modifications to records and signs of Trojan horse software or other malicious code. In addition, monitoring tools should screen for unauthorized activities such as illegal scripts that siphon information out of the database.

Monitoring tools should provide a drill-down capability so that managers can analyze detailed activity in each database. For example, a manager could see when someone at a computer with a particular IP address is inserting a table into a database and decide whether security policies are being followed.

Such tools should also create graphical displays of security metrics and track security strategies to demonstrate improvements to FISMA and other auditors.

For regulatory compliance, auditing tools should keep records of changes to database entries. According to STIG, such tools should at a minimum trace the creation, alteration and deletion of database accounts and objects, as well as related storage issues. The guidelines also stipulate keeping a close watch on actions by database administrators, including when they start up, shut down, back up, archive and collect performance statistics about databases.

Because of the large amount of information auditing tools collect, they should offer reporting and data analysis tools that let organizations easily write queries to address specific auditing questions.

“Many vendors will say they do auditing, but all they do is store these huge log files that are essentially successive text entries, so poring through those files looking for a pattern is not anywhere near the same thing as a database query” tool, Neray said.

He adds that auditors now routinely ask database administrators and IT managers to produce new types of reports, including rundowns of all privileged-user activities.

“Government organizations especially can’t afford to hire people to generate these additional reports, so automated report generation is one of the key functions that these solutions provide,” Neray said.

Automated reporting can track everyone who accessed sensitive tables in the database or who accessed Social Security numbers. The auditing system can create the reports and distribute them electronically to the appropriate oversight officials.

Finally, Lane said, auditing tools should be able to call out the use of “select statements,” which are instructions to the database that allow people with privileged access to view the actual content within database records. Misuse of this capability can expose sensitive information to untrustworthy parties.

“Organizations don’t mind if the database administrators are altering a table or performing some sort of work order, but they shouldn’t actually be looking at the contents of the data within the table,” Lane said. “So keeping a record of all the select statements that are issued by [database administrators] is a very important activity.”