Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

2009-08-26 Thread Pravir Chandra
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

2009-08-25 Thread Pravir Chandra
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

2009-07-30 Thread Pravir Chandra
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

2009-04-30 Thread Pravir Chandra
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

2009-03-25 Thread Pravir Chandra
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)

2009-03-20 Thread Pravir Chandra
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

2009-03-11 Thread Pravir Chandra
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 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~

-Original Message-
From: Sammy Migues smig...@cigital.com

Date: Tue, 10 Mar 2009 23:15:39 
To: sc-l@securecoding.orgsc-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 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

Re: [SC-L] Positive impact of an SSG

2009-03-11 Thread Pravir Chandra
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

2009-03-11 Thread Pravir Chandra
:

 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

2009-03-10 Thread Pravir Chandra
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

2009-01-15 Thread Pravir Chandra
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

2008-12-16 Thread Pravir Chandra
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.
___