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] goertzel_ka...@bah.com 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]goertzel_ka...@bah.com 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 chandraatlistdotorg 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) colin.cass...@ge.com 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 chandraatlistdotorg 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 chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: John Steven jste...@cigital.com Date: Thu, 30 Jul 2009 17:20:52 To: Secure CodingSC-L@securecoding.org 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 questionfor yearshas been ³conduct your SA on source code or binary?². You can see that there are interesting subtleties in even those languages that target intermediate representational formats (like Java and the .NET family of languages that compiles to MSIL). The garbage-collection-optimization problems that plague those asking ³How do I assure password String cleanup in Java² are of the same ilk as the gcc optimizations that trouble the C/C++ realm. Yes, this question is still pertinent. It_is_ interesting to those looking for thorough/sound analysis to consider fidelity and resolution at this level. People are beginning to echo what I've been saying for years, this problem extends beyond the initial compile into the runtime optimizations and runtime compilers. My previous post reiterates that there's a lot more to it than most people consider. I think I allowed that clarification to muddle my more strategic point: - Whereas THE question used to be source code vs. binary representation, the question is NOW: What set of IOC-container/XML combos, aspect weaver results, method/class-level annotations, and other such tomfoolery governs the execution of my application beyond what the compiler initially output? - As Fortify, Veracode, and others punch out this 'static analysis on binaries via SAAS' battle, they and the organizations they serve would do well to keep this question in mind... Or risk the same failures that the current crop of parser-based static-analysis tools face against dynamic approaches. -jOHN On 7/29/09 8:44 AM, John Steven jste...@cigital.com 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
[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 chandraatlistdotorg 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 k...@krvw.com 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 chandraatlistdotorg 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 chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Goertzel, Karen [USA] goertzel_ka...@bah.com Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhavelist-s...@secureconsulting.net; Secure Code Mailing ListSC-L@securecoding.org 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
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 chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Benjamin Tomhave list-s...@secureconsulting.net Date: Wed, 11 Mar 2009 10:48:13 To: sc-l@securecoding.orgsc-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 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
Re: [SC-L] Positive impact of an SSG
: 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 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 chandraatlistdotorg PGP: CE60 0E10 9207 7290
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 smig...@cigital.com 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 chandraatlistdotorg 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 step...@twisteddelight.org 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 chandraatlistdotorg 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 g...@cigital.com 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 chandraatlistdotorg 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. ___
