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 :
2. a formal method for deducting points from a properly working but
incorrectly constructed program (a "Show your work" secure coding
equivalent)
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
