Re: [SC-L] Functional Correctness
Well, this topic gets muddy pretty quickly since I agree with many of the comments made on this thread. We have to be careful with hype and claims made by new models (BSIMM and OpenSAMM in particular) since depending on how the 'rest of the world' sees them speaks directly to our credibility as industry experts. I've tried hard when presenting OpenSAMM to fully claim that the model is chocked full of value judgements about what organizations SHOULD be doing to make a justified argument (qualitatively) that the software they produce has a degree of assurance built-in. Is it a guarantee? No. Is it still valuable? Absolutely. Before, we had no ability to make an apples-to-apples comparison between two organizations, and the model helps that. We also didn't know how to quantify iterative improvement very well or explain the breadth of the software security problem to people either, and OpenSAMM helps that too. I disagree with the remark that maturity models are only useful to companies starting with nothing, because I've seen firsthand how OpenSAMM has helped people (already doing a lot for assurance) think through aspects of the software security problem that fell outside their tunnel-vision. Now, on to the sticky topic of value judgements. Based on how I've seen the BSIMM presented, one might think that at face value, it is somehow more free of author/contributor value judgements than OpenSAMM or other secure SDLC models (I've read several articles referring to these as 'alchemy'). This is simply not true. I, for one, agree with Brad that claims of a scientific nature need to be extremely carefully qualified. At the end of the day, we don't yet know enough about practical methods for improving software security that have much justification beyond what experts think amounts to a 'good thing' (excepting formal methods, of course, but I did say practical :). This is the case for both BSIMM and OpenSAMM. I welcome comments/questions/flames. p. On 8/22/09, Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com wrote: Brad Andrews Writes: After all, we can just implement this maturity model and eliminate all our security problems, at least in the application, right? That is likely to end up resulting in even more resistance in the future when management questions why they need to keep spending more for software security, a secure architecture, etc. Don't people learn what they need to know at some point? I don't thinks that's ever been the case that you can just apply your model and all will be well Microsoft didn`t release their SDL and said there all our software will now be secure, they're constantly evolving their processes. Also some of the activities within the BSIMM are about constant improvement and keeping up with the latest trends, so even just following the BSIMM your processes are never static. I don't think we will ever be static. As soon as we remove the low hanging fruit, the fruit higher up the tree will be the problem. Or, the fruit on another tree :) who's attacking the OS now when the apps are so easy to attack This isn't to say a maturity model is useless, but I remain skeptical that it will live up to the hype (low key now, but there) it is being presented with. I think that the models (both BSIMM and OSAMM) help to provide a framework and a direction to those that have no real security practices at all. Or allow a measurement of existing process and see where their weaknesses are. That and the senior management like the pretty graphs even if they don't know what it means :D CJC -- ~ ~ ~ ~~~ ~~ ~ 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. ___
[SC-L] OWASP Podcast August Update
Hello SC-L! The OWASP Podcast Series continues to accelerate! We released 5 podcasts this month which I hope you find to be of value. 39August 25, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_39.mp3 | Show Notes /index.php/Podcast_39Interview with Gunnar Peterson (Webservices)38August 25, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_38.mp3 | Show Notes /index.php/Podcast_38Interview with the OWASP Global Education Committee37August 22, 2009*Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_37.mp3 * | Show Notes /index.php/Podcast_37Interview with Jason Lam and Johannes Ullrich (SANS Institute)36August 15, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_36.mp3 | Show Notes /index.php/Podcast_36May 2009 News Commentary Recorded July 23 with Boaz Gelbord, Andre Gironda, Jason Lam, Jim Manico, Alex Smolen, Ben Tomhave, Andrew van der Stock and Jeff Williams (part 2)35August 4, 2009Listen Now http://www.owasp.org/download/jmanico/owasp_podcast_35.mp3 | Show Notes /index.php/Podcast_35Interview with Anton Chuvakin, Ph.D (PCI) Faster than a speeding bullet *winks*, the OWASP Podcast Serieshttp://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Showsis bringing on 2 additional hosts, is spawning a Spanish AppSec podcast series, and will be releasing interviews from Andy Steingruebl (PayPal), David Rice (Geekonomics), and the DC AppSec crowd (Acronyms) in September. Ken, please forgive me for ignoring your advice to slow down. ;D Aloha to all of SC-L and thank you for listening. -- Jim Manico jim.man...@aspectsecurity.com jim.man...@owasp.org ___ 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 02:35, Benjamin Tomhave wrote: First, security in the software development concept is at least an intermediate concept, if not advanced. Not at all. That would be like saying that correctness is also an advanced concept, because it gets in the way of coding. Security is about exploiting assumptions (often hidden) that we make when we write and deploy software. I see no reason why teaching to think about assumptions should be deferred. You teach math students how to do proofs right from the beginning for essentially the same reasons :-) Perhaps this means that the language itself needs to require strong type checking that enforce appropriate secure coding behavior? Unfortunately, security assumptions are rarely written down so I don't see how they can be enforced at the language or compiler level. Best, Stephan ___ 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?
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. Great strategy! Our hacker friends will love it. 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 Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced ___ 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 17:35, Benjamin Tomhave wrote: You don't teach proofs - not really. The elementary and junior high curriculum generally does not contain anything about proofs I was talking about college students because that's when I was properly taught programming. That may no longer be true. But in maths, I *was* taught how to do proper proofs in high school (from 7th grade on, when we had Geometry). I may have been unusually lucky. I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science. It increasingly makes sense given the failures up to this point. The problem then is that every Joe, Dick, and Harry out there who can get hello world to compile think they're artists. Seriously, unlike art, programming is usually not a vehicle for one's creative urges, but a tool to get a job done, as you yourself say. (I hesitate to use the word science as an antonym to art here, perhaps craft would be better.) Unfortunately, security assumptions are rarely written down so I don't see how they can be enforced at the language or compiler level. Here you make a patently bad assumption yourself. It should be possible for the compiler to automatically protect against overflows, as an example. Sure, for certain languages and certain classes of well-understood problems, compiler or language support can be engineered. But my point stands: security assumptions are rarely written down. This is because they are taken to be self-evident and not in need of explicit formulation. Also, they depend on the domain. If I express a hospital drug disbursal system in any of the common general-purpose programming languages, the assumption that one cannot be a doctor and a nurse at the same time is usually implicit. I challenge you to develop Java or C ++ support that will capture any flaw in the implementation of this particular RBAC *without* having to make that assumption explicit. Safe input validation and output encoding could also be forced at a given level. Really? I'd be interested in hearing about such techniques that cannot be short-cut (which, as you state, is one big factor for security defects in software). Best, Stephan ___ 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 Tue, Aug 25, 2009 at 4:09 AM, Stephan Neuhausstephan.neuh...@disi.unitn.it wrote: On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote: First, security in the software development concept is at least an intermediate concept, if not advanced. Not at all. That would be like saying that correctness is also an advanced concept, because it gets in the way of coding. Security is about exploiting assumptions (often hidden) that we make when we write and deploy software. I see no reason why teaching to think about assumptions should be deferred. You teach math students how to do proofs right from the beginning for essentially the same reasons :-) Sarcasmreally? First graders are learning to do math proofs instead of basic addition? I'm quite surprised by this./Sarcasm We're missing I think the point I raised earlier. Not everyone learns to program in high school or college. And, even learning the basics of what an algorithm are is tricky, much less learning defensive programming, etc. So, yes, it is an advanced concept for the majority of beginning programmers. -- Andy Steingruebl stein...@gmail.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. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
On Aug 25, 2009, at 18:07, Andy Steingruebl wrote: Sarcasmreally? First graders are learning to do math proofs instead of basic addition? I'm quite surprised by this./Sarcasm Yeah, sorry. When I wrote about students I meant college students. I don't know, is that a difference between British English (pupils) and American English (students)? Anyway, my bad. We're missing I think the point I raised earlier. Not everyone learns to program in high school or college. And, even learning the basics of what an algorithm are is tricky, much less learning defensive programming, etc. But the topic of the thread is Where Does Secure Coding Belong In the Curriculum? and I maintain that when someone is intellectually mature enough so that you can teach them how to program and at the same time really know what they're doing, you can teach them about correctness and security too. Best, Stephan ___ 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] Where Does Secure Coding Belong In the Curriculum?
The just get the bloody thing to work is usually an attitude foisted on developers by the business side. I work in an internal application security function for a large enterprise and i'm yet to meet a developer who wasn't concerned about security. Developer education is very important and we have a lot of it available for out developers, some of it even compulsory. However, unless there is the will of the business behind it, developer concerns are oft pushed aside in the interest of expediency. I find the business side usually does have a genuine interest in security and quality, however they are concepts that remain largely unquantifiable, and in the case of security you only need to mess up once to end up with a nasty situation. It's can be a tough sell getting time to focus on these things, given they can be so vague. In the case of my organisation, business side support comes from both internal advocacy of security practises by our function and externally imposed legal requirements. Mostly the latter ;) Filtering inputs is NOT hard, and most developers are getting better at things like that. However, the problems of application security go beyond the developer level, and it's important not to lose sight of that fact. If there were an easy solution everything would already be perfectly secure. Pete On Wed, Aug 26, 2009 at 12: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. Great strategy! Our hacker friends will love it. 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 Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced ___ 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?
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. ___
