SANS List etc..

[gem at cigital.com (Gary McGraw)]

Dr. Bishop,

I bow to you.

sc-l cohorts, don't forget that Matt was a Silver Bullet victim pretty recently.  Listen here:
http://www.cigital.com/silverbullet/show-031/

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 1/15/09 2:50 PM, "Matt Bishop" <bishop at cs.ucdavis.edu> wrote:

As an academic who does teach this stuff whenever they let me in a
classroom ...

> I'll address your third point.  I am ALL FOR teaching software
> security at the university level (and have been actively working
> with universities for over a decade).  I just don't think it is
> realistic to try to push the problem off on universities and hope
> that they will solve it.

WHOLEHEARTEDLY AGREE!!!!! Companies, purchasers, etc. have to help.
The old saw of "working together" is, I believe, actually true. I have
about 50 other cliches here that I could add, but I'll not bore you
with them.

> As I have said, I would love to be proven wrong regarding my opinion
> on whether adding software security to a curriculum us realistic.
> For more on this, see page 98 of "Software Security" <http://www.swsec.com
> > .

Hey, that's cool -- I forgot about the page. Thanks for the plug! At
any rate, I do think it's realistic to add software security to the
curriculum, but I think it's horribly *un*realistic to think that
taking a class in it will solve the problems (and requiring students
to take a class in it won't change that). You have to practice it,
just like you have to practice writing.

> I do hope that academic programs will not focus on the bug parade
> approach, however.  Building a course around the OWASP top ten or
> the CWE/SANS top 25 would be rather silly.  I would rather see vulns
> like this covered in every programming course and a software
> security course focused on the touchpoints (especially code review
> and architectural risk analysis).

I'd emphasize *why* these problems occur, and use the Top 25 list to
explain what happens when you don't follow the principles. You can
then show how to apply the principles to prevent (or at least limit)
these problems. That will cut down on problems before code review.

And then you teach code review. You need to teach both how to do it
right and how to catch problems when it is not done right, because I
don't know anyone who *always* does it right. Perfection may be the
goal, but it's not the reality.

> One thing emphasized by outstanding software security initiatives
> (think Microsoft) is that teaching developers and architects how to
> do things right is far superior to an after the fact analysis
> approach driven by audit and regulations.

A very academically sound approach :-)

Matt