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.