Guardium 7 – database security review

You start by deciding which inspection engines should run and choose from options including MSSQL, Oracle, Informix, DB2 and Sybase. You also have options to monitor many proprietary protocols such as named pipes and Oracle Bequeath. A smart graphic on the home page shows clearly what databases are being monitored and the traffic each inspection engine is seeing.

Auditors have access to an extensive range of reporting tools and they can pass reports to other users for approval and once they’ve been signed off Guardium will not accept any further changes to them. Reports also default to hiding the values of SQL queries run on sensitive data and will only show them if an auditor specifically requests this.

Regulatory compliance is upheld for administration as root access is not permitted, thus stopping reports and data on the appliance from being subsequently modified. Guardium also maintains internal audit trails to keep track of all users and their activities. Databases are monitored in real time by the probes and policies containing a range of rules are used to provide protection and enforcement.

Access rules look out for database users and report on their activities. These can contain actions so anything untoward can be used to generate an alert or actually terminate the user’s session. If you use port spanning the latter is achieved with a brute force TCP reset whereas the S-Gate probe is far more elegant as it does this at the SQL command level.

Extrusion rules inspect traffic exiting a database allowing them to see the results of user queries and check for patterns such as credit card numbers. There’s no need to learn a new query language as the interface breaks down queries into their component parts for easy understanding.

So how does Guardium protect against SQL injection vulnerabilities? Real time monitoring can spot activities such as system procedures being executed by application users, whilst correlation alerts advise on suspicious activity such as excessive errors or login failures. A good practise is to use Guardium’s baselining for a couple of weeks after deployment. This monitors normal activity and makes policy suggestions based on this information that will alert you to subsequent activity outside these parameters.

During testing we found it easy enough to create rules and deployed one to control system users by stopping them from using certain commands and blocking access to tables with payment card details in them. We then logged on to the test Oracle database and the moment we tried to select these tables Guardium used the probe to terminate our session.

The damage to a company’s reputation after a database security breach can be far reaching with customers quickly losing confidence in its ability to protect their personal information. The much used adage of learning lessons is simply not acceptable where loss of personal data is concerned and although smaller businesses will find it represents a high initial outlay, Guardium does offer a sophisticated solution that can make sure it never happens in the first place.