On November 4, I am going to present at Italy OWASP Day E-Gov 09 OWASP-CONSIP sponsored conference (CONSIP is a company of the Italian Department of Economy and Finance). I will be presenting on the topic of software security initiatives and based upon my experience in this field elaborate on the topic of acquisition and assimilation of software security within an organization. I will start with the good reasons (rationale) for software security such as compliance with standards that explictly call for application and software security assessments such as PCI-DSS, software in-secure root causes, increased level of software security assurance and least but not last costs.I will jump start the presentation with data breaches reported from datalossdb.org and incidents-vulnerabilities correlated data from WHID to make the case for software security root causes of most of cybercrime incidents occurring today. Since the business case has often to be made for senior management such as CIOs that need to sponsor the initiative, it is imperative to follow the main-stream approach that is to refer to what trusted analysts say on software security like Gartner and Forrester as well as to reference basic research such as data from NIST (e.g cause of vulnerabilities and on the economics of in-secure software)The initial case for software security can be created by using criteria that compares the organization's secure software engineering processes with the ones adopted by peer organizations: this can be done with a maturity model by qualifying the capabilities and the necessary context for software security activities.I'll present a roadmap that takes software maturity models as a level of reference to measure which software security effort an organization should be focusing on where to put the effort. A maturity model is in essence a framework of essential activities that once followed can provide consistent results:this is being proved in reality with companies that have adopted and agreed upon the effectiveness of the maturity model.Based upon my experience on CMM, I will provide a mapping of software security activities to the CMM maturity levels: from initial to optimized via repeatable, defined and managed levels of software security assurance. I will provide some reference to software security assurance models and emphasize the importance of the definition of draw the roadmap of software security maturity for the organization. Besides the roadmap, it is important not to forget the essential elements: people, process and tools/technology, people being a factor of adoption and assimilation of software security.I will focus the presentation on metrics and measurements for software security: in essence what we should measure, where and how. I will present essential software security metrics in support of root cause analysis as well as some examples of compliance driven metrics and process and management metrics.After the initiative is started it is important to ensure continuous support from the initiative sponsors and project stakeholders this imply making the case for developer leads, project managers and information security officersOn November 5, I am will be in Milan to present at Italy OWASP Day 4 on the topic of creating business cases for software security initiatives. As there is a need to provide rationale to justify investments on software security intiatives, we need to justify the spending in security from costs and business impact perspectives. The goal of the presentation is help security managers answering questions from management such as why we should spend money for software security, how much we should spend and where.Based upon my experience on software security intiatives roll out, I will talk on which are the main factors that currently drive software adoption for most organizations. To start the business case we need first to make executives and senior management aware of the problem of software security. As in any security initiative, the first step is assessing the status quo and this can be done using a maturity model as a standard way to look at the organization capabilities in critical areas (domains) relative to secure software development such as for example secure software engineering and risk analysis. In essence, a maturity model provides organizations for decision making information on which activities are required to reach pre-determined goals in software security assurance and to show how these goals can be reached by assuming certain capabilities.Besides maturity models, metrics and measurents can be used to validate a need for software security such as for example showing which vulnerabilities are caused by unsecure software (coding errors) instead of design flaws or configuration gaps.Among the several maturity models that can be used I'll mention CMM, BSIMM and SAMM. I will show more in details the use of CMM and the mapping of CMM maturity levels to software security processes. I'll provide a map from CMM L1 (Initial): catch and patch approach to CMM L2 (repeteable): as reactive penetration testing and/or only for high risk apps (non projects) to CMM L3 (defined) as ethical hacking/security testing process defined for each project with gathering of vulnerability metrics for risk assessments. At CMM L4 (managed) it is expected that your organziation would be able to manage software security risks across all the SDLC and make informed decision at each phase, factoring defect management costs and be able to improve the quality of the security assessments. At CMM L5 (optimized) your company should be able to optimize software security processes for increased return of investments, find gaps and cost savings and risk reduction opportunities.In my experience, after a self assessment of maturity your company will get the picture of where is and identify what are the suggested improvements according to a standard roadmap. I'll refer to CMM because is the one I am most familiar with and because CMM is is currently already done by most large organizations covering several domains such as business, customer, financial, training, risk management besides software engineering processes.One aspect that I am very keen covering in the presentation is the concept of the maturity curve: this is similar to the learning curve and it shows where the effort required for reaching the software security capability level is the highest that is to pass from CMM level 3.5 to 4 that is from proactively define a process like software risks assessment to manage them across the SDLC for each product at organization wide level. The maturity level curve provides also a time frame for reaching software security maturity. In my experience, drafting the maturity curve helps planning and set up the right expectations. In large organizations, for example software security processes are not acquired and assimilated overnight but over the course of several years expecially when the sofwtare security initiative impacts several business units with several SDLCs as well as thousands of web applications.I will then step into the core of the presentation that are the business cases, starting with awareness of secure software engineering quoting Russ Anderson definition and then walking the audience on the how to respond to FAQ related as the “why” for software security initiatives.Preparing a qualifying answer for software security means to provide an analysis to back the point. The methods I am suggesting are cost vs. benefit analysis, assumption costs vs. failure costs, quantitative risk analysis and ROSI. The key in this analysis is to estimate the costs and the most difficult cost to quantify are the failure costs such as the ones due to business impact deriving from a data breach or fraud.I'll provide some methods for derive a rough estimates of data loss liability estimates using FTC data. I will also use data from public sources such as datalossdb.org and WHID to estimate a probability of a data loss related to a web application exploit such as SQL injection. For the impact, I will refer to a population of hundred of millions of records of sensitive information such as credit cards and I will use this data to estimate the business impact and compare these estimates with the ones reported in public sources.Other business case can be based upon quantitative risk analysis. In the presentation, I will show how to use quantitative risk analysis to justify software security spending: this is based upon an estimated annualized value of loss. This is a widely known formula, some nothing new here but the problem is not the formula per se but the data, therefore the method of the analysis is as good as the data. I will provide rough estimate of ALE (Annual Loss Expectancy) based upon data from public sources to calculate the probability of attack and by factoring the exposure factors as well as the single loss expectancy.The last methodology that I will use to make the business cases will be in terms of ROSI (Return Of Security Investement) of software security. I will refer to previous studies that quantify savings in security software engineering activities comparing with catch and patch activities (Soo Hoo IBM stufy). I''ll use ROSI to justify investment for software security activities in terms of cost savings that the intiative will provide comparing with the costs of the initiative.Finally, I will cover which kind of metrics can be used to support the business cases. As the business case is initially made with estimated engineering and security data, it needs to be supported with measurements on the fields. This metrics need to show management that the software security initiative provides value to the shareholders and that is aligned with other company goals and values such as financial value for the company, value for the company customers, value for the internal business processes and value for learning and growth.
On November 4, I am going to present at Italy OWASP Day E-Gov 09 OWASP-CONSIP sponsored conference (CONSIP is a company of the Italian Department of Economy and Finance). I will be presenting on the topic of software security initiatives and based upon my experience in this field elaborate on the topic of acquisition and assimilation of software security within an organization. I will start with the good reasons (rationale) for software security such as compliance with standards that explictly call for application and software security assessments such as PCI-DSS, software in-secure root causes, increased level of software security assurance and least but not last costs.
I will jump start the presentation with data breaches reported from datalossdb.org and incidents-vulnerabilities correlated data from WHID to make the case for software security root causes of most of cybercrime incidents occurring today. Since the business case has often to be made for senior management such as CIOs that need to sponsor the initiative, it is imperative to follow the main-stream approach that is to refer to what trusted analysts say on software security like Gartner and Forrester as well as to reference basic research such as data from NIST (e.g cause of vulnerabilities and on the economics of in-secure software)
The initial case for software security can be created by using criteria that compares the organization's secure software engineering processes with the ones adopted by peer organizations: this can be done with a maturity model by qualifying the capabilities and the necessary context for software security activities.
I'll present a roadmap that takes software maturity models as a level of reference to measure which software security effort an organization should be focusing on where to put the effort. A maturity model is in essence a framework of essential activities that once followed can provide consistent results:this is being proved in reality with companies that have adopted and agreed upon the effectiveness of the maturity model.
Based upon my experience on CMM, I will provide a mapping of software security activities to the CMM maturity levels: from initial to optimized via repeatable, defined and managed levels of software security assurance. I will provide some reference to software security assurance models and emphasize the importance of the definition of draw the roadmap of software security maturity for the organization. Besides the roadmap, it is important not to forget the essential elements: people, process and tools/technology, people being a factor of adoption and assimilation of software security.
I will focus the presentation on metrics and measurements for software security: in essence what we should measure, where and how. I will present essential software security metrics in support of root cause analysis as well as some examples of compliance driven metrics and process and management metrics.
After the initiative is started it is important to ensure continuous support from the initiative sponsors and project stakeholders this imply making the case for developer leads, project managers and information security officers
On November 5, I am will be in Milan to present at Italy OWASP Day 4 on the topic of creating business cases for software security initiatives. As there is a need to provide rationale to justify investments on software security intiatives, we need to justify the spending in security from costs and business impact perspectives. The goal of the presentation is help security managers answering questions from management such as why we should spend money for software security, how much we should spend and where.
Based upon my experience on software security intiatives roll out, I will talk on which are the main factors that currently drive software adoption for most organizations. To start the business case we need first to make executives and senior management aware of the problem of software security. As in any security initiative, the first step is assessing the status quo and this can be done using a maturity model as a standard way to look at the organization capabilities in critical areas (domains) relative to secure software development such as for example secure software engineering and risk analysis. In essence, a maturity model provides organizations for decision making information on which activities are required to reach pre-determined goals in software security assurance and to show how these goals can be reached by assuming certain capabilities.
Besides maturity models, metrics and measurents can be used to validate a need for software security such as for example showing which vulnerabilities are caused by unsecure software (coding errors) instead of design flaws or configuration gaps.
Among the several maturity models that can be used I'll mention CMM, BSIMM and SAMM. I will show more in details the use of CMM and the mapping of CMM maturity levels to software security processes. I'll provide a map from CMM L1 (Initial): catch and patch approach to CMM L2 (repeteable): as reactive penetration testing and/or only for high risk apps (non projects) to CMM L3 (defined) as ethical hacking/security testing process defined for each project with gathering of vulnerability metrics for risk assessments. At CMM L4 (managed) it is expected that your organziation would be able to manage software security risks across all the SDLC and make informed decision at each phase, factoring defect management costs and be able to improve the quality of the security assessments. At CMM L5 (optimized) your company should be able to optimize software security processes for increased return of investments, find gaps and cost savings and risk reduction opportunities.
In my experience, after a self assessment of maturity your company will get the picture of where is and identify what are the suggested improvements according to a standard roadmap. I'll refer to CMM because is the one I am most familiar with and because CMM is is currently already done by most large organizations covering several domains such as business, customer, financial, training, risk management besides software engineering processes.
One aspect that I am very keen covering in the presentation is the concept of the maturity curve: this is similar to the learning curve and it shows where the effort required for reaching the software security capability level is the highest that is to pass from CMM level 3.5 to 4 that is from proactively define a process like software risks assessment to manage them across the SDLC for each product at organization wide level. The maturity level curve provides also a time frame for reaching software security maturity. In my experience, drafting the maturity curve helps planning and set up the right expectations. In large organizations, for example software security processes are not acquired and assimilated overnight but over the course of several years expecially when the sofwtare security initiative impacts several business units with several SDLCs as well as thousands of web applications.
I will then step into the core of the presentation that are the business cases, starting with awareness of secure software engineering quoting Russ Anderson definition and then walking the audience on the how to respond to FAQ related as the “why” for software security initiatives.
Preparing a qualifying answer for software security means to provide an analysis to back the point. The methods I am suggesting are cost vs. benefit analysis, assumption costs vs. failure costs, quantitative risk analysis and ROSI. The key in this analysis is to estimate the costs and the most difficult cost to quantify are the failure costs such as the ones due to business impact deriving from a data breach or fraud.
I'll provide some methods for derive a rough estimates of data loss liability estimates using FTC data. I will also use data from public sources such as datalossdb.org and WHID to estimate a probability of a data loss related to a web application exploit such as SQL injection. For the impact, I will refer to a population of hundred of millions of records of sensitive information such as credit cards and I will use this data to estimate the business impact and compare these estimates with the ones reported in public sources.
Other business case can be based upon quantitative risk analysis. In the presentation, I will show how to use quantitative risk analysis to justify software security spending: this is based upon an estimated annualized value of loss. This is a widely known formula, some nothing new here but the problem is not the formula per se but the data, therefore the method of the analysis is as good as the data. I will provide rough estimate of ALE (Annual Loss Expectancy) based upon data from public sources to calculate the probability of attack and by factoring the exposure factors as well as the single loss expectancy.
The last methodology that I will use to make the business cases will be in terms of ROSI (Return Of Security Investement) of software security. I will refer to previous studies that quantify savings in security software engineering activities comparing with catch and patch activities (Soo Hoo IBM stufy). I''ll use ROSI to justify investment for software security activities in terms of cost savings that the intiative will provide comparing with the costs of the initiative.
Finally, I will cover which kind of metrics can be used to support the business cases. As the business case is initially made with estimated engineering and security data, it needs to be supported with measurements on the fields. This metrics need to show management that the software security initiative provides value to the shareholders and that is aligned with other company goals and values such as financial value for the company, value for the company customers, value for the internal business processes and value for learning and growth.
