Re: [SC-L] InformIT: You need an SSG
as product teams did less and MSEC had to compensate. But the culture of MSEC is to help the product groups with tools, training, consulting and process and hold them accountable - not to do their job. And the product groups also want to control their own fates (and code) so they accept the responsibility that comes with that model. Steve -Original Message- From: DESAUSOI Alain [mailto:alain.desau...@swift.com] Sent: Monday, January 04, 2010 7:23 AM To: Gary McGraw; Secure Code Mailing List; Steve Lipner Cc: list-s...@secureconsulting.net; David Ladd Subject: RE: [SC-L] InformIT: You need an SSG [now posted on sc-l] I agree that in an ideal world, security would be naturally built-in by delivery and operational teams. They would transparently (?) report deviations/risks to central (ERM) team that would handle and escalate as appropriate. From my own experience, SWIFT's SSG helps ensure 'right the first time' and 'continuous improvements' on security front. It provides management transparency on risks as well as upstream assurance on what and how things will be/are being done. And it only brings value in as much there is tight 2-way cooperation with delivery and operational teams. With the support of senior executives, SSG allows a more natural cross fertilisation of risks, threats and solutions across the board, in terms of learning, need for infrastructure initiatives, ... Also, very much like using external penetration testers provides 'wilder' and more update testing techniques, having dedicated SSG helps having and outside look and keeping threat/risk management knowledge up to date. Could the ideal world succeed ? Probably so, assuming security governance, transparency, assurance and discipline. I have no experience with large scale organisation (SWIFT is only 500 developers - SSG is 5 staffs) and we already have the challenge of choosing our battles. So, even in those areas that we pamper less, the key values I preserve are (1) the ability to provide 'before the fact' security assurance on critical projects (critical in terms of businesses introducing new threats or arising security challenges) (2) sharing findings and lessons learned across the organisation (3) some level of assurance by keeping up with penetration testing as a motivator and (weak) indicator of alignment. In favour of dissemination is the fact that, according to my own experience (I have been 15 years on the other side of the fence), SSG only really works if they are on the field and well accepted by delivery/operational teams. The flip side is the need for a strong (and harmonised) security culture as it might easily drift away according to different business unit leadership: I would think that this would be a real challenge for the CISO. This also reflects my own experience on the delivery side. In summary, SSG provides down-the-earth facts and figures helping management making risk balance instead of leaving delivery teams on their own. It provides real meat for balancing security measures and learning as time goes. I think a reasonably-sized SSG with 'satellite' for granularity and scalability is the most appealing solution. -Original Message- From: Gary McGraw [mailto:g...@cigital.com] Sent: Wednesday, December 23, 2009 3:05 PM To: Secure Code Mailing List; Steven Lipner; DESAUSOI Alain Cc: list-s...@secureconsulting.net; David Ladd Subject: Re: [SC-L] InformIT: You need an SSG 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
Re: [SC-L] InformIT: You need an SSG
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
Re: [SC-L] InformIT: You need an SSG
At 08:01 AM 22/12/2009, Mike Boberski wrote: 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. I'd have to agree - whilst SSG is probably a great opportunity for a management consultant, it rarely delivers anything directly useful. In fact I would go as far as to say that if a SSG delivers something useful, the organisation was already ready to deliver the changes. Committees rarely take direct ownership of a problem. Toolsets may or may not deliver results - depending on if there are ways around them - too often you hear the excuse we can't waste time with that - the business won't wait However toolset will work if you have a good properly supported securty mgmt function :) Cheers Bret ___ 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. ___
Re: [SC-L] InformIT: You need an SSG
Mike Boberski mike.bober...@gmail.com wrote: 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. I don't quite grok what you're saying here. The syntax looks like you're saying that matrix management is a tool or toolkit, which doesn't make sense to me. Your next paragraph: 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. seems more like you're saying it's an environment conducive to bad security. Now that I can agree with, and would extend it to quality in general. A typical large-company matrix management environment seems very conducive instead to an attitude of who gives a flying fig, all I have to do is make it work well enough to get the customer to sign off. A given worker is unlikely to ever work on that same project again, so the usual write it well so that you can read it well later doesn't apply, and there's little to no other reward to write it well to be nice to the next poor sod who has to read it. All the more so in the typical Beltway Bandit (DC-speak for government contractors, especially defense) environment, where they'll probably be laid off in a few years anyway, so they won't be pestered by colleagues with questions, As for the tools, again absolutely agreed, though I'd place less emphasis on some of the pickier aspects of coding standards (like do block-opening braces get their own line, and do you put a space before the opening paren of a function call's argument list), and more on any automagically detectable security (or other types of quality) flaws. A couple years ago I was on a project where I was trying desperately to get the company to buy some kind of static analyzer, so we could use it as part of our CM process and have Subversion automagically reject changesets that introduced flaggable flaws. I did at least manage to set up the makefiles so that it would warn if any module had no unit tests, and fail to build if any unit tests failed On the other claw, I still don't grok what you mean by treated like any other module of the application. Maybe it's just a matter of preferred phrasing, but like any other *aspect* is closer to at least my own thoughts on it. IOW, they usually ask does it do the job right (verification) and maybe does it do the right job (validation), but should also ask (for security) does it Do The Right Thing (whatever that may be) in the face of all forseeable types of attacks, and (for quality) diDTRT(wtmb)itfoafto *errors* (including those forced by an attack!) and is it maintainable. -Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -+ Play: davearonson.net | \/ Ribbon Specialization is for insects. | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net| EmailWeb ___ 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. ___
Re: [SC-L] InformIT: You need an SSG
hi bret and mike,
While you guys are certainly entitled to your opinion, I think it is important
to acknowledge facts when you state an argument. Please take a few minutes to
read the article I posted on SSG's (this committee language you're both using
is very humorous BTW...thanks for the laugh). After you've read the article,
lets have an informed debate. Here's the URL again:
http://www.informit.com/articles/article.aspx?p=1434903
The article draws conclusions based on observations from 26 companies
(Microsoft is only 1 of the 26). The data I based my SSG claims on are
provided in analyzed form. Just for the record, the article also states that
we're not sure whether the data described in the BSIMM are relevant for SMB
(small and medium sized businesses), something I repeated in my sc-l post
yesterday. We have plans to find out using real data (again). We will not
draw any conclusions without gathering data and publishing it.
Your opinion that an SSG rarely delivers anything useful certainly does not
apply to the 26 companies we studied (so far) in the BSIMM, nor does it cohere
with my fifteen years of experience in the field. What observations are you
basing your argument on? Can you show us some data?
I'm afraid your toolset argument teeters precariously on opinion and falls into
a familiar pattern that goes something like this in BNF:
FlavOfDay = {owasp top 10, code review tools,pen
testing,firewalls,APIs,rampant finger crossing}
Software security can be solved by FlavOfDay because I said so.
While it is true that you said so, I'm pretty sure you're going to need a more
convincing argument. Unless we rely on data and evidence when we do our work,
we'll end up looking just as silly as those people who disagree with evolution
and global warming.
It's science time.
gem
company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com
On 12/21/09 11:24 PM, Bret Watson li...@ticm.com wrote:
At 08:01 AM 22/12/2009, Mike Boberski wrote:
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.
I'd have to agree - whilst SSG is probably a great opportunity for a
management consultant, it rarely delivers anything directly useful.
In fact I would go as far as to say that if a SSG delivers something
useful, the organisation was already ready to deliver the changes.
Committees rarely take direct ownership of a problem.
Toolsets may or may not deliver results - depending on if there are
ways around them - too often you hear the excuse we can't waste time
with that - the business won't wait
However toolset will work if you have a good properly supported
securty mgmt function :)
Cheers
Bret
___
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.
___
Re: [SC-L] InformIT: You need an SSG
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@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 fal...@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 ___ 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. ___
Re: [SC-L] InformIT: You need an SSG
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 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@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
Re: [SC-L] InformIT: You need an SSG
but it is nowhere near as important or as effective as teaching defensive programming I.e., arming developers with toolkits that perform expected security checks and that result in expected security effects, and making sure they can use them. Not a sermon just a thought, as the local radio station ad goes. Best, Mike B. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, December 22, 2009 12:09 PM To: list-s...@secureconsulting.net; Secure Code Mailing List Subject: Re: [SC-L] InformIT: You need an SSG 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 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
[SC-L] InformIT: You need an SSG
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. ___
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. ___
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. ___
Re: [SC-L] InformIT: You need an SSG
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
