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

Sincerely,
 Pavel.

2011/5/3 Michael Wehrle <michaelw436_at_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