How is secure coding sold within enterprises?

[James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))]

John, thanks for the response and I think you have an understanding of the essence of the problem in that current books 
don't cover the "selling" security aspects nor how things actually work in large corporations. One of the benefits to 
me seeing someone's deck that went before me is that I get to see and understand not only salient points, but also how 
they were presented in terms of order and emphasis. I of course could like most folks who are new to a space is to take 
a first shot at it and mercilessly iterate but I do think it is wise to figure out ways to leverage the work of my 
peers in other enterprises (of course I can return the favor on other initiatives) and only iterate based on local 
custom and not broader themes.
 
In terms of job grade, no I am not an EVP nor am I a developer. I someone higher on the foodchain than most in that my 
responsibilities include strategic direction. Likewise, the issue in terms of selling is really about budget, but it is 
about first buy-in of all participants throughout the enterprise and secondly the ability to make the case once we 
collectively conclude that we need consulting assistance, the ability to go off preferred vendor list and make the 
right choice.
 
Based on your comment, in your opinion, I would love to know which analysts should I quote and if you know of specific 
gems? In terms of keeping up with the Joneses, part of this requires the ability to understand what others are up to. 
From what I can tell from this list, I have only seen replies from two Fortune enterprises where the vast majority of 
other folks either have some government connection and/or employed by software vendors/consulting firms. One of my 
concerns with why ideas sometimes don't fly is not do to validity but the perception that if one waits it out, things 
will get better and more efficiency in terms of spend will emerge. In other words, one perception may be that focusing 
on secure coding is too early (Yes, the current description of why it is important is valid but it doesn't address the 
early concern)
 
Got any URLs to any good architectural checklists? I have only ran across code-oriented ones.
 
Anyone seen any good pictorial representations of roadmaps in this space?

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]On Behalf Of John Steven
Sent: Monday, March 19, 2007 9:56 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


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.



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070320/07c170a9/attachment-0001.html