The increasing frequency of database attacks is driving federal and state legislation that requires virtually every organisation to deploy more robust audit mechanisms to protect sensitive data.
To meet this requirement, some organisations attempt to use the built-in auditing tools supplied with database software platforms. This practice of setting up a self-auditing database is based upon several false assumptions and violates the fundamental audit requirement for independence.
There are several false assumptions implicit in the use of built-in audit tools. The first is that the audit tool is the only element of the database that is not vulnerable to attack. In September 2005, we discovered a MS-SQL Server vulnerability (
http://support.microsoft.com/default.aspx?scid=kb;en-us;910741) which proves that this is not the case.
By preceding the client login message with NULL characters, an attacker can avoid MS-SQLs built in audit tools. This and other similar vulnerabilities (e.g.
http://seclists.org/lists/bugtraq/2005/May/0043.html) illustrate the flaw in assuming that built-in database audit tools are not vulnerable. Audit mechanisms are just as likely to be vulnerable as any other database element.
Even more flawed is a second assumption that an attacker will not turn off auditing, or tamper with audit records once a server is compromised. An attacker may, for example, gain database administrative privileges and immediately disable auditing mechanisms. Similarly, a rogue administrator or developer may abuse legitimately acquired administrative privileges to delete audit records in order to hide an attack.
To further illustrate the point, consider a car with a built-in video tape security feature. In the event that the door locks fail, a thief could be identified after the fact using the built-in video tape. Does this make sense? The video tape would be stolen along with the car! Perhaps the considerate thief will leave the camera on and mail the tape to police after the theft? This is an absurd system, but its directly analogous to built-in database auditing and it illustrates the obvious flaws in self-auditing security systems.
A keyword in the audit business is independence. Any audit professional will tell you that audit mechanisms should be independent of the system being audited. Therefore, any legitimate database audit mechanism should be independent of database server and users. Database audit appliances offer one simple approach to achieving independence. As network devices, such appliances can extract detailed audit information from network traffic traveling to and from a database.
Such a device can operate in stealth mode (no IP address, etc.) and remain completely invisible to attackers. All activity is tracked and records cannot be tampered with at any point. In addition, since network devices can be deployed by independent security/audit personnel, they enable independence of audit and database administration (DBA) job functions when desired.
Audit appliances also offer performance and cost advantages versus native database mechanisms. Native audit mechanisms are notorious for consuming database CPU and disk resources. The performance decline experienced when these audit features are enabled forces many organisations to scale back or abandon auditing altogether. This performance drawback is a clear disincentive to appropriate audit practices.
Audit appliances, on the other hand, operate at line speed and have zero impact on database resources. By offloading audit overhead to independent appliances, organisations can enable extensive tracking, deploy fewer database servers, require less load balancing, and reduce costs.
Native database audit mechanisms do not meet the fundamental audit requirement for independence. To make matters worse, they impact performance to an extent that drives many organisations to abandon database auditing altogether. As database attacks and legislation take center stage, organisations will be pressed to find and implement independent audit solutions. Database audit appliances represent an immediate, cost effect approach.
BIOS, Apr 24, 06 | Print | Send |
Comments (0) | Posted In
Networking