[SC-L] Inherently Secure Code?
I am not sure I agree that this is any more achievable than claiming a bank building should allow all valid customers in, but keep out all thieves. While we can and should make great strides, we will always have some exposure because we have to let some things through. The only way we can have perfectly secure code is to not allow someone to use it. The same is true of bug free code, but that is another argument. :) Isn't this kind of like wanting the evil bit to be set in all malicious packets? Great idea, but not achievable. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Benjamin Tomhave list-s...@secureconsulting.net: we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure. ___ 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?
Personally I think secure coding should be included in the entire curriculum irrespective of the level. People learn habits early on that they tend to carry for as long as they are programmers. How many programmers that learned the KR style of indentation for example continue to use it as their default style even when they have learned new languages. Having just done a quick survey of the programming books on my shelves I don't find security or secure coding covered much if at all. I doubt that is because some business guy came down to the author and told him to excise security from the book. If basic security and secure coding practices are not integrated into programming from the beginning it is an add on, and hence not a natural component of the (art|science) of programming and much easier to skip. I have started teaching my 12 year old son C programming at home. We started off with a basic Hello World, then added his name as a variable, then a loop to print different names, then added the ability to take the name as input from the command line. At each step we added in a bit of exception handling, and once we got to user input data we added basic data and input validation. Each new version of the program had a test plan and had to handle exceptions. This is a very simple example and is not something production ready, but every step showed him how to program without leaving security out. In my opinion, any educational program that deals with computers or networks should have security and secure coding woven into it. The amount and type of secure coding depends on the subject. A management class that calculates costs and ROI of a project should have metrics for the cost of security or robustness failures. Networking classes should have secure configuration integrated. Software engineering/design would need to have appropriate modules on encryption, identity management, etc, etc. In the end I think the question should be: Is there a place where does security and secure coding NOT belong in a curriculum? ___ 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?
Not so much anti-social as untrusting, supicious, and paranoid. Actually, being highly social could provide an excellent cover to fool the bad guys into thinking one is a lot less security-savvy than one actually is. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of McGovern, James F (HTSC, IT) [james.mcgov...@thehartford.com] Sent: Tuesday, August 25, 2009 2:09 PM To: Secure Code Mailing List Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? There are several perspectives missing from the dialog: - Before we even talk about secure coding, we need a course on secure thinking. Most folks are indoctrinated into thinking positive which blinds them from seeing vulnerabilities right in front of them. A prereq on being antisocial might be a good start ___ 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?
James McGovern wrote... - Taking this one step further, how can we convince professors who don't teach secure coding to not accept insecure code from their students. Professors seed the students thinking by accepting anything that barely works at the last minute. Universities need to be consistent amongst their own teaching/thinking. Well, actually, I think that what Matt Bishop wrote in his response to Benjamin Tomhave is the key: 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. That is, Matt suggested a direct reward / punishment. Specifically, if the students don't account for bad input via exceptions or some other suitable mechanism, the simply loose points. Matt's right. If it boils down to grades, most students will get it, and fast. And whether we call this secure-coding, robustness, or simply correctness, it's a start. I think that too many people when they hear that we need to start teaching security at every level of CS are thinking of more complicated things like encryption, authentication protocols, Bell-LaPadula, etc. but I don't think that was where the thrust of this thread was leading. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ 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] informIT: attack categories
hi sc-l, Fred sent me some email today and reminded me that he has written about this idea himself in IEEE Security Privacy magazine. We already had a link to his article on the Silver Bullet website, but here's a direct link: The Monoculture Risk Put in Context IEEE Security and Privacy 7, 1 (January/February 2009), 14-17. Fred Schneider and Ken Birman. http://www.cs.cornell.edu/fbs/publications/IEEEspMonoculture.pdf gem On 8/25/09 1:35 PM, gem g...@cigital.com wrote: hi sc-l, If you listened recently to the latest episode of Silver Bullet with Fred Schneider from Cornell http://www.cigital.com/silverbullet/show-041/, one of the ideas Fred and I discussed was the notion of attack categories and anticipating large scale trends in attack space. Hopefully you guys all recall that I am a strong proponent of understanding the attacker's perspective (see, for example Exploiting Software from way back in 2004 where Hoglund and I coined the term attack pattern http://exploitingsoftware.com/). This month's informIT article is about the notion of long term attack categories and is meant to inform software security research: Software [In]security: Attack Categories and History Prediction http://www.informit.com/articles/article.aspx?p=1393066 BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the usual nay sayers. Feedback is most welcome. (Thanks to Ken and Sammy for helping me make this article slightly more coherent.) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/justiceleague book www.swsec.com ___ 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] informIT: attack categories
hi steve, The bugs/flaw continuum is, in fact, a continuum. It's great that you guys have begun to collect and publish information about flaws in the CWE. I agree completely with your statement I suspect that design/architecture level taxonomies will be very challenging to build. Part of what Fred is trying to spark with his work is some research funding for that area. gem On 8/25/09 6:36 PM, Steven M. Christey co...@linus.mitre.org wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) we lack a taxonomy of flaws such as the ones we have for bugs (see the Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The weaknesses introduced during design view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 (API Abuse which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the graph tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to public instead of private has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say well that's clearly a bug but at the design level, is the problem use of a language that supports arbitrary indexing of arbitrary pointers or use of a risky API function that doesn't perform its own bounds-checking or use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer or failure to validate input? (The answer may be all of the above or it depends on your perspective, but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve ___ 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?
The playing in traffic example is one extreme end of the spectrum. A good analogy for the other end might be physics where you just teach Newtonian theory it as if it were 100% accurate and then, if the student decides to take a relativistic physics class, you teach them on day 1 that everything they know isn't right. It seems teaching secure programming must lie somewhere between these two ends of the spectrum. Perhaps a more useful exercise (rather than debating where in the gradient through metaphor) is to try to enumerate the variables that play into what draws a topic toward one end or the other. Such variables might include: * stickiness of the bias/habits acquired as you learn more * impetus to learn more * ability/access to learn more Just a thought. p. On 8/25/09, Goertzel, Karen [USA] goertzel_ka...@bah.com wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that good is much more desirable than expedient, and then to introduce the various properties that collectively constitute good - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... ___ 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. ___ -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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?
Matt Bishop wrote: 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 would agree with this, as I think it again syncs with what James McGovern talked about earlier, too. A graduated approach to secure coding (for whatever definition we might insert) is the only logical progression. However, as you conceded, we have to be very careful just how much we introduce and when. I remember the disconnect in the mid-90s when the CompSci curriculum switched to OO. Some of us got caught in the blender where our first CS class was non-OO and our 2nd class was suddenly all OO and we didn't know what the heck was going on. It seems we're perhaps still in this transitional state to a large part. 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. 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 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? :) -ben -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Reading is to the mind what exercise is to the body. Sir Richard Steele ___ 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?
Goertzel, Karen [USA] wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she would be completely and totally unprepared (and in serious danger). She lacks the language skills to even marginally understand basic concepts like street let alone don't play in the street. I think this rather proves my point that secure coding is not itself a fundamental concept, but rather an intermediate-to-advanced concept. Matt Bishop's comments are great, but they've also been applied in a context of higher ed., and recognize the limits of student understanding at different phases of development. -ben But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that good is much more desirable than expedient, and then to introduce the various properties that collectively constitute good - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] That which has always been accepted by everyone, everywhere, is almost certain to be false. Paul Valery ___ 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?
Matt Bishop wrote: 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. This sounds like an excellent extension for OWASP. :) -ben -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] I hope if dogs ever take over the world and they choose a king, they don't just go by size, because I bet there are some Chihuahuas with some good ideas. Deep Thoughts by Jack Handy ___ 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?
So many mistakes have been made in generations before mine that we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure. This is the comment that agrees with my own belief. When teaching how to program secure coding should be seen as inherent in this and not as some sort of optional add that is only required if the code is supposed to secure. Many of the techniques are just making the code more robust and this covers a considerable amount of the problems with code today. I see no reason that this shouldn't be taught as part of any programming course. Does this cover all secure coding, no of course not, but unless the foundations of secure implementation is inherent then more advance issues ar the least of the communities worries. Consider the environment before printing this mail. Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmas...@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited. ___ 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?
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.4788Application 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,
Re: [SC-L] informIT: attack categories
Gary, Great article and since you used attacks and categories in the same :) sentence I am tempted to ask if you looked at WASC Threat Classification project? On Tuesday, August 25, 2009, Steven M. Christey co...@linus.mitre.org wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) we lack a taxonomy of flaws such as the ones we have for bugs (see the Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The weaknesses introduced during design view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 (API Abuse which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the graph tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to public instead of private has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say well that's clearly a bug but at the design level, is the problem use of a language that supports arbitrary indexing of arbitrary pointers or use of a risky API function that doesn't perform its own bounds-checking or use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer or failure to validate input? (The answer may be all of the above or it depends on your perspective, but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve ___ 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. ___ -- Thanks Regards, Prasad N. Shenoy ___ 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?
On Aug 25, 2009, at 8:16 PM, Olin Sibert wrote: Exploits are FUN. I agree, at least to a point. Whenever I work exploits into my workshops, the results are right on the mark. So long as the exploits are balanced with just the right amount of remediations, it works great. The key is to hook the students with the exploits, and then sprinkle in a now here's how to do it _right_ discussion while they're still paying attention. ;-) And FWIW, I've found OWASP's WebGoat to be phenomenally effective at doing just that. There are other similar tools out there as well, but the point is to give the class a safe sandbox to play in. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) smime.p7s Description: S/MIME cryptographic signature ___ 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] informIT: attack categories
At 6:36 PM -0400 8/25/09, Steven M. Christey wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I think it has been happening for years. I use Microsoft Word V5.1a from 1992, because Microsoft followed that with Word 6.0 which introduced the design defect allowing Macro Viruses. Of course this was not actually an innovation, as IBM had previously introduced _and_withdrawn_ a similar vulnerability in their CMS operating environment (the mail program would automatically call a text formatter which could call the operating system under the direction of the sender. Those who do not study history are condemned to repeat it. -- Larry Kilgallen ___ 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?
Your example is spurious as a refutation of what I was trying to say (as I suspect you already know). Obviously you're not going to try to teach a not-yet-verbal infant a self-preservation concept that requires even the most rudimentary reasoning. That said, I'll be interested to hear from you in, say, a year and a half from now. And I still maintain that the intellectual maturity of a two-and-a-half-year-old hardly constitutes intermediate-to-advanced EXCEPT possibly when compared with that of a one-year-old. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Wednesday, August 26, 2009 12:27 AM To: Goertzel, Karen [USA] Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Goertzel, Karen [USA] wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she... ___ 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?
I too remember learning proofs in Jr. High. And I also believe the main objective was to teach 12 and 13 year olds that it is possible to apply a repeatable, disciplined process to how they approach problem solving. Certainly not a worthless lesson, even if the mathematics involved are never used again. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews [andr...@rbacomm.com] Sent: Tuesday, August 25, 2009 4:23 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? 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. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI ___ 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?
I see your point. On the other hand, there are times I worry that teach the hacker mentality approach to secure development training smacks a bit too much teaching future policemen the delights of robbery, rape, torture, and murder in order to prepare the to defend the public against robbers, rapists, torturers, and murders. Definitely teach - with examples - what it is about software that makes it so easy to exploit and violate. But stop short of handing the students detailed blueprints and instructions, reinforced by lots of hands-on lab time. I'm just untrusting enough of human nature to worry that once some of them discover how much more fun it is to hack than to defend against hacking, what you'll end up with is not the next Bob Seacord but the next Kevin Mitnick. At the very least, make psychological exams a prerequisite of acceptance into your class, so you can weed out the likely psychopaths and sociopaths. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Olin Sibert [u3...@siliconkeep.com] Sent: Tuesday, August 25, 2009 8:16 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I'm mostly a lurker here, and I'm a practitioner rather than a professional educator, but there's a viewpoint I haven't seem much of that I want to support, namely: Exploits are FUN. Teach from that angle, and I think you'll get more traction ___ 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?
Your Picasso - or, perhaps, Frank Lloyd Wright would be a better analogy - definitely has a role in software development. I want his creativity up front in the specification and high-level design of the building (the software system). But when it comes to detailed design and testing, I'm going to call in the engineers, and when it comes to coding, no-one does it better than skilled construction workers who have mastered the use of hammers, saws, adzes, etc. So yes - the coders are craftsmen. But the problem is that in software development, the roles are seldom so clearcut, especially not in Agile development. So one does find far too many craftsmen attempting the engineers' and architects' jobs without anything like the necessary training and certification of their competence to perform those functions. Or maybe, if we accept the software development as an art analogy, our problem is we have way too many architects trying to code successfully. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jim Manico [...@manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim ___ 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. ___
