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

[Crispin Cowan <crispin () immunix com>]

der Mouse wrote:


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).
 

That's an interesting distinction, but it doesn't really map to reality. 
There are lots of academic computer scientists who actually study 
implementation issues. Me, for instance :) We publish in security at 
USENIX Security, NDSS (Network and Distributed Systems Security, I am on 
the PC for 2005 
<http://www.isoc.org/isoc/conferences/ndss/05/cfp.shtml>), more broadly 
for systems at USENIX (plug: I am on the Freenix program committee for 
2005 <http://www.usenix.org/events/usenix05/cfp/freenix.html>), OSDI, 
SOSP, etc.


Even more broadly, people publishing stuff at SIGGRAPH are often doing 
at least as much with implementation as algorithms.


Another perspective (overheard at a conference 12 years ago):

   * Scientists build stuff in order to learn stuff.
   * Engineers learn stuff in order to build stuff.

So both classes learn stuff and build stuff, but for different motives. 
As a result, the output of scientists is often informative, but not so 
often useful, and the output from engineers is often useful, but not so 
often informative. To the contrary, it is rather poor work if a 
scientists work is not informative, and disastrous if an engineer's work 
is informative (e.g. the Tacoma Narrows bridge, or Microsoft Windows :)



There is a good deal of overlap, of course; it's rare to find anyone
who is wholly one of these without any bleedover from the others.  In
particular, any really good person in any of the three fields is going
to have a good deal of skill/knowledge from the other two mixed in.
 


Agreed.


What this means for acamdeia is less clear.  In particular, most CS and
SE programs actually include a good deal of programming, partly because
that's what many of the students actually want, partly for historical
reasons, and partly because you do need some familiarity with
programming to be a good CS or SE (just as you need some CS/SE to be a
good programmer).
 

... however, the programming skills that universities teach is usually a 
side-effect of something else they are teaching: topics like algorithms, 
graphics, database, operating systems, networking, etc. They teach you 
the topic, give you a development project in that topic, and expect you 
to pick up the programming skills along the way.


This effect is more pronounced the more advanced the school is. The 
thought is that programming is a relatively simple topic, so while a 
community college will spend most of their time teaching programming, a 
top-tier university will spend about 2 weeks teaching the frosh to 
program, and the rest of it they are supposed to gather while studying 
actual computer science.


What is broken about all this is security: the above approach teaches 
the kiddies to implement software anyway they can, under a lot of time 
pressure, and with very little QA pressure: graders have no time to 
rigorously test assignment hand-ins, and certainly not time to pen-test 
them.


Bringing us back to the root of this thread: we have been waiting 
forever for security to make it into the basic CS curricula. The rate of 
progress is not encouraging.



Thus, to really separate the programs, you'd have to pull the
programming out of the CS and SE curricula and put them in a
programming curriculum, perhaps with some new material added.  I'd
actually argue for going the other way, though, since the lines between
the areas are actually rather artificial, drawn not so much because
there really are boundaries there as because humans like to draw
boundaries around things.
 

For that to work, there would have to be programming content in 
curricula to pull out :)  OTOH, on reflection I tend to agree that 
unless "how to program *safely*" is a subject, that you cannot expect 
kids to infer it, and so successfully teaching security



What this has to do with _secure_ coding...well, nothing, directly.
But part of teaching programming really ought to be teaching the
security side of it, and whether you call it CS or SE or programming,
that's something I agree academia has mostly failed at.

Security for CS includes things like a bit of cryptography, some of the
mutant complexity theory that considers a problem that's O(1) 99% of
the time O(n^n) the other 1% easy rather than hard; security for SE
includes things like writing interface contracts that specify what
_isn't_ defined as well as what _is_; security for programmers includes
things like not overrunning buffers.  Again, there's a lot of overlap.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
X  Against HTML        [EMAIL PROTECTED]
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


 



--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com