Darkreading: Secure Coding Certification

[arian.evans at anachronic.com (Arian J. Evans)]

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) <James.McGovern at thehartford.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070516/b8de9d15/attachment.html