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. ___
[SC-L] Darkreading: Secure Coding Certification
Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first. * 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] Darkreading: Secure Coding Certification
> Maybe the test shouldn't focus on code at all? If we can agree that many > flaws are found at design time even before code is written (Yes, most > folks still use waterfall approaches but that is a different debate) > then why can't questions occur at this level? It was decided early on that this test would have a heavy emphasis on coding, since programmers who've just entered the workplace (the target examinees) are not likely to be heavily involved in design. While this decision was not unanimous, many of the core contributors agreed with this philosophy. Obviously this leaves a few gaps with respect to secure software development, which I'm sure will be addressed by someone somewhere, sometime. - 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] Darkreading: Secure Coding Certification
As someone who has read your books, I am in full agreement that we should use much of the material contained to create an exam around design. Instead of making it a "later" thing, what would it take for folks on this list to have some sense of urgency and blast SANS to do it sooner? If any members here will also be in attendance at the TechForum in NYC (http://www.techforum.com/sf2007_1/index.html) would love to hook up for lunch. -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 4:26 PM To: McGovern, James F (HTSC, IT); 'SC-L@securecoding.org' Subject: RE: [SC-L] Darkreading: Secure Coding Certification Hi all, I like this idea. There is plenty of non-code material to master in our field. I think a bunch of it is covered in detail in "Software Security"...but I am biased. I would like to see coverage of common attack patterns, coverage of risk analysis basics, and coverage of both positive and negative design patterns. gem P.S. I plan to respond soon to previous posts. Too much time on airplanes lately. company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com Sent from my treo. -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 03:08 PM Eastern Standard Time To: SC-L@securecoding.org Subject:[SC-L] Darkreading: Secure Coding Certification Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first. * 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. ___ ___ 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
Hi all, I like this idea. There is plenty of non-code material to master in our field. I think a bunch of it is covered in detail in "Software Security"...but I am biased. I would like to see coverage of common attack patterns, coverage of risk analysis basics, and coverage of both positive and negative design patterns. gem P.S. I plan to respond soon to previous posts. Too much time on airplanes lately. company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com Sent from my treo. -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 03:08 PM Eastern Standard Time To: SC-L@securecoding.org Subject:[SC-L] Darkreading: Secure Coding Certification Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first. * 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. ___ ___ 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
I don't understand this thread. These are different sets of issues. Often, they are different sets of people. Organizational size is a factor. A three-man startup is going to have a lot of hat overlap, where a monolithic enterprise is going to have broad distribution of hats. The spirit of this thread seems to have a well-meaning but misguided swaping of "ANDs" and "ORs". The arm-chair quarterbacking of a very useful, overdue effort, is a bit silly. We need these efforts. As I mentioned previously, we need multiple tests: + "How to write and implement code that isn't weak to bit-fiddling" (e.g. don't concatenate strings, strongly type data, encode output safe for user agent, don't use LIKE queries with weak authorization models, blah blah; this is how you make XSS and SQLi and BoF/HoFs go away.) --> Check. That's the first thing thing SANS (err, SSI) is addressing. We still need: + "Non-dangerous requirements-gathering for Product Evangelists/Owners" (no, the customer does not really want that) + "Strong Software Design Principles for Business Owners" (weak secrets often reduce short-term costs, customer service, etc., but...) + "Strong Software Design Patterns for Software Architects/Lead Developers" (yeah, your authorization model is Borked man. What were you drinking? In fact, why do you even have "roles" in your application? Might as well just use "Trust".) + "How to describe mis-use case and dangerous omissions for people writing functional specifications" (So Rob should run Rob's reports. Should Rob be able to run Sally's report(s)?? yes|no ) These are all different actions... often taken by different actors. At minimum it is while a given actor is performing different tasks. I'd love to see SSI collect a body of knowledge and make tests for all of these. I see no reason to debate "ORs" in here. chow Arian Evans On 5/16/07, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote: Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first. ___ 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. ___
