Entries tagged with “monitoring”.

Fern Halper, an analyst with Hurwitz & Associates wrote in her blog “Data makes the world go ’round” about database activity monitoring (as well as highlighting some of what my company Sentrigo does).

In the summary of her post she raises an important issue – that most DBAs are reactive rather than proactive when it comes to monitoring their databases. I’ll take this even further… it’s not just DBAs (and I’m not going to get into the whole issue of who owns database activity monitoring…) but companies in general are too reactive when it comes to database security.

Yes, I know that security doesn’t generate revenues, it doesn’t even reduce costs – at least not in any consistent, measurable way. Security is all about reducing risk and the cost associated with that risk. The problem is that by being reactive, companies are addressing yesterday’s risks, not today’s or tomorrow’s risks. There are a several biases in how the IT security budget is allocated, and one of the biggest biases is the visibility bias: The tendency to invest in protecting against visible threats, even if they are small. Spam is a good example. It doesn’t do much harm, but it’s visible every day in everyone’s inbox (I’m not talking about malware, just the “classic” commercial spam which is 99.9% of spam). Companies are investing more today in reducing the marginal spam to the n-th degree, with diminishing returns, than they are in database security. Far more.

Risk, on the other hand, is not just a question of visibility or sheer quantity. It’s also a question of the potential damage of even a single attack, and the probability of such an attack succeeding. The risk posed by inadequate database security is currently greater than the risk posed by spam, given the counter-measures already in place for the latter. Yet many enterprises, by force of habit and inertia, continue to invest in protecting against threats for which they already have good enough solutions, whereas other areas remain barren. Some companies do, of course, shift their attention to new threats every once in a while, but I wonder how many enterprises do an annual (or more frequent) risk assessment that includes a “green field” threat analysis and gap analysis?

Back after a short and much needed hiatus, I came across this piece by security analyst Eric Ogren on Computerworld’s website. He discusses how DBAs have become public enemy number one because of compliance mandates to exercise segregation of duties, and how this has been blown out of proportion to other, greater risks.

A few days pass, and the story about the Fidelity database breach comes to light (incidentally I chose this article from Computerworld as well). A senior DBA sold 2.3 million records, including bank account and credit card details, to a data broker.

So are DBAs “dangerous” or not?

Unfortunately, there is no denying the risk element. If risk is the arithmetical product of the probability of an incident happening and the potential damage that incident could cause, then due to the latter factor DBAs as well as other highly skilled insiders with access privileges pose a significant risk.

This does not mean, however, that there is a high probability of DBAs becoming malicious insiders. Obviously, the vast majority of DBAs pose no threat to their employers or clients, but the old adage of one rotten apple applies nonetheless. While there is a much higher probability that someone who is not a DBA would try and breach the database, the DBA is in a much better position to succeed should he or she really want to do that.

An external hacker would find it very difficult to achieve this kind of scale (millions of records) without insider cooperation. It is difficult to determine what direct damages this will bring to Fidelity and its customers, but the bad publicity is already quite significant: Running a news search on Google for fidelity data breach yielded 529 results at the time of writing.

Clearly, there is a problem here which cannot be ignored, but on the other hand, Eric’s conclusion was absolutely correct – DBAs are a part of the solution, and I would even stress that they are an essential part of the solution. The fact is, DBAs know more about database security than anyone else. They know more about database vulnerabilities, exploits and hacks, and more about how to address them than anyone else. Trying to implement a database security solution by circumventing or ignoring DBAs would be futile.

It is important, for security as much as for regulatory compliance reasons, to monitor and audit DBA activity. In fact, this should be done for all users who access the database. DBAs are first to understand this. If you work in a bank vault, you know there are CCTV cameras on you. You want those cameras on you. DBAs are in a similar situation and they understand this requirement completely.

What DBAs should not accept are two kinds of solutions that one sometimes comes across (sometimes it isn’t the tool but the implementation process):

  • Solutions that hinder or interfere with the DBA’s daily tasks – DBAs are primarily concerned with running databases efficiently. Any solution that jeopardizes this primary objective is counter-productive, and doomed to fail anyway because DBAs and other staff will find ways to circumvent it.
  • Solutions that ignore DBA input – As I suggested, DBAs are not as opposed to the notion of monitoring their own activities as some people think, so there is no real reason not to involve them. More importantly, I believe it is simply impossible to implement a solid database security solution without DBA cooperation. Any solution that ignores the specific data structures, user profiles, schemas and views simply cannot be doing a good job. Those are all managed by DBAs.

Finally, there is the question of priorities. Obviously my company sells database security monitoring products, so my view is not objective, but I’ll say this: Databases are still the most neglected parts of the enterprise IT infrastructure security-wise, especially when taking the magnitude of the threat into account. The Fidelity incident is just the latest in a long string of examples demonstrating this.