SQL57_TEST issues

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

SQL57_TEST issues

Charles McClain

I'm involved in developing Vulnerability Assessment test content for IBM's
Infosphere Guardium  product, and in a conference call recently with Danny
Haynes, Jon Baker, and Matt Hansbury, I raised some concerns about
limitations in OVAL's <sql57_test> that preclude us from using it as a
testing mechanism at this point in time.

Following that discussion, Danny suggested that I post some of these
concerns here as a way of kicking off a group discussion.  We're both
interested in finding out if others have similar concerns, and in
stimulating a discussion as to how the OVAL language could best address
these issues.  So, here goes:

   Database types – Our tests currently support the following DBMS's:  DB2
   z/OS, DB2 LUW, Oracle, SQL Server, Informix, Teradata, MySQL,
   PostgreSQL, Netezza and Sybase.  From what I can see, the OVAL
   sql57_object <engine> enumeration does not support all of these DBMS's;
   Username/password security and encryption – The deprecated <sql_test>
   and the newer <sql57_test> provide for a <connection_string> element,
   but the username and password elements are in clear text.  We know from
   experience that this is unacceptable to our customers, who are obligated
   to satisfy their auditors and legislative requirements;
   Complex queries – Some database vulnerabilities require very complex
   queries, including, but not limited to:  A.) Multi-table queries
   involving complex JOIN conditions; B.) subqueries, both simple and
   coordinated; C.)    UNION SELECT queries involving potentially a dozen
   tables or more; D.) Anonymous block execution.  We have queries
   supporting some of our vulnerability assessment tests that run to 100 –
   200 lines of code.  I'm not sure the existing OVAL <sql57_test> type can
   support all the variety of queries that we need;
   Multi-database queries – This is an extension of our “Complex queries”
   concern.  Some DBMS's (e.g., Oracle) store catalog information
   centrally, but others (e.g., Microsoft SQL Server) store catalog
   information inside each database.  For these DBMS's, our tests query the
   central catalog to retrieve a list of databases and then loop through
   this list, executing the same query against each database's catalog.
   Pass/Fail is based on the results of the entire loop, encompassing
   multiple queries;
   Resultsets – Our customers demand more than simple pass/fail
   information.  They requre specifics as to what caused them to fail one
   of our tests.  For example, if we have a test that says, “No non-DBA
   user should have access to database objects of type X”, our customers
   require that our assessment results tell them which non-DBA users have
   such privileges, and on which objects of type X.  In both cases – the
   users involved and the objects involved – the count could run into the
   100's or even 1,000's in a large environment, and telling the customer
   that he has to take our results and go off and identify the users and
   objects that caused him to fail is not going to fly;

I invite any and all forum members to respond with their thoughts.

Charles McClain
Advisory Software Engineer
IBM InfoSphere Guardium
550 King Street
LKG1-3rd floor
Littleton, MA 01460
Office: 978-899-3144