Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
It also solved the buffer overflow problem, and a number of others. *sigh* Matt On Jan 7, 2010, at 8:15 PM, Peter G. Neumann wrote: ... and of course Multics solved the Y2K problem in 1965, deferring the overflow for many additional decades. ___ 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. ___ ___ 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. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Ben, Let's just hope that the code isn't compiled with -O3 or similar, creating an unintended bug. :) http://isc.sans.org/diary.html?storyid=6820 Brings back memories -- the first day on the job as a summer intern I had to track down a bug in a UNIX device driver. Turned out the optimizer was clobbering a jump -- the driver worked fine unoptimized. I quit believing tools like compilers were flaw-free after that! Most people got it quickly. Getting it and applying it IRL are of course two completely different things. I still find it somewhat absurd that we even need to have this discussion still after how many decades of curriculum development? :) Oh, I don't -- I think it's all too understandable. A story first, to provide some background. One of my grad students (a security type, of course :-)) was my TA for the undergraduate operating systems class. We had the students form teams, and each team modified a kernel. The TA then graded interactively, asking the students about what they did and why, as he went through their code. My TA was appalled at the poor quality of the code of most teams -- it worked, but was not robust and was sloppy. So, he told each group that if they turned in code that poor the next time, he'd deduct 20% on general principles. So what do students do in that case? Right -- complain to the professor (me). I said something to the effect that I strongly disagreed with the TA, and felt he should have handled the situation differently; but since he said he'd only take off 20%, instead of the 40% I would have taken off, I'd support his decision. The students got the message. On the next assignment (and for the res of the class), the code was much better. This suggests to me the problem is not so much a failure to teach robustness; in fact, I suspect most intro to programming teachers do mention it (although to different degrees of thoroughness and probably not using that name). The *real* problem is that we don't keep reinforcing it throughout the student's career. And that's an artifact of a lack of resources for the type of grading. Give classes the support to do this, and I suspect you'd see people get in the habit of writing better code. Better, use students and people from industry who know this stuff to staff a clinic analogous to a writing clinic for English and law schools -- that would reinforce it not just for the students, but for the clinic staff as well. Anyone who's interested in this idea can read about a small experiment I did in a paper at http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/ The results of having students use such a clinic, on a very small scale, led to some pretty good improvements in their code. The problem, of course, is that supporting such a clinic requires a lot of people time, and getting people to donate their time, or the resources (read: cash) to pay for it, isn't easy. Matt ___ 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. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
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 ___ 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. ___
Re: [SC-L] What is the size of this list?
Another lurker revealing himself ... my name is Matt Bishop, and I lurk at the University of California at Davis where I teach and do research in lots of areas of computer security, including (surprise!) what is traditionally called secure programming and secure software development. For what it's worth, I don't like the use of the term secure because it's too vague -- I'd prefer robust or something related to assurance, but I can't come up with a short term. Oh, well. I've been working with secure coding for many years. I'm particularly interested in the interaction between coding and policy, and also in how to teach this stuff. I've done some training (long ago, with SANS), but now I focus on college/university education (for the most part). I get lots of good examples and ideas from this list, and sometimes the postings challenge me to think about different perspectives. In particular, the discussions of how people use these techniques, and the ones people find the most pernicious and troubling, help me give realistic examples when I teach students how to write good code. So Ken, thank you for starting and maintaining this list -- I think you've done the community a great service. A thought about Rob Floodeen's comment: 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. My own feeling is that this should be a basic skill for people who program, not just software engineers. But the level at which practitioners (for want of a better term) need to know this varies depending on what they do. An occasional programmer (a physicist, for example) probably doesn't need to know about race conditions and, indeed, about security in general -- but she would need to know how to write a program that checks its input (lest the results be invalid -- GIGO), which is security from her point of view. A software engineer darn well better know about race conditions, though! So I agree with what Rob posted, and I did have one thought. Is writing good English a minor objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps incidental and important describes how I feel better than minor. Matt ___ 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. ___
Re: [SC-L] SANS List etc..
As an academic who does teach this stuff whenever they let me in a classroom ... I'll address your third point. I am ALL FOR teaching software security at the university level (and have been actively working with universities for over a decade). I just don't think it is realistic to try to push the problem off on universities and hope that they will solve it. WHOLEHEARTEDLY AGREE! Companies, purchasers, etc. have to help. The old saw of working together is, I believe, actually true. I have about 50 other cliches here that I could add, but I'll not bore you with them. As I have said, I would love to be proven wrong regarding my opinion on whether adding software security to a curriculum us realistic. For more on this, see page 98 of Software Security http://www.swsec.com . Hey, that's cool -- I forgot about the page. Thanks for the plug! At any rate, I do think it's realistic to add software security to the curriculum, but I think it's horribly *un*realistic to think that taking a class in it will solve the problems (and requiring students to take a class in it won't change that). You have to practice it, just like you have to practice writing. I do hope that academic programs will not focus on the bug parade approach, however. Building a course around the OWASP top ten or the CWE/SANS top 25 would be rather silly. I would rather see vulns like this covered in every programming course and a software security course focused on the touchpoints (especially code review and architectural risk analysis). I'd emphasize *why* these problems occur, and use the Top 25 list to explain what happens when you don't follow the principles. You can then show how to apply the principles to prevent (or at least limit) these problems. That will cut down on problems before code review. And then you teach code review. You need to teach both how to do it right and how to catch problems when it is not done right, because I don't know anyone who *always* does it right. Perfection may be the goal, but it's not the reality. One thing emphasized by outstanding software security initiatives (think Microsoft) is that teaching developers and architects how to do things right is far superior to an after the fact analysis approach driven by audit and regulations. A very academically sound approach :-) Matt ___ 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. ___
