Darkreading: Secure Coding Certification

[James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))]

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: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]On Behalf Of Arian J. Evans
Sent: Wednesday, May 16, 2007 4:05 PM
To: SC-L at 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.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070521/7c13f129/attachment.html