Where Does Secure Coding Belong In the Curriculum?

[bishop at cs.ucdavis.edu (Matt Bishop)]

Ben,

> First, security in the software development concept is at least an
> intermediate concept, if not advanced. Riffing on Brad's comments, it
> seems irrational to think that you can jump straight from structural
> basics with which many students struggle (OO anybody?) directly to
> concepts that bridge computer architecture, code structure, and  
> various
> other problems.

I agree and I disagree. If I walked into an ECS 10 (Intro to  
Programming class) and began "We use the waterfall model to provide a  
moderate level of assurance ..." about 75% of the students would be  
out the door. That's one problem with teaching security per se: you  
need to describe *what* your security requirements are, and when  
you're struggling to learn how to write a "for" loop, being asked to  
implement security requirements as such is intimidating.

Instead, what you can do is frame the issues as "good programming".  
When teaching for loops, teach the idea of a "limit" (upper and lower  
bounds). Then when you get to arrays, it's natural to discuss bounds  
checking in the context of iteration (I don't phrase it that way, of  
course). When you grade, you check for it. Presto! Now you have taught  
what is commonly considered a security requirement without ever  
mentioning the word "security".

I find the distinction between "robust" and "secure" is useful,  
although often the two are interchangeable. By "robust", I mean the  
more nebulous requirement that the program not crash (although it may  
terminate gracefully :-)) and that it handle unexpected inputs  
reasonably, and so forth. By "secure", I mean meeting a specific set  
of requirements that describe what "security" means; for example,  
unexpected inputs may require specific actions (in which case handling  
them is both robust and secure :-)). Note: I'm not sure the  
distinction here is too meaningful, so please don't ask me to define a  
boundary.

But in introductory classes, I tend to focus on what I am calling  
"robust" above; when I teach software security, I focus on both, as I  
consider robustness part of security.

By the way, you can do this very effectively in a beginning  
programming class. When I taught Python, as soon as the students got  
to basic structures like control loops (for which they had to do  
simple reading), I showed them how to catch exceptions so that they  
could handle input errors. When they did functions, we went into  
exceptions in more detail. They were told that if they didn't handle  
exceptions in their assignments, they would lose points -- and the  
graders gave inputs that would force exceptions to check that they did.

Most people got it quickly.

Matt