Musings on Database Security

This is a personal as well as a commercial posting for me… Tomorrow is a special day in the short history of my company – after long months of R&D, we are finally releasing our product, named Hedgehog (there’s already some coverage in Dark Reading). These are very exciting times both for me personally and for the entire team at Sentrigo, who’ve made this possible through a lot of hard work and well applied knowledge – I feel very lucky to have such a great team working with me.

Hedgehog is database security monitoring software that monitors DB transactions in real-time, and generates alerts based on a highly flexible set of policy rules. A light-weight sensor is installed on the database machine and monitors the shared memory. It doesn’t use redo logs or DBMS APIs – those would be too slow… The trick is to do it so that it doesn’t use up CPU power.

Hedgehog can be downloaded from Sentrigo’s website, and while it supports only Oracle for the moment, in the coming months we will release versions for MS SQL, DB2 and other major DBMSs. There are basically two version – Hedgehog Standard, which is totally free to use, and Hedgehog Enterprise, which is not free but available for free evaluation. The differences are explained in some detail on the website, but basically it boils down to prevention capabilities and enterprise scalability and integration.

My sense is that we’re bringing something new to this space, and I’m anxious to see how this will be received. Feedback is of course welcome. Give it a try!

As promised, this is the second of a three part blog entry discussing the propagation of middle-tier users to the database. This post will mainly concentrate on the Java side of things. I will show how to use Spring-framework’s excellent transactional support using AOP to add an additional advice, relying on ThreadLocal to pass application user identities from the web tier all the way to the database, and using annotations on the service layer to specify the module and action.

I strongly advise downloading the linked zipped source code at the end of the post if you’re planning on seriously reviewing the code.

(more…)

About a month ago I posted about breaches at educational institutions, and suggested that rectifying the problem could start by simply not hoarding PII (personally identifiable information) unnecessarily.

Today I read about this breach at Northwestern University (not the first data breach for them) where social security numbers of 4,000 individuals may have been compromised, including all those who attended a certain program from 1991 to 2007.

Why oh why would the university need to keep SSNs of people who went there in 1991?! Surely there are some other ways of identifying those individuals. Why take such unnecessary risk?

Like a Greek tragedy unfolding, you know that the SSN appearing in the first scene will be breached in the end. Tragic, but in this case entirely avoidable.