But, do those require a second security group to execute(?) Mike
On Mon, Dec 21, 2009 at 9:41 PM, David Ladd <davel...@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 s...@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.bober...@gmail.com] > *Sent:* Monday, December 21, 2009 5:46 PM > *To:* David Ladd > *Cc:* Gary McGraw; SC-L@securecoding.org; dustin.sulli...@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 <davel...@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.bober...@gmail.com] > *Sent:* Monday, December 21, 2009 5:22 PM > *To:* Gary McGraw > *Cc:* David Ladd; SC-L@securecoding.org; dustin.sulli...@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 <g...@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 <g...@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@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. > _______________________________________________ > > > > > > >
_______________________________________________ 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. _______________________________________________
