Re: [SC-L] BSIMM-V Article in Application Development Times

[Sammy Migues]

Hi Stephen,

I agree that would be interesting. While we have data at the firm level for all 
BSIMM participants, and at the BU level for many BSIMM participants, we don't 
formally capture data on development methodology (as opposed to software 
security activities) for each development team (which may number well into the 
double digits for many BSIMM participants).

Also, in nearly all cases, it would be very hard to characterize an entire firm 
or even an entire business unit in larger firms as "Agile" or not. Many larger 
firms use "Agile" for only a small percentage of projects (e.g., for mobile or 
cloud things, if they're a traditional waterfall shop and are just evolving 
into new technology stacks). Even those firms who "do Agile" often do it in 
different ways across different development teams, even in the same business 
unit. The teams with very large applications or critical applications that go 
through more testing might do 3-4 week sprints while others do 2-week sprints. 
However, they might be using exactly the same process, so I'm not sure the 
frequency of deployment would work as the measure of "agility."

As for writing "Agile" rather than Agile above, firms and teams who call 
themselves "Agile" mean many different things with that word. I've run into 
some teams who feel very agile in their quarterly development cycles and at 
least one that "scrums" its way through various parts of their waterfall 
process.

Cheers,

--Sammy.

-Original Message-
From: SC-L [mailto:sc-l-boun...@securecoding.org] On Behalf Of Stephen de Vries
Sent: Tuesday, December 17, 2013 5:21 AM
To: Gary McGraw
Cc: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM-V Article in Application Development Times


On 13 Dec 2013, at 22:51, Gary McGraw  wrote:
> 
> From time to time we talk about getting to the dev community here.  This 
> article is at least in the right publication!
> 
> Read it and pass it on: 
> http://adtmag.com/blogs/watersworks/2013/12/bsimm-v-released.aspx

Hi Gary,

In the current BSIMM-V dataset is it possible to narrow the data down to only 
organisations practising Agile dev?  I think it would be interesting to see 
which BSIMM activities are popular with agile houses, and which not.

Ideally, it would be nice to not only differentiate between Agile and 
non-agile, but different degrees of agile based on the length of iterations 
and/or the frequency of deployments.  E.g. less-agile = 3 month iterations and 
multi-month deploys, more-agile = continuous delivery with multiple deploys per 
day.


regards,


Stephen de Vries

http://www.continuumsecurity.net
Twitter: @stephendv



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Application Security Debt and Application Interest Rates

[Sammy Migues]

Just in case others have missed it, there's a response from Russell Thomas on 
the New School blog at 
http://newschoolsecurity.com/2011/03/fixes-to-wysophal's-application-security-debt-metric/.



From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of Chris Wysopal
Sent: Friday, March 04, 2011 7:38 PM
To: SC-L@securecoding.org
Subject: [SC-L] Application Security Debt and Application Interest Rates


I have a couple of blog posts modeling application vulnerabilities the way you 
might think of technical debt.

Part I: Application Security Debt and Application Interest Rates
http://www.veracode.com/blog/2011/02/application-security-debt-and-application-interest-rates/

Part II: A Financial Model for Application Security Debt
http://www.veracode.com/blog/2011/03/a-financial-model-for-application-security-debt/

-Chris

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Julia Allen podcast on BSIMM

[Sammy Migues]

Hello everyone, 

Julia Allen, a senior researcher over at CERT, did a podcast with Gary, Brian, 
and me several weeks ago on the Building Security In Maturity Model (BSIMM).

You can listen to the results over at 
http://www.cert.org/podcast/show/20090331mcgraw.html. We talk a little about 
our mindset when starting the BSIMM research and our goals for the business 
uses.

Just as a reminder, BSIMM was released under Creative Commons license and is 
freely available at http://bsi-mm.com.

--Sammy.

___
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] Supply Chain Resiliency Project Assistance

[Sammy Migues]

Hello everyone,

To reinforce Mason's request, we're looking for any collection of "controls" 
(contractual, technical, people, process, etc.) that organizations should 
request, demand, cajole, enforce, etc. when out-sourcing software development 
to ensure the required "software security" in the resulting deliverable. For 
the purposes of this exercise, you can define "controls" and "software 
security" as broadly as you like and we'll sort it out later.

Our next meeting with Jim is Tuesday afternoon and any pointers to public 
information, or copies of shareable non-public information, you can provide 
will be much appreciated.

Thanks,

--Sammy.

-Original Message-
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of Mason Brown
Sent: Sunday, March 22, 2009 9:09 AM
To: 'Secure Code Mailing List'
Subject: [SC-L] Supply Chain Resiliency Project Assistance

 
Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a
project for the Financial Services ISAC.  There is a lot of knowledge on
this list and I was hoping you might be willing to offer your thoughts.
Below is the request from Jim.  If you have thoughts or data and could
share it, I'll be happy to collate and send back to the list or to anyone
that requests.  After he presents it to the FS-ISAC in May, the complete
information will be made public.

Important project if your organization uses contractors and outsourcers to
design, build or deploy important applications. Jim Routh, CISO at
Depository Trust and Clearing Corporation (and one of the top CISOs in
implementing application security), leads a broad industry team
identifying leading practices in improving supply chain resiliency --
specifically in the area of procurement for outsourcing software
development and services. They have asked for your help in finding sources
of information in the public domain and/or descriptions of a practice or
control that you have used that actually mitigates one or
more risks. If you have experience or knowledge of security controls and
practices specific to the outsourcing of application development through
service providers please send a note to Mason Brown at mbr...@sans.org.
This can include things like sample contract language or URLs
information/resources you have seen or used. We will provide a summary of
the information to anyone who contributes or expresses and interest in
seeing the results.


***
Action Required: 

Give some thought to helpful information on security controls and
practices specific to the outsourcing of application development work
through service providers that will help improve the resiliency of the
supply chain that may be in two categories: 

1. Source information in the public domain with reference information on
where to find it (eg: url) 
2. Description of a practice/control along with a summary of the risks
mitigated

We are striving to create a summary of practices/controls for
consideration for those organizations interested in significantly
increasing their supply chain resiliency and mitigate the risk of sabotage
of supply chain sources. This information along with the survey results
will provide the information security professional with a source of
information enabling him/her to determine the appropriate
practices/controls for his/her organization. 



Mason Brown, Director
SANS Institute (www.sans.org)
865-692-0978 (w)
 

Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in
Baltimore, MD http://www.sans.org/info/39248 

"SANS courses are hands-down the best security courses in the industry." -
Scott Hiltis, Bruce Power

___
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

[Sammy Migues]

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 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

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

[Sammy Migues]

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 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] Positive impact of an SSG

[Sammy Migues]

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.
___

[SC-L] Human Elements of Security Survey

[Sammy Migues]

Hello everyone,

Cigital and Safelight Security Advisors are conducting a survey to understand 
the practices organizations are using to deal with some of the human elements 
surrounding software security risk. We'd sincerely appreciate participation by 
this audience and invite you to take that survey by October 28th at: 
https://www.surveymonkey.com/s.aspx?sm=ksU2a8N56_2fJNir5961VPUA_3d_3d. 
JavaScript is required on SurveyMonkey.

All respondents who provide sufficient contact information will receive a 
complimentary copy of the anonymized, summary best practices report based on 
the survey findings and a chance to win one of 3 Apple iPod touch devices.

Thank you for your participation.

Sincerely,

Michael Maziarz
Safelight Security Advisors
[EMAIL PROTECTED]

Sammy Migues
Cigital
[EMAIL PROTECTED]

___
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] Software Security Training for Developers

[Sammy Migues]

Hi Hollis,

Thanks for the questions. I think this is the kind of information you're 
looking for and I've tried to keep my answers very non-salesy.

>- What languages/OS/environments are you developing in?

Well, we're a consultancy, so we develop in whatever language the client 
desires. (:-)

As for our defensive programming courses, we focused on JavaEE, core Java, 
.NET, and C/C++. We have had recent requests for COBOL, but not for PHP, Ruby, 
or Python, as examples.

>- Does your training address your language/OS/environment? If so, what 
>percentage?

If I understand correctly, the answer is most training addresses it. As odd as 
it may seem, the general market demand is for good defensive programming 
techniques in the native language. Many customers ask for customization based 
on their threat model and specific business objectives. A smaller percentage 
ask for course customization for general technologies (e.g., encryption) and a 
much smaller percentage ask for customization based on the frameworks they are 
using (e.g., Spring and Acegi). On the other had, they all hate seeing examples 
from frameworks they don't use.

>- How long is the/each course?

We build most of our courses as 1-day modules that can be linked together 
(e.g., one group of lead architects and lead developers might get Fundamentals, 
then Architecture Risk Analysis, then Defensive Programming, while some QA 
folks might get Fundamentals, then Security Requirements and Abuse Cases, then 
Risk-Based Security Testing, and so on). A lot of organizations simply can't 
shut down development or testing for more than a day or two at a time.

>- did you go with inclass, self-paced, JIT or a combination. And which aspects 
>to each?

All our classes are initially developed as instructor-led training. Some are 
then re-cast as eLearning.

>- What is your audience size? And what percentage did you train?
>- Over what period of time?

For Fundamentals classes, we can deal with larger class sizes (e.g., 30). For 
Defensive Programming, we try to cap at 20 due to the nature of the labs and 
the time it takes to get through the questions. For Architecture Risk Analysis, 
a smaller class size is a little better because it's so interactive.

Between on-site classes, conference tutorials, some public training, and so on 
for analysts, architects, developers, and testers, we've trained thousands of 
individuals over the years

>- Was it mandatory? And to Sammy's point, at what management level was it 
>loudly supported?

Well, it was being paid for, so it was always mandatory. (:-) The more 
interesting question may be "Did the students go willingly?" Whenever we had 
time to work with management to craft a message appropriately tuned to the 
intended audience, we've had good, willing participation. The management level 
we've worked with has varied from head of engineering up to the CIO.

--Sammy.


-Original Message-
From: Hollis via Rubicon Recluse [mailto:[EMAIL PROTECTED]
Sent: Monday, August 20, 2007 2:09 PM
To: Johan Peeters
Cc: Sammy Migues; sc-l@securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers

Hi Sammie and Yo,

Tkx for the good highlevel insights. A few
questions, I'm interested specifically for
developer/designers, but I'm sure others are interested in other audiences:

- What languages/OS/environments are you developing in?
- Does your training address your
language/OS/environment? If so, what percentage?
- How long is the/each course?
- did you go with inclass, self-paced, JIT or a
combination. And which aspects to each?
- What is your audience size? And what percentage did you train?
- Over what period of time?
- Was it mandatory? And to Sammy's point, at what
management level was it loudly supported?

Thanks for your insights,
Hollis


___
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] Software Security Training for Developers

[Sammy Migues]

Hi Chris,

My experience is that, like most engineers, most software developers want to 
improve their skills and that, as a group, they hate making easily-avoidable 
mistakes of any sort. Training that focuses on reinforcing their existing 
skills in design and development and then works methodically to give them the 
extra layer of knowledge to make the code not only function, but also behave 
with respect to security, is almost always well received. Any training that 
comes across as, "You're doing it wrong, stop everything and do it this way" 
will almost always be ignored. No one has time for that.

Internal groups and others who are getting started in developer training tend 
to create "bug parade" kinds of materials. You'll see slide after slide of 
five-line code snippets while the instructor says "That's wrong, don't do 
that." That kind of mistake detection is often so easily automatable these 
days, that buying or building training for it, and taking all your developers 
out of action for a day or two to run through it, may not be the best choice.

As you alluded to, we need to teach developers how to actually write secure 
code. The problem, however, is that the march of development methods, 
languages, frameworks, architectures, and so on means there usually cannot be a 
single approach for, by way of example, coding input validation routines. On 
the whole, the industry is at the stage where we need to teach developers to 
recognize situations where "security goes here," and give them the reasoning 
skills and prescriptive guidance to code their way out of the problem in their 
particular environment.

This kind of defensive programming training seems to be most valuable these 
days and it takes real experience and real experts to create and deliver such 
material.

Meanwhile, it takes more than educated developers to produce software that 
behaves appropriately in the face of attack. The requirements people also need 
some help and it's unlikely the business analysts, the architects, and the 
testers are sufficiently considering the non-functional security aspects of the 
thing they are trying to bring to life. Of cause, the operations folks also 
need to understand their part in the "secure software" lifecycle. In addition, 
executives need to understand how to govern and managers need to understand how 
to facilitate.

By way of full disclosure, I've spent a great deal of time building such a 
cross-cutting curriculum at Cigital, which we've delivered to a variety of 
financial services, independent software vendor, and other organizations.

As for pricing, I've seen everything from a few hundred dollars per person for 
material you could effectively download yourself to $12,000 or more per day for 
a few slides and one big exercise that may have nothing to do with a group's 
particular needs. I've also seen a few examples of some really good stuff that 
just "speaks to me." Organizations must make sure they're getting an instructor 
that thoroughly understands the material and that they've worked with the 
training provider to ensure the material is appropriately customized to their 
needs.

Effectiveness is in the eye of the beholder. The actual impact of developer 
training alone may take months to show up in even the most mature dashboard. 
More broad training across each of the key roles, appropriately supported by 
prescriptive guidance and automation, has historically shown a recognizable 
impact (e.g., finding many more security-related bugs much earlier in the SDLC) 
much more quickly.

I recently put together some (long) thoughts on an approach for training. You 
can see them at 
http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/.


--Sammy.

Sammy Migues
Director, Knowledge Management and Training
703.404.5830 - http://www.cigital.com<http://www.cigital.com/>



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, 
Christian M
Sent: Thursday, August 16, 2007 7:23 PM
To: sc-l@securecoding.org
Subject: [SC-L] Software Security Training for Developers



What are folks' experiences with software security training for developers?  By 
this, I'm referring to teaching developers how to write secure code.  Ex. 
things like how to actually code input validation routines, what "evil" 
functions and libraries to avoid, how to handle exceptions without divulging 
too much info, etc.  Not "how to hack applications".  There are quality courses 
and training that show you how to break into apps--which are great, but my 
concern is that if you are a developer (vs. a security analyst, QA type, 
pen-tester, etc.),even when you know what could happen, unless you've been 
specifically taught h