Justice League Blog
Suggestions for ESAPI 2.1 and Beyond
This year’s ESAPI Summit, organized by Chris Schmidt and other contributors, represented a marked improvement over previous conversations.
A clear evolutionary path for the family of security toolkits lies ahead. In order to achieve broader adoption and greater effect in larger enterprises the project’s participants must focus not just on API-level design but also on what I’ve dubbed enterprise readiness. Enterprise readiness entails:
- Centrally managed development road map
- Predictably periodic release schedule
- Increased modularity and reduced dependencies
- Adopter-centric documentation
- Stated backward compatibility
- Integration with scanning technologies, demonstrating correct usage
Interestingly, the project in current release form already addresses some of the above items. Users’ complaints prescribe an upgrade-even if that entails only more prominent communication of existing resources.
Road Map
Since 2008, the project underwent a multiple management changes. Now firmly in the hands of individuals focused on secure development, it’s time to form a steering committee or other community process that results in the creation of a single shared direction for all involved parties. Organizations need to know not only what ESAPI represents today but also what it wants to address and offer in the next 12-36 months.
Release Schedule
The 2.0 GA release accomplished much but suffered from a changing and delayed schedule. In order to reliably fit into organizations’ own release plans adopters must be able to rely on a release schedule for their own planning purposes.
It would be helpful if development efforts published and adhered to a “software development lifecycle”, regardless of how agile. Why? Such a move would demonstrate maturity and would help individuals from adopting organizations follow and predict progress against schedule releases.
Pushing features to release compels security folk by deflecting criticism and reducing adopters’ risk. However, from the adopting organizations’ perspective, it creates work. Even if they don’t adopt new releases immediately, it forces information-gathering and decision work. Predictability outranks both feature progress and frequency of releases.
Modularity
Tinkerers and serious adopters complain that a large list of dependencies creates undue collisions and conflicts, complicating both adoption and maintenance. Splitting each language’s code base up (call that better componentization, modularization, or <whatever>) should help address that problem. Truly upgrading existing tightly coupled elements into a la carte modules will require comprehensive refactoring, dramatic changes in dependency choice, and clever use of namespaces and dynamic loading (Spring-style dependency-injection has already been discussed).
Because modularity produces not only its intrinsic benefits but also clarifies subsequent road map definition and reduces risk in release schedule planning, I count pursuit of this goal as the task of paramount importance. Chris hopes to schedule a modularization tiger team shortly.
Documentation
When one [successfully] adopts a particular implementation, what security problems should they expect to no longer find in assessments? What steps will adoption require? How much effort does customization, integration, and implementation entail? Increasing enterprise readiness requires user-centric documentation.
- Define a threat model, scoping toolkit objectives/effect
- Outline user stories, indicating workflow support (and addressed misuse/abuse)
- Produce adoption guide, enumerating steps acquiring organizations need to successfully adopt and implement a security API
Summit participants rightly concluded that early adopters can best help close these documentation gaps based on their own experiences. Later, more specific ‘specification’ of toolkit function can follow.
Backward Compatibility
Throughout its evolution, the toolkit’s implementers balanced backwards compatibility with progress. However, one of the first “user comments” at the summit was, “We need backward compatibility.” This represents the prime example of need for better (perhaps more formal?) communication.
Scanning Tool Support
Finally, getting credit drives good behavior. Providing organizations “rule packs” for static and dynamic assessment tools that show alleviated risk from toolkit use should increase adoption. Updating leading commercially-produced SAST products (or SaaS) with rules that remove findings where provided security functionality effectively mitigates risk requires more thought than existing first-pass “ESAPI rule packs” incorporate.
Contributors must carefully consider the level such rules should target. Yes, unit testing shows quality of the toolkit’s implementation itself, but does not demonstrate correct integration of the toolkit with an application. Toolkit contributors, unfortunately, can not produce a generic parametrized system-level security test either demonstrating adopting applications bear no vulnerability.
Conclusion
Summit participants showed support across this broad set of suggestions and discussed each item in relative depth. Now, the objective will be to follow-through on each without loosing momentum.
One possible facilitator could, of course, be private funding. Such funding could facilitate several factors of enterprise readiness simultaneously by 1) defining a road map, 2) proposing, funding, and therefore guaranteeing a work schedule, and 3) narrowing focus to a particular aspect of (increased) modularity (or documentation). Excitement regarding the possibility of both accelerating and focusing progress caused me to blog about the Interaction Model in my last post.
In the meantime, as summit members return home to day jobs and dig themselves out from under inevitable mounds of e-mail and TODOs, I reflect on the possibility of the ESAPI project with renewed interest.
