There is a lot of good chatter about what I have learned is being called OWASP 4.0. A fourth generation project no doubt! I posted here and Michael Coates posted here which seems to be stimulating some good debate.
Ahead of meeting Dinis Cruz for what will undoubtedly be too much beer tonight I wanted to jot down a few thoughts on how we could organize OWASP 4.0. There are only so many beer mats you can assemble into meaningful diagrams in a brewery! This is very similar to Michael Coates excellent suggestions but with some subtle and I think important differences.
First I think its important to have a community for people who are engaged in planning and managing software security. These people range from the CSO’s to the scrum masters. There are a lot of important topics not covered at OWASP to day ranging from broad sweeping like application security scorecards and metrics to detailed issues such as how to estimate security during Agile planning.
Second I think its important to have a community for the architects and software developers. In this track you would cover the software design issues such as how to to AuthN and AuthZ, how to design secure WS*’s etc as well as code level implementation topics.
Test should cover the traditional security testing but also include topics aligned to the much bigger and more mature software QA discipline.
Finally Operate would be for those whose primary role is in deploying, monitoring and defending against attacks. There are really important topics in deployment and monitoring that I don’t think are well represented today.
The taxonomy or nomenclature is both trivial and actually very important. People who are consuming content (educational, documentation or tools) need to be able to easily identify with their role and navigate to material that they relate to. There clearly needs to be co-ordination across the verticals and over-lap may occur but for the most part projects should fit.
Across each of the sub-communities you would have a collection of high value projects that could generally fit into people (or education projects), Process & Documentation projects and Tools / Technology projects. Coding guidelines for Ruby for instances would fit into the Design & Dev community under the Process & Documentation bucket. App HoneyPots would be in the Operate community under the monitoring focus area.
Some communities would have more of a bias to build tools (Design & Dev and Test for example) and others move of a bias on documentation and process (Plan & Manage).
Underpinning the buckets is a need for commonality and reuse. This is where guiding principles fit, taxonomies and definitions. This ensures some degree of uniformity across the OWASP community.
There are some obvious gaps such as where do browsers fit and what about R&D / security researchers? Security researchers would scare most software QA people IMHO but I don’t have any magical suggestions.
I will follow-up tomorrow with a detailed post of what I would specially drive inside the Design & Develop community. That would include a set of GitHub repo’s, a CI environment and a set of AWS instances to start with. Dev’s need dev stuff to code with!