RE: Security Question - how do you deal with sensitive information hardcoded in SQL statements
Date: Mon, 2 May 2011 15:27:16 -0500
Message-ID: <F077F09A0E11504D9E720358BEE994D107A3711E_at_APSW0553EVS.ms.ds.uhc.com>
We deal with this kind of information on a daily basis. How we deal with it is prety much what HIPAA is all about.
As an organization we are trained in how to handle this kind of information. Our company has policies and procedures put in place to deal with the use of said information including what to do if it gets out .... inadvertantly or otherwise. And the rules are hard core. They can include removal from the job, fines, lawsuits, and criminal prosecution. They are VERY serious about it.
Database security is very strict and access to any place that this data can reside is very limited.
There is NO sending anything to oracle or any other organization. All sensitive info would have to be scrubbed from communications, reports, or presentations made. That would include removing SSNs, Birth Dates, etc. from them and preplacing them with "hypothetical" values.
Any breach of the rules for handling have to be reported immediately and a full investigation would begin as to how and why it happened.
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jared Still
Sent: Monday, May 02, 2011 12:49 PM
To: Oracle-L Freelists
Subject: Security Question - how do you deal with sensitive information
hardcoded in SQL statements
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
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
-- http://www.freelists.org/webpage/oracle-lReceived on Mon May 02 2011 - 15:27:16 CDT