The enemy within?

FST spoke with Scott Hayes, the President and CEO of Database Brothers Inc (DBI), who explained why database activity monitoring is so important, both to keep regulators happy, and to ensure rotten apples within the firm don’t compromise security.

FST. Why is database auditing so important in the financial services space?
SH. Organizations need to verify that financial information hasn’t been tampered with by the highly privileged database administrators (DBAs) who hold the keys to the database kingdom. In regulatory terms, there is a need to verify for SOX that the financials are accurate, and the only way to do this is to show an audit trail. Why do we have this regulatory compliance burden? When companies rushed to embrace client server computing in the nineties we created open systems, we put up databases and built data warehouses and data marts. Throughout the rush to put everything up there has been very little attention paid to security, and activity monitoring, to watch how people are using this data. And we’re paying the price for it. Look at what happened at Enron, and the tampering with financial information there – the bottom line is we haven’t been good stewards of data security. So the regulatory compliance burdens that we have, we own, we’re accountable for our failures to be good stewards of data. As you look at all these data breaches occurring weekly, it’s really time to clean up our data security act.

FST. And how does database activity monitoring improve database security?
SH. Anywhere that you go where there is a very valuable asset there is a surveilance camera. If you go to the bank or the jewellers shop you’ll find surveillance cameras; these act as deterrents, and they also help apprehend those who commit crimes.

When we look at database activity monitoring, basically what you’re doing is putting a surveillance camera on the database, so you can know who is using or abusing their data privileges. If we have surveillance cameras on our corporate databases, we can play those tapes back and understand how data is being used, and if it is being used inappropriately we can track down the individuals who are abusing their privileges.

FST. And presumably this helps protect the reputation of the institution as well?
SH. Reputation management is all about staying out of the media. There is almost weekly news of some data breach or another, and I think if we can improve the security of our databases through tighter security controls, granting of appropriate privileges, and following the principle of least privilege – people have the minimum privileges necessary to get their jobs done – and if we communicate that we’re doing day-to-day activity monitoring, that’s going to take substantial steps for improving reputation management.

You need to know if somebody in the organization is pulling out 100,000 identities from your employee database, or if someone is accessing credit carder holder data – there was the incident at the American Red Cross, where the privileged DBA helped himself to a million blood donor’s identities. You really need to know about that as soon possible, so that you can proactively address it within your organization, and have a good response ready if it hits the media.

FST. Apart from the damage to reputation, what are the hard costs associated with a data breach?
SH. The Ponemon Institute did a study into some 22 data breaches and found that the average cost of a data breach was $4.8 million – and that’s an average. The same study found that the cost of the preventative measures was around 4 percent of the breach cost. So you could spend between $180,000 to $250,000 and have some good preventative measures in place, in contrast to $4.8 million. This is the reason that folks like you and I buy health insurance or life insurance – we pay a small upfront cost as a preventative measure to avoid a large cost later.

FST. Apart from avoiding a breach cost, how can database monitoring improve profitability on the day-to-day level?
SH. You can improve profitability by automating auditing, and automating some of your internal controls. Right now it’s a very laborious process with internal and external auditors going through reports by hand. If you take preventative measures that automate some of the required reporting you can achieve cost savings there, and have your auditors leave happy, as they can be confident that there hasn’t been any data-tampering or inappropriate use of data.

FST. So, what are methods for monitoring databases?
SH. The first method is network sniffing – the company puts an appliance on the network, and watches network traffic. The shortcoming of this is that you can only report on activity that is traversing the network unencrypted. So DBAs who are working directly – logged onto the database servers – their activity might not be captured. The other drawback is that encrypted data on the network won’t be picked up by the sniffers. It’s not an ideal method.

Another approach is database recovery log readers. This has a fairly low overhead on the database, as it’s looking at change activity after it has occurred. The trouble is these logs are intended for the database to do recovery in the event that there’s a crash or something. So if we have the requirement as we have for PCI or HIPAA, or if we want to put security measures in place, we need to have reports of access or reading data, and that information isn’t available in the database recovery logs.

A third method is to use triggers to accomplish auditing. When a table is modified it triggers a copy of the information in another table. Two problems with this: the information in that table isn’t protected, so someone with privileges could cover their tracks; and triggers only fire with change activity. So again we have the problem that there is no audit trail of access to information.

Another approach is to use the audit trails provided by third party applications. These will show you how users of an application are using the application, so there is some monitoring going on. But the big hole is that because it’s auditing the application it’s not auditing the database, so we don’t have database activity information for privileged users, and really that DBA activity – the privileged insider – that’s our greatest risk.

So, this takes us to our fifth potential method, which we recommend, which is engaging the native database auditing utility. If we use the audit capabilities that are supplied with Oracle, or IBM DB2 for example, because this audit trail is right at the database it will capture not only the activity from the application, but also the decision analyst users, and all the DBA activity. That’s really where we need to have our surveillance camera – at the database level.

Database auditing isn’t really the business of the database vendors – they’re all about performance and transactions per second. So this leaves the door open for opportunities for improvement. You need to automate space management so that you’re not wasting space on your servers or database tables with unnecessary audit data. You also need to take that data and apply some tamper evident seals, or digital signatures, so that you can have confidence that the audit trail is accurate. So that’s our opportunity to add value above and beyond just the native database auditing abilities.

If you’re smart about how you configure auditing the overhead should be nominal, somewhere in the three to eight percent range. In terms of our customers, none have reported a performance issue to us. So it’s important to selectively and appropriately configure the auditing so that you’re getting the right information that you need to improve you security and meet your auditing requirements without getting too crazy about it.

Scott Hayes
Scott Hayes is President and CEO of DBI. Its mission is to help organizations achieve greater accountability for privileged use, or abuse, of data assets while, at the same time, helping improve business performance, efficiency, and profitability.

Hayes is an expert on DB2 LUW performance and security who speaks regularly at DB2, ISACA, and ISSA User Group meetings, as well as IBM DB2/Data Management conferences and writes on the subject. He is an IBM DB2 GOLD Consultant (an elite, exclusive group of IBM recognized top DB2 advocates), has obtained Advanced IBM DB2 Certifications, and is widely regarded by the worldwide DB2 community as the top performance security expert for DB2 on distributed (UNIX, Linux, and Windows) platforms.

Hayes started DBI in July 2005 to serve the distributed database communities with deeply focused attention. Prior to this he was Director of Product Marketing at BMC Software for two years, after BMC bought DGI, the software company he’d founded in 1998. Hayes graduated SUNY Geneseo with a Management Science Major and Computer Science Minor.