I agree. The two that I feel should be next in terms of developing certifications around are: - How to describe misuse case and dangerous ommissions for people writing functional specifications: This is highly applicable in outsourcing environments including the Federal Government - Strong Software Design Patterns for Software Architects/Lead Developers: This is where if security were properly addressed, would be pretty cheap to handle and have a better ROI than dealing with it at coding time. http://www.theimf.com/events_detail.aspx?ID=164
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arian J. Evans Sent: Wednesday, May 16, 2007 4:05 PM To: SC-L@securecoding.org Subject: 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 ************************************************************************* 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. _______________________________________________
