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 :)