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
