Secure Coding mailing list archives
Re: BSIMM3 lives
From: Gary McGraw <gem () cigital com>
Date: Fri, 21 Oct 2011 13:14:52 -0400
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.wall () gmail com> wrote:
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 _______________________________________________
Current thread:
- Re: BSIMM3 lives Steven M. Christey (Oct 15)
- Re: BSIMM3 lives Chris Wysopal (Oct 17)
- Re: BSIMM3 lives Gary McGraw (Oct 18)
- Re: BSIMM3 lives Gary McGraw (Oct 18)
- Re: BSIMM3 lives Kevin W. Wall (Oct 20)
- Re: BSIMM3 lives Gary McGraw (Oct 21)
- Re: BSIMM3 lives Greg Beeley (Oct 22)
- Re: BSIMM3 lives Kevin W. Wall (Oct 20)
- Re: BSIMM3 lives Chris Wysopal (Oct 17)