Strengths: No database downtime, unique vPatch feature, low-footprint sensors, intuitive management interface, simple rule-creation process
Weaknesses: Baselining requiries LX or MX appliance
Verdict: LogLogic's database security solution provides extensive monitoring and alerting features and its unique vPatch has uptime high on its agenda
Businesses must comply with data protection regulations, but database security is often left out of the equation for one simple reason: to monitor database activity, auditing must be enabled and many administrators will not do this due to serious concerns about performance.
This has a big impact on the majority of log data gathering and reporting solutions. LogLogic is well aware of this as its LX and MX appliances cannot report on databases if auditing is turned off, so to overcome this it has launched its Database Security Manager (DSM) appliances.
A key feature of the DSM family is that they can monitor database activity and enforce security policies without the need to enable auditing. LogLogic's DSM sensors monitor activity from shared cache memory on the database host. They have a light footprint on the host as they don't interact with the database, but are able to see every activity, including network and local traffic.
The sensors enforce database security policies and LogLogic currently has ones available for Oracle, SQL Server and Sybase ASE 12.3. None of them requires the host system to be rebooted after installation.
DSM also takes on the sticky problem of database patches and LogLogic's solution makes it quite unique. All too many databases have never been patched or are far from up-to-date, as administrators are either not prepared or not in a position to allow downtime while patches are applied.
LogLogic's optional vPatch overcomes this, as it simply applies patches virtually to each database. As the database vendors release patches, LogLogic takes them and makes them available as vPatch updates. Alerts for these are posted in the DSM's web console, where they can be applied to selected databases - all without any downtime. Yearly subscription costs for vPatch start from £2,750.
For testing, we used both Oracle 10g and SQL Server 2005 Express databases running on a Windows Server 2003 host system. We found DSM deployment to be a pleasantly swift affair, after which we could install the sensors on each database host. They can be deployed directly from the appliance or via the internet from LogLogic's website, after which they scan the host system looking for databases.
The DSM's web interface is a well-designed affair offering a smart dashboard showing views of all monitored databases plus alerts for each one and their severity. A graphical alert summary is provided and you get traffic lights showing the status of sensors and the databases.
The appliance automatically discovers all sensors and adds them to the console, after which they need to be approved. This process stops anyone installing sensors, as administrators have to authorise them from the console before they become active.
DSM uses rules that look for specific activities and enforce actions - alerts, SNMP traps, syslog, Windows Event log, running scripts and so on. User sessions can also be terminated using brute force TCP resets.
An unusual feature is the ability to quarantine users. Many database administrators are wary of permanently terminating users as there may be cost implications and in these situations the quarantine feature can prove useful. It allows DSM to block user access for a set number of minutes while the alert is investigated. The user is not aware they are being blocked.
LogLogic provides wizards to help with custom rule creation. You start by selecting criteria such as database command types, applications, user names, dates, times, database schema and so on, apply Boolean expressions and values and add single or multiple triggers. Next, you select actions and then choose the databases the rules are to be applied to. Tags can be used to group rules together, making it easier to apply multiple rulesets to a database.
Each alert entry is accompanied by four icons, allowing you to: quickly create a rule for this activity, trust the session, terminate the session immediately or resolve it. For the last, you enter text explaining what actions were taken and this will be logged for auditing purposes.
When the sensors are activated, you can enable default triggers where one blocks DDL (data definition language) actions before they can occur and another provides alerts of excessive failed logins that may be the result of a DoS attack.
SQL injection attacks are handled using a number of methods. Default vPatch rules use triggers to alert in the event of an unusual number of errors or login failures, which may be the result of a denial of service attempt or dictionary attack.
Baselining also protects against SQL injection attacks and is run during the first few weeks to get a clear picture of normal database usage. However, DSM doesn't do baselining itself, as this must be conducted using LogLogic's MX or LX log management appliances. DSM works with these appliances and can send all information to them, allowing them to baseline database usage.
LogLogic also tackles essential compliancy with wizards that create rule sets that apply best practices for a range of data protection regulations. You have five standard ones, including PCI-DSS, HIPPA and SOX, plus a general best practices option that takes the best from each and automatically creates a set of rules.
LogLogic's latest DSM offers a smart solution for database monitoring and security that requires no downtime to deploy. Baselining will require additional MX or LX appliances but the vPatch feature could be just what businesses have been looking for to keep their databases patched and their SLAs intact.