If All Else Fails

for RuBoard

Unfortunately, your code is likely to ship with security weaknesses. Like eliminating all bugs from a complex product, finding all the security flaws is a gargantuan task, and mistakes are likely to be made.

Proper design can help mitigate these potential disasters; code can be sectioned off so that a breach in one area doesn't compromise the entire system. But it's always wise to have something up your sleeve if the unthinkable happens. If a security vulnerability is found and exploited and your code is out in the field, you'll need to offer a fix very quickly indeed.

This can be problematic : Finding the vulnerability, designing, implementing, and testing a fix can certainly take more than a few hours. In this situation, it would be nice to have some workarounds for the customer (short of uninstalling your software altogether). Here are some ideas that might help:

• Supply a rip cord. The idea here is to provide a means to turn off part of the functionality of your software (the part where the vulnerability is discovered ) without impacting unrelated parts of your product. The rip cord could be configured through a registry setting or a config file, for instance.

  Say that your software processes transactions sent and received using HTTP. A vulnerability is discovered whereby a request coming from the Internet can compromise a server. A possible rip cord here is to allow disabling of Internet requests (allowing only local and intranet requests to be serviced). This would remove the possibility of an Internet-based attack, and for some customers, this would be impact free ( assuming they are performing intranet-only transactions). This would give you some time to design a proper solution.

• Offer further configuration options. For instance, if your software is producing digital signatures using a particular signing algorithm and key size, you might want to provide configuration options that allow these to be changed. That way, if a vulnerability is discovered in the algorithm (or if the key size becomes insufficient) you have a way of updating customer systems without requiring a patch.

  These configuration options don't need to be documented, or even officially supported. They're just an option you can keep in your back pocket. That way, the maintenance cost is kept low. There's no need to design a fancy way to manage these options or spend time making them user friendly in any way.

A word of caution here: Remember to review and thoroughly test any such options that are implemented. It would be terribly unfortunate were such a technique itself to serve as the vector for an attack!

for RuBoard