Login  |  Register  |  Contact

Project Quant: Database Security - Shield

Threats against databases and the information stored therein are not always conventional -- SQL injection and buffer overflow attacks are two of the more common examples. There will be instances where patches for specific threats are unavailable, or security risks are simply inherent to the database features in use. Other exploits leverage weaknesses in database trust relationships, such as Oracle database links, DB2 remote command service, Sybase remote server access, or SQL Server trusted servers. Still others exploit flaws in the underlying network security, such as insecure communication or improperly implemented SSL connections. This task within the Secure phase of the Quant for Database Security project is intended to account for cases where the database is incapable of protecting itself without functional modification or "work arounds".

We are advocating a "Patch and Shield" model to protect the database when patching comes up short. The approach might entail disabling database features, or further refinement to the database configuration. Virtual patching can also be accomplished through firewall, application firewall, or activity monitoring capabilities that block malicious requests. This process is not typically discussed in database vendor recommendations or "best practices", as it directly addresses platform deficiencies and remediation through third party vendors, but is an important step for 0-day protection.

Identify Threats

  • Time to identify at-risk databases.
  • Time to review ingress/egress points and network protocols.
  • Time to identify threats and exploitable trust relationships.

Specify Countermeasures

  • Time to identify workarounds. For any given threat, there are normally multiple possible responses.
  • Time to specify communication protocol changes. Specify how you want to alter communications with the database, what filtering rules you wish to employ, etc.
  • Time to specify connectivity changes. Tune or remove services with implicit trust relationships, and verify existing listeners and network configurations are secure.
  • Time to develop regression test case.

Configure

  • Time to adjust database configuration.
  • Time to adjust firewall/IPS rules.
  • Time to install new security controls (e.g., new firewall, VPN, etc.).
  • Time to verify changes.

Document

  • Time to document.

—Adrian Lane

Previous entry: Project Quant: Database Security - Restrict Access | | Next entry: Quant for Databases: Open Question to Database Security Community

Comments:

Name:

Email:

Location:

URL:

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: