On Thu, Dec 29, 2011 at 10:32 AM, Gary McGraw g...@cigital.com wrote:
hi sc-l,
How about a little software security controversy for the tweener holiday week?
On the last day of the BSIMM Conference in November, SAFECode unveiled
a paper about the SAFECode Practices and their relationship to the BSIMM.
Sammy and I don't think the SAFECode guys got everything right in their
work. In fact, they misconstrue the BSIMM as a software security
methodology (which it is not) focused on compliance (which it definitely
is not), so we wrote an article in response:
BSIMM versis SAFECode and Other Kaiju Cinema
http://www.informit.com/articles/article.aspx?p=1824250 (12/26/11)
Gary,
Hope you and other SC-L readers had a safe and happy holidays. I had a few
comments on your InformIT article referenced here.
First, you take exception of SAFECode of calling out BSIMM as a methodology.
After quickly skimming their paper which you referenced, I think that
perhaps you
and Sammy are overreacting a bit. (Maybe you are misconstruing their
misconstruing? ;-)
Specifically, the SAFECode _Fundamental Practices_ paper which you cite states
in their section Prescriptive vs. Descriptive Models of Security:
Both the SAFECode _Fundamental Practices_ paper and the BSIMM
focus on secure development *methodologies*; however the are
important differences in their respective approaches and
conclusions.
[Emphasis mine.]
I do not see anywhere else that they claim that BSIMM is a methodology, so my
conclusion would be to simply chalk this up to sloppy writing at that
point rather
than drawing a conclusion from this single statement that SAFECode
fails to understand
that BSIMM is not a methodology.
Besides, if you make the assumption that SAFECode did draw this conclusion
that BSIMM is a type of software security methodology, do you really have anyone
other than the BSIMM trainers / interviewers / staff to blame? Why? Well, as I
read your InformIT article, you seem to imply that 6 of the 8 SAFECode members
have participated in BSIMM. So, if that is true and they didn't grasp
this fundamental
truth, then my conclusion would be that your BSIMM training was an
epic fail. However, I
do think that SAFECode understood this. I didn't see anywhere else in
their article
that you cited where the decreed that BSIMM was some sort of
methodology. However,
if there are other paragraphs in their paper that you could cite that
would support your
point that they are miscontruing BSIMM as a methodology, I shall stand
corrected.
(Like I said, I only skimmed their paper rather quickly.)
Secondly, in your InformIT article, you and Sammy wrote:
The SAFECode paper implies that some activities identified
in the BSIMM may be irrelevant to software security. Our
working assumption is that if professional leaders and
members of multiple software security groups are carrying
out an activity, there is some logical reason for them to
do so.
Let me say that I think that you are being kind with your working
assumption by concluding that there is some *logical* reason to *all*
the activities that BSIMM has observed. That is, unless you consider
CYA and office politics to be logical reasons. (I guess they could
be, depending on your perspective.) Similarly, I would say that a lot of
security activities that I have observed are, IMO, based on security myths,
overreaction, or simple misunderstanding of security principles and
risk models. This too is a matter of perspective as to whether this
follows from some logical reasoning, but certainly while all of it may
follow some logic, I would contend that not all of it is rationale. (Unless
you consider reasoning based on fallacies to be rationale.)
Of course, this is all just my opinion from where I sit. I am certainly
not speaking from the perspective of my employer. And I'm not just
writing that as part of some official company disclaimer. FWIW, many of my
colleagues disagree with me. But OTOH, I do know that I am not alone
in the security community with my opinions.
Best regards,
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents. -- Nathaniel Borenstein
___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___
