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

Test2test

From OWASP
Revision as of 17:11, 3 January 2013 by Samantha Groves (talk | contribs)

Jump to: navigation, search


NEW-PROJECTS-BANNER.jpg

An OWASP project is a collection of related tasks that have a defined roadmap and team members. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team. OWASP currently has over 120 active projects, and new project applications are submitted every week. This is one of the most popular divisions of OWASP as it gives members an opportunity to freely test theories and ideas with the professional advice and support of the OWASP community.


All OWASP tools, document, and code library projects are organized into the following categories:

  • PROTECT - These are tools and documents that can be used to guard against security-related design and implementation flaws.
  • DETECT - These are tools and documents that can be used to find security-related design and implementation flaws.
  • LIFE CYCLE - These are tools and documents that can be used to add security-related activities into the Software Development Life Cycle (SDLC).


Every project has an associated mail list. You can view all the lists, examine their archives, and subscribe to any project by visiting the OWASP Project Mailing Lists page.

A summary of recent project announcements is available on the OWASP Updates page.


OWASP Project Inventory

  • Incubator Projects: OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway.
  • Lab Projects: OWASP Labs projects represent projects that have produced an OWASP reviewed deliverable of value.
  • Flagship Projects: The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole.


Who Should Start an OWASP Project:

  • Application Developers.
  • Software Architects.
  • Information Security Authors.
  • Those who would like the support of a world wide professional community to develop or test an idea.
  • Anyone wishing to take advantage of the professional body of knowledge OWASP has to offer.


Contact Us

If you have any questions, please do not hesitate to contact the OWASP Project Manager, Samantha Groves.




                                                                                                                             
Projects Front Page Graphic.jpg



Projects Banner 2.jpg



Projects Banner 3.jpg


So you want to start a project...

Starting an OWASP Project is easy. You don't have to be an application security expert. You just have to have the drive and desire to make a contribution to the application security community.

Here are some of the guidelines for running a successful OWASP project:

  • The best OWASP projects are strategic - they make it easier to produce secure applications by filling a gap in the application security knowledge-base or technology support.
  • You can run a single person project, but it's usually best to get the community involved. You should be prepared to support a mailing list, build a team, speak at conferences, and promote your project.
  • You can contribute existing documents or tools to OWASP! Assuming you have the intellectual property rights to a work, you can open it to the world as an OWASP Project. Please coordinate this with OWASP by contacting owasp(at)owasp.org.
  • Available Grants to consider if you need funding - Click Here
  • You should promote your project through the OWASP channels as well as by outside means. Get people to blog about it!


Creating a new project

Here's the simple process for starting a new OWASP Project.


  • Get the following information together:

A - PROJECT

  1. Project Name,
  2. Project purpose / overview,
  3. Project Roadmap,
  4. Project links (if any) to external sites,
  5. Project License,
  6. Project Leader name,
  7. Project Leader email address,
  8. Project Leader wiki account - the username (you'll need this to edit the wiki),
  9. Project Contributor(s) (if any) - name email and wiki account (if any),
  10. Project Main Links (if any).


OWASP Recommended Licenses

Why are you recommending these licenses?
Which other open source licenses are eligible for an OWASP project?

Choosing a license under which an artifact is distributed and enforcing the license are prerogatives of the copyright holders over that artifact. By default, each contributor is copyright holder over the contributed piece. Contributors must all agree on the license and cooperate in enforcing it or must assign their copyright to the entity which becomes responsible for choosing and enforcing the license.

OWASP is a collaborative initiative for the public good and most of its output is expected to be functional, rather than aesthetic. The problem OWASP tackles is so large that OWASP acknowledges a need to collaborate with the commercial world. Therefore, in order to become an OWASP Sponsored Project, you should be comfortable with:

  • Allowing arbitrary uses for your work, for example for commercial purposes. (If you disagree, consider using CC-BY-NC.)
  • Revealing to the world your project's source code (its form preferred for modification).
  • Allowing your work, under certain conditions (see below), to be modified by others and redistributed. (If you disagree, consider using CC-BY-ND.)
How to choose a license for artifcts of your OWASP project
Artifact Under what conditions can your work be modified and redistributed?
As long as modifications are licensed in the same spirit If credit is appropriately given to you Under any circumstances
Standalone Tool Run locally
GPL (newest version as of 2016 is 3.0)

The "General Public License" protects users' four essential freedoms, among other things by requiring someone who distributes software derived from yours to also publish the source code for the modifications. Anyone can charge money for distributing copies of the software, but cannot prevent its recipients from redistributing it for free. The GPL allows the copyright holders to distribute the software under additional licenses, too, which can be a way to make it proprietary-friendly.
Apache License (newest version as of 2016 is 2.0)

Has the fewest restrictions, even allowing proprietary modifications and proprietary forks of your project, and is more up-to-date than the BSD license.
CC0 (newest version as of 2016 is 1.0)

The "Public Domain Dedication" means that anybody can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
Consumed over the network
AGPL (newest version as of 2016 is 3.0)

The "Affero General Public License" extends the GPL to SaaS: users of the modified software must be able to obtain the source code of the modifications.
Library
GPL or LGPL (newest version as of 2016 is 3.0)

The "Lesser General Public License" relaxes the GPL for libraries: if the library is not modified, just integrated (function calls, global variables,...), with other software, it does not require the source code of the other software to be published. The Free Software Foundation recommends the LGPL only for libraries which have established competitors for the same functionality, otherwise they recommend the full GPL.
Document (includes E-Learning, presentations, books etc.)
CC-BY-SA (newest version as of 2016 is 4.0)

The "Creative Commons Attribution-ShareAlike" is like the GPL, but for documents.
CC-BY (newest version as of 2016 is 4.0)

The "Creative Commons Attribution" is like the Apache License, but for documents.


Project Release

  • As your project reaches a point that you'd like OWASP to assist in its promotion, the OWASP Global Projects Committee will need the following to help spread the word about your project:
  1. Conference style presentation that describes the tool/document in at least 3 slides,
  2. Project Flyer/Pamphlet (PDF file),


  • If possible, get also the following information together:

B – FIRST RELEASE

  1. Release Name,
  2. Release Description,
  3. Release Downloadable file link
  4. Release Leader,
  5. Release Contributor(s),
  6. Release Reviewer,
  7. Release Sponsor(s) (if any),
  8. Release Notes
  9. Release Main Links (if any),


Project Process Forms

These forms were created to help project leaders, and those interested in a going through a process in the OWASP projects infrastructure. They facilitate the management of each query based on the specific task an applicant will need help with. The forms are described below, and they are linked with their designated online application form.

  • Project Transition Application:The OWASP project transition form gives current project leaders an easy way of handing over project administration information to individuals wishing to take over a project.
  • Project Review Application:This form is for current project leaders to request a review of their project based on OWASP graduation criteria. The aim is to designate an OWASP volunteer to review these projects within 3 months time.
  • Project Donation Application:This form is for projects outside of the OWASP project infrastructure. Project Leaders for these open source projects can choose to partner or give their project to OWASP directly through this form.
  • Project Abandonment Request:The OWASP project abandonment form gives current project leaders an easy way of letting the OWASP Foundation know that they wish to resign their project leader duties. This form should be used when no replacement project leader exists to take over these duties.


OWASP Project Lifecycle

The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state. The greater the maturity of the project, the greater the level of responsibility for the project leader. These responsibilities are not trivial as OWASP provides incentives and benefits (Section 7) for projects who take on these added responsibilities.


The OWASP Project Lifecycle is broken down into the following stages:

Incubator Projects: OWASP Incubator projects represent the experimental playground where projects are still being designed, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity; moreover, the label allows project leaders to leverage the OWASP name while their project is still maturing. OWASP Incubator projects are given a place on the OWASP Projects Portal to leverage the organizations' infrastructure, and establish their presence and project history.

Labs Projects: OWASP Labs projects represent projects that have produced a deliverable of significant value. Leaders of OWASP Labs projects are expected to stand behind the quality of their projects as these projects have matured to the point where they are accepted by a significant portion of the OWASP community. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are ready for mainstream usage. OWASP Labs Projects are meant to be the collection of established projects that have gained community support and acclaim by undergoing the project review process.


OWASP Project Stage Benefits

This section outlines the benefits of starting an OWASP project, and the benefits of being at each different stage in the projects lifecycle. In my short time here at OWASP as the PM, I have had several potential project leaders ask me what the benefits are of starting their project with OWASP. Below is my proposal for each Stage’s benefits.

Incubator

  • Financial Donation Management Assistance
  • Project Review Support
  • WASPY Awards Nominations
  • OWASP OSS and OPT Participation
  • Opportunity to submit proposal: $500 for Development.
  • Community Engagement and Support
  • Recognition and visibility of being associated with the OWASP Brand.

Labs

  • All benefits given to Incubator Projects
  • Technical Writing Support
  • Graphic Design Support
  • Project Promotion Support
  • OWASP OSS and OPT: Preference

Flagship

  • All benefits given to Incubator & Labs Projects
  • Grant finding and proposal writing help
  • Yearly marketing plan development
  • OWASP OSS and OPT participation preference


For more detailed information on OWASP Project Stage Benefits, please see the 2013 Project Handbook.


OWASP Project Graduation

The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.

The review centers around the following core questions. Each core question has three (3) specific questions made up of binary queries. A project must receive at least two (2) positive responses from each reviewer in two of the binary questions, to warrant a postive response for the core question. Each core question must receive a positive response from both project reviewers to pass the Project Health Assessment for Incubator Projects.


OWASP Project Health Assessment

The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the Project Health Assessment Criteria Document. If a project passes the assessment, it then becomes eligible to graduate into the OWASP Labs Project stage. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.


OWASP Project Deliverable/Release Assessment

The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.

Reviews must be performed by two (2) OWASP Chapter or Project Leaders, and their review must answer affirmatively to at least the first two (2) core Project Deliverable/Release Review questions. A project must pass the OWASP Project Deliverable/Release Assessment in order to graduate into the OWASP Labs Project stage.


Flagship Projects

The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining.


Code


Tools


Documentation


Labs Projects

OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.


Tools


Documentation


Incubator Projects

OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.


Code


Tools


Documentation


Inactive Projects

Archived Projects

OWASP Archived Projects are inactive Labs projects. If you are interested in pursuing any of the projects below, please contact us and let us know of your interest.


Philosophy

OWASP stands for informed security decisions based on a solid, comprehensive understanding of the business risk associated with an application. OWASP's philosophy is that achieving security involves all parts of an organization, including people, process, and technology. We support the use of our brand consistent with this philosophy. However, we cannot allow the use of our brand when it implies something inconsistent with OWASP's comprehensive and balanced approach to application security. Therefore, we have defined these brand usage rules to clarify appropriate and inappropriate uses of the OWASP brand, including our name, domain, logos, project names, and other trademarks.


Brand Usage Rules

The following rules make reference to all OWASP marketing and graphic materials. This refers to any tools, documentation, or other content from OWASP. The rules also make reference to "OWASP Published Standards" which are currently in the process of being developed and released. Currently there are no OWASP Published Standards.

  1. The OWASP Brand may be used to direct people to the OWASP website for information about application security.
  2. The OWASP Brand may be used in commentary about the materials found on the OWASP website.
  3. The OWASP Brand may be used by OWASP Members in good standing to promote a person or company's involvement in OWASP.
  4. The OWASP Brand may be used in association with an application security assessment only if a complete and detailed methodology, sufficient to reproduce the results, is disclosed.
  5. The OWASP Brand must not be used in a manner that suggests that The OWASP Foundation supports, advocates, or recommends any particular product or technology.
  6. The OWASP Brand must not be used in a manner that suggests that a product or technology is compliant with any OWASP Materials other than an OWASP Published Standard.
  7. The OWASP Brand must not be used in a manner that suggests that a product or technology can enable compliance with any OWASP Materials other than an OWASP Published Standard.
  8. The OWASP Brand must not be used in any materials that could mislead readers by narrowly interpreting a broad application security category. For example, a vendor product that can find or protect against forced browsing must not claim that they address all of the access control category.
  9. The OWASP Brand may be used by special arrangement with The OWASP Foundation.


Resources


Merchandise Requests


Ads/Flyers


Banners


Presentations

These slides are presented at Global AppSec Conferences by the Global Board to provide a high level overview of OWASP and to highlight some of the key initiatives at a Global level. This can be presented in its current form at OWASP Chapter meetings to enable a clarification of the mission and purpose of the local chapter. This can also be used or sent to the press/media when looking for an "overview of owasp".


OWASP Press

The OWASP press is a pattern for massive community collaboration on OWASP documentation projects with just-in-time publication. Visit the OWASP Press Page for more information.


OWASP Project Infrastructure

  • OWASP Project Lifecycle: The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state.


  • Incubator Project: OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.


  • Labs Project: OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.


  • Flagship Project: The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining.


  • Project Benefits: The standard list of resources and incentives made available to project leaders based on their project's current maturity level.


OWASP Project Reviews

  • Project Reviews: Project reviews are the method OWASP uses to establish a minimal baseline of project characteristics and release quality. Reviews are not mandatory, but they are necessary if a project leader wishes to graduate to the next level of maturity within the OWASP Global Projects infrastructure. Projects can be reviewed when an Incubator project wishes to graduate into the OWASP Labs designation, and project releases can be reviewed if they want the quality of their deliverable to be vouched for by OWASP.


  • Project Reviewer Pool: The project reviewer pool is made up of veteran reviewers who have proven themselves dedicated to executing quality reviews of projects.


  • Project Graduation: The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.


  • Project Health Assessment: The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the Project Health Assessment Criteria Document.


  • Project Release: A project release refers to the final deliverable a project produces. It is the final product of the project.


  • Project Deliverable/Release Review: The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.


OWASP Project Processes

  • Project Processes: The set of streamlined processes that exist to help projects move smoothly through the OWASP Project Lifecycle.


  • Project Inception Process: The Project Inception Process is how a brand new idea becomes an OWASP Project. Such projects are labeled as OWASP Incubator projects. The process involves submitting the proposed project name, project leader information, project description, project roadmap, and selecting an appropriate open-source license for the project using the New Project Form on the Projects Portal.


  • Project Donation Process: The Project Donation Process is used for a project that has an existing functional release, but is not currently associated with OWASP. This process is the primary mechanism by which individuals or organizations can transfer the ownership of their project’s copyright to OWASP.


  • Project Transition Process: The Project Transition Process is used to transition leadership of a project to a new project leader. This is a simple automated process to transfer the relevant accounts, mailing lists, and other project resources to the new project leader.


  • Project Abandonment Process: The Project Abandonment Process was put in place for those occasions in which a project leader is no longer able to manage their project, and has not been able to find a suitable replacement for the leader role. Project Abandonment can also occur when the project leader feels his/her project has become obsolete. Under these circumstances, the acting project leader is encourage do submit the Project Abandonment Form found in the Projects Portal.


  • Incubator Graduation Process: The Incubator Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.


Projects at Conferences

  • AppSec Conferences: OWASP AppSec conferences bring together industry, government, security researchers, and practitioners to discuss the state of the art in application security. This series was launched in the United States in 2004 and Europe in 2005. Global AppSec conferences are held annually in North America, Latin America, Europe, and Asia Pacific.


  • Open Source Showcase: The Open Source Showcase is an OWASP AppSec Conference event module designed to give Open Source project leaders the opportunity to demo their projects.


  • OWASP Project Track: The OWASP Project Track is an OWASP AppSec Conference event module designed to give OWASP Project leaders the opportunity to showcase their projects as an official conference presenter.


OWASP Projects General

  • OWASP Code of Ethics: The OWASP Code of Ethics are the set of guidelines and principles that the OWASP Foundation expects all of its members and conference attendees to abide by. A copy of the Code of Ethics can be found here in the OWASP About page.


OWASP Projects, a global division of the OWASP Foundation, is run under the same world wide not-for-profit charitable status as all the foundation strategic groups. OWASP provides a platform for contributors to share their work while providing them with the project and community support they need throughout their project development. All OWASP Projects are run by volunteers and they rely on personal donations and sponsorship to continue their development. Donate to OWASP Projects, and we promise to spend your money wisely on open source initiatives.

This is how your money can help:

  • $20 could help us spread the word on the importance of open source initiatives in the Application Security industry.
  • $100 could help fund OWASP project demos at major conferences.
  • $250 could help get our volunteer Project Leaders to speaking engagements.


Donate Button.jpg


OWASP Project Sponsors

Americas

Africa

Asia

Europe

Middle East

Social Media

Blogger-32x32.png Twitter-32x32.png Facebook-32x32.png Linkedin-32x32.png Google-32x32.png Ning-32x32.png


Security Podcast with Jim Manico
Jim Projects.jpg The OWASP foundation presents the OWASP PODCAST SERIES hosted and produced by Jim Manico. Listen as interviews are conducted with OWASP volunteers, industry experts and leaders within the field of software security. Visit the Podcast Page for more information.


OWASP Appsec Tutorial Series with Jerry Hoff
Jerry Projects.jpg The OWASP AppSec Tutorial Series project provides a video based means of conveying complex application security concepts in an easily accessible and understandable way. Each video is approximately 5-10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious - provide top notch application security video based training... for free! Visit the Tutorial Series Page for more information.


OWASP Global Projects Announcements

Open Source Project Track Opportunities at AppSec APAC 2013

The AppSec APAC conference organizers, in conjunction with the Global Projects Division, is pleased to announce a Call for Entries for the OWASP Projects Track (OPT).

We are offering a limited number of speaking opportunities to open source projects this year, as well as FREE conference admission for the representatives of the chosen projects. We would like to invite ALL open source projects to apply.


About the AppSec APAC 2013 OWASP Project Track The APAC 2013 OPT forum differs from OSS in that only OWASP Projects can apply to participate. This is a great opportunity for OWASP Project Leaders to showcase their project as an official conference presenter. Please note that successful OPT applicants are responsible for developing and presenting in their designated timeslot at the conference.

For an opportunity to present your open source project through the OPT at AppSec APAC 2013, please submit your application using the OSPT APAC 2013 Application.


Sponsorship Opportunities OWASP Project Leaders have the option of requesting financial assistance from the Foundation to cover travel and hotel expenses ONLY. This funding is only available to projects that have been selected to participate in the OSS and OPT at AppSec APAC 2013. Preference will be given to OWASP Project Leaders that are applying to present at the confernce that is closest to their region. Additionally, preference will be given to OWASP Project Leaders that have not presented or participated in the OPT forum.


Date and Times

APPLICATION DEADLINES

OPT Applications are due: December 28, 2012


CONFERENCE DATE

February 19-22, 2013


OPT DATE & TIME

All OPT Talks will be held between February 21-22, 2013.


LOCATION

Hyatt Regency Jeju
114,Jongmoongwangwang-ro 72 beon-gil,Seogwipo-si,
Jeju Special Self-Governing Province
South Korea
Phone: +82 64 733 1234


Samantha Groves: OWASP Project Manager
Sam2.jpg Samantha Groves is the Project Manager at OWASP. Samantha has led many projects in her career, some of which include website development, brand development, sustainability and socio-behavioural research projects, competitor analysis, event organisation and management, volunteer engagement projects, staff recruitment and training, and marketing department organisation and strategy implementation projects for a variety of commercial and not-for-profit organisations. She is eager to begin her work at OWASP and help the organisation reach its project completion goals.

Samantha earned her MBA in International Management with a concentration in sustainability from Royal Holloway, University of London. She earned her Bachelor's degree majoring in Multimedia from The University of Advancing Technology in Mesa, Arizona, and she earned her Associate's degree from Scottsdale Community College in Scottsdale, Arizona. Additionally, Samantha recently attained her Prince2 (Foundation) project management certification.

Please see the Project Manager Role Description for more information.


GPC Meeting Reports

2012


Board Meeting Reports


Project Funds


Project Manger's Quarterly Strategic Objectives

Goals and Objectives: 2012 Q4

  • Identify and initiate 3 grant opportunities.
  • Complete metadata for Salesforce import related to projects.
  • Finalise and launch the Project database communication tool and webpage
  • Complete the project lifecycle redesign
    • Sort out levels and stages for projects.
    • Determine and define landmarks for project advancement.
    • Document release stages and reviewer participation.
  • Update Project handbook
    • Document process for project donation.
    • Define and develop process for project advancement.
    • Define and develop process for funding requests.


Contact the Project Manager

If you need any help with anything projects related, or if you simply need some more information, please do not hesitate to contact the OWASP Project Manager, Samantha Groves.


Jason Li
Jason.jpg Jason has led security architecture reviews, application security code reviews, penetration tests and provided web application security training services for a variety of commercial, financial, and government customers. He is also actively involved in the Open Web Application Security Project (OWASP), serving on the OWASP Global Projects Committee and as a co-author of the OWASP AntiSamy Project (Java version). Jason earned his Post-Master's degree in Computer Science with a concentration in Information Assurance from Johns Hopkins University. He earned his Master's degree in Computer Science from Cornell University, where he also earned his Bachelor's degree, double majoring in Computer Science and Operations Research.

Past conference presentations include:


Justin Searle
Justin.jpg Justin is a Managing Partner of UtiliSec, specializing in Smart Grid security architecture design and penetration testing. Justin led the Smart Grid Security Architecture group in the creation of NIST Interagency Report 7628 and currently plays key roles in the Advanced Security Acceleration Project for the Smart Grid (ASAP-SG), National Electric Sector Cybersecurity Organization Resources (NESCOR), and Smart Grid Interoperability Panel (SGIP). Justin has taught courses in hacking techniques, forensics, networking, and intrusion detection for multiple universities, corporations, and security conferences, and is currently an instructor for the SANS Institute. In addition to electric power industry conferences, Justin frequently presents at top security conferences such as Black Hat, DEFCON, OWASP, and AusCERT. Justin co-leads prominent open source projects including the Samurai Web Testing Framework, Middler, Yokoso!, and Laudanum. Justin has an MBA in International Technology and is a CISSP and SANS GIAC certified Incident Handler (GCIH), Intrusion Analyst (GCIA), and Web Application Penetration Tester (GWAPT).


Keith Turpin
Keith.jpg Over the years Keith has held a number of positions at The Boeing Company including: Application Security Assessments team leader, Team Leader for IT Security International Operations, Team Leader for Information and Supply Chain Security Assessments, engineering systems integrator, software developer and senior manufacturing engineer on the 747 airplane program.

He represented Boeing on the International Committee for Information Technology Standard's cyber security technical committee and served as a U.S. delegate to the ISO/IEC sub-committee on cyber security.

He is a member of the (ISC)2 Application Security Advisory Board, and the Director of the HPPV Northwest regional engineering competition.

You can see his OWASP project on secure coding practices here: http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

The presentation on his OWASP project at AppSec USA 2010 can be found here: http://vimeo.com/17018329

You can see the video of his AppSec USA 2009 presentation on Building Security Assessment Teams here: http://vimeo.com/8989378


Nishi Kumar
Nishi.jpg Nishi Kumar IT Architect Specialist, FIS

Nishi Kumar is an Architect with 20 years of broad industry experience. She is part of OWASP Global Industry Committee and project lead for OWASP CBT (Computer based training) project. She is a committed contributor of OWASP. She has spearheaded Secure Code Initiative program in FIS Electronics Payment division. As part of that program, she has delivered OWASP based training to management and development teams to various groups in FIS. She has been involved with PA-DSS certification of several applications in FIS. Since joining FIS in 2004 she has worked as an architect and team lead for several financial payment and fraud applications. She has hands-on accomplishments in design, development and deployment of complex software systems on a variety of platforms. Prior to joining FIS Nishi Kumar has worked for Pavilion, HNC, Fair Isaac, Trajecta, Nationwide Insurance and Data Junction as Senior Software Engineer, Architect and in Project Management roles. Nishi can be reached at: nishi787(at)hotmail.com


Brad Causey
Brad.jpg Brad Causey is a Web Application Security, Forensics, and Phishing specialist working in the financial sector. He frequently contributes to various open source projects, and participates in training and lectures at various educational facilities.

Brad Causey is also an OWASP GPC member, the President of the OWASP AL Chapter, and the President of the AL IISFA Chapter.


Chris Schmidt
Chris.jpg Chris is currently the Project Leader for the OWASP ESAPI Projects and also serves on the OWASP Global Projects Committee. He has been involved with OWASP for 4 years and has spoken at many OWASP events about the benefits of the Enterprise Security API as well as participated in Leadership discussions amongst the organization.

During the day, Chris is an Application Security Engineer and Senior Software Engineer for Aspect Security where he has been since fall 2010. Prior to joining the team at Aspect Security he spent 5 years as 'Black Ops Beef' for ServiceMagic Inc with the official title of Software Engineer. Before getting involved in software professionally, Chris worked in hardware as a Senior Field Service Engineer providing hardware and software support for PC’s, Servers, Midrange Systems and Peripherals for 9 years.

In addition to his professional career he is also a musician with several ongoing projects and enjoys cold beer and long walks in the park.

Links:



OWASP Representation


Global Project Committee Members


If you need any help with anything projects related, or if you simply need some more information, please do not hesitate to contact the OWASP Project Manager, Samantha Groves.


Retrieved from "https://wiki.owasp.org/index.php?title=Test2test&oldid=141770"