BSIMM update (informIT)

[gem at cigital.com (Gary McGraw)]

hi james,

I'm afraid you are completely wrong about this paragraph which you have completely fabricated.  Please check your 
facts.  This one borders on slander and I have no earthly idea why you believe what you said.

> Would BSIMM be a better approach if the audience wasn't so self-selecting? At no time did it include corporations who
> use Ounce Labs or Coverity or even other well-known security consultancies.

BSIMM covers many organizations who use Ounce, Appscan, SPI dev inspect, Coverity, Klocwork, Veracode, and a slew of 
consultancies including iSec, Aspect, Leviathan, Aitel, and so on.

gem


On 2/4/10 10:29 AM, "McGovern, James F. (eBusiness)" <James.McGovern at thehartford.com> wrote:

When comparing BSIMM to SAMM are we suffering from the Mayberry Paradox? Did you know that Apple is more secure than 
Microsoft simply because there are more successful attacks on MS products? Of course, we should ignore the fact that 
the number of attackers doesn't prove that one product is more secure than another.

Whenever I bring in either vendors or consultancies to write about my organization, do I only publish the positives and 
only slip in a few negatives in order to maintain the fa?ade of integrity? Would BSIMM be a better approach if the 
audience wasn't so self-selecting? At no time did it include corporations who use Ounce Labs or Coverity or even other 
well-known security consultancies.

OWASP on the other hand received feedback from folks such as myself on not the things that work, but on a ton of stuff 
that didn't work for us. This type of filtering provides more value in that it helps other organizations avoid 
repeating things that we didn't do so well without necessarily encouraging others to do it the McGovern way.

Corporations are dynamic entities and what won't work vs what will is highly contextual. I prefer a list of things that 
could possibly work over the effort to simply pull something off the shelf that another organization got to work with a 
lot of missing context. The best security decisions are made when you can provide an enterprise with choice in 
recommendations and I think SAMM in this regard does a better job than other approaches.

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, February 03, 2010 4:08 PM
To: Secure Coding
Subject: Re: [SC-L] BSIMM update (informIT)

On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
> Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive 
> models which purport to tell you what you should do.

Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome BSIMM and I welcome SAMM.  I don't see it 
in the least as a "one or the other" debate.

A decade(ish) since the first texts on various aspects of software security started appearing, it's great to have a 
BSIMM that surveys some of the largest software groups on the planet to see what they're doing.  What actually works.  
That's fabulously useful.  On the other hand, it is possible that ten thousand lemmings can be wrong.  Following the 
herd isn't always what's best.

SAMM, by contrast, was written by some bright, motivated folks, and provides us all with a set of targets to aspire to. 
 Some will work, and some won't, without a doubt.

To me, both models are useful as guide posts to help a software group--an SSG if you will--decide what practices will 
work best in their enterprise.

But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves if we consider these to be standards or 
even maturity models.  Any other engineering discipline on the planet would laugh us all out of the room by the mere 
suggestion.  There's value to them, don't get me wrong.  But we're still in the larval mode of building an engineering 
discipline here folks.  After all, as a species, we didn't start (successfully) building bridges in a decade.

For now, my suggestion is to read up, try things that seem reasonable, and build a set of practices that work for _you_.

Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, 
confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender 
immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


_______________________________________________
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.
_______________________________________________