[Esapi-user] Esapi-user Digest, Vol 2, Issue 14

John Steven jsteven at cigital.com
Wed Jan 13 09:11:34 EST 2010


Regarding the TCK / ESTAPI toolkit idea,

I've always agreed with Dinis that, in principle, the idea was very exciting. I disliked the name for a few reasons, some of which too vague for me to formulate. I had forgotten about TCK, which Jeff brought up, but like that notion (dislike its name too :-P).

[This is an EXCEPTIONAL idea, imo]
Because organizations 1) will have a propensity to make their own ESAPI and 2) already often have a framework-based one under way, I'm nothing short of freakin'-thrilled that we could--as a community--provide them guidance. 

This divorces the ESAPI concept from its current religious-sounding 'my way or the highway' stance into an accepting, positive approach. Maintaining an ESAPI reference implementation continues to provide artillery support for those who don't have their own toolkits, are just starting this process, or who are building web-apps in languages/platforms that don't have robust security controls support (IE: not JavaEE / .NET).

[NO ASVS]
ASVS can not meet this TCK need any more than a high-level test plan can meet the need for good user stories/use cases or requirements/spec. No.

ASVS meets a sub-need of the TCK idea: something Sun calls "TCK Project Plan Template". Please refer to my previous email regarding this topic (send to Jeff and Mike privately).

[Sign me up]
Put me in coach, I'm ready to play for ESAPITCK. Rohit's recent post re: the secure-web-application-framework manifesto is a good start, IMO. I'd bring him into this fray.

[Roadmap]
It's time for ESAPI to grow up. I don't mean that pejoratively either. If I was consulting OWASP on ESAPI, I'd say the following:

1) If you don't like the activities defined by BSIMM's SSF, adhere ESAPI development to a subset of SAMM activities. Using BSIMM, however, would give you better alignment with the over 30 respondents' secure SDL that already have security groups, and who will serve as likely adopters to OWASP's ESAPI resources.  
2) Develop and document requirements (TCK) for application to both the reference implementation and organizations' independent ones
3) Stop self-assessment: Manico's stated ESAPI grades don't stand up to light scrutiny and self-assessment is something we bang on organizations regarding PCI about all the time. Get a real assessment--not a system integrator's. I've never been impressed with an integrator's capacity for software security. Usually, they set the low bar. 
4) Get usage stories. Get metrics regarding success. Drive external messaging from the numbers.

People obliquely reference "large enterprises succeeding using ESAPI" but the list of ESAPI adopters I maintain (which is probably woefully inaccurate) doesn't have better assessment results when my guys pen-test / code review their apps (than w/o) nor do I see evidence of widespread adoption within those organizations. Perhaps Kevin Wall + QWest can help with this or McGovern + Hartford. I don't know. But, we need real data.

I've copied a bunch of people on this mail, particularly from OWASP's board. But I think, Jeff, you need to take the lead on this effort. As an outsider, my perception is that people are unwilling to make these suggestions (despite having offered them to me) because, in my opinion, OWASP hasn't fostered a culture where such suggestions are effectively accepted. In short: I think people are afraid negative comments re: ESAPI will be seen as calling (jeff) your baby ugly. I don't see it that way.

At the AppsecDC summit, you were magnanimous about using ESAPI as the trial ballon for techniques to mature OWASP projects and I perceive this discussion as the impetus to begin doing so. As I stated in Portugal, without a central command-and-control structure (And I'd expect the CTO/CIO rolls to collaborate to define/enforce this quality standard), OWASP will need its cultural keepers ('elders' I think I called them at AppsecDC) to lead by example.

-jOHN


On Jan 13, 2010, at 12:25 AM, <esapi-user-request at lists.owasp.org> wrote:

> 
> Message: 1
> Date: Wed, 13 Jan 2010 00:12:33 -0500
> From: "Jeff Williams" <jeff.williams at aspectsecurity.com>
> Subject: [Esapi-user] ESAPI Technology Compatibility Kit (TCK)
> To: <mike.boberski at gmail.com>,  "Dinis Cruz"
>        <dinis.cruz at googlemail.com>
> Cc: rob.spremulli+esapi at gmail.com, ESAPI-Developers
>        <esapi-dev at lists.owasp.org>,    esapi-user at lists.owasp.org
> Message-ID:
>        <B9A412898630124ABE8350F4EBD32E84011C1B78 at mymail.aspectsecurity.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> (Pulled off of SC-L)
> 
> 
> 
> I suggest that we should *not* call this the ESTAPI.  It's confusing and
> inaccurate.  As I've mentioned before, I really think the right model
> for this is the Java Technology Compatibility Kit (TCK).
> http://jcp.org/en/resources/tdk.
> 
> 
> 
> I think separating the interfaces from the concrete classes within the
> Java implementation is a weak attempt to achieve this. The right
> approach is to really write a technology-independent specification and
> create the rest of the TCK.  This should be relatively easy since we
> have several different working implementations.  Incidentally, writing
> the spec fairly late in the process is the recipe for most successful
> technologies.
> 
> 
> 
> Is anyone interested in leading this important effort (with support from
> the rest of the team)?  I'm seeking someone with the right combination
> of technical, managerial, and writing skills to pull this off
> effectively.
> 
> 
> 
> --Jeff
> 
> 
> 
> 
> 
> From: esapi-user-bounces at lists.owasp.org
> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Mike Boberski
> Sent: Tuesday, January 12, 2010 7:47 PM
> To: Dinis Cruz
> Cc: rob.spremulli+esapi at gmail.com; ESAPI-Developers;
> esapi-user at lists.owasp.org; SC-L at securecoding.org
> Subject: Re: [Esapi-user] [Esapi-dev] Recommending ESAPI?
> 
> 
> 
>> we start to create standards for how Security Controls should behave
> [and basically the rest of the post]
> 
> I submit ASVS for your consideration. If one is further concerned about
> building blocks in the environment, check out Common Criteria and FIPS
> 140-2.
> 
> Also,
> 
> There have also been discussions about creating standardized test suites
> for ESAPI implementations to ensure consistent security checks/effects
> across ESAPI language implementations, but I don't think that's what
> you're getting at.
> 
> It's not hard (with respect) to differentiate interfaces from reference
> implementations from adapters (customized controls), please see the
> design patterns doc I wrote that's posted to the project page. I'm not
> sure I see advantages to further rearranging and splitting out the
> interfaces.
> 
> Best,
> 
> Mike
> 
> 
> 
> n Behalf Of Jeff Williams
> Sent: Wednesday, January 13, 2010 12:13 AM
> To: mike.boberski at gmail.com; Dinis Cruz
> Cc: rob.spremulli+esapi at gmail.com; ESAPI-Developers;
> esapi-user at lists.owasp.org
> Subject: [Esapi-user] ESAPI Technology Compatibility Kit (TCK)
> 
> 
> 
> (Pulled off of SC-L)
> 
> 
> 
> I suggest that we should *not* call this the ESTAPI.  It's confusing and
> inaccurate.  As I've mentioned before, I really think the right model
> for this is the Java Technology Compatibility Kit (TCK).
> http://jcp.org/en/resources/tdk.
> 
> 
> 
> I think separating the interfaces from the concrete classes within the
> Java implementation is a weak attempt to achieve this. The right
> approach is to really write a technology-independent specification and
> create the rest of the TCK.  This should be relatively easy since we
> have several different working implementations.  Incidentally, writing
> the spec fairly late in the process is the recipe for most successful
> technologies.
> 
> 
> 
> Is anyone interested in leading this important effort (with support from
> the rest of the team)?  I'm seeking someone with the right combination
> of technical, managerial, and writing skills to pull this off
> effectively.
> 
> 
> 
> --Jeff
> 
> 
> 
> 
> 
> From: esapi-user-bounces at lists.owasp.org
> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Mike Boberski
> Sent: Tuesday, January 12, 2010 7:47 PM
> To: Dinis Cruz
> Cc: rob.spremulli+esapi at gmail.com; ESAPI-Developers;
> esapi-user at lists.owasp.org; SC-L at securecoding.org
> Subject: Re: [Esapi-user] [Esapi-dev] Recommending ESAPI?
> 
> 
> 
>> we start to create standards for how Security Controls should behave
> [and basically the rest of the post]
> 
> I submit ASVS for your consideration. If one is further concerned about
> building blocks in the environment, check out Common Criteria and FIPS
> 140-2.
> 
> Also,
> 
> There have also been discussions about creating standardized test suites
> for ESAPI implementations to ensure consistent security checks/effects
> across ESAPI language implementations, but I don't think that's what
> you're getting at.
> 
> It's not hard (with respect) to differentiate interfaces from reference
> implementations from adapters (customized controls), please see the
> design patterns doc I wrote that's posted to the project page. I'm not
> sure I see advantages to further rearranging and splitting out the
> interfaces.
> 
> Best,
> 
> Mike
> 
> On Tue, Jan 12, 2010 at 7:38 PM, Dinis Cruz <dinis.cruz at googlemail.com>
> wrote:
> 
> My view is that the key to make this work is to create the ESTAPI, which
> is the Enterprise Security Testing API
> 
> 
> 
> This way we would have (for every language):
> 
> *       ESAPI Interfaces - which describe the functionality that each
> security control should have
> *       ESTAPI - Unit Tests that check the behaviour of the security
> controls
> *       ESAPI Reference Implementation(s) - Which are (wherever
> possible) 'production ready' versions of those security controls (and
> in most cases a one-to-one mapping to the ESAPI Interfaces)
> *       Framework XYZ ESAPI 'connectors' - Which wrap (or expose) the
> security controls defined in the ESAPI Interfaces in Framework XYZ
> 
> What I really like about this world, is that we (Application Security
> Consultants) we start to create standards for how Security Controls
> should behave. and (as important) are able to work with the Framework
> developers without they felling that ESAPI is a 'competitor' to they
> Framework. After all, the way we will really change the market is when
> the Frameworks used by the majority of developers adopt ESAPI (or its
> principles)
> 
> 
> 
> Of course that the Framework developers are more than welcomed to grab
> large parts (or even all) of the code provided by the ESAPI reference
> implementation(s). But the key is that they (the framework developers)
> must: a) take ownership of the code and b) respect the ESAPI Interfaces.
> 
> 
> 
> And hey, if the Framework developers decide NOT to implement a
> particular security control, that is fine too.
> 
> 
> 
> BUT!
> 
> 
> 
> I would at least expect them to provide detailed information why they
> made that decision and why they chose NOT to implement or support it
> (which would allow us (Security community) to respectably agree or
> disagree with their choices (hey for some Frameworks, being insecure is
> a feature :) )
> 
> 
> 
> Finally, In addition to all the advantages that we will have when
> frameworks adopt these security controls, there is one that for me is
> probably the MOST important one: An 'ESAPI compliant app' (which btw is
> a term we still have to agree what exactly means), is an app that is
> providing explicit information about where they (the developers) think
> their (the app) security controls are located.
> 
> 
> 
> In another works, via the ESAPI Interfaces (and the ESTAPI tests) the
> developers are actually telling us (the security consultants):
> 
>  a) what they think their application's attack surface is and
> 
>  b) what is the security behaviour that they have already tested for
> 
> 
> 
> Of course that they can game the system, which is why we (Security
> Consultants) will still be needed (we will also need to make sure that
> they implemented the security controls properly). But compare that to
> today's (2009) world, were we are lucky to get an up-to-date application
> diagram and a reasonable accurate description of how the application was
> actually coded and behaves.
> 
> 
> 
> This would also (finally) give the application security tools (white,
> black, glass, gray, pink, blue) a fighting change to automatically, or
> operator-driven, understand what is going on and report back:
> 
>  - what it knows (security vulnerabilities) and (as important)
> 
>  - what it doesn't know / understand
> (ok there is a lot more that these tools will provide us (for example
> ESTAPI tests) but that is a topic for another post)
> 
> 
> 
> So, for me, the key added value of the ESAPI Interfaces, is that it will
> provide us (Security Consultants) a way to understand how the app works
> (from a security point of view) and to be able to finally be able to
> give the clients what they want: Visibility, Assurance and the ability
> to make 'knowledgeable Risk-based decisions'.
> 
> 
> 
> Dinis Cruz
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100113/17b7c001/attachment.bin 


More information about the Esapi-user mailing list