InformIT: You need an SSG

[mike.boberski at gmail.com (Mike Boberski)]

But, do those require a second security group to execute(?)

Mike


On Mon, Dec 21, 2009 at 9:41 PM, David Ladd <daveladd at microsoft.com> wrote:

>  A lot of people look at what has been published from Microsoft about the
> SDL ? most notably the MSDN guidance
> http://msdn.microsoft.com/en-us/library/84aed186-1d75-4366-8e61-8d258746bopq.aspxand Michael Howard/Steve Lipner?s 
> SDL book - and walk away thinking that it
> is the SDL. It?s not. It?s the SDL as its practiced *at Microsoft.* It
> outlines the practices necessary for a multinational organization that ships
> hundreds of applications, to 100+ countries worldwide (each with their own
> regulatory regime), on a half dozen or more different hardware platforms.
> Given that, I would say that it?s our responsibility to apply the SDL in
> this fashion.
>
>
>
> The book and the guidance have been published and maintained in the
> interest of process transparency - to allow third parties to take a peek at
> what we do in a variety of different contexts, it is not implementation
> advice.
>
>
>
> I will concede that security ?SME-dom? can be a rare commodity and
> sometimes you have to go outside an org to get help, but a significant
> portion of the practices in the SDL (and the BSIMM for that matter) can be
> achieved at little to no cost. (e.g. Point a fuzzer (pick a free one -
> Minifuzz, Peach, whatever) at an application and set it: ?Run to infinity ?
> alert when problem found?)
>
>
>
> If you remove the regional/hardware plat/software plat/regulatory goo out
> of the SDL at MS picture, you?re left with a series of proven security
> practices that can be performed at organizations of any size. Security
> requirements, quality gates, threat modeling, static code analysis, dynamic
> analysis, etc. aren?t concepts that apply to, or only work in large orgs,
> and certainly aren?t proprietary to Microsoft.
>
>
>
> Dave
>
>
>
> *From:* Mike Boberski [mailto:mike.boberski at gmail.com]
> *Sent:* Monday, December 21, 2009 5:46 PM
> *To:* David Ladd
> *Cc:* Gary McGraw; SC-L at securecoding.org; dustin.sullivan at informit.com
>
> *Subject:* Re: [SC-L] InformIT: You need an SSG
>
>
>
> I think, MS is more an example of an ideal, than what the comparatively
> everyman organization can realistically hope to achieve, basically given
> resource constraints.
>
> Mike
>
>  On Mon, Dec 21, 2009 at 8:37 PM, David Ladd <daveladd at microsoft.com>
> wrote:
>
> To be clear - we do both.  We automate and standardize to the extent
> possible, then advise/adjudicate as necessary for situations that don?t fit
> the norm.
>
>
>
> Dave
>
>
>
> *From:* Mike Boberski [mailto:mike.boberski at gmail.com]
> *Sent:* Monday, December 21, 2009 5:22 PM
> *To:* Gary McGraw
> *Cc:* David Ladd; SC-L at securecoding.org; dustin.sullivan at informit.com
>
>
> *Subject:* Re: [SC-L] InformIT: You need an SSG
>
>
>
> I dunno, the concept of "SSG" seems overly broad to me. Looking at security
> libraries as a feature or a module eliminates the us vs. them paradox.
> Adding a new second security group is just twice as confrontational to the
> still single development team.
>
> Mike
>
> On Mon, Dec 21, 2009 at 7:20 PM, Gary McGraw <gem at cigital.com> wrote:
>
> Hi mike,
>
> The BSIMM calls out "security features and design" explicitly, and covers
> that good idea. (Though watch out for generic one-size-fits-all solutions.)
> An SSG helps with creation, review, and roll out of such.
>
> Calling an SSG a "committee" is pretty hilarious. I doubt any of the 100
> microsoft SSG members think they are a committee. Hey ladd, how goes the SDL
> committee?
>
> gem
>  ------------------------------
>
> *From*: Mike Boberski
> *To*: Gary McGraw
> *Cc*: Secure Code Mailing List ; Dustin Sullivan
> *Sent*: Mon Dec 21 19:01:37 2009
> *Subject*: Re: [SC-L] InformIT: You need an SSG
>
> Hi Gary.
>
> To play devil's advocate:
>
> Current organizational practices aside, I would say that organizations
> really need more and better toolkits and standards for developers to use,
> than they need more and better committees.
>
> A toolkit example that comes to mind, to keep this email short: the
> highly-matrixed environment (and actually also the smaller environment, now
> that I think about it) where developers fly on and off projects.
>
> Toolkits that enforce coding standards, and that are treated like any other
> module of the application in terms of care and feeding, are the only things
> that give security a fighting chance in environments like those.
>
> Best,
>
> Mike B.
>
> On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw <gem at cigital.com> wrote:
>
> hi sc-l,
>
> This list is made up of a bunch of practitioners (more than a thousand from
> what Ken tells me), and we collectively have many different ways of
> promoting software security in our companies and our clients.  The BSIMM
> study <http://bsi-mm.com> focuses attention on software security in large
> organizations and just at the moment covers the work of 1554 full time
> employees working every day in 26 software security initiatives.  One
> phenomenon we observed in the BSIMM was that every large initiative has a
> Software Security Group (SSG) to carry out and lead software security
> activities.
>
> I wrote about our observations around SSGs in this month's informIT
> article:
>
> http://www.informit.com/articles/article.aspx?p=1434903
>
> Simply put, an SSG is a critical part of a software security initiative in
> all companies with more than 100 developers.  (We're still not sure about
> SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75
> firms) may be revealing.)
>
> Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as
> founding members).  Since its inception, we've helped plan, staff, and carry
> out ten large software security initiatives in customer firms.  One of the
> most important first tasks is establishing an SSG.
>
> Merry New Year everybody.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20091221/f735e6c6/attachment.htm>