Re: BSIMM3 lives

["Kevin W. Wall" <kevin.w.wall () gmail com>]

On Tue, Oct 18, 2011 at 10:34 AM, Gary McGraw <gem () cigital com> wrote:
> On 10/15/11 5:45 PM, "Steven M. Christey" <coley () rcf-smtp mitre org> wrote:
> > 3) The wording about OWASP ESAPI in SFD2.1 is unclear: "Generic open
> > source software security architectures including OWASP ESAPI should
> > not be considered secure out of the box."  Does Struts, mentioned
> > earlier in the paragraph, also fall under the category of "not
> > secure out of the box?"  Are you saying that developers must be
> > careful in adopting security middleware?
>
> Of course struts is not secure out of the box, which is the whole point of
> the activity.  The major difference between struts as insecure and ESAPI
> as insecure is that ESAPI claims to be a secure solution, though it is
> often not.  One might argue that it is worse to claim to be secure and not
> to be than to ignore the whole thing, but that's not really worth
> pursuing.  For more regarding Cigital's view on ESAPI, see
> http://www.cigital.com/justiceleague/2011/09/24/suggestions-for-esapi-2-1-a
> nd-beyond/

Gary,

While I wholeheartedly agree with John Steven's championing that ESAPI be
made enterprise ready, I think your characterization of John's blog entry of
having anything to do with ESAPI "not being secure out of the box" is
simply unfair.

I did not see that listed as one of John's concerns about ESAPI. The
closest way that one could make that association is that for most of
ESAPI's security components there are no high level user stories /
use cases to provide overall guidance on each component. And while
that conceivably could cause security issues, I don't really see inadequate
documentation as being the same thing as a being "insecure by default".

While I think one could make the argument that ESAPI 1.4 was insecure
by default (at least in the case of its symmetric encryption), I think that
is an unfair assessment of the ESAPI 2.0 GA release. In fact, in some
cases, we deliberately sacrificed backward compatibility (one of John's
"enterprise readiness" criterion) with the 1.4 release compatibility because
the development team's preference to choose security over backward
compatibility. (Which is something that I believe is the right decision
for security APIs.)

This is not to say that the security in ESAPI 2.0 is perfect. In fact, the
configuration issus is one of my nits to pick with ESAPI. Not only is
it overly complex, but it does not allow an enterprise's operations team
to lock down ESAPI properties in accordance with company security
policies.  But IMNSHO, I think that it does a far better job being
secure-by-default than does Struts, which is the other API that you
explicitly mention.

Best regards,
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein

_______________________________________________
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
_______________________________________________