Anyone in the software industry knows that it's much harder to build a system than it is to tear them down (ignore what those tree-hugging hippy cryptographers say; these are the same people who want you to give your source code away for free!). So why is it that security bug reports get so much more publicity than your press releases about new product features? Probably because you're mishandling bug reports! Know what the pros know; don't let security problems get out of hand. The following 10 tips should help you contain and control security problems:
1. Deny Everything
Never, ever admit that there's a problem. When you receive a bug report,
discredit the report. Did the report come from a competitor? Bias! Slander!
Remember: if 99 percent of your customers can't reproduce the problem,
99 percent of your customers won't be able to disprove you when you say
the problem doesn't exist. Remember handy key phrases: "that's not a bug,
it's a feature!" and "the product was NEVER designed to handle that!".
2. Keep it Secret
Bury the report. Inform the reporters that the problem will take months to
fix, or that the fix can't be released until all your products are sent back
through regression testing. Remind them how irresponsible it would be to
announce a problem for which there is no fix. Congratulate them for their
cleverness and assure them there there is no way any evil crackers will ever
find the problem themselves. If all else fails, bribe.
3. Forget the Report
Route the bug report to level-1 technical support. For best effect, ensure
that the support technician assigned to the problem speaks minimal English.
Delete the report from your bug tracking system. When the reporters give up
on you and announce publically, claim you never heard about the problem, and
inform the press and your customers that the reporters are simply seeking
publicity. Proceed directly to step 1.
4. Make Excuses
Blame the operating system. Make sure your customers realize that the
problem would never have occurred if Windows 95 popped up a modal dialog
asking users if they'd like to wipe their swap file and start a new one
every time a program exits. Blame the network. Make sure the press knows
that the problem will never, ever occur on "real" networks, where only
well-formed web traffic is passed through the packet filters. Blame the
reporter. Remember handy key statement: "what was once an obscure problem
is now a widely-known problem that hackers can use".
5. Downplay
Make sure your customers know every limitation of the security problem
being reported. If the bug lets attackers read any file, remind your
customers that attackers can't use it to reformat hard drives. If the
attack is complicated, make sure your customers know that it would take
an evil genius to exploit the problem, and that it isn't a problem for
anyone in the real world. If the press calls, be ready to inform them
that nobody is known to actually be exploiting the problem, and thus the
problem isn't important.
6. Wait for Next Release
Frequent updates confuse customers. Loads of bug fixes give customers the
impression that your software is less reliable than you know it really is.
Don't give your customers the wrong idea about your quality assurance and
testing practices... silently roll fixes into the next release of the
software. Added bonus: you can claim "significant security enhancements" in
the advertising for the next version!
7. Beta-Test the Fix
Bug fixes are much easier to produce when you take absolutely no
responsibility for problems caused by the patch. Easier means faster
(not to mention cheaper), and faster is always better when it comes to
security. Tell your customers that you're acting in their best interests
by getting them a fix as quickly as possible, and that an official
version of the patch will be available soon (see step 6). Save valuable
tech support resources by refusing to provide any assistance for any
aspect of your software to customers who have moved to an unsupported,
experimental configuration by installing your security patch.
8. Patch the Exploit
Capitalize on free quality assurance work by waiting for the exploit to
be released instead of finding and reproducing the problem yourself.
Add "3" to every fixed constant in your source code. Rebuild software.
Try exploit. Repeat until exploit ceases to work. If this fails to solve
the problem, convert all strings in your source code to Unicode. Rebuild
software. Inform customers that you have resolved the problem.
9. Shoot the Messenger
Anybody who would purposely look for security problems, or tell someone
about a security problem they found "accidentally" (yeah, right), is
clearly a dope-smuggling pedophile. Accuse reporter of attempting to
blackmail your company. From this point on, refer to bug reporters as
"hackers", as in this statement to concerned customers: "hackers like these
will always be finding problems in software products, and we will continue
to quickly resolve these problems after notifying the proper authorities."
Remember: the messenger is expendable. The value of your stock options is
not.
10. Threaten Lawsuit
Sneak clause forbidding reverse engineering of your products into your
license. Inform reporter that you believe there could be no way to find
security bugs in your software without violating the license. Too late
to modify license? Accuse reporter of libel, and claim hundreds of thousands
of dollars of damage to your company's reputation if the reporter lies
to the public about nonexistant flaws in your software. Remember: it is
highly unlikely that anyone who finds bugs in programs can afford to
defend themself in court. Make sure the reporter remembers that too.
For examples of how real software companies employ these techniques in their daily business, simply jump over to CNet's NEWS.COM and search for stories with the words "security" and "flaw" in them. See how simple and effective these real-world strategies are. Remember: your company pays for every letter of publicity it obtains. Don't let childish hackers get a free ride at your expense.