This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

OWASP 2013 Project Summit Working Session Outcomes Leader Reports

From OWASP
Jump to: navigation, search

Working Session Outcomes: Leader Reports

The working sessions outcomes below are the direct reports sent to the OWASP Projects Manager from the participating Project Leaders. They outline, in greater detail, what their session deliverables were, and list their roadmaps for future work to be completed. Please note, that some sentence structure, and spelling was corrected before implementation of each report to this document.

OWASP Projects Review Session

SESSION DESCRIPTION: During the OWASP Projects Review working session, attendees will be able to participate in the review of the entire inventory of OWASP Projects using the new assessment criteria developed by our team of Technical Project Advisors. The aim of this session is to establish a more accurate representation of OWASP project health and product quality. The session outline is as follows:

  • Overview of new assessment criteria to conduct reviews.
  • Team in small groups (2 to 3 max) based on experience and background to asses a set of Projects (Code, Tool or Documentation)
  • Fill in the Questionnaire (Google Forms) to complete assessment of Projects and provide the review with a final score and results (Project defined as Incubator, Lab or Flagship)
  • Review results of questionnaire with your team.
  • Present results and conclusions of assessment session.

OUTCOMES

  1. We are able to present quality and health assessments that the team had worked on over the prior few months, get some good feedback from OWASP leaders, and have a number of OWASP members use the assessment to rate some of the existing projects so we could see what worked well and what didn't work.
  2. Yes, we were able to take everyone's input to further improve both assessments. We removed a couple of questions that were well-intentioned, but problematic for reviewers. Since it wasn't clear if a project passed a health assessment and should be promoted or not, we made sure all of the questions on the overall project health questions were knock-out questions, meaning that if they did not satisfy the criteria they weren't ready to be promoted since these are all key principles fundamental to the goals of all OWASP projects.. To accomplish this, more subjective questions were moved to the quality assessment which uses a numeric scale to rank the project, rather than being ‘Yes’ or ‘No’ questions. We also created a standard scoring scale for all project types, which works with a single rating range if users assign full credit if a question is not applicable. There were also some cosmetic changes made regarding the instructions to make it easier to focus on the question, and yet still easily get guidance on how to answer each question. The bottom line is that I believe that the time spent talking with OWASP Leaders and Members directly resulted in the biggest improvement to the project assessments, which exceeded my expectations of what we wanted to accomplish at the summit.
  3. The follow-up items were to create an online form that reviewers could use to rate projects, ask project leaders to rate their own project (partly as a process to weed out inactive projects, so we don't spend time reviewing dormant projects), get 10 quality reviews for each project from OWASP members who use the projects (especially the tool and library code projects since good health assessments are predicating on having reviews from those most familiar with those project that have an environment to use them in and projects to apply them to), and perform health assessments on all of the projects (focusing first on projects who have requested a review or to be promoted and flagship projects, then lab projects, and finally incubator projects).

OWASP Media Project Session

SESSION DESCRIPTION:The OWASP Media Project is an infrastructure project that gathers, consolidates, and promotes OWASP content in video format on a central appealing hub. The first and main instance of the project will be a YouTube channel.

The session will be used in order to bring project leaders up to speed on how video sharing and live streaming can help promote your project and reach people. We will do that by presenting Google Hangout, and the official OWASP YouTube channel.

Then, we will gather potential sources and existing videos in order to populate the OWASP channel. This summit experience will not just be about promoting the Media Project itself, but also about the exposure of any other projects with video content.

OUTCOMES

  1. What were the outcomes of the Sessions? I can't speak for the other project leaders really, but on my part I did meet a lot of them and briefly exchanged contacts. I'd say the session brought us together, not only to see the people within one project, but to also see other project leaders and volunteers and this should be encouraged regularly.
  2. Did you accomplish what you set out to accomplish before the summit? In our cases we just presented the project to one interested person, so it was not that good on this part. I think it's hard for a project that isn't flagship level to motivate people to go one day only for that. However we wanted to accomplish something else with the Media Project: record other people from other project, and in that regards we succeeded.
  3. What is there left to do? Do more stuff in order to promote the project leader's presentations online and do working session.
  4. Roadmap for accomplishing what is left to do. That would be added to the roadmap of Media Project; however, we have many more priorities and this would be down on the list. That could change if we get more volunteers.

OWASP Mobile Security Session

SUMMIT DESCRIPTION:Just as the mobile security landscape has changed, so has the OWASP Mobile Project. Join us as we discuss the major milestones of 2013 and what is in store for the projects future. We will also go deeper in to the Mobile Top Ten project where we will discuss the decisions made on categories, vulnerability information, and look at some surprising vulnerability trends in mobile applications.

During this session we will cover:

  • OWASP Top 10 Mobile Risks, 2014 Refresh
  • Mobile project 2013 achievements and the 2014 roadmap.
  • Increasing industry collaboration within the mobile security space.

OUTCOMES

  1. What are the outcomes of this session?
    1. Our small group spent time trying to identify classes of mobile vulnerabilities. The mobile top ten in specific. We went over a lot of ideas but ended up deciding on minimal changes to the current categories. This was for a few reasons. Some places have already instated a standard for one. We did identify some new issues arising and new potential projects to add to the overall mobile security project, such as criteria for MDM type solutions since they are not cover in the mobile project but companies want some security guidance when they test or evaluate them.
  2. Did you accomplish what you set out to accomplish before the summit?
    1. We did. We decided on a few category changes. We talked to users of the mobile top ten and addressed some pain points (mostly project incompletion).
  3. What is there left to do?
    1. We are finishing the wiki content this month and "unveiling" it at AppSec California. We are also aiming to re-categorize for 2014, but we are unsure if we can make the next week deadline.
  4. Roadmap for accomplishing what is left to do.
    1. Wiki content is our top priority at the moment.
    2. Followed by restructuring the categories and evaluating data from 2013.
    3. A PDF guide would be awesome after that.

OWASP PCI Toolkit Session

SUMMIT DESCRIPTION: Join us and learn how to help organize achieve PCI-DSS compliance with OWASP tools and Documentation by creating an interactive scope toolkit app.

OUTCOMES

  1. What were the outcomes of the Session?
    1. At AppSec we had one session with a group of 20 persons approx., ranging from recent graduates in security engineering to experienced PCI-QSA auditors. The session focused on explaining the purpose of the project and their feedback before embarking into fully programming the toolkit. All agreed that such a tool will be very beneficiary to companies looking to understand the PCI-DSS requirements and how OWASP guides fits into all of that.
  2. Did you accomplish what you set out to accomplish before the summit?
    1. Yes. The idea was to get feedback from the sector to understand and adapt the toolkit requirements to their needs and what kind of information are they looking for to comprehend. Before the summit I had a defined idea, but after speaking to the assistants, it was cleaerer and better to focus in certain areas, which helped to define a better plan that fits their needs.
  3. What is there left to do?
    1. Right now, I'm programming the different sectors. End of December I had a PCI_training and I was able to become a PCI professional which took time from my development, but I think this all adds to better understanding and the credibility of the project. I'm happy now that people can verify my credentials as a PCI professional through the PCI council website. This achievement was also part of my project.
  4. Roadmap for accomplishing what is left to do.
    1. Right now, I'm focusing to deploy by mid February the first beta version with 2 modules (APPS and NETWORKO) I need to adapt the Wiki, and the idea is that by May to have the other modules completed. A simple draft is available already as a google app on [1] This app will be updated and later available through GitHub. I have 2 potential contributors but again, after I'm back from the Netherlands I'll check with them to get some work done on this part.

OpenSAMM Session

SESSION DESCRIPTION: OWASP Software Assurance Maturity Model (SAMM) is an open framework to help organizations start and implement a secure software development lifecycle that is tailored to the specific risks facing the organization. During the AppSec USA conference, the SAMM project team organizes this workshop for you to influence in which direction SAMM evolves. The workshop is also an excellent opportunity to exchange experiences with your peers.

We will cover the following agenda:

  • Introduction/getting to know each other
  • Project status and goals
  • OpenSAMM inventory of tools and templates
  • Case studies/ sharing experiences
  • What do we need (thinking about improvements, can be anything ranging from translations over tools to model improvements)
  • What do we need next (prioritization)
  • Call for involvement (responsibilities), identity teams for specific topics
  • Rough planning for the future
  • Extra topic: source/build control

OUTCOMES Thursday November 21, 2013 1:00pm - 5:00pm

Location: Sky Lounge (16th Floor)(NY Mariott Marquis)

During the AppSec conferences, the SAMM project team organizes workshops for you to influence the direction SAMM evolves. This is an excellent opportunity to exchange experiences with your peers. Understanding of SAMM is a prerequisite for participation in this OWASP summit session.

Present:

  1. Stephanie Tan
  2. David Felio
  3. Aaron Estes
  4. Adam Langford
  5. Martin Knobloch
  6. Seba Deleersnyder
  7. Yan Kravchenko
  8. Qinglin Jiang
  9. Colin Watson
  10. Matteo Meucci
  11. Jonathan Carter

Agenda:

  1. Introduction / getting to know each other - 10 mins.
  2. Project status and goals
  3. OpenSAMM inventory of tools and templates
  4. Case studies / sharing experiences
  5. What do we need (thinking about improvements, can be anything ranging from translations over tools to model

improvements)

  1. What do we need next (prioritization)
  2. Call for involvement (responsibilities), identity owners / teams for specific topics
  3. Rough planning for the future
  4. Source/build control

Meeting Notes: Latest OpenSAMM presentation done as project talk: https://www.owasp.org/images/4/47/OpenSAMM_-_OWASP_USA_2014_-_Seba-Pravir.pptx

Resources from the wiki/opensamm.org website / mailing list will all be consolidated online in https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model#tab=Tools__26_Templates

The Quick Start draft is created and can be commented on online: https://docs.google.com/document/d/1WNCcoYg1-PYli5DNQZKLxwzibmwpNawacloH-8ZAlUc/edit?usp=sharing

Metrics: Some overall SAMM score calculation options were discussed, with weighing the 4 business functions (possibly slider based).With the latest SAMM-BSIMMv5 mapping it should be possible to produce statistics on implemented SAMM activities in different verticals.

Latest mapping by Lius Service is uploaded to the mailing list on http://lists.owasp.org/pipermail/samm/2013-November/000528.html

Operational Enablement: Request to update the name for security practice "operational enablement" as this title is too "fuzzy" and interpreted in different ways.

Suggestions during the meeting were: "DevOps", Operations, Production Support.

Action decided: start thread on the mailing list to gather input on new name with a timing towards selection of a new name (or keep the existing one) (Seba)

Improvement for next SAMM version: More guidance to add on how to manage/prioritize fixing found vulnerabilities during verification/production phases.

Yan - Experiences and examples were shared on how to implement SAMM on a portfolio of applications, measuring "static/dynamic" risk for applications.

Yan will share a template on this.

Matteo showed how they guide prioritization of SAMM security activities based on estimated effort and expected impact. This nicely complements the prior portfolio view.

Matteo will share the template.

Action: combine the demonstrated templates to one SAMM application portfolio dashboard to guide people on implementation priorities and reporting.

Aaron showed a secure development implementation guideline as used by Lockheed Martin, based on SAMM with extra metrics, resources, tips and tricks. The final document (with a how-to) will be donated to the SAMM project.

Action: Aaron to share final document

David has mapped SAMM on PCI (v2) and Microsoft SDL and will share these mappings with the SAMM projects. Kuai to coordinate the PCI mapping (also started with this).

Jonathan proposed to put focus on how to handle code modification / reverse engineering in hosting environments and mobile apps. During the meeting it was suggested to first create a paper to discuss of this specific topic should be integrated in the SAMM model.

SAMM Version 1.1 priorities are confirmed to be:

  1. Add quick start guide
  2. Add tools and OWASP resources
  3. Add use cases, experience.
  4. Revamp SAMM wiki

All SAMM modle related changes are to be implemented in SAMM v2.

A full day SAMM summit will be organized in Cambridge (AppSec Europe 2014).

Actions Points:

  1. Use the BSIMM Mapping to create an overview of SAMM activities that are done by organizations? (Seba?)
  2. Start thread on the mailing list to gather input on new name to replace “Operational Enablement” with a timing towards selection of a new name (or keep the existing one). (Seba)
  3. Share SAMM portfolio view of applications, measuring "static/dynamic" risk for applications. (Yan)
  4. Share how to prioritize SAMM security activities based on estimated effort and expected impact. (Matteo)
  5. Create a unified SAMM application portfolio dashboard (owner : TBD)
  6. Share the secure development implementation guideline as used by Lockheed Martin, based on SAMM with extra metrics, resources, tips and tricks (Aaron)
  7. Create / share a PCI v3 mapping on SAMM activities (Kuai / David)
  8. Create / share separate paper on how to handle code modification / reverse

engineering in hosting environments and mobile apps and propose how this could be integrated in SAMM. (Jonathan)

OWASP O2 Documentation Session

SUMMIT DESCRIPTION: The objective of this session is to discuss the development of a Book about the O2 Platform Web Automation capabilities. Join us during our initial discussion, and get your ideas heard.

OUTCOMES During the O2 Session we were looking at the O2 book and we were able to distribute several copies. The initial book can be found at GiHub https://github.com/o2platform/Book_WebAutomation.

We had an interesting conversation about it and the main idea is to continue writing the book and add an introductory chapter about the O2 platform to reduce the learning curve. We also are adding a chapter for the already created applications available at O2 so developers and security consultants can consume them.

For the O2 book we will be working on adding more chapters about how to use the O2 Platform and reducing the learning curve. Basically is to continue developing the book in a way that more developers and security consultants can take advantage of the framework already created. We need to define the outline and then start to write the content. The roadmap here is to define/discuss the outline of the chapters, we defined some sections that are a must to include in the next version of the book.

Writing and Documentation Review Session

SUMMIT DESCRIPTION: OWASP Documentation Projects are a key element in the industry. They are broadly adopted and used. This session aims to review the below documents, and give recommendations on where they can be improved.

Books to be Reviewed:

  • OWASP AppSensor Project
  • OWASP Development Guide Project
  • OWASP Code Review Guide Project
  • OWASP Testing Guide Project
  • OWASP Code of Conduct

During this session, the objectives we will be covering are:

  1. Figure out what needs to be done for each project.
  2. Assign sections to each participant.
  3. Finish various sections assigned to you.
  4. Consolidate all finished sections.

OUTCOMES Larry Conklin, the Project Manager, participated during the session which was really good because we had the chance to discuss about the book and the sections that need improvement.

We received feedback about the organization of the content and also about completing the chapter that requires more content. Pretty much the feedback received was about organization. For the Code Review Guide, there are some content that needs to be finished and we are expecting to finished it soon. Larry defined a nice goals to be completed and we are working on them :

I am need for authors to sign up for the following…

  1. Manual Review - Pros and Cons (https://www.owasp.org/index.php/CRV2_ManualReviewProsCons)
  2. 360 Review: Coupling source code review and Testing / Hybrid Reviews (https://www.owasp.org/index.php/CRV2_360Review)
  3. Code Review Approach (https://www.owasp.org/index.php/CRV2_CodeReviewApproach) I am not sure about this subject. It seems to me it would be covered in the above section under Code Review Introduction.
  4. Application Threat Modeling (https://www.owasp.org/index.php/CRV2_AppThreatModeling) Update this section. I am going to take this one.
  5. Understanding Code layout/Design/Architecture (https://www.owasp.org/index.php/CRV2_CodeLayoutDesignArch)
  6. SDLC Integration (https://www.owasp.org/index.php/CRV2_SDLCInt) Update this section
  7. Secure Deployment Configuration (https://www.owasp.org/index.php/CRV2_SecDepConfig)
  8. Metrics and Code Review (https://www.owasp.org/index.php/CRV2_MetricsCodeRev) Update this section
  9. Source and sink reviews (https://www.owasp.org/index.php/CRV2_SourceSinkRev)
  10. Code Review Coverage (https://www.owasp.org/index.php/CRV2_CodeRevCoverage) Update this section
  11. Risk based approach to Code Review (https://www.owasp.org/index.php/CRV2_RiskBasedApproach) I am not sure about this subject. It seems to me it would be covered in the above section under Coder Review Introduction.
  12. Code Review and Compliance (https://www.owasp.org/index.php/CRV2_CodeRevCompliance) Update this section


OWASP PHP Security and RBAC Projects Session

SESSION DESCRIPTION: The aim of this session is to introduce attendees to both projects, and to get them working on project related activities.

OWASP PHP Security Project

  1. To demonstrate and introduce the OWASP PHP Security Project, have people contribute to it and have people contribute it to their own projects!
  2. The project is developed, we're going to show sample usages and have people try to hack them (which should be impossible). We also introduce the libraries and discuss what future works are needed on the project.
  3. The project is really interesting and has a cool aim, and this will help get a lot more people in its community.

OWASP RBAC Project

  1. OWASP RBAC is a new cutting-edge technology that can revolutionize the authorization domain. Unfortunately because its rigorous and complex, we haven’t been very successful in expanding its usage.
  2. Get the people know how awesome this is, and get them use it in their applications. This is a pretty mature project and is one of those things that you don't know exists, but when you do you can't get enough of. We also like to get contributors porting it to other programming languages.
  3. We've done 85% of the job. There is a website, API, full code with tests, all we need is people to go ahead and use it, and some people who want to use it in another programming language so that we get the community to port it!

OUTCOMES The outcome of our sessions were only outreach. We expected more participants and project promotion, but due to limited audience we were unable to achieve that. We planned to have an audience, intrigue them, and get them to support the project by promotion, using the product, coding, and testing. However, we were not really able to accomplish what we set out to accomplish before the summit due to limited participants.

Most of the team working on these projects are students, so we will do a promotion kick-start after the Fall semester. We will start coding and contributing to the project after they are out of school. I want to add a whole new section to project as well. We plan to develop the full roadmap for 2014 after the exams and Rahul’s graduation.

ESAPI Hackathon Session

SESSION DESCRIPTION: Take part in building the next generation of the Enterprise Security API. In this hackathon we will focus on building modular security controls that can be plugged in to the brand new ESAPI 3.0 framework allowing developers to quickly and easily integrate the security controls they need into their projects. During the hackathon, the ESAPI leaders will be on-site to get the effort kicked off, join in the coding fun, and to present awards for submitted components on the final day! Join us to leave your mark on one of the most visible OWASP Code Projects in our arsenal, and help make tomorrow's applications more secure!

OUTCOMES

  1. What were the outcomes of the Hackathon?
    1. We got two bugs from the ESAPI Google Issues fixed. We received a fix from a Maven pom.xml problem I was on one of the SVN branches (kww-java-html-sanitizer). One person wrote some implementations of the proposed interfaces. We met Kevin Greene from DHS SWAMP project that may be a source of grants. Most importantly, we discussed 3 companies (Akamai, Oracle, and LivePerson) about dedicating some of their developer time to ESAPI.
  2. Did you accomplish what you set out to accomplish before the summit?
    1. Well, I was hoping that more coding would have been accomplished there, but meeting Kevin Greene, and discussing companies that could dedicate some of their developers to the project more than makes up for it if those people follow through. I had hoped for more submissions of controls for new ESAPI, but I think that we got the word out, sparked a bunch of interest and it was extremely well received.
  3. What is there left to do?
    1. We need to finish up the proposed interfaces for ESAPI 3.0. Chris said he will try to get those finished by year end 2013. Additionally, to summarize, some of the most important pieces are:
      1. Move from Google Code to GitHub
      2. Stand up new esapi.org website
      3. Work on CloudBees integration
      4. Solidify ESAPI 3.0 interfaces before end of year.
      5. T-Shirts (I have good contacts for this and some great artists already working on the full design)
      6. Sync up on ESAPi Book Status
      7. Schedule and plan next years (Q2) and (AppSec USA) Hackathons

ZAP Hackathon Session

SESSION DESCRIPTION: This session is a chance for people to learn how to work on ZAP from the ZAP Project Leader. ZAP is a community project, and as such participation is actively encouraged. Simon will explain the numerous ways in which individuals and companies can contribute to ZAP. He will also explain how the code is structured and explain how any part of the project can be changed. Working on ZAP is a great way to learn more about web application security.

Being able to change the code means that you can add and change any features you want, either just for you own benefit or to contribute back to the community. There will be time set aside for hacking ZAP, with Simon on hand to answer any questions and give any guidance required. This is a great opportunity to be part of the fastest growing and most active OWASP project.

During this session, Simon will:

  • Explain how people can contribute to ZAP.
  • Demonstrate how to set up a ZAP development environment.
  • Explain ZAP code structure.
  • Show people how to code scripts, active/passive scan rules, add-ons, core changes and improve the docs and localization.
  • Let people hack the ZAP code and docs with full support and guidance.

Please note that if you want to work on ZAP source code (including add-ons) then you should set up a ZAP development environment prior to attending this session.

You will need to download and install Eclipse and import the main ZAP project as well as the ZAP extension projects - for more details see http://code.google.com/p/zaproxy/wiki/Building

You will not need to set up a development environment if you just plan to work on scripts, documentation or translation.

OUTCOMES The hackathon ended up being more of a training event than a session for enhancing ZAP. My goals were fairly flexible. I was primarily interested in getting a dozen or so people along who seemed to be very happy with how it went. Since I was able to do that it means that I'm happy with the outcome. For the hackathon, there is nothing left to do; however, for ZAP, there are always more things to do. I do not have plans for future work related to a ZAP Hackathon.

OWASP AppSensor 2.0 Hackathon

SUMMIT DESCRIPTION: Take part in building the next generation of AppSensor. In this hackathon we will focus on building the code for AppSensor 2.0, which will involve moving to a services (both REST and SOAP) model for event detection and response. During the hackathon, the AppSensor development leaders will be designing and coding side-by-side with you. Come join us and help make the AppSensor idea available to all!

OUTCOMES

  1. What were the outcomes of the Sessions?
    1. Reviewed documentation for V2 of the book and gave initial feedback.
    2. Met with team members in person and discussed V2 book timeline and goals
    3. Presented initial V2 design/code and got feedback from internal team and session visitors
    4. Met with various folks new to OWASP and presented AppSensor along with other projects based on their needs.
    5. By the way, Dennis, could you send me an e-copy of the new doc - I shared the paper copy with someone at the conference who was interested and didn't get it back. I want to give you better feedback over the intro section in

particular.

  1. Did you accomplish what you set out to accomplish before the summit?
    1. Yes. Goal for me was to review V2 book intro and discuss V2 design/ code.
  2. What is there left to do?
    1. For me:
      1. Send more detailed feedback on V2 book intro section to Dennis / Colin
      2. Complete V2 code and release - progress is happening! https://github.com/jtmelton/appsensor
  3. Roadmap for accomplishing what is left to do.
    1. For V2 book review, when Dennis gets me the e-copy of the book, I'll try to get detailed feedback to him within a week or so - definitely by end of year.
    2. For V2 code, I'm looking at a release in Q1 2014. Things are going well at the moment, so we may get some code from other folks as well. Looks like we have 1 or maybe 2 people who are actively jumping in, so I'm hopeful.

OWASP Education Initiatives Session

TRAINING DEVELOPMENT SUMMIT DESCRIPTION: Training is an important part of OWASP's mission as it helps not only in increasing the awareness around application security but also in actually improving the security of applications. In the past, we have tried several training models (e.g. Training Days, Tours, etc.) and dozens of ideas have been put on the table. Nevertheless, we are still missing a viable training model that will be easy to reproduce and will provide added value to attendees.

During the Project Summit, we will discuss various training models, and the experience we have gained over the past years in order to build a model that will be subsequently used to train developers and anyone involved in securing applications.

ACADEMIES DEVELOPMENT SUMMIT DESCRIPTION: The OWASP Academies program aims to bring together academic institutions from all over the world in order to collaborate towards increasing awareness on application security. The OWASP Academy Portal is the actual deliverable of this process: a portal that will provide various types of content (presentations, labs, etc.) to students and faculty who wish to learn or teach application security.

During the Projects Summit we intend to kick start the Academy Portal, complete the initial design and add some actual content. The OWASP Academy Portal will then serve as the meeting point for application security in academia. Moreover, the Projects Summit will serve as a meeting point for several members of the academic community and a unique opportunity to exchange ideas and experience.

OUTCOMES The OWASP Educational Initiatives have suffered from a stall for development. During the project summit, we came together to solve the two main problems that cause this in our opinion:

  • splintering into many projects / initiative
  1. Some of the educational projects / initiatives even competed for volunteers and visibility.
  2. Goals and purpose of each educational project / initiative was not defined with clear boundaries.
  3. Some of the educational projects / initiatives suffered form lack of visibility, being overrun (not to say ignored) by "yet another great idea.
  • Unreachable targets for each project/ initiative
  1. The project targets where set high, to high, what seemed to cause a stall in progress as the targets where unreachable.

During the project summit at the AppSec-US 2013, the following was achieved. The volunteers who came together for the Education Project during the summit agreed on:

  • One major project, leading the sub projects that are mainly supporting or implementing projects / initiatives.
  1. The OWASP EDU project is created and nominated to be the leading OWASP educational initiative
  2. Smaller targets, as reachable first target of the EDU project, the creation of "Instructor Lead Courses" has been defined.
  3. During the Summit, we defined the setup / lay-out of what we understand as "Instructor Lead Course”.
    1. We defined the context and building blocks of a "Instructor Lead Course”.
    2. We defined first to implement courses

OWASP Instructor Lead Course outcome. Using a mind map tool, we defined the framework and some implementation ideas for the ILC (instructor Lead Courses):

  • Mission
  1. Produce Training Material.
  2. The material can be delivered in a consistent manner by an experienced professional.
  3. Delivery mechanism agnostic.
  • Available Resources
  • Framework
  • Mechanisms
  1. Lecture
  2. Demo
    1. Mutillidae (vulns)
    2. WebGoat (coding)
    3. ZAPBodgeIT (coding)
  3. Hands-on Labs
    1. attack
    2. coding
  • Precompiled courses
  1. OWASP Top 10 for development teams
  2. OWASP Secure Development
  3. Testing security in software
  • Topics
  1. OWASP TopTen
    1. SQLi
    2. Broken Authentication
    3. XSS
    4. Insecure Direct Object Reference
    5. Security Misconfiguration
    6. Sensitive data exposure
      1. Information leakage
      2. Improper Error Handling
      3. Insecure Crypto Storage
      4. Insufficient Transport Layer Protection
    7. Missing function level Access Control
    8. CSRF
    9. Known Vulnerabilities
    10. Unvalidated redirects and forwards
    11. Malicious file execution
  2. Secure Development
    1. Secure Design Principles
      1. least privileges
      2. defense in default
      3. secure by default
      4. security / obscurity
      5. fail securely
      6. keeping it simple
      7. default deny
      8. complete mediation
      9. minimize attack surface
      10. Trust no-on
      11. proportional acceptable to risk
    2. Secure Development principles
      1. input validation
      2. output coding
      3. authentication and autorisation
      4. session management
      5. error handling
      6. logging and auditing
    3. Secure Testing
    4. SDLC
  3. Passwords
  4. Basic Risk Classification
    1. How to tell your manager he can be hacked?
Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_2013_Project_Summit_Working_Session_Outcomes_Leader_Reports&oldid=168994"