How a process model can help bring security into software development

Very good article about SSDLC (Security Enhanced Software Development LifeCycle). It should be mandatory reading for promoters of SSDLC initiatives within organizations. This article (third in the series on the secure software lifecycle) captures some of my previous work around the concept of the (SSF) Software Security Framework. The SSF was conceived as framework to integrate security within the (SDLC) Software Development Lifecycle as well as with existing information security and risk management processes. The idea of the SSF originated in 2005 while working with clients of Foundstone (the security consulting company that was acquired by McAfee in 2004) mostly financial institutions and telcos and presented at Blackhat USA Conference in 2006.


Software Security Framework

In general, I have to give credit to the idea of the SSF to the CISOs that I worked for back then as consultant like Mr. Denis Verdon. I also have to thank Mr. Joe Jarzombeck PMP Director Of Software Assurance at the National Cyber Security Division at the Department Of Homeland Security (DHS) for capturing my contributions in the first SSDLC DHS document as well as the SMEs such as Mrs. Karen Mercedes Goertzel at the IATAC (Information Assurance Technology Analysis Center) to document the SSF in the 2007 State of The Art Report of Software Assurance. More recently the idea of SSF evolved thanks to the work of Dr Gary McGraw CTO of Cigital in the context of software security maturity models as framework of software assurance best practices within software maturity model domains

OWASP Italy Day 4 Software Security Initiatives Conference Presentation Videos

OWASP Italy has published the videos of the conference on Software Initiatives held in Milan and Rome, Italy last November

The videos for the Milan conference can be reached at the following OWASP Day 4 Italy Page

From the OWASP page you can also download my two video webcasts (Italian language over English slides) of the related conference presentations (1) Guidance for starting software security initiatives within your organization and (2) business cases for software security initiatives

OWASP Italy

An hearth felt thank-you to the OWASP Italy organization and for putting this together, expecially to Matteo Meucci OWASP Italy Chair and Giorgio Fedon, Chief Operation Officer Minded Security.

If there is interest in having these webcasts also in English please contact me directly, thanks

Business Cases For Software Security Initiatives, Maturity Models and Security Costs Analysis

On November 4, I am going to present at Italy's OWASP Day E-Gov 09 OWASP (Open web Security Project) and CONSIP (a company of the Italian Department of Economy and Finance)security conference on the topic of software security initiatives. In my presentation , I am going to address first the pre-requisites for the software security initiative:

1. Compliance with information security standards (e.g. PCI DSS);
2. Education and awareness on root causes of vulnerabilities in applications/software;
3. Software security engineering benchmarking using a software security maturity model;
4. Business cases to justify budget and investments in software security. 

Since the initial cases for software security initiatives are often made for the senior management (the sponsors of the initiative), it is important to make the appropriate business cases and use the so called "drivers" for software security adoption such as executive level reports from Gartner, Forrester as well as public research on software security from NIST, SEI, DHS. Examples of good resources include NIST research on the causes of vulnerabilities and on the economics of in-secure software and Gartner press releases on economic impact of software security.

The next step is to assess the organization's secure software engineering processes and capabilities using a standard such as a Software Security Maturity Model (SSMM): the objective is to make the sponsors of the initiative aware of the organization's capabilities in secure software engineering, risk management, governance and training

BSIMM SSF

The recently (2009) published Build Security In Maturity Model (BSIMM) from Dr. Gary McGraw and the Software Assurance Maturity Model (SAMM) from Mr. Pravir Chandra can help organizations in the assessment, planning and implementation of software security initiatives. These models are explictly designed for software security assurance and are based upon real data (surveys) from companies that actually had enacted and implemented software security initiatives. The models are organized along similar domains (e.g. governance, intelligence, SSDL touchpoints, deployment for BSIMM and governance, construction, verification, deployment for SAMM) each domain has three best practices and three levels of maturity. BSIMM's 12 best practices have a total of 110 sofwtare security activities and maturity levels that can be achieved by assigning goals and objectives to each activity.

A traditional maturity model such as the Capability Maturity Model (CMM) can also be mapped to levels of software assurance even if is primarly designed to assess maturity for software quality assurance, engineering and other organization domains. More specifically for the security domain, the System Security Engineering Capability Maturity Model (SSE-CMM) addresses maturity of security systems as a whole not software security in particular but based upon my previous professional experience on the System Security Engineering-Capability Maturity Model (SSE-CMM), it is possible to map software security activities to CMM maturity levels and provide a roadmap for software security maturity.

For example it is possible to map software security from the initial (level 1) to optimized (level 5) via repeatable (level 2), defined (level 3) and managed (level 4) levels of software security assurance. The mapping of software security activities for each level need to include main security domains such as:

1. Software Risk Analysis & Management
2. Software Security Engineering
3. Security Assessment Processes and Tools
4. Security Training & Awareness.

In my presentation, I provide the mapping of CMM maturity levels to software security processes starting from security testing (in BSIMM this domain is referred as SSDL touchpoints domain and in SAMM as verification business function) since for most organizations the evolution toward software security starts from application security assessments such as web application pen testing and then evolves to secure code analysis, threat modeling as well as other supporting best practices such as metrics and measurements, risks management, software security training and awareness.

One fundamental element of any maturity model is the definition of the software security roadmap that provides the set of standard activities that bring an organization to a certain capability level in software security that can measured both qualitatively and quantitatively.

For example an organization can start at CMM Level 1 (Initial) with a catch and patch approach, move to CMM Level 2 (repeteable but reactive) by ethical hacking existing applications.

An organizaiton can reach CMM Level 3 (defined and proactive) by defining a security testing process such as vulnerability assessment as part of the SDLC that is adopted for security assessing vulnerabilities for each web application project at the organization level.

At level CMM 4 (managed) organizations are capable to risk manage projects with checkpoints in all the SDLC phases (e.g. asserting security by design, development and deployment) and by using vulnerability metrics to make informed risk management decision at each checkpoint.



Software Assurance Maturity Curve And CMM Levels

At level CMM 5 (optimized), organizations have optimized software security processes for increased return of security investment, security cost savings and improved risk mitigation/reduction.

One essential factor for achieving maturity is understanding the concept of the maturity curve: this is similar to the learning curve to mature in knowledge and skills: a maturity curve shows that time is needed to acquire maturity. Since the maturity level curve provides the time frame for reaching software security maturity, it helps planning and set up the right expectations to management and also factor the costs.

For example, according to the maturity curve, the effort required to an organization for passing from CMM level 3.5 to 4 is the highest hence only few large organization can afford the cost that is required.

This costly step coincides from proactively define a software security process and manage it thought the SDLC for each product at organization wide level. From the time perspective for example software security processes are not acquired and assimilated overnight but over the course of several years especially when the sofwtare security initiative impacts several business units with several different SDLCs as well as hundreds of web applications to risk manage.

One of the factors most critical to the success of software security initiatives are the metrics and measurements: only by the definition of what we should measure, where and how it will be possible to manage software security risks and assess the organization maturity in acquisition and assimilation of software security best practices.

The essential software security metrics for a successfull software security include process and vulnerability management metrics, vulnerability root cause analysis, governance and the risk analysis.

On November 5, I will be in Milan to present at Italy OWASP Day 4 on the business cases to justify investments on software security initiatives such as the spending in software security: the goal of this presentation is help security managers in answering questions from senior management such as how to justify the security budget such as why we should spend money for software security, how much we should spend and where.


In a nutshell this means quantify the business case for software security in terms of security costs such as cost vs. benefit analysis, assumption costs vs. failure costs, quantitative risk analysis and Return of Security Investments (ROSI).

The key in the analysis is to be able to estimate the software security failure costs such as the ones due to business impact deriving from a data breach or fraud. For most organizations this is a daunting task because these data are not available, hence I am suggesting an approach that uses public sources to estimate such costs such as reported data breaches from FTC (Federal Trade Commission), data loss incident data from datalossdb.org and correlation of incidents to vulnerabilities from the Web Hacking Incident Database (WHID).

Quantifying failure costs is essential for determining the benefits of security initiatives so can be justified using cost vs. benefit analysis. In the presentation I show how assumption costs (cost that your organization assume for software security initiatives) correlate to failure costs (costs that the organization incur because of insecure software) to an increased level of software security assurance: the objective is to justify an investment in software security by monetize the security costs.

Optimized Software Security Costs

Some studies that use cost vs benefit analysis show that when the cost of a security investment is around an optimal value of 30-40% of the overall failure costs, the security cost can be justified.
This can be desumed by optimizing the overall costs when factoring the cost of security failures and the cost of security measures.

Another method for justifying software security costs consists on using quantitative risk analysis. Quantitative risk analysis allows to estimate the annualized impact of loss such as the one due to a cause of insecure software such as SQL injection. For example it is possible to calculate a rough estimate of ALE (Annual Loss Expectancy) for a SQL Injection attack by calculating the probability of such attack occurring based upon data of the reported incidents. As data loss from FTC (US Federal Trade Commission) show that the probability of a company incurring in a data loss of PII is about 4.5% the probability of a data loss due to web channel and because of SQL injection is about 2.5%. The business impact can be quantified in terms of FTC estimate for each record of a data loss to be about 655 $/per lost record and multiplied by the number of records that can be potentially be lost to estimate the overall asset value that can be lost. This value can be multiplied by the probability of the loss to calculate the liabitility for the company. According to FTC data, in the case of a generic data loss for example (e.g. probability of 4.5%) the liability for a company of each PII record loss is about 35 $/record.

Another security cost analysis method is to evaluate the cost savings to the company by the introduction of the software security initiative by calculating the ROSI (Return Of Security Investment) of software security. I will refer to previous studies (Soo Hoo IBM study) that use ROSI to justify investment for software security activities as well as to use a standard ROSI formula (SonnenBerg) and previously computed ALE (Annualized Loss Expectancy) to determine the ROSI. According to Soo Hoo study it is shown that comparing software security assessments such as threat modeling, source code analysis and pen test, threat modeling provides the highest return of the investment since is done earlier in the SDLC: is you spend $ 100 K in a software security initiative, 21% will be saved if you adopt threat modeling for example.

Finally, I will cover the dashboard metrics can be used in support the business cases to different shareholders in an organization. As the business case is initially made with estimated engineering and security data, it needs to be supported with measurements on the fields. This dashboard 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.



Business Cases For Your Software Security Initiative

I dealt with the topic of the business case for software security initiatives in the past: you can refer to published articles (ISSA Journal 2006, In-secure Magazine 2008) and presentations(Black Hat in 2006 and OWASP in 2008). Interesting enough, this seems to be still an hot topic: I am often inquired on this by CISOs and CIOs in the past as well in my current ISO work, hence I decided to articulate my answer again with more details with this post.

Building software security into the organization’s software engineering and information security practices can be accomplished by following software security maturity models (e.g. BSIMM or SAMM) as well as by adopting software frameworks to integrate software security activities within the SDLC along with security processes such as information risk management, patch management and security training and awareness.

From the software engineering perspective for example, the assumption is that your organization already measures the costs for fixing software security failures due to known vulnerabilities as well as the cost of fixing the ones resulting from incidents/exploits. Total software security failure costs include both the cost of business impact in exploiting software failures (e.g. cost of a vulnerability exploit that caused harm to the organization such as denial of service) as well as the cost to fixing a known defect due to a security issue found with testing, being a security bug, a design flaw or a mis-configuration.

The problem of the software security metrics is that implies that the organization software and information security practices are matured enough to produce this data so you can correlate this information from risk management, fraud management, vulnerability assessment, software engineering/project management and quality assurance. The availability of such metrics implies that development teams have already started to build software security activities into the SDLC such as source code analysis, penetration testing, threat modeling but also that they have started working together with security teams to measure software security risks and manage them during the different phases of the SDLC.

A pre-requisite for any software security initiative business case is the availability of the organization's information risk data that include risk management, vulnerability metrics as well as software security engineering data such as defect management and patch management.

From information security perspective, the business case for software security need to start from the organization's information risk management data, business impact analysis and correlate application vulnerabilities as critical when these correlate to business impacts. For this reason (i.e. the lack of organization software security data) the business case for software security is one that is hard to make.

Based upon my experience on the topic, that is working both as consultant as well as security technology officer for large software organizations, you can make the business case (or the case for the business) for software security initiative by following the approach outlined herein:
1) Adopt an information risk management perspective, that is using your vulnerability, incident and fraud data for the business case
2) Gather software engineering data and categorize them in terms of when are found, when are fixed, when the fixes are tested and deployed. Correlate this data on how much it costs to fix vulnerabilities at different phases of the SDLC.
3) Gather data on security incidents and fraud because of the application/software being attacked. Quantify in dollar amount how much these security incidents and fraud cost to your organization.
4) Analyze the business case by analyzing/quantifying the following factors:
• Cost vs. benefit: by comparing software failure costs vs. security assumption costs
• Quantitative risk: by comparing cost of mitigation vs. impact of probable loss
• Return of Security Investment (ROSI): by quantifying $$ saving amounts for adoption of software security activities early in the SDLC

Basically the business case for the software security initiative needs the data that the initiative is suppose to provide. In essence this is a chicken vs. egg problem you can only manage what you measure and you need metrics to make the business case for.

So what are the alternatives for the business case in absence of such data ? You need to make assumptions on what are you software engineering costs, estimate the cost of patching and to fix vulnerabilities as well the security costs because of software failing such as for example financial losses that vulnerability exploits might cause, include for example the cost of loosing customer data, money losses because of fraud via the web channel, disruption or denial of service and least and not last intangible reputation loss because of vulnerabilities being publicly disclosed.

The data to produce for the case depends on who the case is made for. If the business case needs to be made for engineering and software development teams for example, you can assume a software engineering perspective. You can refer to public studies that analyze the cost of fixing software defects.

A NIST study on the economic impact of insecure testing for example shows that cost of fixing defects is 100 times more expensive during system testing than coding. You can tailor this data to estimate how much it would cost to your organization fixing vulnerability from quality/defect management perspective. If development teams already started doing vulnerability assessments such as by including web application penetration testing in the SDLC, the vulnerability metrics can also be used and correlated with the cost of fixing them.

If your organization is mostly relying on patching to fix security defects, you can refer to the cost of producing security patches (e.g. hotfixes) to fix vulnerabilities vs. the cost saving of testing and fixing software security defects earlier in the SDLC.

Let's say the cost of engineering, developing, testing and deploying a patch to your vulnerable software/web application is 10,000: it is realistic to estimate using NIST data that the fixing this patch earlier in the SDLC would have cost you 10% of the patching costs and your company 90 % of overall patching costs (e.g. 9,000 $)

Just including patching costs is not conservative enough for a real estimate of total software security failure costs: you need also to include the business impact of exploits such as either the risk of exploiting a known vulnerability or an unknown vulnerability (e.g. Zero Day) such as the ones exploited and do not follow responsible public disclosure causing the organization intangible costs..

Even in absence of a vulnerability exploit it is still important to factor the cost posed by the business impact to the organization caused by the exploit of the vulnerability. In the case of intangible costs for example what is the intangible cost of cross site scripting vulnerability publicly disclosed on XSSEd.com site? How much is the cost of reputation damage to have such vulnerability publicly disclosed? Any public published vulnerability can cause intangible loss to company reputation, the company brand and the franchise and affect customer confidence on the company product and services.
Would intangible costs by themselves justify the existence of a responsible disclosure process to engage security researchers that have found your site vulnerabilities: YES. Would this justify fixing all known vulnerabilities before going into production with a penetration test? YES

But to really factor software failure costs as the business impact of exploiting a vulnerability it is important to correlate attacks with vulnerabilities and the business impact that cause. The recent data from the Web Hacking Incident DB that correlates public information from security incidents with web application attack vectors for example has SQL injection as #1 (19% of all attacks) that includes manual targeted attacks as well as mass SQL injection bots. From the perspective of attack vs. risk prioritization SQL injection vulnerabilities represents the ones that most likely will be exploited to cause harm to your organization and are the ones that would produce high failure costs (e.g. use for break into authentication, upload malware, denial of service, un-authorized access to sensitive data), when mitigated, SQL injection vulnerabilities would provide the most benefit in terms of mitigating business impacts.Since the SQL injection vulnerabilities root cause is coding such as using concatenated SQL statements instead of store procedures or prepared statements, fixing SQL injection vulnerabilities in the code alone would make the case of adopting secure code reviews.

Most organization's directors of technology and security try to sell technologies and new initiatives to high management with the sales pitch of getting the most "Bang For The Buck" BFTB. But the BFTB business case need to answer the basic question: if I spend that much on a security technology or process what is the benefit for security ? In technical terms this means doing a Cost vs Benefit Analysis (CBA). CBA can be used in security to correlate the total cost of security to increased information or software security assurance. Dan Geer covers well this analysis as related to data security in his book "Economics and Strategies of Data Security".

By analogy, in the case of software security, "Bang For The Buck" decision spending need to take into account the total security costs that is all failure costs such as the total cost of failing as business impact as well the total cost of finding, fixing, testing and deploying the security defect. Only then, the total cost of software security (the BUCK) can be compared against the BANG that is the increased level of software security assurance.

The general law for bang for the buck is that you are getting the most bang for the buck when your total costs (cost of failure/data loss/fraud + cost of security/countermeasure) reaches a minimum. As failure costs decrease exponentially, the "anticipation costs" that you take proactively by spending in software security initiatives will increase.

From risk management perspective this means that the total software security costs decrease up to a minimum to raise again as you keep spending on security measures. You will reach an optimal cost vs. benefit where more spending in anticipation cost (e.g. countermeasures) will not provide the most benefit (e.g. spending more in countermeasures then the value of the assets that the countermeasure is supposed to protect)

This optimal spending for anticipation costs (proactive countermeasures) is about 40% of your failure costs (to be exact 37% according to Gordon and Loeb research: The Economics of Information Security Investment).

According to the empirical law of the most bang for the buck applied to software failure costs vs. assumption costs it is therefore fair to assume that you get the most of security by spending 37% of what your software failure costs are.

Assume for example software security failures costs are $ 10 ML it would be reasonable for an organization to spend as much as $ 3.7 ML in acquiring software security tools and technology, develop new software security process as well as in new software security training activities.

Application security failure costs can be also factored as monetized fraud occurring via your web site/channel: a spending of as much as 37% of the fraud costs in securing the web site can be justified according to the most bang for the buck law.

In the case of business impact due to data loss such as identity theft for example, you can factor the overall fraud related to data loss potentially impacting your organization: consider that 14% of all publicly reported data loss incidents occur via the web channel according to the data collected from datalossdb.org.

Assume that according that 2003 FTC data the potential loss per identity theft incident is $ 655 per incident. Assume you are serving via your web site a population of 4 million customers, the potential loss of losing your customer data such as credit card accounts for example would be of $ 2,6 Billion and with probability of identity theft occurrence of 4.6 % (also FTC data) the projected loss for your company could be $ 120 ML for which 14% or $ 16 ML would be the cost of data losses via the web channel alone.

With these assumptions based upon publicly disclosed data losses, a security program (that include both information and application security) that cost as much as $ 16 ML would be justified for a company with a customer base of 4 million on-line customers for example.

A quantitative risk assessment can also be used to determine the extent on which a software security initiative can reduce risk from potential losses. The correlation has to take into account the probability of the event and the loss that the event can cause. This is difficult to quantify in general for software security issues since assumes a cause-effect between vulnerability exploit and financial impact. Nevertheless it can be used for rough estimates.

Assume a web application that delivers banking services for example and that the loss caused by an event such as denial of service impact on-line transactions for 3 million customers with an average of $ 20 per transaction: the loss per single DOS event (SLE) is $ 60 ML.

Assume that the probability that a new SQL injection vulnerability would cause a denial of service is 30% (Annualized Rate of Occurrence) then the Annual Loss Expected (ALE) is $ 1.8 ML. If the cost of the new security countermeasures that will stop the security incident is less than $ 1.8 M than the organization should implement it.

Assume the countermeasure in this case is the total cost of secure code reviews, you need to factor the cost of tools and technologies/APIs (e.g. source code analysis and penetration tools), of the security engineering process (e.g. documentation and metrics) as well of software security training and awareness for developers. The tools and technologies need to include the Total Cost Of ownership that is both the cost of acquiring and maintaining the technology.

Besides cost vs benefit analysis and quantitative risk assessment, the return of security investment (ROSI) can be used to make the software security business case around effectiveness of a software security initiative.

ROSI answers the question if I spend $ 100K in software security initiative do I save more money by fixing defects with a penetration test, secure coding or threat modeling. Again this is where the metrics is essential:making the case with ROSI assumes you already collect SDLC data that show how much it cost to perform software security per each phase, the number of issues being identified at each phase and the how many are fixed at each phase you can make the business case for an activity vs another. Otherwise you can reference public study of ROSI from Kevin Soo Study " for every $ 100,000 spent on software security, $ 21,000 are saved by doing application threat modeling during design, $ 15,000 are saved by doing source code analysis and $ 12,000 are saved when defects are found with penetration tests. Overall the earlier you invest in security the greater the return.

Producing Secure Software With Software Security Enhanced Processes

On behalf of OWASP and as a PR for the organization I wrote an article for the April edition of in-secure magazine: Producing Secure Software With Software Security Enhanced Processes. Besides evaluating the pro and cons of different software security enhanced process models such as MS-SDL, OWASP-CLASP and Cigital-Security TouchPoints, I deal with the basic steps of the process that are 1) assessment of the software engineering and information security processes currently used by the organization, 2) implementation of the process models within the software security framework, 3) software security metrics and measurements. Regarding the assessment I deal with maturity levels and I published a maturity level curve that I took from the old CLAPS methodology as a reference (herein included). The maturity curve depicted in the article comes from old CLASP documentation that dates back to when CLASP was owned by Secure Software. The reason I put that figure in the article is to make the point that security activities can be effectively built into the SDLC if tied to reaching capability maturity levels. This is based upon my experience in rolling out software security framework for large financial organizations. The concept is very intuitive “per se”, some activities like metrics and measurements require higher maturity level then others. Others like training and awareness are pre-requisite to achieve maturity and allow the adoption of other activities such as secure code reviews for example. I had recently done an extensive work on mapping software security roadmap to the maturity levels assessed for the financial organization I currently work for. Such CMM takes into account SDLC methodologies, risk management processes as well as security tools and training and awareness levels across all departments within the organization. The maturity exercise helps in setting a roadmap to determine what can be achieved in the short term and in the long term and at which cost. A reader of my article, Dan Fiedler suggested to map CLASP, MS SDL and TP to the maturity curve. I think this can be very useful in terms of comparison of what maturity levels can be achieved using different models making some assumption to the adoption spread within the organization.

Current Industry Best Practices for Software Assurance: SAFECode



From Leigh Honeywell Presentation on Writing Secure Software
Source http://www.globalnerdy.com/tag/leigh-honeywell/



The Software Assurance Forum For Excellence in Code (SAFECode) has recently published a white paper on the software industry best practices for software assurance. The forum is lead by Paul Kurtz. Before SAFECode Mr Kurtz successfully led the Cyber Security Industry Alliance (CSIA) to raise the awareness on information security assurance by coordinating the effort with network security vendors such as ISS, Symantec, RSA and others. Now Mr. Kurtz leads the software security assurance forum of software security vendors such as EMC, Juniper, Microsoft, SAP and Symantec. Michael Howard of Microsoft is also chair of the Development Processes working group within SAFEcode. Quoting Michael on his blog:" SAFECode is a great example of "industry helping industry," because it is led by people who have "been there, done that" and have the battle scars to prove it".

The whitepaper on software security provides guidance to software vendors on software security disciplines that should be followed to build, deploy and support security into software products.

I summarized herein the disciplines, with emphasis on the best practices:

1. Train application developers on software security issues
2. Define the security requirements including for secure design, coding and tests of a product early during the Software Development Lifecycle (SLDC)
3. Enforce security by design by identifying design flaws and addressing potential threats to the application with countermeasures so that risks can be mitigated before coding
4. Follow secure coding best practices and secure coding standards during product development
5. Protect the integrity and the confidentiality of source code being developed from un-authorized changes and disclosure of intellectual property
6. Security test products/applications to verify that the meet security requirements as early as during design as well as during implementation
7. Document the software and vulnerability managament processes such as how software vulnerabilities found by others can be disclosed and how the application/product need to be configured and deploy the product securely
8. Validate and document security risks such as with a security control gap analysis prior product release
9. Document how to handle any potential vulnerabilities security incident response processes, notify incidents to the appropriate team and mitigate the vulnerabilities
10. Enforce trustworthy use of software. Offer customers a way to verify that the product being acquired indeed comes from a trusted vendor
11. Research on new software threats and countermeasures
12. Evangelize software security by promoting use of software assurance best practices and by discussing these in open forum as well as publishing of articles, papers and books.

The whitepaper can be found here :http://www.safecode.org/publications/SAFECode_BestPractices0208.pdf

On the resource page of SAFECode site you can also download the current "state-of-the-art" in software security assurance that collects recommendations and best practices for building software security into the SDLC and in particular a more in-depth variety of techniques and technologies in use in government, industry, and academia for specifying, acquiring, producing, assessing, and deploying secure software.

In some sections of this document there are references of my previous work on Software Security Frameworks that I did on behalf of Foundstone as well as references to this blog. Even if I am not working for a software vendor anymore (last time was between 1998-2001 developing software for ISS) I am practicing most of these software security best practices in my day to day working activities and I also advocate for software security initiatives within the bank(Citigroup) where I currently work for as Technology Information Security Officer . On point 12 in particular, I am committed to evangelize software security on this blog and through OWASP, publications and participation to conferences etc.

Building the case for software security within your organization

Cost vs benefit ratios, source
http://webinsecurity.blogspot.com/

Just came across a video clip on last year turbo talk I did at Black Hat.

http://www.findinternettv.com/Video,item,1249009004.aspx

As I look back to this presentation and the concepts I pioneered back then (Software Security Framework) , I see that these are still very valid concepts today. If I had to do the speech again, maybe I'll introduce some new concepts. I would probably cover the risk data driven approach and put software security in the frame of the organization maturity levels CMM (Capability Maturity Model).

I'll also try to understand better the audience to tailor my talk. My BH turbo talk was intended for information risk managers with high visibility on information security processes. Since at the end of my presentation someone asked me a question on threat modeling frameworks, that make me think that I should have talk more in detail about software security activities and methodologies on how to implement them. Overall, the effectiveness of the presentation, besides the presenter skills, really depends on target the content to the right audience. If I had to talk of software security to project managers I will put the emphasis on missed deadlines on product delivery because of fixing vulnerabilities and how software security can help. If I had to talk to developer managers/architects I will probably present "how to" use case scenario for software security implementation showing use/misuse cases, architectural risk analysis, secure code reviews, source code analysis tools, security unit tests, security system tests, vulnerability management and remediation.

The scope of the 06 BH presentation was really to build the case of software security to CIOs.

So if you are looking for a software security recipe for a CIO dinner, based upon my experience (e.g. in consulting and now as information security officer) this is the one I'll use:

1) explain how software security is different from information and application security (apples and oranges)

2) make the software security risk management case using your risk data (e.g. 30% of vulnerabilities are LHF that can be fixed with better coding and source code analysis early in the SDLC instead of penetration tests in UAT and production ). If you do not have risk data use public and unbiased sources (e.g. NIST, SANS, Gartner, Forrester)

3) assess the maturity level of software security and position it on the organization CMM framework. If you do not have a CMM framework, position it on a general one.

4) make the business case using your cost center data (cost me 100 man/hrs to fix a cross site scripting vulnerability that I could have avoided by implementing secure coding standards and catch it with source code reviews and unit tests)

5) suggest both strategic (long term) and tactical (short term) solutions

6) suggest short term solutions as "stop the bleeding" kind of activities (e.g. penetration test with common vulnerability check lists, source code analysis for projects in the development phase, threat modeling for projects in the requirements and design phase)

7) recommend long term strategic solutions (e.g. ad-hoc software security frameworks, software security enhanced SDLCs methodologies)

And I stop here not because of the magic number (7) that we remember but because if your start with this you should be in the right path to build your case. Now is a good meal sufficient to made the case? Well depends. Check what the CIOs say after tasting it? Are my CIO more sensitive to tool pushing agendas or security policies/standards? Are they driven by the bottom line? (i.e. costs) Are they driven by risk analysis and the risk data? To be effective in building the case, we have to understand what CIO taste is (e.g. needs, concerns, technology, people, processes) and then build the case for it. Therefore a session after the presentation to capture feedback and explain further your point is very important.

Ultimately, I should remind you of my golden formula for security:

Security = Commitment * (Policies.Standards.Frameworks.Guidelines^2+ Procedures.Technologies.Tools)

With commitment being NULL (e.g. the people component!) there is no security as you can see from the empirical math. So to build the case you need to focus on the commitment point and move from awareness (your presentation ) to training (the next step). You know you made the point when you've asked to talk about the details and elaborate on software security activities moving forward.

As an example, you know you made the case for wine when the next time you talk to a friend of yours that knew little about wine, you do NOT need to make the case of why drinking wine is good but between choosing to drink a pinot grigio instead of sauvigon blanc

If you have been asked that question, your friend got the point of drinking wine by now :)