Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 

Consulting Requirements:
Data Obfuscation and Client Privacy

Don Burleson

 

Note:  In addition to these guidelines, make sure to review our Dress Code, etiquette requirements, Cross-Cultural Guidelines, forum guidelines and obfuscation requirements.

In an effort to be kind to those who demand evidence for our observations from client’s sites, some of you have been tempted to share snippets from STATSPACK reports (after obfuscating the client’s private table names, etc), and other details about a client’s server environment and configuration.

This approach is extremely dangerous.  We have seen some people actually ask for an export of a client’s confidential data, as-if they were going to try to replicate the situation on their own 32-way server.  Obviously, this is nonsense, and you should not be bullied into disclosing details from a actual client database. 

Obfuscation of client's identity on MOSC forums

In light of recent exposures within Oracle MOSC, it might be possible to find an Oracle client who is experiencing a vulnerability by clicking on the name of the forum poster's e-mail address, and all Burleson Consultants should use free-mail accounts or BC domains ( www.remote-dba.net, www.dba-oracle.com) for all MOSC forums and iTar postings.

Obfuscation and inadvertent disclosure

Our consulting agreements always require absolute data and configuration confidentiality and the obfuscation of client data must be carefully controlled, especially when you are retained via an NDA or a classified government database. 

We are absolutely required to thoroughly obfuscate all reports and listings from client sites.  It's not enough to change table and index names.  Often, a client's competitive advantage comes from their hardware and consulting investment and we must be ever vigilant to not disclose identifiable configurations.  For example, there may only be a handful of shops using a dozen 64-CPU HP Superdomes in a RAC configuration.  That disclosure, by itself, can lead to their identification and violate our confidentiality agreement.

We cannot afford to take any chances when reproducing data for illustrative purposes in books, conference proceedings and articles.  The inadvertent disclosure of confidential data is a huge issue, even with obfuscated systems.  The best example is an obfuscated medical database where the identity of an individual can be derived by a low-count scope of a query. A report listing one Eskimo dentist in Miami Florida with HIV is all someone needs to derive the persons name and violate their privacy.

This paper notes how Google can be used by hackers to locate Oracle system details on the web and within Oracle forums and offers obfuscation advice:

• Customers should use, if possible, a freemail account in forum entries.

• Anonymous configuration files when posting on MOSC

• Remove passwords before posting content on MOSC

• If you are reporting a bug to Oracle think of the possibility that this bug could be security related and escalate it if necessary. Even, if this costs additional time and money it would make Oracle more secure in the long run.

• Oracle analysts should become more security aware and try to avoid providing insecure advices like removing listener passwords, submitting xhost+, …

Avoiding the Disclosure Trap

Many of our consultants are altruistic, sharing their experiences in forums and blogs.  You should be suspicious about anyone who challenges your observations with a challenge of "prove it".  Obfuscation of client data is neither dishonest or a fabrication, it is a contractual requirement by your clients.  IMHO, no legitimate database professional would ask you to provide a reproducible case from a clients database, and it might be a trap by a malicious hacker.

If you participate in web forums, make sure that you do not fall into a disclosure trap.  All Oracle professionals should be wary of anyone who insults them or claims that withholding a reproducible test case from your client is "dishonest":

"I fear many (excluding Mr. Burleson, or Mr. Ault) who would oppose Tom's 'Scientific' method prefer the dishonest methods described, above, as a cover just to pad their bank account and get out the door so they can get on to their next victim."

Unprofessional allegations of fabrication and dishonesty should be an immediate "red flag", as a baiting technique to disclose confidential client information.  Anyone who shares information about their on-the-job experiences should be especially wary of anyone who demands that you "prove" your observations with a repeatable real-world test case.  It could be a trap.

We are under no obligation whatsoever to provide reproducible evidence or test-cases to anyone and it is our readers trust in our judgment and real-world experience that counts.  Even if you are insulted or ridiculed, resist the temptation to fall-in to the “prove it” trap.


 

 

  
 
  
 
 
 

 
 
 

Oracle training Excel
 
Oracle performance tuning software 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2014

All rights reserved by Burleson

Oracle © is the registered trademark of Oracle Corporation.