Grading Secure Programs

[andrews at rbacomm.com (Brad Andrews)]

This brings up a great point.  How can we grade a program's security  
level?  Is it just a checkoff list?  Which elements should be in that  
checkoff list?

The worst part of teaching is grading papers (programs are a close  
second).  Making that more complicated is not likely to work.  I  
already spend more time than I want on it, how are you going to  
convince me to spend more time looking for "secure programs"?  It  
won't happen.

(10 seconds grading would be too long, so "enough time" is a relative  
rather than an absolute time.)

This also ties back to what things you can really look for in most  
instructional programs, though this would depend on the level of the  
class.  Still, if you are going to require a solid mathematical  
algorithm, you had better have spent some time going over how to  
implement mathematical algorithms in code.  In the same way, if you  
want a student to check against SQL injection, you have to have taught  
that at some point.  (Neither have to be in the same class, but they  
must be prerequisites and likely part of a lower level class.)

Curious question:  How many proclaiming "weave it into the curriculum"  
have worked with many lower-level classes as an instructor?

-- 

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting Rob Floodeen <floodeen at gmail.com>:

>   2. a formal method for deducting points from a properly working but
> incorrectly constructed program (a "Show your work" secure coding
> equivalent)