Jared, I had this issue (possibly similar) a few years back on a 10.2.0 database, and Oracle actually provided a patch for it. See my writeup about it here iamsys.wordpress.com/2010/03/16/how-to-protect-sensitive-bind-data-in-redo-logs/, and if you have anymore questions, I will be glad to TRY to remember them, as it was a few years ago. On Tue, May 3, 2011 at 11:39 AM, Jared Still <jkstill@xxxxxxxxx> wrote: > What I have seen so far in this thread is this: > "There isn't a good technical solution to this problem using > without using add on products" > > Not terribly surprising I guess. > > Even with add on products I am not sure of the value in > this situation. > > Do data masking and/or encryption hide the values > that may be hardcoded into a WHERE clause? > > I don't know the answer to that, but I don't expect > that values appearing in the WHERE clause would > be affected. > > ASO and probably data masking as well are aimed at > hiding the values seen in a table, not the values hardcoded > into a SQL statement. > > Jared Still > Certifiable Oracle DBA and Part Time Perl Evangelist > Oracle Blog: http://jkstill.blogspot.com > Home Page: http://jaredstill.com > > > On Mon, May 2, 2011 at 10:49 AM, Jared Still <jkstill@xxxxxxxxx> wrote: > >> >> 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 >> >> >