Re: Strategies for teaching secure coding practices

["Jeff Williams @ Aspect" <jeff.williams () aspectsecurity com>]

I think we have to go *beyond* just using anecdotes and realize that the
only way to understand vulnerabilities is to learn about them in context.
In law school, we used the "case-book" method for exactly this reason.  You
can't understand the law in the abstract -- you need a set of facts.

I think many developers are in this situation. We tell them abstract rules
for secure programming, and they don't remember them because they're not
applied to anything. I'd love to see a course that used a set of well-known
vulnerabilities as a way of teaching security to developers.

We wrote OWASP WebGoat to help overcome this problem. It's a J2EE
application with real vulnerabilities structured as lessons.  Developers get
hands on experience with the code and the vulnerabilities it contains.

--Jeff

Jeff Williams
Aspect Security
http://www.aspectsecurity.com



----- Original Message ----- 
From: Jared W. Robinson
To: Carl G. Alphonce
Cc: [EMAIL PROTECTED]
Sent: Friday, December 12, 2003 4:32 PM
Subject: Re: [SC-L] Strategies for teaching secure coding practices


On Fri, Dec 12, 2003 at 10:05:49AM -0500, Carl G. Alphonce wrote:
> ... I am very interested to hear from the list what you all
> consider to be important "secure coding" topics to cover in these
> first-year classes.  Also, what topics to you feel should be covered
> in an undergraduate curriculum but later than the first year?

I find that anecdotal stories are important to emphasize the importance
of secure coding practices. You could say something like "Who remembers
the Blaster, Welchia or SoBig worms? They are estimated to have caused X
million dollars in damage. The worms exploited a buffer overflow, which
is what we're going to talk about today...."

It's also important to teach studends some basic risk assessment. For
example, What is the risk of shipping the product with buffer overflow
bugs? How will the product be used and in what environment?  What kinds
of security requirements does the customer have?

Remember that security is not usually the goal of building software.
Building a tool that helps people solve problems (usually so that you
can make a profit) is the goal.  Unfortunately, there are security
threats that will make the tool unable to deliver value, so developers
have to plan countermeasures that will mitigate those threats in a
cost-effective manner. Not all countermeasures are worth the cost they
take to implement. Some countermeasures introduce other risks.

If people focus too much on security, they may never deliver a product
that can make enough money to fund continued development. Not only that,
but software is never completely "secure". It can only be "secure
enough" for a certain set of conditions.

Risk assessment can help define "secure enough".

- Jared Robinson

-- 
"It's a well known technology truism that [not] all of the smart people
work for you, and that one of the surest ways to success is to get more
ideas and more work out of people outside your own fences."
- Tim O'Reilly