Security Question - how do you deal with sensitive information hardcoded in SQL statements

From: Jared Still <jkstill_at_gmail.com>
Date: Mon, 2 May 2011 10:49:17 -0700
Message-ID: <BANLkTimwPiD0t21Fn_Fgquo6dwKYT6d5SQ_at_mail.gmail.com>



First, the assumption is that you are working with a 3rd party application, and there
is nothing you can do to modify the SQL statements used by the app.

Nor are you able at this time to apply an extra cost option, such as ASO.

How do you deal with sensitive information that may be hardcoded into SQL statements?

This kind of SQL presents all kinds of problems.

  • statspack/AWR reports showing Top SQL
  • queries for cached SQL
  • execution plans.
  • trace files
  • probably many more I am not thinking of at the moment.

The problem arises when any sensitive information (SSN, CC#, etc) appears as a
hardcoded value in a SQL statement, and the SQL in question is a subject of current performance discussions, or troubleshooting of database and SQL issues.

The SQL statements get sent to Oracle support as part of AWR or Statspack reports,
execution plan analysis, trace files etc.

They can also inadvertently appear in emails, meetings and even presentations.

How do you deal with this?
This issue has the potential for a fairly serious security breach.

TIA, Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Oracle Blog: http://jkstill.blogspot.com Home Page: http://jaredstill.com

--
http://www.freelists.org/webpage/oracle-l
Received on Mon May 02 2011 - 12:49:17 CDT

Original text of this message