SECURITY QUESTIONS TO ASK YOUR VENDOR MAY 2010 Background It is a well established fact that software may contain security vulnerabilities. Even well managed, well funded, highly professional software developers can often produce code which contains unknown (at the time) vulnerabilities which may be exploited at a later date. Vulnerabilities are inevitable, and more lines of code will result in more vulnerability: industry average is often quoted as 15-50 errors per 1000 lines of delivered code (see “Code Complete” – Connell 2004). It is also well established that obtaining and deploying software patches/updates for many different products within a corporate network is a difficult task. The problem of updating software also causes a serious problem for organisations which must make a trade-off decision between availability and security: should they apply software updates as quickly as possible to secure the network, or should more time be put into testing updates for compatibility with the existing environment, to prevent deployment of an update that impacts on other applications or products. A contributing factor to this situation is that vendors are in competition with each other for share of a finite market. Hence it is important (to vendors) that their product should be swift to market, and should have all the features which customers demand. Hopefully they will then achieve good sales figures, and derive a revenue stream which can help to further develop the product throughout its life. This paper provides valuable information to procurement teams, business risk managers and information security professionals about the kinds of security questions they should be asking of vendors. By asking questions about the security of products right at the beginning of a procurement cycle, organisations are more likely to receive a better product at the end; one that does not require quite so many updates and cause so much downtime. Secure code should be one of the “features” that customers demand. It is hoped that by encouraging an early appraisal of a product’s security credentials more vendors will feel the need to build security into their products from the design stage. The questions we have suggested below are primarily derived with software applications in mind, however the same approach applies equally to wherever software is found: hardware appliances, multi-functiondevices, operating systems, embedded software, databases and other specialist applications. We suggest that organisations study the suggestions below and think about the approach they currently take with regard to procuring software. Then identify or adapt the questions which would best apply to themselves. We do not suggest what the model answers to these questions should be; it is up to organisations to decide for themselves, on a case by case basis (taking account of their risk-appetite) if their prospective supplier is making a good attempt to answer them fully and succinctly. The Questions 1. Which SDL (Secure Development Lifecycle) programme does your development team adhere to? 2. What methodologies do you use for security testing your products? (Automated testing, codereview, fuzzing, manual tests etc.) 3. How frequently and using which methodology do third parties conduct security assessments on your products? 4. What training do your development and testing teams receive specific to application security? 5. Do you have a dedicated team to assess and respond to security vulnerabilities reported in your products? 6. What is your patch release strategy and what tools do you offer for patch deployment? 7. Do you disclose all vulnerabilities that affect your software, and how/when are customers notified? 8. How did you Threat-Model the application? 9. Do you conduct security testing separately from functional testing? 10. What technical guidance do you provide about vulnerabilities, including how they could be exploited, how they are currently being exploited, and how to mitigate vulnerability? 11. For applications developed on Microsoft platforms: do you utilise Microsoft's D.R.E.A.D model to assess the security of your software? 12. What is a typical vulnerability to patch delivery time frame? 13. Would you support a future product Health Check? 14. Are there any outsourced / subcontracted components related to your product? And how do you assess the security impact of such components? 15. Who do I talk to if there is a (security) problem with your product? 16. If the operating system is patched or upgraded, will the application continue to work and how will security be affected?