[Owasp-leaders] OWASP Summit: Secure Coding Workshop: Update

John Steven John.Steven at owasp.org
Wed Jan 12 16:31:29 EST 2011


I've begun working on this "Secure Coding" workshop idea in earnest.
The trajectory attempted here:

1) Identify topics in which we can make immediate implementation progress
2) Identify facilitators & key participants to lead sessions
3) Work in a distributed fashion to set up 'topic objectives', 'kit',
& 'skeleton'
    programming tasks for each task.
4) Establish shared understanding of topics' & participate in each others'
5) Debrief sessions at summit's-end & plan on-going conference track

Several people beyond the set that can participate in person have
expressed interest. As such, I'd prefer to reduce scope / length of
this track as we near the summit date. A solid start that generates
momentum for future conferences will be more beneficial, long term,
than a flash in the pan that happens only once.

By week's end, expect updated track documentation on the Summit Wiki
regarding objectives, goals, rules of engagement, organizing
facilitators, and related high-level topics.

The track seeks to add to OWASP's canon of "secure code" snippets. I'm
setting things up to focus on snippets because I don't want to be
encumbered by the size/maturity/"existing focuses" of ESAPI. If we
create code that 1) get plugged into ESAPI or that 2) support ESAPI's
adoption that's super but we don't want to set so a goal so high, or a
goal that requires as much context and background as extending ESAPI
requires. We will make a point of providing ESAPI value where it makes
sense and "input validation"/AppSensor represent two targets we've
already included focus on.

Our goal will be to extend the practice of "building security into
applications" without a preference for whether or not the application
exists in a calcified form of maintenance or whether it's being
developed in a green-field manner.

As a guiding principal facilitators will drive participants to
specify, implement, test, or support adoption of code that makes it
easier to build secure applications with respect to their topic area.
Where existing code exists within the topic area, we'll ask
participants to be at least conversationally familiar with existing
and applicable OWASP tools (such as ESAPI modules, CSRFGuard,
AppSensor, or <whatever>). Moving forward, I believe the track should
stick to this prerequisite a bit strictly but we may have to relax it
a tad for our first go-round (then again, we may not if the quality of
summit attendees exceeds that of an average conference).  As such, we
should encourage facilitators or their lieutenants to present a
"introductory course" to the technology being extended in our secure
coding track in a separate (50-75 minute) section scheduled to occur
in the conference prior to their "Secure Coding Track" module.

We'll want track participants to self-police each sub-section. If
things get too introductory and forward progress stalls, perhaps
participants can help a lagging participant "Get up to speed" with the
rest of the session quickly in a side conversation/demo/hand-holding

Summarizing: the objective of each sub-section is to make our
technology better not necessarily to raise awareness of its existence.

[Sample Code]
During my day-job, I tell my consultants, "Arguments about design
can't be solved in the air. Truth is in the code...
...well, the binary...
... well, mostly." (It's usually at this point where one of my
consultants points out my propensity for code-injection and code
mutation, but I digress)

In order to conduct grounded activities like threat modeling,
requirements analysis, or general exploration (informal though they
may be), implement changes, test those changes, or integration code
written, we're going to need sample application code on which to
operate. I don't believe it's vitally important we work on a single
application code base, or that the application hang together entirely.
However, the closer we get to a single non-toy application, the more
concrete our tracks activities will be.

Starting with WebGoat makes sense but we'll need to augment it
(especially for persistence tier conversations and some of the work I
plan around RIA). The question of what our sample environment will be,
and how to supply that rapidly to track participants is probably the
most important question for us to answer immediately.

TODO: Standardize on, collect, and augment test application bases for
track work

When my chapter (NoVA) did its static analysis "saturday session" we
distributed a Virtual Machine image designed to solve this tool/dev
env. bootstrapping problem and the problem of populating the sample
app space (for analysis). This didn't succeed as well as I would have
liked, and I don't recommend going the same route again, despite how
conceptually attractive it is to simply download a common working

Instead, I think it will be more important for facilitators and key
participants to use _their own_ environments: environments in which
they already comfortably program and assess code. I imagine a way in
which we can "push" code to each person's environment. I don't have
high hopes for consistency or "one-step" readiness for participants'
laptops for version #1 of this track. Readiness and consistency can be
addressed over time after initial successes warrant.

TODO: figure out as light-weight a 'quick start' participant readiness
[thingee] as possible. Maven script?

Mr. Tesauro, you may have some ideas on how to help out here. Thoughts?

[Code Repository]
Due to the flexibility demands of the previous section, the
distributed nature in which this track will get its start and the
chaos built into the track by design, we need effective distributed
source code control. GITHUB is the correct tool for this situation,
IMO. I've set up:


If we pull material like GoatBank and ESAPI from their present
repositories, the current (free) level at which this repository lives
should suffice. We'll address this IFF it becomes a problem.

TODO: Get license figured out
TODO: Get Track documented, referred to in Summit Wiki

[Shared Space]
GITHUB will allow us to share code pretty rapidly. We'll also need the
ability to "look over someone's shoulder" in bulk. This track will
need at least one high-quality overhead (for the facilitator) and
potentially more, if we're in sub-groups. Remote participation has
already been requested. Having done a cross-Atlantic dev session once
(five days, last year) I'm not relishing the thought of repeating it.
I found the quality of 'shared space' was too low and communication
suffered despite all parties being single-language. If people know of
a good enabling technology that might allow Mr. Sheridan (CSRFGuard)
or Mr. Schmidt (ESAPI, various) to participate, Let me know.

To some extent, an organic and chaotic experience seems preferable.
I'm counting on facilitators and participants to come in a positive
and collaborative frame of mind. However, preparation will improve the
participant experience and our overall productivity. I'd like to set
up calls (at least weekly) for a select group of individuals
interested in this Secure Coding track.We've got a list of
facilitators that are forming but will need more help on many fronts
(as this email begins to lay out). Unfulfilled roles include:

* Facilitator
* Participant(s)
* Build Master
* Tech writer/scribe

We'll also need "one-time" (yea right) help with TODO items in this
email like building a participant readiness kit, starter
documentation, and so forth. If you'd like to actively help or just
lurk and follow what we're doing please contact me and I'll try to
keep you on our distro list  /conversations. Otherwise, I'll only be
placing _STATUS_ on the leader's list; I don't like too many emails.

TODO: Set up post-summit "refactor + merge" party where we pull in
participant code and make it available through the master repos.
TODO: Set up post summit "ESAPI integration convo. if nec."


More information about the OWASP-Leaders mailing list