hi kevin, I think I understand your position. Thanks for your feedback.
Maybe some background will help me get this straight. BSIMM has 12 practices. One of the twelve is Security Features and Design (SFD). We say this about SFD, "The overall goal for the Security Features and Design practice is the creation of customized knowledge on security features, frameworks, and patterns. The customized knowledge must drive architecture and component decisions." The particular BSIMM activity in questions is SFD2.1 (one of the 109 BSIMM activities). Here is its description from page 27 of the BSIMM: SFD2.1: **Build secure-by-design middleware frameworks/common libraries.** The SSG takes a proactive role in software design by building or providing pointers to secure-by-design middleware frameworks or common libraries. In addition to teaching by example, this middleware aids architecture analysis and code review because the building blocks make it easier to spot errors. For example, the SSG could modify a popular Web framework such as Struts to make it easy to meet input validation requirements. Eventually the SSG can tailor code review rules specifically for the components it offers. (See [CR3.1] Use automated tools with tailored rules.) Carefully vetting middleware frameworks for security before publication is important. Encouraging adoption and use of insecure middleware does not help the software security situation. Generic open source software security architectures including OWASP ESAPI should not be considered secure out of the box. As you can see, there is no claim that struts is secure or any direct comparison with ESAPI at all here. (Really, I think Steve may have accidentally mischaracterized things in his question.) What is implied is a warning that even things designed to be secure often may not be (buyer...or cut-n-paster...beware). Your last paragraph hits the nail right on the head. And you are absolutely right in saying that ESAPI does a better job than generic Struts. In any case, a quick refresher on Ross Anderson's statement WRT programming Satan's computer is probably in order. See what Schneier says here: http://www.schneier.com/essay-185.html FWIW, 23 of 42 firms practice activity SFD2.1. None of them make use of ESAPI. gem On 10/19/11 11:22 PM, "Kevin W. Wall" <kevin.w.w...@gmail.com> wrote: >On Tue, Oct 18, 2011 at 10:34 AM, Gary McGraw <g...@cigital.com> wrote: >> On 10/15/11 5:45 PM, "Steven M. Christey" <co...@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 _______________________________________________
