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

I haven't seen database vault mentioned, but I *believe* that this (extra cost add-on) directly addresses - or at least when properly configured can address - your area of concern. I've not played with it at all though. The problem area is always likely to attract high cost add-ons because the people who really need the security will pay for it. Those who don't will find that the requirement fades in the face of the bill. :)

On Tue, May 3, 2011 at 4:39 PM, 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
>>
>>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

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