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

[Fernando Schapachnik <fernando () mecon gov ar>]

En un mensaje anterior, der Mouse escribió:
> > > > I think over the past 40 years or so, as a discipline, we've failed
> > > > rather miserably at teaching programming, period.
> > > Right.  But on the other hand, that's not surprising - [because
> > > we've mostly not even _tried_ to teach programming, as opposed to
> > > computer science or software engineering].
> > Care to explain what do you think a 'programming course' should have
> > that is not covered in SE or CS courses (or curricula)?
>
> A computer scientist is a theoretician.  A software engineer is a
> designer.  A programmer is an implementer.
>
> A computer scientist can prove you can't, in general, sort faster than
> O(n log n) (and a good one can recast this as an explanatino of why).
>
> A software engineer can look at the application and decide which
> sorting algorithm is approproate for _this_ task, including, perhaps,
> choosing one with O(n^2) worst-case behaviour because of some
> application-specific property.
>
> A programmer can sit down and implement a sorting algorithm.

Well, my view is that a computer scientist is a scientist, which means he looks
into new/open problems. He'd better recall you can't sort faster than O(n log n)
based on comparisons, as a phisicist better recall general relativity laws, but
it can be a theoretician or an applied one (for example, designing new
programming languagues, etc). A software engineer applies stablished methods (if
shuch a thing exists today is left as an excercise to the reader) to tackle
problems. But that includes desigining, testing and programming. They are just
different parts of the software life cicle but all of them should be undertaken
as professional grade tasks.

So, in short, I think that programming is included in SE is included in CS.
Where "A is included B" means that any individual with an B degree should have
the knowledge necessary to successfully performs A's dutties (he might not have
the experience).

I don't agree with David Wheeler's statement that secure coding should be
taught instead of more basic things like sorting algorithms. Both are
important, but I believe that properly understading foundations is more
important that 'don't trust the input'. Of course there's more to security
than that, but that leads me to my main point. How should secure coding be
taught?

I've considered 'secure coding' courses, and the idea allways 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.

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.

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

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

Regards.

Fernando.