Q: Can you use the same approach for calculating ROSI in corporate security as you do for information security?A: While there are subtle differences between the two, you still have the parallel of using the same metrics to calculate the savings from implementing a form of risk management. In a lot of cases, it is easier to quantify savings based on known variables of physical risk management. One example of this would be the effect of implementing surveillance on shoplifting. In a lot of instances, it is more tangible than in information security risk management.Q: How would you suggest a government agency calculate its return on investment?A: A government agency should think of itself as an individual business unit when doing this so as not to confuse calculations, metrics and baselines that may not apply to it. Start by reviewing any recent cost studies by budgeting and accounting entities for applicability to your specific case. Pick smaller instances where you want to calculate ROI to draw metrics that can be applied to calculate overall ROSI.Q: If you were the CSO of a major bank doing business online, how would you calculate the ROI of a software solution that monitors your website for application security vulnerabilities?A: I would list all the variables of risk and assign priority, weight and value to them. In this situation, you have two kinds of vulnerabilities: vendor-inherent and developer-induced. Many people faced with doing this often forget the training aspects of this situation. You can use your vulnerability assessment to direct training where the same mistakes are being made, such as how to do proper input validation. That alone saves development and QA time.Q: I've read several articles on ROSI, and they all sound great. But when you actually try to implement a quantitative risk analysis, it's easy to get lost in the details. Network security is an especially difficult item. There are a dozen really important mitigations one can implement to protect network availability. How do you calculate ROSI for network security items?A: Establish which mitigative measures are really necessary and which are "nice to have." A lot of the time spent implementing a preventive or mitigative control can have the reverse effect on network performance, which should be taken into consideration as part of the overall factoring. If you find yourself getting buried in details, take a wider view. You can always delve deeper at a later point, once your metrics are in place.Q: Companies continue to buy software from vendors, regardless of whether those vendors have adopted secure coding practices and secure development lifecycles. That said: What is the financial incentive for software vendors to invest in educating their developers, to introduce security into their software development life cycle and to improve their overall security stance? Is risk avoidance the only justification, or are hard-dollar savings and revenue driven by developing more secure code?A: Security has to be viewed as a competitive advantage for companies. Consumers as a whole should demand more from their vendors. Until customers start making security an equal priority with performance and ease of use, vendors will continue to put secure coding on the back burner in order to shorten time to market and remain competitive in their space. Hard-dollar savings to the vendors can be calculated easily by the revenue lost to a competitor that is not releasing 30 security patches a month.Q: What do you find to be the most compelling business argument for investing in security for C-level executives?A: This depends on the C-level executive. Chief marketing officers are likely to have reputational risk foremost in their minds. A CFO will probably think of compliance as the main business case for investing in security. More and more, CEOs are looking at security as a competitive advantage rather than as a necessary evil.Q: All the models for calculating ROSI seem to involve two factors: the probability of an event and the cost if such an event occurs. I find that estimating these is very subjective. Am I missing something?A: You are correct. Unless you've established the necessary metrics applicable to your business model to draw your return estimate, it is very subjective. Especially the first time you try to calculate ROSI. These all become much more accurate over time.Q: Is it possible to accurately quantify ROSI? If so, are there industry standard metrics in place to measure ROSI?A: Yes, it is possible to accurately calculate ROSI, but your calculations are only as good as your metrics. I'm not aware of industry standard metrics for ROSI, but these resources might help you:The Systems Security Engineering Capability Maturity Model: www.sse-cmm.org\/metric\/metric.aspThe Security Metrics Consortium: www.secmet.orgThe National Institute of Standards and Technology's Security Metrics Guide for Information Technology Systems: csrc.nist.gov\/publications\/nistpubs\/800-55\/sp800-55.pdfThe Institute for Security and Open Methodologies' Security Metrics Risk Assessment Values: www.isecom.org\/securitymetrics.shtmlQ: I've heard that net present value is a better gauge than ROSI. Do you agree? What are the main differences? Are there any scenarios in which you'd want to use net present value instead of ROSI? A: This is a another great question, and another one that is difficult to sum up in just a few sentences. NPV is great when you are calculating return based on estimated cash flow and initial investment, but you rarely will see an actual tangible cash flow or return from investing in an area or form of risk management. NPV is used most of the time to justify starting an initiative, and ROSI is used when a security initiative has to be quantified. You might have to do a project whether or not it will show a return at all, but at least with ROSI you can compare to scale among similar projects and investments with greater flexibility. ROSI's flexibility is what gives it purpose.