Vulnerability

Cause

UDA Rule Book Solution

DB Defaults

Database installations always include default usernames and passwords for DBA and other privileged user accounts.

Users and DBAs are prone to taking these defaults when “getting up and running” is the typical focus of an installation effort. Even more so a DBA skills diminish.

Create default rule that deems all default logins

“insecure” and have any of the following rules in place

·        Reject all connections

·        Permit connections, but enforce read-only mode.

Create a custom domain (an identifier for your connection) that totally obscures your destination database. Instead of value "Oracle xx" or "SQL Server" you have values such as "Dept. X DB" or "Sales Data Source". None of these Domain names identify the database type which makes the default databases vulnerability exploit harder to decern.

Authentication

Some databases maintain their own user pools while others may simply authenticate against the OS, and others a combination of both.

Create a rule that enforces OS or DB level authentication – whichever is the company standard.

Create a rule that encrypts sessions with the DB Server along the following lines:

·        Login only

·        Login and data transmission

DB Privileges

DB level privileges are User, Role, Columns, and Rows based. They have no concept of client application.

The problem here (which is severe) is that applications introduce databases to enterprises and these applications tend to handle matrix of user, roles, and privileges relative to the applications’ use within the application itself. In most cases this implies minimal if any use of DB level privileges, roles, column, or row security.

One of the most timelessly distinct and powerful features of the Rule Book is that it enables data access session rules to be scoped to actual applications.

You can have a session rule in play that enforces no-access, read-only access, or full read-write access (with or without encryption)  on an application by application basis.

If a specific application introduces a mission critical DB to your enterprise, and you want to protect it from access outside of the application that it serves, or you want to provide limited access. All you need is an application specific rule.

Buffer Overuns

SQL Statements assembled from String concatenation, and then stored on the client (typically a dynamic web page; asp, jsp, php, perl,python etc.).

The attacker derives knowledge of DB schema from SQL text or from his/her general knowledge of DB schemas (you get to know all schemas if you write ODBC Drivers for numerous databases).

There is no substitute for keeping DB connection and authentication attributes residing on the Server. Even the recent introduction of "Web.config" style files that are referenced from asp.net based pages still do not cut it.

Authentication code doesn’t need to be written on the client since user credentials (per application, OS, DB combination) can be maintained in the rule book.

A DSN can have all its connection attributes server based via the SQL book. The Rule Book in question is then advertised via Rendezvous such that client simply connect to a Rendezvous server with actual connection attributes stored on the server (they are none the wiser and same applies to attackers).

SQL Injections

Compromise of DBA login details and associated privileges.

Scope DBA privileged access to DB in read/write mode to specific machine(s). For instance a rule can be constructed that only allows full read/write mode if DBA is working from machine alias ‘X” or at IP address ‘x.x.x.x’.