Shipping and Maintenance Phases

Shipping and Maintenance Phases

The hard work is done, or so it seems, and the code is ready to ship. Is the product secure? Are there any known vulnerabilities that could be exploited? Both of these beg the question, How do you know when you're done?

How Do You Know When You're Done?

You are done when you have no known security vulnerabilities that compromise the security goals determined during the design phase. Thankfully, I've never seen anyone readjust these goals once they reach the ship milestone; please do not be the first.

As you get closer to shipping, it becomes harder to fix issues of any kind without compromising the schedule. Obviously, security issues are serious and should be triaged with utmost care and consideration for your clients. If you find a serious security issue, you might have to reset the schedule to accommodate the issue.

Consider adding a list of known security issues in a readme file, but keep in mind that people often do not read readme files. Certainly don't use the readme file as a means to secure customers. Your default install should be secure, and any issues outlined in the document should be trivial at worst.

IMPORTANT
Do not ship with known exploitable vulnerabilities!

Response Process

It's a simple fact that security flaws will be found in your code after you ship. You'll discover some flaws internally, and external entities will discover others. Therefore, you need a policy and process in place to respond to these issues as they arise. Once you find a flaw, you should put it through a standard triage mechanism during which you determine what the flaw's severity is, how best to fix the flaw, and how to ship the fix to customers. If vulnerability is found in a component, you should look for all the other related issues in that component. If you do not look for related issues, you'll not only have more to fix when the other issues are found but also be doing a disservice to your customers. Do the right thing and fix all the related issues, not just the singleton bug.

If you find a security vulnerability in a product, be responsible and work with the vendor to get the vulnerability fixed. You can get some insight into the process by reading the Acknowledgment Policy for Microsoft Security Bulletins at www.microsoft.com/technet/security/bulletin/policy.asp, the RFPolicy at www.wiretrip.net/rfp/policy.html, and the Internet Draft Responsible Vulnerability Disclosure Process by Christey and Wysopal (http://www.ietf.org.)

If you really want to get some ideas about how to build a security response process, take a look at the Common Criteria Flaw Redemption document at www.commoncriteria.org/docs/ALC_FLR/alc_flr.html. It's heavy reading, but interesting nonetheless.

Accountability

In some development organizations, the person responsible for the code is not necessarily the person that fixes the code if a security flaw is found. This is just wrong. Here's why. John writes some code that ships as part of the product. A security bug is found in John's code, and Mary makes the fix. What did John just learn from this process? Nothing! That means John will continue to make the same mistakes because he's not getting negative feedback and not learning from his errors. It also makes it hard for John's management to know how well he is doing. Is John becoming a better developer or not?

IMPORTANT
If a security flaw is found, the person that wrote the code should fix it. That way she'll know not to make the same mistake again.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net