Quant for Databases: Open Question to Database Security Community

Should we cover code and query analysis?

We have an open question about how much coverage, if any, we should provide to embedded application code or query analysis for the purpose of database security. We are on the fence about including SQL Injection prevention (application code changes or use of stored procedures). Obviously code injection remains a major issue for most applications, especially web facing applications as new threats are discovered on a regular basis. SQL Injection attacks are directed at the database, but typically addressed at the application layer or supporting services. It is, however, a capability within the database to thwart SQL Injection through parameter screening and data type matching capabilities provided with stored procedures. For most firms this is handled in the realm of application security.

As such, we would like to defer the question to the community at large: Should we cover query analysis and code injection prevention and develop a process for code verification ad part of this Quant project? Where does this responsibility lay within your organization today? Is it purely part of the application security teams job, or does it fall upon DBA's and database security team?

Please send in your thoughts.

—Adrian Lane

Posted at Monday 18th January 2010 2:30 pm Filed under:

Previous entry: Project Quant: Database Security - Shield | | Next entry: Project Quant: Database Security - Monitoring

Comments:

By Cesar Cerrudo on 01/19 at 08:15 AM

First of all, congratulations for Quant for databases project, this is something that can really help organizations.

I think query analysis and code injection prevention should not be covered, it’s a very broad topic and more related with application security. If you cover it then mabye you will have to go deep in secure programming, SDL, etc.

BTW: use of stored procedures doesn’t always prevent SQL Injection.

Thanks.

Cesar.

By Adrian Lane on 01/19 at 09:21 AM

@Cesar - Thanks for the input. And point well taken ... stored procedures don’t always stop SQL Injection ... but neither does WAF.

-Adrian

By Slavik Markovich on 01/25 at 03:36 PM

A few remarks:
1. Databases are complex beasts that support stored program units such as procedures, packages, triggers, etc. and provide lots of built-in stored program units
2. Many applications are developed with tons of #1
3. Many vulnerabilities exist in built-in program units but much more in custom code. I’ve yet to see a single customer without problems in procedures, etc.

When you talk about database security, analyzing applications is a out of the scope but analyzing the database code is definitely in. Going over the code automatically and flagging dynamic statements is not a big issue. Of course, changing them is. At least, the organization will know where the problems are and can try and shield them through permissions, etc.

Page 1 of 1 pages