Here are some excerpts (inlined) with my comments
(outlined)from an interesting
articleon SQL DBMS exploits and vulnerabilities by
Aaron C. Newman, for
"6 Security Secrets Attackers don't want You To Know".
How secure is your data? Looking at your information management
resources through a would-be intruder's eyes can help you find (and
When E. F. Codd developed his relational data model in 1970, the
business world was a different place. Almost 35 years after his
seminal work appeared, RDBMSs that sprung from Codd's ideas are the
standard for storing corporate information. And, with government
and industry regulations dictating what kinds of information
companies have to store, manage, and audit (and for how long),
protecting this information is more important than ever.
Unfortunately, it's also more challenging
Even in 1985, when Dr. Codd published
12 guidelines for RDBMSs, there was little concern for data
security. In those days, gaining access to a database was so
difficult that advanced security features on the database were
Today, RDBMSs carry the lifeblood of every organization. Note
the use of the plural: Organizations now have many databases that
demands that data access be extended to customers, partners,
suppliers, and other parties who were rarely considered in the
early data management days. With all this availability ? not to
mention pressure from an array of government and industry
regulations (see the sidebar,
"Security and Compliance") ? the need to control exactly who
can access or modify data is becoming paramount.
Absolute facts, that are still partially understood at
best. For instance we are still in a so called "Information Age" in
which standards based data access remains an issue of contempt
instead of absolute necessity.
There are a number of prevailing myths about standards
based data access that continue to cloak reality:
ODBC, JDBC, ADO.NET, OLEDB all deliver poor performance
(compared to their native, proprietary, and database specific
counterparts; native interfaces)
You can't really right generic database applications with
these standards due to inconsistencies in the DBMS implementations
of SQL (not true! there are many aspects of the specs that address
these concerns if only a majority of driver vendors would implement
these features, and the application developers actually used them
by seeking drivers with full implementations).
Even if the above were true (which I refute strongly), how about
the general security vulnerabilities that affect both Native, and
Standards compliant, data access interfaces?
Aaron's article does a good job of highlighting 6 areas of
DBMS Defaults (usernames and passwords)
Authentication (at connect time)
What I have been able to do very quickly (thanks to blogging,
and the power of a blog engine that supports WebDAV),
is write a
tabulated response to each of the items (bar Fixpaks)
indicating how the OpenLink Multi-Tier
Data Access Drivers (for ODBC, JDBC, ADO.NET, and OLEDB)
protect corporate databases from each of these vulnerabilities.
To cut a long story short, we are increasingly living a
contradiction where the terms "simple" and "free" are supposed to
lead us to products that can adequately handle the challenges of an
increasingly sophisticated grid of inter-connecting point.
I have been asked on numerous occassions, "How can you build a
company and business based on data access technology?". My reply is
the same as usual, "because everything comes down to data". If the
data is compromised in anyway, then kiss Information, Knowledge,
and everything else goodbye!