RE: Education and security -- another perspective (was "ACM Queue - Content")

["Wall, Kevin" <Kevin.Wall () qwest com>]

Fernando Schapachnik wrote...

> I've considered 'secure coding' courses, and the idea always 
> look kind oversized. How much can you teach that students can't read 
> themselves from a book? Can you fill a semester with that? I'm
> interested in people's experiences here.

I suppose that depends largely on how you define "secure coding"
and how much depth you want to go into.

For the past 2 years I've taught a CS masters level course in
computer security. In addition to "secure coding" practices, I
also discuss:

    * fundamental concepts of security (e.g., authentication,
      authorization, confidentiality, data integrity, nonrepudiation,
etc.);
    * risk management and threat models;
    * cryptographic foundations;
    * authentication, access control, and auditing;
    * common threats and vulnerabilities, and
    * designing secure systems.

For the most part, because of time constraints and the fact that we are
trying to cover broader things then simply coding-related issues, the
"secure coding" practices are interspersed with the other topics, where
and when appropriate. (If you want more detail, you can find the
syllabus
at http://cs.franklin.edu/Syllabus/comp676/.)

> Adding a 'security chapter' to existing courses seems more 
> appropiate (at least to me). At the end of our Programming II
> course, I showcase students the vulnerabilities that can be
> understood or are related with what they've saw in
> class: these includes buffer overflows, input validation, integer
> over/underflows, race conditions, least priviledge, etc. I 
> stress that these are only samples, and point them to links
> (like David's great 'Secure Programming How-To') and books.
> I haven't had the chance to evaluate the impact of that, but
> it is on my to-do list.

I think that is a good approach, although I prefer mixing these
issues in where/when they might be more appropriate (e.g., discuss
security issues arising from race conditions when discussing
multi-threading, etc.) rather then saving them up for the end--if
only because there's a chance that they get crowded out if the
pace goes slower than expected.

> Similary, some other courses where security can be plugged 
> include operating systems, networking, SE, system's design, etc.

Indeed. At the same university, I taught the Distributed Operating
Systems masters level course. We used the Tannebaum / van Steen
text. The longest single chapter in the book was on security,
so the topic naturally fit in. (However, I know of other instructors
before me who simply skipped that chapter, thinking it wasn't as
important as the rest of the stuff.)

> I'd be interested to hear what people think of the two 
> approaches (separate security courses vs. spreading security
> all over the curricula).

I don't see it as "either / or", but rather "both / and". I think that
we sprinkle discussion of security, where appropriate, throughout
core courses (OS, networking, software design, etc.) and also have a
course or two at an upper (junior/senior) level. In that way, I
see it very similar to the way that we approach software design.
Generally there's a specific course or two on design, but we (hopefully)
teach it in bits and pieces at the beginning programming levels as well.
---
Kevin W. Wall           Qwest Information Technology, Inc.
[EMAIL PROTECTED]       Phone: 614.215.4788
"The difference between common-sense and paranoia is that common-sense
 is thinking everyone is out to get you. That's normal -- they are.
 Paranoia is thinking that they're conspiring."    -- J. Kegler