|
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 MetaLink forums
In light of
recent
exposures within Oracle MetaLink, 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 MetaLink 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 Metalink
• Remove passwords before posting content on Metalink
• 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. |
