Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
The "playing in traffic" example is one extreme end of the spectrum. A
good analogy for the other end might be physics where you just teach
Newtonian theory it as if it were 100% accurate and then, if the
student decides to take a relativistic physics class, you teach them
on day 1 that everything they know isn't right. It seems teaching
secure programming must lie somewhere between these two ends of the
spectrum.
Perhaps a more useful exercise (rather than debating where in the
gradient through metaphor) is to try to enumerate the variables that
play into what draws a topic toward one end or the other. Such
variables might include:
* "stickiness" of the bias/habits acquired as you learn more
* impetus to learn more
* ability/access to learn more
Just a thought.
p.
On 8/25/09, Goertzel, Karen [USA] wrote:
> We teach toddlers from the time they can walk that they shouldn't play in
> traffic. A year or two later, we teach them to look both ways before
> crossing the street. Even later - usually when they're approaching their
> teens, and can deal with "grim reality", we give examples that illustrate
> exactly WHY they needed to know those things.
>
> But that doesn't mean we wait until the kids are 11 or 12 to tell them
> shouldn't play in traffic.
>
> There has to be some way to start introducing the idea even to the rawest of
> raw beginning programming students that "good" is much more desirable than
> "expedient", and then to introduce the various properties that collectively
> constitute "good" - including security.
>
> Karen Mercedes Goertzel, CISSP
> Associate
> 703.698.7454
> goertzel_ka...@bah.com
>
> From: Andy Steingruebl [stein...@gmail.com]
> Sent: Tuesday, August 25, 2009 1:14 PM
> To: Goertzel, Karen [USA]
> Cc: Benjamin Tomhave; sc-l@securecoding.org
> Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
>
> On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen
> [USA] wrote:
>> For consistency's sake, I hope you agree that if security is an
>> intermediate-to-advanced concept in software development, then all the
>> other "-ilities" ("goodness" properties, if you will), such as quality,
>> reliability, usability, safety, etc. that go beyond "just get the bloody
>> thing to work" are also intermediate-to-advanced concepts.
>>
>> In other words, teach the "goodness" properties to developers only after
>> they've inculcated all the bad habits they possibly can, and then, when
>> they are out in the marketplace and never again incentivised to actually
>> unlearn those bad habits, TRY desperately to change their minds using
>> nothing but F.U.D. and various other psychological means of dubious
>> effectiveness.
>
> Seriously? We're going to teach kids in 5th grade who are just
> learning what an algorithm is how to protect against malicious inputs,
> how to make their application fast, handle all exception conditions,
> etc?
>
> ...
> ___
> 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.
> ___
>
--
~ ~ ~ ~~~ ~~ ~
Pravir Chandra chandralistorg
PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~ ~ ~
___
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] Functional Correctness
Well, this topic gets muddy pretty quickly since I agree with many of the comments made on this thread. We have to be careful with hype and claims made by new models (BSIMM and OpenSAMM in particular) since depending on how the 'rest of the world' sees them speaks directly to our credibility as industry experts. I've tried hard when presenting OpenSAMM to fully claim that the model is chocked full of value judgements about what organizations SHOULD be doing to make a justified argument (qualitatively) that the software they produce has a degree of assurance built-in. Is it a guarantee? No. Is it still valuable? Absolutely. Before, we had no ability to make an apples-to-apples comparison between two organizations, and the model helps that. We also didn't know how to quantify iterative improvement very well or explain the breadth of the software security problem to people either, and OpenSAMM helps that too. I disagree with the remark that maturity models are only useful to companies starting with nothing, because I've seen firsthand how OpenSAMM has helped people (already doing a lot for assurance) think through aspects of the software security problem that fell outside their tunnel-vision. Now, on to the sticky topic of value judgements. Based on how I've seen the BSIMM presented, one might think that at face value, it is somehow more free of author/contributor value judgements than OpenSAMM or other secure SDLC models (I've read several articles referring to these as 'alchemy'). This is simply not true. I, for one, agree with Brad that claims of a scientific nature need to be extremely carefully qualified. At the end of the day, we don't yet know enough about practical methods for improving software security that have much justification beyond what experts think amounts to a 'good thing' (excepting formal methods, of course, but I did say practical :). This is the case for both BSIMM and OpenSAMM. I welcome comments/questions/flames. p. On 8/22/09, Cassidy, Colin (GE Infra, Energy) wrote: > > > Brad Andrews Writes: > >> After all, we can just "implement this maturity model and eliminate >> all our security problems, at least in the application, >> right?" That >> is likely to end up resulting in even more resistance in the future >> when management questions why they need to keep spending more for >> software security, a secure architecture, etc. Don't people learn >> what they need to know at some point? > > I don't thinks that's ever been the case that you can just apply your model > and all will be well Microsoft didn`t release their SDL and said "there all > our software will now be secure", they're constantly evolving their > processes. > > Also some of the activities within the BSIMM are about constant improvement > and keeping up with the latest trends, so even just following the BSIMM your > processes are never static. > >> I don't think we will ever be static. As soon as we remove the low >> hanging fruit, the fruit higher up the tree will be the problem. > > Or, the fruit on another tree :) who's attacking the OS now when the apps > are so easy to attack > >> This isn't to say a maturity model is useless, but I remain >> skeptical >> that it will live up to the "hype" (low key now, but there) it is >> being presented with. > > I think that the models (both BSIMM and OSAMM) help to provide a framework > and a direction to those that have no real security practices at all. Or > allow a measurement of existing process and see where their weaknesses are. > That and the senior management like the pretty graphs even if they don't > know what it means :D > > CJC > -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] Static Vs. Binary
First, I generally agree that there are many factors that make the true and factual fidelity of static analysis really REALLY difficult. However, I submit that by debating this point, you're belaboring the correct angle of survivable Neptunian atmospheric entry with people that don't generally value the benefit of flying humans past the moon. The point being, if you're debating the minutiae of static analysis vis-a-vis compile time optimizations, you're convincing people to let good be the enemy of perfect. There are few (if any) perfect technologies, but we use them because they're needed and provide a ton of great value. Anyone who doubts this should glance at the device you're reading this on and imagine yourself refusing to use it because it doesn't have perfect security (or reliability, or usability, etc.). p. ~ ~~~~~~~~~ ~~~~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: John Steven Date: Thu, 30 Jul 2009 17:20:52 To: Secure Coding Subject: [SC-L] Static Vs. Binary Something occurred to me last night as I pondered where this discussion¹s tendrils are taking us. An point I only made implicitly is this: The question wrote: > All, > > The question of ³Is my answer going to be high-enough resolution to support > manual review?² or ³...to support a developer fixing the problem?² comes down > to ³it depends². And, as we all know, I simply can¹t resist an ³it depends² > kind of subtlety. > > Yes, Jim, if you¹re doing a pure JavaSE application, and you don¹t care about > non-standards compilers (jikes, gcj, etc.), then the source and the binary are > largely equivalent (at least in terms of resolution) Larry mentioned gcj. > Ease of parsing, however, is a different story (for instance, actual > dependencies are way easier to pull out of a binary than the source code, > whereas stack-local variable names are easiest in source). > > Where you care about ³a whole web application² rather than a pure-Java module, > you have to concern yourself with JSP and all the other MVC technologies. > Placing aside the topic of XML-based configuration files, you¹ll want to know > what (container) your JSPs were compiled to target. In this case, source code > is different than binary. Similar factors sneak themselves in across the Java > platform. > > Then you¹ve got the world of Aspect Oriented programming. Spring and a broader > class of packages that use AspectJ to weave code into your application will > dramatically change the face of your binary. To get the same resolution out of > your source code, you must in essence Oapply¹ those point cuts yourself... > Getting binary-quality resolution from source code therefore means predicting > what transforms will occur at what point-cut locations. I doubt highly any > source-based approach will get this thoroughly correct. > > Finally, from the perspective of dynamic analysis, one must consider the > post-compiler transforms that occur. Java involves both JIT and Hotspot (using > two hotspot compilers: client and server, each of which conducting different > transforms), which neither binary nor source-code-based static analysis are > likely to correctly predict or account for. The binary image that runs is > simply not that which is fed to classloader.defineClass[] as a bytestream. > > ...and (actually) finally, one of my favorite code-review techniques is to > ask for both a .war/ear/jar file AND the source code. This almost invariable > get¹s a double-take, but it¹s worth the trouble. How many times do you think a > web.xml match between the two? What exposure might you report if they were > identical? ... What might you test for If they¹re dramatically different? > > Ah... Good times, > > John Steven > Senior Director; Advanced Technology Consulting > Direct: (703) 404-5726 Cell: (703) 727-4034 > Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 > > Blog: http://www.cigital.com/justiceleague > Papers: http://www.cigital.com/papers/jsteven > > http://www.cigital.com > Software Confidence. Achieved. > > > On 7/28/09 4:36 PM, "ljknews" wrote: > >> At 8:39 AM -1000 7/28/09, Jim Manico wrote: >> >>> A quick note, in the Java world (obfuscation aside), the source and >>> "binary" is really the same thing. The fact that Fortify analizes >>> source and Veracode analizes class files is a fairly minor detail. >> >> It seems to me that would only be true for those using a >> Java bytecode engine, not those using a Java compiler that &g
[SC-L] SAMM helps with real software development
The Real Software blog by Jim Bird has a good post about how his software security assurance program has evolved over time, and now, SAMM is helping out. http://swreflections.blogspot.com/2009/04/opensamm-shows-way.html p. -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] SAMM 1.0 Released! | OpenSAMM
Hey Ken. Thanks for sending this out. I've mentioned it before, but today I'm proud to announce that the Software Assurance Maturity Model (SAMM) version 1.0 has been released and is freely available for download from http://www.opensamm.org For those unfamiliar, SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in: * Evaluating an organization’s existing software security practices * Building a balanced software security program in well-defined iterations * Demonstrating concrete improvements to a security assurance program * Defining and measuring security-related activities within an organization SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-business, or even for an individual project. As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use. The project has received a huge amount of attention and is keeping me busy, but we're always open to more feedback and supporters. Thanks! p. On Wed, Mar 25, 2009 at 8:09 AM, Kenneth Van Wyk wrote: > Good news today from the Software Assurance Maturity Model (SAMM) group. > > http://www.opensamm.org/2009/03/samm-10-released/ > > Their release says: > > "The Beta release has been out for quite a while now (since August 2008) and > lots of organizations and individuals have provided excellent feedback to > help improve the model. I’ve heard lots of stories from people using SAMM > (some are consulting firms, and some are development organizations) and that > feedback has been some of the most valuable. This release marks the official > 1.0 version of SAMM and there’s a few new pieces added: > > * Executive summary and introduction to the model > * Improved details on applying the model to solve problems > * Assessment worksheets for evaluating existing programs > * Roadmaps for financial services and government organizations > * Improvements and refinements to the model (I’ll cover changes > individually in separate posts) > > Many thanks to the individual reviewers and the organizations that have > volunteered time to help improve SAMM. I look forward to more active > participants as we push forward with some of the future development plans > for SAMM." > > > > Cheers, > > Ken > > - > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.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. > ___ > > -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
Well, it seems that there's an interesting nuance here. We don't really have a concrete definition for what software is (code, design, compiled bins, etc.). All of these things plus the subjective expectations from designers, users, and security folks tend to be the domain for how the term is used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). In fact, I'd be willing to be that for just about every software security problem we've dealt, I could give you a design/spec level solution that would prevent it in general (and make auditing and so forth incredibly streamlined). p. ~ ~~~~~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: "Goertzel, Karen [USA]" Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhave; Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) ___ 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] Positive impact of an SSG
b site wasn't down... ;) > > -ben > > Sammy Migues wrote: >> Hi Pravir, >> >> Thanks for clarifying what you're positing. I'm not sure how we could >> have been more clear in the BSIMM text accompanying the exposition of >> the collective activities about the need to take this information and >> work it into your own culture (i.e., do "risk management"). As a few >> examples: >> >> p. 3: "BSIMM is meant as a guide for building and evolving a software >> security initiative. As you will see when you familiarize yourself >> with the BSIMM activities, instilling software security into an >> organization takes careful planning and always involves broad >> organizational change. By clearly noting objectives and goals and by >> tracking practices with metrics tailored to your own initiative, you >> can methodically build software security in to your organization’s >> software development practices." >> >> p. 47: "Choosing which of the 110 BSIMM activities to adopt and in >> what order can be a challenge. We suggest creating a software >> security initiative strategy and plan by focusing on goals and >> objectives first and letting the activities select themselves. >> Creating a timeline for rollout is often very useful. Of course >> learning from experience is also a good strategy." >> >> p. 47: "Of the 110 possible activities in BSIMM, there are ten >> activities that all of the nine programs we studied carry out. Though >> we can’t directly conclude that these ten activities are necessary >> for all software security initiatives, we can say with confidence >> that these activities are commonly found in highly successful >> programs. This suggests that if you are working on an initiative of >> your own, you should consider these ten activities particularly >> carefully (not to mention the other 100)." >> >> p. 48: "The chart below shows how many of the nine organizations we >> studied have adopted various activities. Though you can use this as a >> rough “weighting” of activities by prevalence, a software security >> initiative plan is best approached through goals and objectives." >> >> Your words (...BSIMM fails...) imply (to me) that you posit >> organizations attempting to use the collected wisdom in BSIMM will, >> inexplicably, look at it and say "Okay, we have to do all 110 of >> these things exactly as written, so let's get started" without regard >> to their local need. This is as opposed to, say, looking at it and >> thinking "Here's what nine companies have spent dozens of >> person-decades and millions of dollars learning about what works; >> let's see what we can glean from that." Uh, okay. >> >> Yes, previous models exist. Although it may have come up in >> conversation, we did not ask any of the nine something like "What >> model did you start with back in the beginning?" because it simply >> isn't relevant to what we're trying to accomplish (documenting what >> successful organizations are doing), just as "could" and "should" >> aren't relevant. We asked "What *are* you doing now?" and documented >> it so others could learn from it. >> >> --Sammy. >> >> -Original Message- From: Pravir Chandra >> [mailto:chan...@list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: >> Sammy Migues; sc-l-boun...@securecoding.org; sc-l@securecoding.org >> Subject: Re: [SC-L] Positive impact of an SSG >> >> Yes, I don't think its exclusive to your BSIMM interviews that you >> found when people put controls into place, they saw improvement. >> That's what I (and I'm sure many other consultanting firms) have been >> doing for years based upon previous models (CLASP, MS SDL, etc.). >> Nothing to do with BSIMM per se (actually, most of what DTCC started >> doing was based on CLASP), just that they added controls 'early into >> software development lifecycle' and saw benefit, which isn't >> surprising. >> >> That being said, the important part we're missing as 'software >> security guys' isn't the specification of all the possible things >> that an organization *could* do, but rather what a given organization >> *should* do based on good business decisions around risk management. >> And that's the crux of what BSIMM fails to do. By basing the current >> maturity model on the collected practices of 9 massive firms that >> spend the
Re: [SC-L] Positive impact of an SSG
Ben: I agree with the points you make. I think you captured my point nicely. Sammy: I didn't intend to imply that I thought organizations would lose their minds and "inexplicably" try to do everything. I think you misunderstood my point which is: A useful maturity model must be prescriptive and BSIMM isn't since, as you quote, it doesn't answer the hard questions of what companies *should* be doing. So, I think its a useful study/catalog of what a sampling of big companies do for software security, but organizations at large won't be able to pick it up and run with it without serious outside help. p. ~ ~ ~~~~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Benjamin Tomhave Date: Wed, 11 Mar 2009 10:48:13 To: sc-l@securecoding.org Subject: Re: [SC-L] Positive impact of an SSG I think it's an interesting leap of faith. Statistically speaking, 9 is a very small sample size. Thus, the proposed model will be viewed skeptically until it is validated with a much larger and more diverse sample. Putting it another way, there's no way I can take this to a small or medium sized org and have them see immediate relevance, because their first reaction is going to be "those are 9 large orgs with lots of resources - we don't have that luxury." You quoted "we can say with confidence that these activities are commonly found in highly successful programs" - how do you define a "highly successful program"? What's the rule or metric? Is this a rule or metric that can be genericized easily to all development teams? My concern is exactly what you speculate about... organizations are going to look at this and either try to tackle everything (and fail) or decide there's too much to tackle (and quit). In my experience working with maturity models as a consultant, very few people actually understand the concept. Folks are far more tuned-in to a PCI-like prescriptive method. Ironically, the PCI folks say the same thing you did - that it's not meant to be prescriptive, that it's supposed to be based on risk management practices - yet look how it's used. Maybe you've addressed this, but it doesn't sound like it. I'd perhaps be better educated here if the web site wasn't down... ;) -ben Sammy Migues wrote: > Hi Pravir, > > Thanks for clarifying what you're positing. I'm not sure how we could > have been more clear in the BSIMM text accompanying the exposition of > the collective activities about the need to take this information and > work it into your own culture (i.e., do "risk management"). As a few > examples: > > p. 3: "BSIMM is meant as a guide for building and evolving a software > security initiative. As you will see when you familiarize yourself > with the BSIMM activities, instilling software security into an > organization takes careful planning and always involves broad > organizational change. By clearly noting objectives and goals and by > tracking practices with metrics tailored to your own initiative, you > can methodically build software security in to your organization’s > software development practices." > > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in > what order can be a challenge. We suggest creating a software > security initiative strategy and plan by focusing on goals and > objectives first and letting the activities select themselves. > Creating a timeline for rollout is often very useful. Of course > learning from experience is also a good strategy." > > p. 47: "Of the 110 possible activities in BSIMM, there are ten > activities that all of the nine programs we studied carry out. Though > we can’t directly conclude that these ten activities are necessary > for all software security initiatives, we can say with confidence > that these activities are commonly found in highly successful > programs. This suggests that if you are working on an initiative of > your own, you should consider these ten activities particularly > carefully (not to mention the other 100)." > > p. 48: "The chart below shows how many of the nine organizations we > studied have adopted various activities. Though you can use this as a > rough “weighting” of activities by prevalence, a software security > initiative plan is best approached through goals and objectives." > > Your words (...BSIMM fails...) imply (to me) that you posit > organizations attempting to use the collected wisdom in BSIMM will, > inexplicably, look at it and say "Okay, we have to do all 110 of > these thin
Re: [SC-L] Positive impact of an SSG
Yes, I don't think its exclusive to your BSIMM interviews that you found when people put controls into place, they saw improvement. That's what I (and I'm sure many other consultanting firms) have been doing for years based upon previous models (CLASP, MS SDL, etc.). Nothing to do with BSIMM per se (actually, most of what DTCC started doing was based on CLASP), just that they added controls 'early into software development lifecycle' and saw benefit, which isn't surprising. That being said, the important part we're missing as 'software security guys' isn't the specification of all the possible things that an organization *could* do, but rather what a given organization *should* do based on good business decisions around risk management. And that's the crux of what BSIMM fails to do. By basing the current maturity model on the collected practices of 9 massive firms that spend the most on that problem, anyone (aside from firms in a similar situation to your 9) that attempts to apply it to their organization effectively throws risk management decisions out the window and commits to a much more costly solution than they could have created based on the knowledge of their own business needs since all the practices are based solely on the behaviors of the select few firms you interviewed. I'm not discounting the validity of the empirical data, I'm just positting that it isn't scientifically valid for solving the problem at hand. I'm interested to hear what you learn when you get to the small and medium sized businesses as well as firms using agile development models (something I particularly considered and accounted for with SAMM). Regardless of whether we agree on the percentage of orgs for which a dedicated SSG isn't cost effective, I'm sure we can agree that affording 'someone in charge of success' doesn't equate to a dedicated SSG. There's a myriad of ways that can be accomplished in any organizational structure. Thanks! p. ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Sammy Migues Date: Tue, 10 Mar 2009 23:15:39 To: sc-l@securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hi Pravir, Yes, I agree completely: the data gathered in the BSIMM interviews seem to indicate that "the controls over all" led to what the interviewees saw as improvements in their capability to produce secure software. In the nine companies interviewed, those controls (BSIMM activities, I think) sprang from well established SSGs -- that is, a specific person or persons with the responsibility for ensuring lots (110, collectively) of activities actually get done. The BSIMM data to date from specific large organizations indicate that a little under 100:1 is the average ratio for dev/QA to SSG size. It'll be interesting to see how this changes when we get to interviewing smaller organizations and we see if and how they're actually getting it done. Personally, I don't believe I agree with your guess that 95% of organizations building code can't afford an SSG. I believe every organization that wants to succeed can afford to have someone in charge of success, but that's just my opinion and isn't relevant to BSIMM. Cheers, --Sammy. -Original Message- From: Pravir Chandra [mailto:chan...@list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: Sammy Migues Cc: sc-l@securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM > (bsi-mm.com). Since we built the model directly from the data gathered, each > activity is actually being done in one of the nine organizations interviewed. > The question is whether there's any evidence the activities are actually > effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this > recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one > of the nine organizations interviewed), is quoted as follows relative
Re: [SC-L] Positive impact of an SSG
Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM > (bsi-mm.com). Since we built the model directly from the data gathered, each > activity is actually being done in one of the nine organizations interviewed. > The question is whether there's any evidence the activities are actually > effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this > recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one > of the nine organizations interviewed), is quoted as follows relative to the > impact of software security group activities: > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > "One of Routh's big wins is inserting security controls early into software > development lifecycle at the DTCC. Vulnerabilities are weeded out well before > they appear in functional code that ends up in production and that has > resulted in close to $2 million in productivity gains on a base of $150 > million spend for development, Routh says. > > "Those gains are exclusively the result of having mature and effective > controls within our system and software development lifecycle," Routh says. > This is a three-year-old initiative that educates and certifies developers in > all DTCC environments in security. Developers are also provided with the > necessary code-scanning tools and consulting and services help to keep > production code close to pristine." > > --Sammy. > > Sammy Migues > Principal, Technology > 703.404.5830 - http://www.cigital.com > Software confidence. Achieved. > smig...@cigital.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. > ___ > -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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. ___
[SC-L] Relationship between BSIMM and SAMM
Hey Everyone. You've probably seen the posts I've made to sc-l about the Software Assurance Maturity Model (SAMM) and I'm sure you've seen the latest from Gary with the BSIMM. Lots of folks have pinged me over the last two days about the relationship between the two (short answer: they're different), so I blogged about it here: http://www.opensamm.org/2009/03/whats-up-with-the-other-model/ Thanks! p. ~ ~ ~~~~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors
On Thu, Jan 15, 2009 at 12:35 AM, Stephen de Vries wrote: > Interesting articles, and they really whet the appetite for more of > your maturity model. Can we expect a public/open release? Since you made mention of the maturity model, I'll toss in my shameless plug for the SAMM project (Software Assurance Maturity Model). For now, only a Beta is available, but it was heavily debated and refined at the OWASP Summit in November and a new revision is imminent (within the month). In the mean time, check out the Beta at: http://www.opensamm.org/downloads/SAMM-BETA-0.8.1.pdf As soon as the next version is ready, we'll be launching it as an OWASP project to serve as a new revision to the CLASP project, if you're familiar with that. I've also been talking to a number of vendors (both product and services) about supporting the SAMM project and things are looking positive so far. I encourage anyone with data, ideas, or motivation to ping me and get involved. p. -- ~ ~ ~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] top 10 software security surprises
Hey All. On the topic of maturity models, in Gary's first article he mentioned a draft model I created. Since I've mostly been discussing it in OWASP circles, I wanted to point out the Software Assurance Maturity Model (SAMM) project at http://www.opensamm.org I kicked off that work based on a few years experience running with CLASP and with help from the guys at Fortify. Currently, there's a BETA release ( http://www.opensamm.org/downloads/SAMM-BETA-0.8.1.pdf), but a new revision should be available by the end of year. That next revision will reflect feedback from individual reviewers, output from OWASP working sessions, and much of the real-world feedback that Gary talks about below. I'm always interested to hear comments/questions/flames, so please feel free to download it and send any feedback. Thanks! p. On Tue, Dec 16, 2008 at 10:25 AM, Gary McGraw wrote: > hi sc-l, > > Using the software security framework introduced in October (A Software > Security Framework: Working Towards a Realistic Maturity Model < > http://www.informit.com/articles/article.aspx?p=1271382>), we interviewed > nine executives running top software security programs in order to gather > real data from real programs. Our goal is to create a maturity model based > on these data, and we're busy working on that (stay tuned here for more). > However, in the course of analyzing the data we gathered, we unearthed some > surprises that we share in this month's informIT article: > > http://www.informit.com/articles/article.aspx?p=1315431 > > My bet is that some of the findings will come as a surprise to sc-l readers > as well. Check the article out. > > Merry New Year to you all. > > 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. > ___ > -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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. ___
