Software Security Training for Developers

[yo at secappdev.org (Johan Peeters)]

On 8/20/07, Hollis via Rubicon Recluse <hollis at rubiconrecluse.com> wrote:
> 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?

On the one hand, we would like to be technology-neutral, on the other,
we want to teach people about real-world technologies and security
issues, so we tend to cherry-pick technologies to suit the purposes of
the principles we are trying to illustrate. For example, the access
control module has tended to have a lot on Windows because their model
is somewhat richer than the Unices'. Language-based security
mechanisms discussions, on the other hand, have focused mainly on Java
because of their seminal significance.

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

At the last presentation, 25-30%% of the time was spent on the
infrastructure at the disposal of the developer, including
language-based, OS, middleware and  cryptography.

> - How long is the/each course?
> - did you go with inclass, self-paced, JIT or a
> combination. And which aspects to each?

The secappdev courses take one week in-class, but, as I mentioned,
recordings are mostly available on-line, giving the opportunity for
self-paced or JIT study. Let me also clarify that secappdev.org only
offers public courses, so, as an organization, we are not in a
position to taylor content to the specific needs of a particular
project though a number of the people on the secappdev faculty would
take on such assignments.

> - What is your audience size? And what percentage did you train?

I am not sure that I understand your question. We have limited the
number of participants to 25 in the past. At the last presentation,
all these seats were taken. We are now increasing the number of places
offered to 50, but offering a dual track course so that, in a sell-out
scenario, the average class size will again be 25.

> - 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
>
> At 11:51 AM 8/19/2007, Johan Peeters wrote:
> > > From my experience with secappdev.org (http://secappdev.org), a
> > not-for-profit organization set up to create security awareness and
> > improve skills in the developer community, I find myself in agreement
> > with many of the points that Sammy raises.
> > Development is not only about coding. secappdev tends to pay
> > relatively little attention to coding; adoption of new technologies
> > offering novel opportunities to shoot yourself in the foot is so
> > rapid, platforms so varied and applications so different that we have
> > found teaching secure software engineering principles to be a better
> > investment for both students and teachers alike. While it is certainly
> > true that what ultimately matters is the code, conventional wisdom has
> > it that coding only accounts for about 20% of the development effort.
> > The rest of the time is spent in specification, design, test,
> > deployment and project management. We feel it is counter-productive to
> > draw sharp distinctions between these various activities, they all
> > need to be done well to deliver a succesful project. So we spend
> > considerable time looking at their security implications.
> >
> > Apart from chiming in with Sammy, I would also like to point out that
> > our target audience are application developers and their main focus is
> > definitely not security, nor should it be: their job is to create
> > value by adding functionality. Rather than teaching them to become
> > security experts, we try to teach them strategies for getting away
> > with as little security knowledge as possible so that they can focus
> > on their core concerns.
> > So one of the things we do is to make sure that participants have a
> > good grasp of the security services offered by application platforms.
> > An example of an architectural level discussion would be the choice of
> > platform and its impact on security as well as how to mitigate the
> > risks.
> >
> > Effective security teaching imparts a mindset, the body of knowledge
> > is incidental. So we have a strong commitment to teach small groups
> > with plenty of opportunity for interaction and immersion. At the next
> > presentation, we are increasing the number of workshop sessions
> > requiring participants to actively participate in problem-solving.
> >
> > So far, all secappdev.org presentations have been in Belgium and that
> > may be a little out of the way for some/most of you. However,
> > recordings of most of the last presentation are available from the web
> > pages with the descriptions of individual sessions - mail me if you
> > need fuller instructions.
> > The next presentation is planned for the week starting March 3rd 2008.
> > This will be a dual-track event. I hope to be able to publish the
> > program very soon.
> >
> > kr,
> >
> > Yo
> >
> > On 8/17/07, Sammy Migues <SMigues at cigital.com> wrote:
> > > 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
> > >
> > >
> > > ________________________________
> > > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> > > On Behalf Of McCown, Christian M
> > > Sent: Thursday, August 16, 2007 7:23 PM
> > > To: sc-l at 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 how to implement these concepts  in your
> > > language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting
> > > the most bang for the buck from them.
> > >
> > >
> > > What vendors teach it?
> > > How much does it cost?
> > > Actual impact realized?
> > >
> > > Tx
> > >
> > > ____
> > > Chris McCown, GSEC(Gold)
> > > Intel Corporation
> > > ( (916) 377-9428 | * c.mccown at intel.com
> > > _______________________________________________
> > > Secure Coding mailing list (SC-L) SC-L at securecoding.org
> > > List information, subscriptions, etc -
> > > http://krvw.com/mailman/listinfo/sc-l
> > > List charter available at -
> > > http://www.securecoding.org/list/charter.php
> > > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> > > as a free, non-commercial service to the software security community.
> > > _______________________________________________
> >
> >
> > --
> > Johan Peeters
> > http://johanpeeters.com
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L at securecoding.org
> > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> > as a free, non-commercial service to the software security community.
> > ___________________________________________K&??;?


-- 
Johan Peeters
http://johanpeeters.com