On Fri, 22 Oct 2010, Jim Manico wrote:
You may wish to consider OWASP ASVS mitigation recommendations. You can
word-smith negative recommendations of what •not• to do to come up
with a great list of defensive recommendations.
Thanks for the suggestion. In the current CWE, most of our mitigations
are positively-spun, so the negative example I used in the introduction is
not typical... although we do note certain negative practices that
developers might think about doing, but should be explicitly warned
against.
And in general Steve, a list of mitigations implies tactical approaches
to Application Security (ie: fix specific flaws) which is fairly
limited. I'd love to see this expanded to cover general defensive coding
techniques and good security design principles that help dev's build
secure apps from day 1.
Within CWE, our mitigations get characterized (roughly) according to which
phase of the SDLC they can be applied, so a CWE-based mitigation library
will effectively cover these. (See the Mitigation_Phase elements in the
schema). I think there's a notion of "tactical" versus "strategic" - and
the relationships aren't necessarily hierarchical. (See the
Mitigation_Strategy elements in the schema). Then there are the
activities that are external to production (e.g. programmer training,
automated code assessment) versus those that are intrinsic (design,
implementation). We are only focusing on the intrinsic, which can be more
directly tied to individual weaknesses.
Thanks for the feedback!
- 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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________
