Re: [SC-L] What is the size of this list?
Actually, we can't prove programs are bug free if by bug we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything right in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. 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: Friday, August 21, 2009 11:41 AM To: sc-l@securecoding.org Subject: Re: [SC-L] What is the size of this list? I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can prove programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a flawless piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI [snippety snip] ___ 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?
Great points Karen! We can't prove a program is secure in the same vein. The danger I am spouting off about is the idea that we would solve the software security problem if we just take a more scientific or mature (or whatever) approach. I think those can definitely reduce the risk, but I don't think it will reach the goal. I am all for getting 50% of the way there. That is a lot better than being 0% or even 25% of the way there! I am just VERY concerned that if we try to sell management the idea that we are now taking a scientific approach (or whatever the term), we will end up with implied promises that will lead them to expect perfection, which won't come. They will likely ignore all our disclaimers that we are only seeking a partial solution to what we can solve, at least in the current state of thinking. Getting them to even take any action is a challenge in many companies, so some could argue my concerns are foolish. I think they are important because you want to make sure any buy-in you eventually get expects the right things. If you don't do this, you will end up in an even worse position down the road. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Goertzel, Karen [USA] goertzel_ka...@bah.com: Actually, we can't prove programs are bug free if by bug we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything right in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. ___ 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] What is the size of this list?
On Aug 18, 2009, at 2:21 PM, Arian J. Evans wrote: Jeremiah Grossman and I were both pondering the size of the SCL recently. Is the list size public? It's not public per se, but only in the sense that the number isn't directly available--unless you ask for it. The list has pretty consistently hovered around 1000 subscribers since pretty shortly after I launched it in late 2003. I am curious why I don't see many new names on SC-L. Lots of lurkers? We do seem to have a high percentage of lurkers, but I always like to encourage newcomers as well as new active participants. I do my best to keep my moderating light, and I welcome all perspectives and opinions on the topics we discuss here. My primary moderating criteria are ensuring submissions are relevant to the list charter and keep a civil tone. Beyond that, everyone on the list is largely free to say/discuss whatever suits. Plain and simple: the list is what the members make of it. btw// SCL has always been a great place for academic and progressive-minded folks to talk about state of the art, and future ideas for secure coding. I have always recommended it to developers looking for new places to learn as a best and brightest haunt. So thanks for running it guys, Thanks. I've consistently found over the years that efforts like this are worth the effort in a myriad of ways, and it's something that I gladly take on. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com 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] What is the size of this list?
Hi SC-L, I'm a Lurker. I work for CERT | SEI | CMU and monitor the list in an attempt to keep an ear to the ground. While I'm not a professional programmer I do have an undergrad and graduate degree in CS which means I've been trained a little about programming. I'm really interested in two things with this list, 1. How do we teach secure coding from a training perspective (I develop training scenarios for CERT and I'm in the Workforce Development group, so this is exactly the kind of list that draws my attention.) 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. Warm Regards, -Robert Floodeen On Wed, Aug 19, 2009 at 11:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ 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. ___
