Detecting mischievous activity
Comment Computing magazine recently ran a major feature on security. In particular, it focused on internal as opposed to external threats, reflecting the fact that, according to the (former) National Hi-Tech Crime Unit, some 38 per cent of financial fraud in the UK is a result of internal security breaches.
The article(s) then went on to look at the prevention of unauthorised access to data. However, any casual reading of fraud reports in the news media will quickly reveal that a significant proportion of fraud (not to mention sabotage by disgruntled employees) is committed by authorised rather than unauthorised personnel. And if someone is authorised to read, write or update data, then how do you prevent, or at least detect (at the earliest possible stage) any unauthorised activity?
The simple answer to this is that you have an audit trail and log files associated with your database that you can query as and when required. However, log files are really only useful for finding information when you already know what you are looking for: in other words after the event (that is, too late). More proactive facilities that monitor database activity, as provided by a number of database vendors, are much more useful, but the overhead incurred by these tools is such that they are almost invariably turned off for performance reasons.
In fact, the only practical way to monitor database activity in anything like real-time is to monitor database requests across the network. That is, before the data is committed to the database. This has the advantage that you also pick up illicit attempts to access the database as well as those that are legitimate. Further, you can implement filters against the monitored traffic to issue real-time alerts when suspicious activity is reported. In addition, as you are logging all the requests that are sent to the database, you can also use the same software for compliance reasons, to analyse data usage (for example, to support archival policies) and so on.
To give examples of the type of monitoring you might want to do, you might want to raise an alert if someone who normally accesses data between 9am and 5pm suddenly access the database at 2am. He might simply be a diligent employee, but you'd like to know. You might also like to know if a person who has access to user names and to passwords wants to look at them both at the same time. No doubt you can think of lots of other things that might be indicative of something naughty, but I'll leave that for you to work out.
Quite what this class of security/auditing solution should be called is debatable - database security has implications to do with encryption and access control - but regardless of what it is called, there are a few vendors offering relevant solutions though, surprisingly, the big boys such as Symantec do not have offerings in this area (as far as I know) and the event processing vendors such as Streambase, Progress and Aleri are not targeting this area either.
Of the suppliers that I have identified in this area, the leading one is Embarcadero, which acquired Ambeo last year. Unlike the other players it is well-established, has a global presence and a significant, existing customer base. Embarcadero's product, which is called DSAuditor, provides both auditing and monitoring (not all tools do) and it is currently a major focus for the company as it drives its business forward.
Copyright © 2006, IT-Analysis.com