How is secure coding sold within enterprises?

[jsteven at cigital.com (John Steven)]

Andrew, James,

Agreed, Microsoft has put some interesting thoughts out in their SDL  
book. Companies that produce a software product will find a lot of  
this approach resonates well. IT shops supporting financial houses  
will have more difficulty. McGraw wrote a decent blog entry on this  
topic:

http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints- 
versus-microsofts-sdl/

Shockingly, however, I seem to be his only commentator on the topic.

I think James will find Microsoft's literature falls terribly short  
of even the raw material required to produce the PPT he desires.  
Let's see what we can do for him.

First: audience. I'm not sure of James' position, but it doesn't  
sound like he's high enough that he's got the CISO's ear now, nor  
that he's face-down in the weeds either. James, you sit somewhere in- 
between? James appears to work for an insurance company. Insurance  
companies do care about risk, but they're sometimes blind to the  
kinds (and magnitudes) of software risk their business faces. They  
fall in a middle ground between securities companies and banks.

Second, length: If you're going after a SVP or EVP, James, I'd keep  
the deck to ~3-5 slides. 1) Motivate the problem, 2) Show your org's.  
status (as an application security framework) and, 3) show the 6mo.,  
9mo., 12mo. (maybe) roadmap. Depending on the SVP, another two slides  
comparing you to others might work, as well as a slide that talks in  
more detail about costs, deliverables, and resource-requirements, and  
value.

Higher? I'd do two slides: 1) framework and 2) roadmap. The end.  
Place costs and value on the roadmap.

What about content? Longer decks I've seen (or helped create) have  
begun with research from analyst firms, or with pertinent headlines,  
to motivate the problem (couched as FUD if you're not careful) on  
slide one. Still, you'd be wise to pick fodder that will appear to  
the decision maker's own objectives. His/her objectives may be in  
pursuit of differentiation/opportunity or risk reduction, as Andrew  
said, or (more probably) they're pursuant to a more mundane goal:  
drive down (or hold constant) security cost while driving up the  
effectiveness of the spending.

To this end, the decks I've seen quickly moved beyond motivation into  
solution. Here, you have to begin thinking about your current org. See:

http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the- 
jones-security-initiatives/

To summarize my entry, your organization probably didn't start  
thinking about software security yesterday, and they likely have  
something in place--even if it isn't to your satisfaction yet.  
Likewise, true strengths lurk, waiting to be leveraged. Out here in  
mailing-list-land, we can't be sure of specifics, but, I've got some  
premonitions. Insurance companies I've seen seem to mix small wild- 
wild-west (Developers cowboys 'follow' Agile as an excuse to just  
slam code without process) teams with those following a largely  
monolithic waterfall-like (regardless of how 'iterative' it's  
described) development process in their application portfolio. In  
either case, an in-project risk officer exists, but the function  
seems overshadowed by deadlines, features, and cost.

On the topic of the framework slide, you mentioned a _very_ important  
quality: who, what, when structure. I wrote an IEEE S&P article on  
this topic long ago:

www.cigital.com/papers/download/j2bsi.pdf

but you can also look at my talk from OWASP's DC conference in '05 on  
the same topic for slide help.

What about the roadmap--the way forward? Even if currently  
ineffective, current security items like an architectural review  
checklist present opportunity with which to start your roadmap. When  
working on your roadmap focus on how small iterative changes in  
existing elements (like that checklist) can save you on security  
effort (spending) later. Pick sure wins and to communicate value,  
show a metric that will demonstrate the savings. Propose measurements  
up front, if only verbally, as part of this presentation. For  
instance: Do your applications have available a custom implementation  
of input validation routines built on top of Struts' Validator  
framework? Ask about its use in the architectural checklist. Propose  
to measure penetration testing results in the input filtering class  
and correlate it with checklist answers. As you collect data you'll  
be building (or possibly but not hopefully destroying) the case for  
your expanded checklist and the savings it provides. There are a host  
of hidden measures embedded in this example, each shining light in a  
particular direction. Make sure each and every initiative can make  
use of such measures as justification.

Well, this is long enough for now. If there are topics you'd like me  
to enumerate more fully, or if I've missed something, shoot me an email.

Hope this helps, and sorry I didn't just attach a PPT ;)

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F

Blog: http://www.cigital.com/justiceleague
http://www.cigital.com
Software Confidence. Achieved.


On Mar 19, 2007, at 4:12 PM, McGovern, James F ((HTSC, IT)) wrote:

> I agree with your assessment of how things are sold at a high-level  
> but still struggling in that it takes more than just graphicalizing  
> of your points to sell, hence I am still attempting to figure out a  
> way to get my hands on some PPT that are used internal to  
> enterprises prior to consulting engagements and I think a better  
> answer will emerge. PPT may provide a sense of budget, timelines,  
> roles and responsibilities, who needed to buy-in, industry metrics,  
> quotes from noted industry analysts, etc that will help shortcut my  
> own work so I can start moving towards the more important stuff.
> -----Original Message-----
> From: Andrew van der Stock [mailto:vanderaj at owasp.org]
> Sent: Monday, March 19, 2007 2:50 PM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L
> Subject: Re: [SC-L] How is secure coding sold within enterprises?
>
> There are two major methods:
>
> Opportunity cost / competitive advantage (the Microsoft model)
> Recovery cost reductions (the model used by most financial  
> institutions)
>
> Generally, opportunity cost is where an organization can further  
> its goals by a secure business foundation. This requires the CIO/ 
> CSO to be able to sell the business on this model, which is hard  
> when it is clear that many businesses have been founded on insecure  
> foundations and do quite well nonetheless. Companies that choose to  
> be secure have a competitive advantage, an advantage that will  
> increase over time and will win conquest customers. For example  
> (and this is my humble opinion), Oracle?s security is a long  
> standing unbreakable joke, and in the meantime MS ploughed billions  
> into fixing their tattered reputation by making it a competitive  
> advantage, and thus making their market dominance nearly complete.  
> Oracle is now paying for their CSO?s mistake in not understanding  
> this model earlier. Forward looking financial institutions are now  
> using this model, such as my old bank?s (with its SMS transaction  
> authentication feature) winning many new customers by not only  
> promoting themselves as secure, but doing the right thing and  
> investing in essentially eliminating Internet Banking fraud. It  
> saves them money, and it works well for customers. This is the best  
> model, but the hardest to sell.
>
> The second model is used by most financial institutions. They are  
> mature risk managers and understand that a certain level of risk  
> must be taken in return for doing business. By choosing to invest  
> some of the potential or known losses in reducing the potential for  
> massive losses, they can reduce the overall risk present in the  
> corporate risk register, which plays well to shareholders. For  
> example, if you invest $1m in securing a cheque clearance process  
> worth (say) $10b annually to the business, and that reduces check  
> fraud by $5m per year and eliminates $2m of unnecessary overhead  
> every year, security is an easy sell with obvious targets to  
> improve profitability. A well managed operational risk group will  
> easily identify the riskiest aspects of a mature company?s  
> activities, and it?s easy to justify improvements in those areas.
>
> The FUD model (used by many vendors - ?do this or the SOX boogeyman  
> will get you?) does not work.
>
> The do nothing model (used by nearly everyone who doesn?t fall into  
> the first two categories) works for a time, but can spectacularly  
> end a business. Card Systems anyone? Unknown risk is too risky a  
> proposition, and is plain director negligence in my view.
>
> Thanks,
> Andrew
>
>
> On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)"  
> <James.McGovern at thehartford.com> wrote:
>
> I am attempting to figure out how other Fortune enterprises have  
> went about selling the need for secure coding practices and can't  
> seem to find the answer I seek. Essentially, I have discovered that  
> one of a few scenarios exist (a) the leadership chain was highly  
> technical and intuitively understood the need (b) the primary  
> business model of the enterprise is either banking, investments,  
> etc where the risk is perceived higher if it is not performed (c)  
> it was strongly encouraged by a member of a very large consulting  
> firm (e.g. McKinsey, Accenture, etc).
>
> I would like to understand what does the Powerpoint deck that  
> employees of Fortune enterprises use to sell the concept PRIOR to  
> bringing in consultants and vendors to help them fulfill the need.  
> Has anyone ran across any PPT that best outlines this for  
> demographics where the need is real but considered less important  
> than other intiatives?



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070319/0f98053a/attachment-0001.html