Where Does Secure Coding Belong In the Curriculum?

[Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus)]

On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote:

> You don't teach proofs - not really. The elementary and junior high
> curriculum generally does not contain anything about proofs

I was talking about college students because that's when I was  
properly taught programming.  That may no longer be true.  But in  
maths, I *was* taught how to do proper proofs in high school (from 7th  
grade on, when we had Geometry). I may have been unusually lucky.

> I again come back to James McGovern's suggestion, which is treating
> coding as an art rather than a science. It increasingly makes sense
> given the failures up to this point.

The problem then is that every Joe, Dick, and Harry out there who can  
get hello world to compile think they're artists. Seriously, unlike  
art, programming is usually not a vehicle for one's creative urges,  
but a tool to get a job done, as you yourself say. (I hesitate to use  
the word "science" as an antonym to "art" here, perhaps "craft" would  
be better.)

> > Unfortunately, security assumptions are rarely written down so I  
> > don't
> > see how they can be enforced at the language or compiler level.
> Here you make a patently bad assumption yourself. It should be  
> possible
> for the compiler to automatically protect against overflows, as an
> example.

Sure, for certain languages and certain classes of well-understood  
problems, compiler or language support can be engineered. But my point  
stands: security assumptions are rarely written down. This is because  
they are taken to be self-evident and not in need of explicit  
formulation. Also, they depend on the domain. If I express a hospital  
drug disbursal system in any of the common general-purpose programming  
languages, the assumption that one cannot be a doctor and a nurse at  
the same time is usually implicit. I challenge you to develop Java or C 
++ support that will capture any flaw in the implementation of this  
particular RBAC *without* having to make that assumption explicit.

> Safe input validation and output encoding could also be forced
> at a given level.

Really? I'd be interested in hearing about such techniques that cannot  
be short-cut (which, as you state, is one big factor for security  
defects in software).

Best,

Stephan