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

From: Michael Wehrle <michaelw436_at_gmail.com>
Date: Tue, 3 May 2011 14:42:18 -0400
Message-ID: <BANLkTinTQqORQVma6REXKTc=TbXV3TVkRA_at_mail.gmail.com>

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_at_gmail.com> 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_at_gmail.com> 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
>>
>>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Tue May 03 2011 - 13:42:18 CDT