Brad Andrews writes...
> I had proofs in junior high Geometry too, though I do not recall using
> them outside that class. I went all the way through differential
> equations, matrix algebra and probability/statistics and I don't
> recall much focus on proofs. This was in the early 1980s in a good
> school (Illinois), so it wasn't just modern teaching methods that were
> too blame. I am not sure that the proofs were all that useful for
> understanding some things either, though the logic they taught has
> value that I missed a bit of since I did hit some modern techniques.
This may be heading slightly OT, but I don't think your experience
is really that unusual. My BS was a double major in math and physics
and my MS was in CS.
We used "proofs" in most of my math classes, many of my physics classes,
and several of my CS classes.
Besides the frequency, what varied in each of these was the level of
rigor expected. The proofs in math were extremely rigorous, the ones
in physics less so, and the ones in most of my CS classes would have
been classified as only so much "hand waving" if they would have been
done in my math classes. But an important thing to note in all of these
courses was, with the exception of very few advanced (senior & grad
level) math classes such as "advanced calculus" and "abstract algebra"
and "number theory", the use of 'proofs' wasn't the end, but only a
means to the end.
But still 'proofs' were utilized throughout much of this very diverse
coursework to add to the rigor of the logic and presumably to reinforce
understanding and learning.
In the same way, I think that 'security' (or 'robustness' or 'correctness'
or whatever you wish to call it) needs to be CONSISTENTLY blended into the
college and possibly even high school CS curriculum so some element of it
is touched upon in each of the classes and as one progresses it is discussed
more and more. So just as 'proofs' are sprinkled into math, physics, CS,
etc. we need to sprinkle in basic security / robustness concepts such
as:
+ An understanding of what input may be 'trusted' and what inputs
cannot be trusted leading to the concept of trust boundaries.
+ The concept of correctness extends merely past handling 'correct' input
and needs to somehow gracefully handle incorrect input as well.
+ Understanding the concept of risk, eventually leading to an understanding
of risk analysis in upper level CS courses
+ Having an adversarial testing mindset, always thinking "how can I 'break'
this program or system?". (BTW, sad to say, this has probably been the
hardest thing to teach my colleagues. Some of them seem to get it, and
some of them never do.)
There are probably others--this is by no means a complete list--but we
need to emphasize that to those instructing CS that this is not going to
take up a significant portion of their coursework nor require a significant
amount of time or effort on there part. Rather it needs to be folded into
the mix as appropriate.
I think back to my days in elementary mathematics. I recall learning at a
very early age, when learning division, that you can't divide by 0. The
explanation given by the teach wasn't in depth, it was more like "you are
just not permitted to do that", or occasionally "it's undefined" without
telling us WHY it's undefined. In a similar manner, we can teach "don't
blindly accept unchecked input", etc. And then if that is reinforced in
the grading process I do think it will come through.
Surely if we could just do that much, it would be a good start. But my
observation, based on my CS colleagues that I've taught with and before
that, the CS courses that I've taken at the graduate level, is that
other than the obligatory half hour mention of security in my operating
systems course, I can barely recall it ever even coming up. And I also
seldom recall that instructors would every toss your programs truly
malformed input either. By comparison, when I had an opportunity to
teach a masters level CS course on distributed systems (the Tannenbaum
book), I tossed in matters of security throughout, not just in the
chapters about security. Of course, I don't think until we got to the
chapters about security that the students realized that's what I was
teaching them, but that's OK too. The subliminal methods sometimes
work as well.
-kevin
--
Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents." -- Nathaniel Borenstein, co-creator of MIME
_______________________________________________
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.
_______________________________________________
