James,
I can't believe I forgot to mention the presentation before mine at
that particular OWASP con. Anthony Canike did an exceptional job
chronicling what he had done at Vanguard. This presentation, if I
recall correctly, should have some fodder for you.
www.owasp.org/images/0/05/AppSec2005DC-Anthony_Canike-
Enterprise_AppSec_Program.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 9:55 PM, John Steven wrote:
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:[EMAIL PROTECTED]
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)"
<[EMAIL PROTECTED]> 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.
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/
listinfo/sc-l
List charter available at - http://www.securecoding.org/list/
charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://
www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
