[Owasp-leaders] OWASP Summit: Secure Coding Workshop: Update
dinis.cruz at owasp.org
Wed Jan 19 07:12:35 EST 2011
John (and others)
Can you make sure that all of the info below is on the Summit Track and
Working Sessions pages? (start here
We have already a number of developers going to the Summit (and we need
more!!!!!) so ideally we should have a good first crowd to test this out.
In terms of planning, this is definitely a track that needs as much
pre-summit planning as possible. We need to allow the participants to
be aware/briefed of its concepts before they get there.
I also think you should add a 'planning working session' for this track
(which would basically be a 1h to 2h session the day-before, where the key
organizers of the multiple 'Secure Coding Workshop" Working Sessions will
figure out the action plan for the next day(s) )
Please also take into account that you most likely will not have all
attendees participating in all Working Sessions
expect a number of attendees to only participate in a couple (i.e. they will
be attending other Working Sessions)), so you will need to have a special
briefing document/stage for them
Finally, on the topic of
that page really needs some love :)
On 12 January 2011 21:31, John Steven <John.Steven at owasp.org> wrote:
> 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
> specif. As such, we
> should encourage facilitators or their lieutenants to presey, 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)nt 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."
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders