Hi ben,
I would be very much interested in Steve Lipner's opinion here, because Steve
ran the IR program at Microsoft a decade ago before he was recruited to lead
the SSG. Steve, if you would, please take a look at this thread and let us
know what your thinking is RE integrating an IR group and/or an SSG completely
and almost invisibly into the mother organization after it has matured.
I suspect that some core SSG will always remain even after much of the heavy
lifting has been distributed throughout the mother organization by way of
satellite. A ratio of 3:1 (satellite:SSG) is what we observe.
SWIFT also has a long-lived SSG (14 years). Alain, any insight on this thread
you can offer?
gem
company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com
On 12/22/09 8:56 PM, Benjamin Tomhave list-s...@secureconsulting.net wrote:
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-s...@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
