Re: [SC-L] Grading Secure Programs
On Aug 21, 2009, at 12:18 PM, Brad Andrews wrote: This brings up a great point. How can we grade a program's security level? Is it just a checkoff list? Which elements should be in that checkoff list? You may be interested in reading: Teaching Secure Programming IEEE Security and Privacy archive Volume 3 , Issue 5 (September 2005) table of contents Pages: 54 - 56 Year of Publication: 2005 ISSN:1540-7993 Authors Matt Bishop University of California, Davis Deborah A. Frincke Pacific Northwest National Laboratory Publisher IEEE Educational Activities Department Piscataway, NJ, USA ___ 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 was thinking of a beginner-level programming class. I have and it can be a challenge, especially if they don't have the programming mindset. Even if they do, you don't have the time for the things you spoke about. You are focusing on basic coding constructs first. :) -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Stephan Neuhaus stephan.neuh...@disi.unitn.it: On Aug 21, 2009, at 17:51, Brad Andrews wrote: Has anyone who holds to this taught a beginning level programming class? I have. I taught a security class to undergrads. It was easier than I thought, at least the basics were. I got them excited by a let's try to break things attitude. They wrote buffer overflow exploits (using freely available shellcode), they cracked linear congruential PRNGs, they subverted insecure protocols. As far as I can tell, they had a good time, since I had the highest retention rate for optional courses in that year: 40 signed up for the course and 39 took the final exam. Once they understood that the right mind-set is not oh come on, what can possibly go wrong? but okay, let's see what *can* go wrong, they were on their way. 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] Functional Correctness
Now that you mention it I was listening to the CERT podcast where you and a couple of others discussed the BSIMM (probably a while back since I am well behind on those). You made a statement along these lines and I immediately thought that I disagreed! :) I don't think software security is as simple as that. I do agree that companies can (and should) do far more than they do and that many things could be eliminated with very mechanical fixes, but I don't think that gives a good long-term perspective. I also think that it will set management's expectation at a level that will ultimately be harmful. 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 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. 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 am sure this is not as smoothly presented as it needs to be, but I am fairly certain of the general thrust of my conviction. I suppose 20+ in software development helps. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Gary McGraw g...@cigital.com: Software security is an intensely practical problem that will require a practical approach. By studying organizations that are doing a decent job, perhaps we can draw some practical lessons. That's precisely what we're up to with the BSIMM http://bsi-mm.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] 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] Functional Correctness
We are approaching huge industry-wide application security critical mass for the first time. Now is the time to strike. If all we teach is input validation+canonicalization, query parameterization, and output encoding, we stop xss and sqli via education Jim Manico On Aug 21, 2009, at 11:54 AM, Brad Andrews andr...@rbacomm.com wrote: I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the correct proof much more difficult. Can we really believe it is just around the corner to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. ___ 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] 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] Where Does Secure Coding Belong In the Curriculum?
Are there any industry metrics that indicate what percentage of full-time software developers actually learned coding in a university setting? I actually learned in high-school, focused on business administration in college (easiest major on the planet) and learned/matured on the job. Likewise, I also am surrounded by many folks who have been in IT for say 30 or so years that learned coding from those infomercial type schools you see on TV late at night. So, the question of whether trade schools should teach secure coding should be asked as well. This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ___ 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?
Andy Steingruebl wrote: I think our real question isn't just how to reach the professional programmer trained via formal training programs, but also how to reach the amateur programmer trained via books, trial+error, etc. One area here is making sure examples are done correctly. The database examples that connected to an MS SQL server with userid=SA;password= used to drive me crazy. The sample code does it that way so I better do it that way. It makes for more complicated sample code but it may be the only way to reach these self taught folks. -- Mike Lyman mly...@west-point.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?
Brad Andrews wrote: Has anyone who holds to this taught a beginning level programming class? Getting students to understand what a loop is can be hard enough, given limited time. Diving into exploits and buffer overflows can be much more difficult. Getting into exploits at this level is probably more than many can handle but it's not a bad time to teach proper bounds checking and making sure any math operations don't result in overflows. Part of the lesson might even be to create loops with math that cause these errors deliberately if students are no longer taught how numbers are represented in memory and what happens when you exceed the limits directly. Might not be a bad idea though to step back on basic courses and rather than dive in to programing concepts right away start with some demonstrations of what happens with bad code and follow up with refreshers periodically through the course. Nothing in great depth unless the students can handle it but showing them what happens after coding errors might raise awareness and start them thinking what happens when this breaks rather than strictly focusing on how do it get it to work. I cringe at the thought of what I used to do in code based on the habits that started in high school and college. I am sure some things could be put into a basic class, but the ideas are a bit deeper. Security at the Hello World! or Mortgage Calculator program level seems quite difficult. This bears some thinking through, but the security risks seem to be: - Make sure the input amount is in dollars. - Make sure the term is numeric and within reasonable ranges. - Make sure that interest rate is in the form of XX.XX. That's a great start at getting them to think about how they have to treat input and validate it. I don't recall any of my instructors ever focusing on making sure the input to anything is what was expected. I'm sure some did but I don't recall it. Even if the students don't always get it right at this point, get them started thinking about it. Where do you inject security there? Sure, you can note the importance of checking the data, but just because someone checks the input here doesn't mean they will have a clue on checking the input on a web form for an SQL injection attempt. You might not touch on this until you get to those type applications. If they were taught to question input all along though, by time you get to something like this the habit might be forming. -- Mike Lyman mly...@west-point.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. ___
