InformIT: You need an SSG

[list-spam at secureconsulting.net (Benjamin Tomhave)]

Hi Gary,

I've worked with organizations that have taken a similar approach with
incident response management. You have a core IR team (within the
security dept) and then you designate IR contacts within specific ops
teams. This approach seems to work ok, but coordination gets to be
problematic, causing me to question scalability and management.
Basically, a lot of effort for an impact that seems to follow a
logarithmic growth pattern. The more it grows, the more it costs to
manage with not as much cost-effectiveness as when the program started.

What I wonder is this: how to do we get from heavy use of "security"
SMEs to where "security" is simply SOP? Moreover, is this even a good
idea, or particularly realistic? From a CMM perspective, it's akin to
our being at Level 0 or 1 right now, with Level 5 being the
disappearance of dedicated security personnel because there's no longer
a need (achievability aside). It's kind of like dissolving large sugar
crystals into water... at first you see the sugar and the water
separately... then over time you just see the solution without being
able to differentiate sugar from water. Anyway...

-ben

Gary McGraw wrote:
> hi ben,
>
> You may be right.  We have observed that the longer an initiative is
> underway (we have one in the study that checks in at 14 years old),
> the more actual activity tends to get pushed out to dev.  You may
> recall from the BSIMM that we call this the satellite.  Microsoft has
> an extensive satellite with 300 or so people embedded throughout
> their huge company (recall that their SSG is 100).  Because the
> notion of satellite is not as common a phenomenon in our data, we
> can't draw conclusions as clear as the ones we can draw regarding an
> SSG.
>
> Think of the SSG and the Satellite as "coaches" and "mentors" who are
> tasked with helping development get it right (not simply cleaning up
> their messes).  I agree that we have spent too much effort over the
> past decade simply trying to assess the mess and not enough getting
> dev to change their behavior.   The companies we studied in the BSIMM
> are trying to change dev.
>
> As a particular example of where I agree with you that we go off
> track as a discipline, consider training.  Teaching developers about
> the OWASP top 10 in training may be exciting, but it is nowhere near
> as important or as effective as teaching defensive programming.  (And
> this from the guy who wrote "Exploiting Software.")  Developers need
> to know how to do it right, not just what bugs look like on TV.
>
> gem
>
> company www.cigital.com podcast www.cigital.com/silverbullet blog
> www.cigital.com/justiceleague book www.swsec.com
>
>
> On 12/22/09 10:11 AM, "Benjamin Tomhave"
> <list-spam at secureconsulting.net> wrote:
>
> I think the short-term assertion is sound (setup a group to make a
> push in training, awareness, and integration with SOP), but I'm not
> convinced the long-term assertion (that is, maintaining the group
> past the initial push) is in fact meritorious. I think there's a
> danger in setting up dedicated security groups of almost any sort as
> it provides a crutch to organizations that then leads to a failure to
> integrate security practices into general SOP.
>
> What is advocated seems to be consistent with how we've approached 
> security as an industry for the past couple decades (or longer), and
> I don't see this as having the long-term benefit that was desired or 
> intended. It seems that when you don't make people directly
> responsible and liable for doing the right things, they then fail at
> the ask and let others do it instead. It's the old "lazy sysadmin"
> axiom that we script repeatable tasks because it's easier in the long
> run.
>
> The question, then, comes down to one of psychology and people 
> management. How do we make people responsible for their actions such 
> that they begin to adopt better practices? The basic response should
> be to enact consequences, and I think that now is probably an optimal
> time for businesses to get very hard-nosed about these sorts of
> things (high unemployment means lots of people looking for work means
> employers have the advantage). This perhaps sounds very ugly and
> nasty, and obviously it will be if taken to an extreme, but we have a
> serious problem culturally in that non-security people still don't
> seem to think, on average, that security is in their job description.
> Solve that problem, and all this other stuff becomes a footnote.
>
> fwiw.
>
> -ben
>
> Gary McGraw 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. 
> > _______________________________________________
>
> -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog:
> http://www.secureconsulting.net/ Twitter:
> http://twitter.com/falconsview Photos:
> http://photos.secureconsulting.net/ Web:
> http://falcon.secureconsulting.net/ LI:
> http://www.linkedin.com/in/btomhave
>
> [ Random Quote: ] "The only source of knowledge is experience." 
> Albert Einstein

-- 
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Hoare's Law of Large Programs: "Inside every large problem is a small
problem struggling to get out."
http://globalnerdy.com/2007/07/18/laws-of-software-development/