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. _______________________________________________