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] Conditional Compile statements-- coding standards, and code review
Robert/Sean, It's a good question and one that I've never seen a really good answer to! Robert your option certain works but I feel that it somewhat prone to error if deployed on a large source base. So for example if a developer actually uses: #ifdef FRED # define MACRO(x) (x + 5) #endif ... then it's quite possible that this is missed by the review team and there is of course no guarantee that all code is reviewed manual. There is also the problem that there may be more than a single target release build for different variants i.e. it's not just a binary choice of release or debug versions. To make a more 'fool proof' mechanism I believe that it's better to have a more controlled use of which pre-processor directives are allowed for conditional compilation and ensure their use is consistent -- this is particular true of debug information which I believe causes the most problems. Following this approach would allow you to perform automatic searches for directives that are not on a defined white list. A word of warning this isn't as easy as it seems once you start getting statements of the following type -- this just re-enforces the problem of conditional compilation: #if defined c1 && !(defined c2 || defined c3) ... #elif defined C4 ... #endif What would be really nice is to have an automatic tool that can check that for say build target A you can only have I, J and K defined but for not L and M -- using 3rd party code which is often designed to be ported to multiple targets sorting out what is actually used is not easy at all! Use should also looked at carefully to ensure that conditional compilation is only used where 'required'. So as an example do you really want all those call traces and information output used during development left in the code? In conclusion I believe that you should aim for as much automation as possible and also taking the problem out of the developer's hands. It's much easier to ensure that you've done something right once in your build system than expect every developer to do it right every time -- in my experience developers are happy to change what is in their 'local domain' but think about things a bit more carefully if they are making a change the can affect the entire development. Obviously these are just some ideas and I'm sure that there or other equally good solutions and as with all these things it does depend on what level of assurance you want otherwise you get the answer of don't allow conditional compilation! 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] Secure Coding Books
Hi All, With all the questions about what are good books are there any views on actually implementing the principles i.e. using them on real programmes to drive security improvement. In particular the contrast between exisitng programmes and new programmes? 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 [EMAIL PROTECTED] 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] Interesting tidbit in iDefense Security Advisory
-- Message: 3 Date: Thu, 28 Jun 2007 14:47:30 -0400 From: "David A. Wheeler" <[EMAIL PROTECTED]> Subject: Re: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07 To: sc-l@securecoding.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On the comment: > | I am not disagreeing with the fact the static source analysis is a > | good thing, I am just saying that this is a case where it failed (or > | maybe the user/developer of it failed or misunderstood it's use). Fair > | enough that on this particular list you are going to defend source > | analysis over any other method, it is about secure coding after all, > | but I definitely still strongly disagree that other methods wouldn't > | have found this bug. Actually, I am _not_ of the opinion that analysis tools are always "better" than any other method. I don't really believe in a silver bullet, but if I had to pick one, "developer education" would be my silver bullet, not analysis tools. (Basically, a "fool with a tool is still a fool".) I believe that for secure software you need a SET of methods, and tool use is just a part of it. That said, I think tools that search for vulnerabilities usually need to be PART of the answer for secure software in today's world. Customers are generally _unwilling_ to reduce the amount of functionality they want to something we can easily prove correct, and formally proving programs correct has not scaled well yet (though I commend the work to overcome this). No language can prevent all vulnerabilities from being written in the first place. Human review is _great_, but it's costly in many circumstances and it often misses things that tools _can_ pick up. So we end up needing analysis tools as part of the process, even though current tools have a HUGE list of problems because NOT using them is often worse. Other methods may have found the bug, but other methods typically don't scale well. Totally agree with the analysis tools not being a 'silver bullet' and being just another part of the toolkit for producing secure (what ever this means!) software. I think a mistake that companies make is assuming that analysis tools are a substitute for security training. To my mind the tools are really for auditing and enforcement purposes as to the effectiveness of the security training but are limited if just used on their own. The tools are great at taking the mundane work out of code reviews and also take into account that humans are fallible and just because they did something correct once doesn't mean they'll do it correct the next time but security training is essential. ... a "fool with a tool is still a fool" - this has been true for so long be is still amazes me how often this is discarded. It seems that the first answer to any software engineering problems is to throw more expensive tools at it instead of remembering it's good engineers that solve problems not good tools. 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 [EMAIL PROTECTED] 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] What's the next tech problem to be solved in software
Lots of interesting points been raised in thread so here a few points I've picked out: - It's the developer's fault: A few comments were made that the lack of security lies at the door of the developers because they implement insecure code. True to an extent but I don't think you can blame developers unless they been educated in the first place. The situation here seems to be slowly improving but is far from ideal. What I would like to see is more general education and also more integration of technologies into the standard low-level development environment that helps educate a developer into what they are doing wrong. So explaining why it's wrong and secondly automating the stopping of them doing it wrong. - The low-level problems have already been solved: I always find this difficult as has been rightly pointed out the problem has been solved from a technical point of view for some time now. Putting a 'finger in the air' you might suppose that 95% of low-level problems (i.e. not inherent in the design) would just disappear. Why doesn't this happen - difficult answer but the inertia built up by certain languages and the developers is not something that is going to change over night and vendors are going to start producing the right 'tools' unless there is a demand for them from developers. To borrow a phrase from someone else you don't get fired for choosing C/C++ as your implementation language. - How to specify security: This I think is the biggest challenge facing security at present. As has already been stated the low-level problems have been solved but at the higher levels (requirements, design etc.) the security arena makes the software development arena look advanced. We hardly have the techniques of defining the security policy of a system and just as importantly how are these integrated into the software development life-cycle as part of it and not considered just an add on? I don't have the answer to what the challenge is let alone how you achieve it but how you express 'security' within a software design and how you make this and integral part of the software design and implementation seem fundamental in the stages to make software 'secure'. Some of the attempts I have seen although interesting always seem to have the flaw in that they are viewed as almost a separate process to the software development. There are many technologies that a software developer takes as second nature as part of their toolbox but security doesn't seem to be one that features highly. 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 [EMAIL PROTECTED] 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] Darkreading: Secure Coding Certification
Lots of interesting points have been made about the SANS test in particular and multiple choice certifications in general. I think that this, and no I haven't seen the questions so I could be wide of the mark, are a pragmatic step in the right direction. I agree that while this sort of exam can be passed by someone who is almost clueless, or I think more accurately can remember facts but wouldn't be able to apply them to real world situations, experience is not the be all and end all - if this was the case we wouldn't still be seeing the same old mistakes being made time and time again! So until we have a better way of measuring knowledge, and I'm not convinced that will ever happen, this seems at least to be a good idea but certainly not ideal. Hopeful it will raise awareness of the subject and maybe even get people into the idea constant improvement throughout their career. In conclusion I think the original article made some good points but it is a bit harsh on what can realistically be achieved at this point it time. The certification should be seen a part of and not a substitute for what can only be learnt through experience, guidance and the one that always seems to be forgotten, keeping up with what is happening in the area of developing secure code. 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 [EMAIL PROTECTED] 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. ___
