[SAMM] SP 800-37/53/64
Joe InfoSec
ubergeek2007 at yahoo.com
Thu Feb 4 23:14:13 EST 2010
Also, when looking at SP 800-64, be sure to look at Figure 3-2 where one of the Outputs is Development and Coding Standards and section 3.1.3.5 Secure Code Practices and Repositories.
Is it as extensive as BSIMM or SAMM? Surely not, but this is a major step forward toward getting Software Security included in a recognized standard.
Per 800-37, a note from section 3.3, "Organizations use best practices when implementing the security controls within the information system including system and software engineering methodologies, security engineering principles, and secure coding techniques." The Risk Management Framework included here, as well as 800-53 and -39 is the way the government is moving and it is good to see that software security is being included, yet still needs to be highlighted and emphasized by professionals such as those in this group.
Regards,
Joe Klimkowski, CISSP-ISSEP, CSSLP
Security Evangelist
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/training/1090-BSI.html
https://www.isc2.org/csslp-certification.aspx
https://www.isc2.org/dodmandate/default.aspx
"Private industry is your government. I thought you knew that." -- Jon Ross, Daemon (Suarez, 2009)
________________________________
From: "samm-request at lists.owasp.org" <samm-request at lists.owasp.org>
To: samm at lists.owasp.org
Sent: Wed, February 3, 2010 5:30:57 PM
Subject: SAMM Digest, Vol 11, Issue 2
Send SAMM mailing list submissions to
samm at lists.owasp.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.owasp.org/mailman/listinfo/samm
or, via email, send a message with subject or body 'help' to
samm-request at lists.owasp.org
You can reach the person managing the list at
samm-owner at lists.owasp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SAMM digest..."
Today's Topics:
1. Re: NIST SP 800-37 (McGovern, James F. (eBusiness))
2. FW: [SC-L] BSIMM update (informIT)
(McGovern, James F. (eBusiness))
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Feb 2010 15:45:21 -0500
From: "McGovern, James F. (eBusiness)"
<James.McGovern at thehartford.com>
Subject: Re: [SAMM] NIST SP 800-37
To: "Software Assurance Maturity Model (SAMM)" <samm at lists.owasp.org>,
"SecureCode Mailing List" <SC-L at securecoding.org>
Message-ID:
<BFD50E79FBE23A4FB6BE93572A6FE28702CCA5B6 at AD1HFDEXC312.ad1.prod>
Content-Type: text/plain; charset="us-ascii"
I like your take. Maybe the SAMM team could provide formal commentary to
NIST in this regard. I suspect that in not providing feedback, it will
be published and those who read it at a later date will get confused as
to the value proposition of each aka more disturbances in the force...
________________________________
From: samm-bounces at lists.owasp.org [mailto:samm-bounces at lists.owasp.org]
On Behalf Of Bart De Win
Sent: Wednesday, February 03, 2010 2:51 PM
To: Software Assurance Maturity Model (SAMM); SecureCode Mailing List
Subject: Re: [SAMM] NIST SP 800-37
James,
I'm not familiar (yet) with the details of SP800-37.
However, to add another NIST SP document to this discussion, SP 800-64
(R2 of October 2008) is definitely also worth looking at in the secure
development lifecycle context. Imho, from a bird's eye view, the main
differences between SP 800-64 and SAMM/BSIMM are:
- The NIST model is a process model, while SAMM and BSIMM are
maturity models. This is a fundamentally different. In that sense, it is
more related to the SDL/CLASP/TouchPoint type of models.
- In the same line of reasoning, the NIST model is
waterfall-based, while SAMM and BSIMM are actually process agnostic
(they can be applied to waterfall, agile and other types of processes)
- NIST SP 800-64 focuses much more on deployment, operations
and disposal than any of the other models that I've seen so far.
I'd be also interested in hearing any other opinions about this one.
Best regards,
Bart.
------------
Bart De Win CSSLP
Principal Consultant, CC Leader Application Assurance
Tel.: +32 (0)9 243.10.20, Mob: +32 (0)479 46.79.57
"Ascure, demonstrating excellence in operational risk management"
Looking for world class education? Check-out www.ascureacademy.eu
<http://www.ascureacademy.eu/> and www.bcmacademy.be
<http://www.ascureacademy.eu/> .
________________________________
This message may be confidential. It is also solely for the use of the
individual or group to whom it is addressed. If you have received it by
mistake, please let us know by e-mail reply. Ascure is not liable for
any direct or indirect damage arising from errors, inaccuracies or any
loss in the message, from unauthorized use, disclosure, copying or
alteration of it.
For the complete version or other languages of this disclaimer see
http://www.ascure.com/disclaimer.htm
<http://www.ascure.com/disclaimer.htm>
From: samm-bounces at lists.owasp.org [mailto:samm-bounces at lists.owasp.org]
On Behalf Of McGovern, James F. (eBusiness)
Sent: woensdag 3 februari 2010 19:13
To: Secure Code Mailing List; Software Assurance Maturity Model (SAMM)
Subject: [SAMM] NIST SP 800-37
NIST has created a draft document entitled: Guide for applying risk
management framework to federal information systems: a security
lifecycle approach. Curious to know if anyone has identified gaps,
differences in opinion, etc between NIST and how either SAMM or BSIMM
would define the same?
************************************************************
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.
************************************************************
************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/samm/attachments/20100203/73053c5b/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 3 Feb 2010 17:35:21 -0500
From: "McGovern, James F. (eBusiness)"
<James.McGovern at thehartford.com>
Subject: [SAMM] FW: [SC-L] BSIMM update (informIT)
To: "Software Assurance Maturity Model (SAMM)" <samm at lists.owasp.org>
Message-ID:
<BFD50E79FBE23A4FB6BE93572A6FE28702CCA6D9 at AD1HFDEXC312.ad1.prod>
Content-Type: text/plain; charset="us-ascii"
An interesting message on another mailing list that we should have an
opinion on...
-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Wednesday, February 03, 2010 3:02 PM
To: Wall, Kevin; Secure Code Mailing List
Subject: Re: [SC-L] BSIMM update (informIT)
hi kevin (and sc-l),
Sorry for the delay responding to this. I was skiing yesterday with my
son Eli and just flew across the country for the SANS summit this
morning (leaving behind 6 inches of new snow in VA). Anyway, better
late than never.
I'll interleave responses below.
On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>> "Cargo Cult Computer Security: Why we need more description and less
>> prescription."
>> http://www.informit.com/articles/article.aspx?p=1562220
>On 2/2/10 12:30 PM, "Wall, Kevin" <Kevin.Wall at qwest.com>
wrote:
> In my 11 years of experience working
>on this SSG, it is very rare that application development teams are
>looking for a _descriptive_ approach. Almost always, they are looking
>for a _prescriptive_ one. They want specific solutions to specific
>problems, not some general formula to an approach that will
>make them more secure.
Absolutely. I think as an SSG lead in a particular company environment
you must have a prescriptive approach but that the approach you develop
will be better if informed by data from a descriptive model like BSIMM.
(For the record, I see SAMM as a prescriptive model that tells you often
in great detail what your initiative should be doing without knowing one
whit about how your organization ticks.) If you read the article
carefully, there are two paragraphs that together should make this
clear.
Here's the first:
"Prescriptive models purport to tell you what you should do.
Promulgators of such models say things more like, "the model is chocked
full of value judgements [sic] about what organizations SHOULD be
doing." That's just dandy, as long as any prescriptive model only
became prescriptive over time based on sufficient observation and
testing."
And here's the second:
"Also worthy of mention in this section is the "one size fits all"
problem that many prescriptive models suffer from. The fact is, nobody
knows your organizational culture like you do. A descriptive comparison
allows you to gather descriptive data and adapt good ideas from others
while taking your culture into account."
BSIMM is meant to be a tool for the people running and SSG (and for that
matter, strategizing about a company's software security initiative).
The article is really about the differences between BSIMM and SAMM than
anything else. It's not really about the difference between BSIMM and
ESAPI. BSIMM and things like ESAPI fit together.
>Both are useful and ideally should go together like hand and glove.
Exactly right.
>I suspect that this apparent dichotomy in our perception of the
>usefulness of the prescriptive vs. descriptive approaches is explained
>in part by the different audiences with whom we associate.
Agreed. See above. BSIMM is a tool for executives to help build,
measure, and maintain a software security initiative.
>If our SSG were to hand them something like BSIMM, they would come away
>telling their management that we didn't help them at all.
Please do NOT even think about handing the BSIMM to developers as a
solution! The BSIMM is a yardstick for an initiative, and it's meant
for a guy like you. The notion is to measure your own initiative and
most importantly of all compare your initiative to your peers.
>This brings me to my fourth, and likely most controversial point.
>Despite the interesting historical story about Feynman, I question
>whether BSIMM is really "scientific" as the BSIMM community claims. I
>would contend that we are only fooling ourselves if we claim otherwise.
I think this is a valid criticism. The only thing that makes BSIMM more
scientific than other methodologies like the Touchoints, SDL, CLASP, or
SAMM, is that the BSIMM uses real data and real measurement. However
the measurement technique is certainly not foolproof. (Incidentally, I
state that view pretty clearly in the article...computer science, and
other fields with "science" in their name are usually not.)
>While I am certainly not privy to the exact method used to arrive at
>the BSIMM data (I have read through the "BSIMM Begin" survey, but have
>not been involved in a full BSIMM assessment), I would contend that the
>process is not repeatable to the necessary degree required by science.
This criticism holds some water, but you are shooting from the hip and
it is pretty clear that you have not read the BSIMM itself. That, and
the first article we wrote about the BSIMM explain our methods pretty
clearly. Please read those two things and lets continue this line of
questioning.
>I challenge [the BSIMM team] to put forth additional information
>explaining their data collection process and in particular, describing
>how it avoids unintentional bias. (E.g., Are assessment participants
>choose >at random? By whom? How do you know you have a representative
>sample of a company? Etc.)
This is pretty clearly explained in the BSIMM itself.
>In my opinion, comparison of observations from two companies is not
>worth the paper that is printed on UNLESS we can extrapolate from this
>data and make accurate predictions based on past findings.
Given the reaction to actual results from the 30 companies who have
participated so far in the study, I'll respectfully call you out as
incorrect on that one. Turns out that most people who run large SSGs
and initiatives are hungry for comparison with peers (and indeed want to
meet and learn from the peers). Experience in the field is bearing out
the utility of the BSIMM, and the fact that the data we are gathering is
supporting the model in important ways is no small potatoes either.
>After observing this field for 30+ years (ouch!), I have concluded that
>we [computer science] have not matured into a science because as a
>discipline we *do NOT really want to!*
Some of us do. Others don't. But I think a sea change is underway even
in our little subfield of software security
>... efforts such as BSIMM should be welcomed by all. But is also
>important for those who prefer _descriptive_ approaches like BSIMM, to
>acknowledge the importance of _prescriptive_ approaches
I concur.
Thanks for your carefully considered posting Kevin. Hope this response
is satisfying.
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.
_______________________________________________
************************************************************
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.
************************************************************
------------------------------
_______________________________________________
SAMM mailing list
SAMM at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/samm
End of SAMM Digest, Vol 11, Issue 2
***********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/samm/attachments/20100204/b19d7f59/attachment-0001.html
More information about the SAMM
mailing list