Published: 01 May 2008
| DATABASE SECURITY
Nearly every interactive application and true "Web 2.0" application on the Internet is leveraging a backend database. These applications enable users to purchase cars, check bank balances, bid on used toys, and download music. But, regualtory requirements and the persistent fear of security breaches put severe pressure on the businesses providing those services.
Symantec Database Security (SDS) helps alleviate the operational and technical challenges associated with auditing, assessing, and monitoring database traffic in real-time. Policies can be utilized to catch internal application and database abuse in combination with additional policies to monitor external attacks and malicious use
SDS 3.1 supports Microsoft SQL Server 2000 and 2005, Oracle 8, 9, and 10g, Sybase ASE 12, ASE 15, and IQ 12, and IBM DB2 8 and 9; 32- and 64-bit operating platforms are supported for each. Surprisingly, MySQL (acquired by Sun Microsystems earlier this year) is not supported.
The SPAN port on a switch containing the database to be monitored is the ideal location for this type of solution; however, logically it only needs to be in a spot that can capture all of the traffic going to and from the database. Installation is straightforward and only takes a couple of minutes by entering IP address, DNS servers, time zone, and whether or not you want to permit SSH. It was nice to see that SSH is required for remote administration--if you select "No SSH," you have to manage your box locally or through a serial port. Generating the custom SSL certificate with the click of a button was a nice addition--most large organizations use their own SSL certs, so this was helpful.
SDS is sold as a soft-appliance meaning that it is recommended you procure the hardware separately. Symantec recommends a rack-mounted Dell or HP box with two dual core Intel Xeon 2.66 GHz processors, 8 GB of memory, 8000 TPS, 6 network interfaces, and dual 73 GB RAID drives.
SDS' slick Web-based interface is intuitive and has that "Web 2.0" look and feel, with graphic-intense toolbars and rich menus; the speed and response time was good. This is where you create monitoring policies, view reports, analyze incidents, and continually "train" the system via the Adaptive Learning module. Larger organizations will leverage SDS' additional integration capabilities for real-time alerts via syslog, SNMP, XML, and email output streams.
There is no LDAP and Active Directory integration (it's under consideration for a later release).
Policies can be created manually or by using the Adaptive Learning module. (Think of these policies as a series of IDS rules that state what action should occur when the rule is triggered.) Adaptive Learning sniffs and stores all SQL queries to and from the database. It can then provide counts on the common and anomalous queries to the target system and can easily identify common access sources, average traffic patterns, and even errant system administrators. Data leakage rules can also be created to alert administrators when credit card, Social Security, or other potentially sensitive information is being sent to specific users.
We liked the ability to quickly edit policies or apply multiple policies to a database. For example, you could assign both the company PCI and SOX policies to an e-commerce database for rule enforcement. You'll need database expertise--if you don't know what a "left join" (an sql command typically utilized when creating complex queries on databases with several tables) is, you could be in trouble.
Setting up more generic policies, such as an authentication policy is much easier. With little coaching it would be easy to identify the user accounts (based off on login username) to trigger an alert such as the one we created to trigger on all failed login attempts.
SDS accurately clocked all of our queries during adaptive mode; however, it would be nice to see more security intelligence integrated into this module. For instance, when it sniffed our SQL query containing an attack string going after all username entries in the database, it would have been nice to see a warning message or some sort of notice or alert. To fully utilize this module, you will need both the savvy of a database admin and an understanding ofthe types of database attacks.
The showstopper for us was that reports could only be saved in HTML and XML. We were shocked to see that reports could not be saved in CSV or PDF.
Testing methodology: We tested a Symantec Database Security soft-appliance in a lab with the product monitoring the following databases for both network and local activities: IBM DB2 on AIX, Oracle 10gR2 on Solaris 10, Oracle 10g on HPUX, and Microsoft SQL Server 2005 on Windows Server 2003.