I think that you are spot on, and people are sooner than
later going to be demanding that, as a by-product of our
shrinking economic reality.
Take this example (not to stir up a semantic pissing match):
Insufficient Input Validation
I get it. I understand the importance of it. But it is not
clear to a business owner or C level what that means
to execute on. It is fairly ambiguous, especially in
Web 2.0 world, what that really means. And often
you find in the slippery slope between design and
pattern issues, and implementation-level defects,
that your fundamental data/function boundary problem
is *not* best solved/enforced via input validation.
In the case where the ideal solution to enforce a
data/function boundary is parameterized sql, or
encoded output (or a separate data/control channel),
IV in this case simply functions as an attack surface
reduction mechanism and the costs associated in
defining and enforcing what may be loosely typed
data by requirement, can be negligible at best.
Obviously this is highly contextual and YMMV on
that slippery slope between changing a fundamental
design to fixing singular implementation errors.
Architecture will play a huge key in figuring cost.
But if I have to pick one in a weak data access scenario:
1) Stronger IV/data typing (before queries are built)
2) Parameterized SQL or abstracted data access layer
3) Principle of least privilege definition and strict CRUD enforcement
(by objects accessing data)
We would all like to know which has the most return.
I think that will be tough though. I've found cases
where some simple CRUD tweaking mitigated all
negative impact to successful syntax attacks.
And I've found cases where it did not help at all,
or due to design, simply was not possible to make
meaningful priv separations.
How's that for a verbose Yes?
Good questions.
ciao
--
Arian Evans
I ask, sir, what is the militia? It is the whole
people. To disarm the people is the best and
most effectual way to enslave them.
-- Patrick Henry
On Wed, Jan 28, 2009 at 3:20 PM, Steven M. Christey
co...@linus.mitre.org wrote:
In the past year or so, I've been of a growing mindset that one of the
hidden powers of CWE and other weakness/bug/vulnerability/attack
taxonomies would be in evaluating secure coding practices: if you do X and
Y, then what does that actually buy you, in terms of which vulnerabilities
are fixed or mitigated? We capture some of that in CWE with CAPEC
mappings for attacks.
We've also mapped to the CERT C Secure Coding standard, as reflected in
this CWE view: http://cwe.mitre.org/data/graphs/734.html (for the
complete/detailed listing, click the Slice button on the upper right and
sift through the Taxonomy Mappings). Or, check out the coverage graphs
that show where the coding standard fits within the two main CWE
hierarchical views: http://cwe.mitre.org/data/pdfs.html
Now Microsoft has released a paper that shows how their SDL practices
address the Top 25, like they did when the OWASP Top Ten came out. To me,
this seems like a productive practice and a potential boon to consumers,
*if* other vendors adopt similar practices. Are there ways that the
software security community can further encourage this type of thing from
vendors? Should we?
Gary, do your worst ;-)
http://blogs.msdn.com/sdl/archive/2009/01/27/sdl-and-the-cwe-sans-top-25.aspx
- 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.
___
___
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.
___
