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