By Robert Auger
10/18/2006
Introduction
Identifying security defects before a product ships reduces the risk of embarrassing public exposure, the cost of repairing the defect, and the risk to your customers. Your customers will not forget being compromised via a flaw in your product, and they may try to hold you accountable. Properly performing this security validation at each phase can greatly reduce your products risk to security flaws.
Reviewing Your Requirements
Ensure that your requirements take into consideration potential risks exposed via product functionality. Often developers are rushed in an effort to meet a deadline and can do only what is needed to fulfill the product's requirements. Addressing security concerns in your requirements, and ensuring proper time is allocated for them to be handled can go a long way and ensure that things don't fall between the cracks. Below are a few common examples of things that can be addressed in the requirements phase.
* Actions shall be performed with the lowest privileges possible
* Files and Registry Keys shall contain permissions restricting access except to those users that explicitly need it
* Sensitive data must not be stored in clear-text or using a weak encryption model
* User SessionID's must be as unpredictable as possible an not easily enumeratable
* Third party components/libraries handling sensitive data must not improperly store it (See the 2nd example)
Reviewing Your Implementation
Implementation of the requirements may vary from developer to developer and must be taken into consideration when investigating potential risk. The way in which a requirement is actually fulfilled could expose your application to issues unseen during the requirements review process.
Carefully reviewing your products functional specifications with your development team is an important step that should be performed (if possible, however this is the real world) before any code is written. Engineering decisions not properly taking into consideration potential security impacts could result in a serious flaw being discovered with no easy solution. The worst case situation may require re-engineering an implemented requirement entirely which is very expensive and may impact future cycles.
Addressing Risk Probability and Severity
Common usage paths (or steps) take precedence over complicated edge cases. If your application requires 5 specific non-standard configuration changes to be made, and 90% of your audience touches 2 options at the most (that you know of) you're probably not going to care about fixing it before release right? Never assume something isn't going to be found, or a situation isn't going to happen. Edge cases may happen more often then you think in the real world, especially when someone malicious is looking for them. An attacker understands that an edge case might just be the entry point needed to compromise your data or system, so it's important that you understand this as well.
Supporting Your Customer
Customer symptoms can also provide clues to potential problems. Product behaviors will be reported to support and it's important that these unusual behaviors be analyzed accordingly by the support staff and escalated when appropriate. Innocent appearing error messages may be gateway to much larger issues. Ensure that your support staff understands how to gather the appropriate logging information and this is recorded into your customer and bug tracking system.
Conclusions
I'm not going to lie, the first cycle implementing these sorts of security checkpoints isn't going to be easy: you're probably going to find more issues than you were expecting and may be overwhelmed with what you find. The second cycle isn't going to be much better, however by the third or fourth cycle your development team will get used to the idea of these security checkpoints and things will become smoother as your process becomes more defined.