To expand upon "But you need "A" ESAPI for your organization" briefly,
>From a certain point of view, just as application can be PK-enabled, they can >be ES-enabled. Instead of a PKI toolkit, one uses an Enterprise Security API >toolkit. Instead of signature functions, think input validation functions, >where security checks and effects are performed and result according to a >given organization's/application's security policy. Note that crypto should >also be wrapped, but trying not to overcomplicate things in this note. The >toolkit may be an OWASP version, or it may be one of any number of flavors >described below, where security functions are logically and/or physically >grouped into an organization/application-specific ESAPI. The OWASP ones just >happen to exist and are free. Then, developers are trained/instructed/etc. to >use them depending on their own life cycle best practices. I have more to say, but let us start here. Best, Mike B. -----Original Message----- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Jim Manico Sent: Thursday, January 07, 2010 10:56 AM To: John Steven Cc: Secure Coding Subject: Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog John, You do not need OWASP ESAPI to secure an app. But you need "A" ESAPI for your organization in order to build secure Apps, in my opinion. OWASP ESAPI may help you get started down that path. An ESAPI is no silver bullet, there is no such thing as that in AppSec. But it will help you build secure apps. Jim Manico On Jan 6, 2010, at 6:20 PM, John Steven <jste...@cigital.com> wrote: > All, > > With due respect to those who work on ESAPI, Jim included, ESAPI is > not the only way "to make a secure app even remotely possible." And I > believe that underneath their own pride in what they've done--some of > which is very warranted--they understand that. It's hard not to become > impassioned in posting. > > I've seen plenty of good secure implementations within organizations' > own security toolkits. I'm not the only one that's > noticed: the BSIMM SSF calls out three relevant activities to this > end: > > SDF 1.1 Build/publish security features (*1) SDF 2.1 Find/publish > mature design patterns from the organization (similar URL) SDF 2.3 > Build secure-by-design middleware frameworks/common libraries (similar > URL) > > Calling out three activities within the SSF means that it can't just > be "John Steven's top client" (whatever that means) that's doing this > either. I've formally reviewed some of these toolkits and I'd pit them > against ESAPI and expect favorable results. Plenty of organizations > are doing a great job building stuff on top of profoundly broken > platforms, frameworks, and toolkits... and they're following a 'secure > SDL' to get there. ESAPI can not be said to have adhered to that rigor > (*2). Organizations care about this risk regardless of the pedigree > and experience of those who are building it. > > Is the right answer for everyone to drop everything and build their > own secure toolkit? I don't think so. I like that the OWASP community > is taking a whack at something open and free to share. > These same people have attempted to improve Java's security through > the community process--and though often correct, diligent, friendly, > and well-intentioned, their patience has often been tested to or > beyond the breaking point: those building the platforms and frameworks > simply aren't listening that well yet. That is very sad. > > One thing I've seen a lot of is organizations assessing, testing, > hardening, documenting, and internally distributing their own versions > of popular Java EE toolkits (the "secure struts" > phenomenon). I've seen some organizations give their developers > training and write SAST rules to automatically verify correct use of > such toolkits. I like this idea a hell of a lot as an alternative to > an ESAPI-like approach. Why? A few reasons: > > 1) Popularity - these toolkits appeal to developers: their interfaces > have been "voted on" by their adopting user population-- not conceived > and lamented principally by security folk. No one forces developers to > go from Struts to Spring they do it because it saves them time, makes > their app faster, or some combination of important factors. > > 2) Changes App Infrastructure - MVC frameworks, especially, make up > the scaffolding (hence the name 'Struts') of an application. MVC code > often touches user input before developer's see it and gets the last > chance to encode output before a channel (user or otherwise) receives > it. Focusing on an application's scaffolding allows in some cases, a > best-chance of touching all input/out and true invisibility relative > to developer generated code. Often, its configuration is declarative > in nature as well--keeping security from cluttering up the Java code. > Note that this approach is fundamentally different from Firewalls and > some dynamic patching because it's "in the app" (an argument made > recently by others in the blogosphere). > > 3) Top-to-Bottom Secure by Default - Declarative secure-by-default > configuration of the hardened toolkit allows for securing those data > flows that never make it out of the scaffolding into the app. If an > organization wrote their own toolkit-unware security API, they'd have > to not only assure their developers call it each-and-every place their > it's needed but they'd also need to crack open the toolkits and make > sure THEY call it too. Most of the time, one actively wants to avoid > even having this visibility let along maintenance problem: it's a > major headache. > > and, most importantly, > > 4) Less Integration points - Developers are already going to have to > integrate against a MVC framework, so why force them to integrate > against YA (yet-another) API? The MVC frameworks already contend with > things like session management, input filtering, output- encoding, and > authentication. Why not augment/improve that existing idiom rather > than force developers to use it and an external security API? > > The ESAPI team has plenty of responses to the last question... not the > least of which is "...'cause [framework XXX] sucks." Fair. Out of the > box, they often do. Fair, [framework team XXX] probably isn't > listening to us security guys either. > > If you're an ESAPI shop--good. Careful adoption of a security API can > help your security posture. Please remember to validate that the API > (if you sucked in an external one rather than writing it) applies to > your applications' threat model and ticks off all the elements of your > security policy. Because, having hooked it into their apps, teams are > going to want a fair amount of exoneration from normal processes (Some > of which is OK, but a lot can be dangerous). Second, please make sure > it's actually secure--it will be a fulcrum of your security controls' > effectiveness. Make sure that assessment program proves your > developers used it correctly, consistently, and thoroughly throughout > their apps. What do I tell you about ESAPI and your MVC frameworks > (Point #3 from above)? - > sigh- That's a longer discussion. And, by all means, don't think you > can let your guard down on your pen-testing. Is it a silver bullet? > No. > > Is ESAPI the only approach? No. I submit that it's -A- way. I hope > this email outlines that effectively. And viewed from a knowledgeable > but separate perspective: the ESAPI approach has pluses and minuses > just like all the others. > > ---- > John Steven > Senior Director; Advanced Technology Consulting > Desk: 703.404.9293 x1204 Cell: 703.727.4034 Key fingerprint = 4772 > F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 > > Blog: http://www.cigital.com/justiceleague > Papers: http://www.cigital.com/papers/jsteven > http://www.cigital.com > Software Confidence. Achieved. > > (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1 > (*2) During the AppSecDC summit, Jeff indicated the ESAPI project > would later pilot SAMM but the global projects committee indicated > that getting OWASP projects to follow some secure development > touchpoints is too onerous/impossible. Dinis, I'll note is a huge > proponent of adherence. > > > On Jan 6, 2010, at 4:36 PM, James Manico wrote: > >> Hello Matt, >> >> Java EE still has NO support for escaping and lots of other important >> security areas. You need something like OWASP ESAPI to make a secure >> app even remotely possible. I was once a Sun guy, and I'm very fond >> of Java and Sun. But JavaEE 6 does very little to raise the bar when >> it comes to Application Security. >> >> - Jim >> >> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons <mparsons1...@gmail.com> >> wrote: >>> From what I read it appears that this Java EE 6 could be a few rule >> changers. It looks like to me, java is checking for authorization >> and >> authentication with this new framework. If that is the case, I >> think that >> static code analyzers could change their rule sets to check what >> normally is a manual process in the code review of authentication and >> authorization. >> Am I correct on my assumption? >> >> Thanks, >> Matt >> >> >> Matt Parsons, MSM, CISSP >> 315-559-3588 Blackberry >> 817-294-3789 Home office >> mailto:mparsons1...@gmail.com >> http://www.parsonsisconsulting.com >> http://www.o2-ounceopen.com/o2-power-users/ >> http://www.linkedin.com/in/parsonsconsulting >> >> >> >> >> >> >> -----Original Message----- >> From: sc-l-boun...@securecoding.org [mailto:sc-l- >> boun...@securecoding.org] On Behalf Of Kenneth Van Wyk >> Sent: Tuesday, January 05, 2010 8:59 AM >> To: Secure Coding >> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application >> Security made simple ! | Core Security Patterns Weblog >> >> Happy new year SC-Lers. >> >> FYI, interesting blog post on some of the new security features in >> Java EE 6, by Ramesh Nagappan. Worth reading for all you Java folk, >> IMHO. >> >> http://www.coresecuritypatterns.com/blogs/?p=1622 >> >> >> Cheers, >> >> Ken >> >> ----- >> Kenneth R. van Wyk >> SC-L Moderator >> >> >> _______________________________________________ >> 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. >> _______________________________________________ >> >> >> >> -- >> -- >> Jim Manico, Application Security Architect >> jim.man...@aspectsecurity.com | j...@manico.net >> (301) 604-4882 (work) >> (808) 652-3805 (cell) >> >> Aspect Security(tm) >> Securing your applications at the source >> http://www.aspectsecurity.com >> _______________________________________________ >> 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. > _______________________________________________ _______________________________________________ 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. _______________________________________________
