Difference between revisions of "FLOSSHack for Organizers"

From OWASP
Jump to: navigation, search
(Created page with "FLOSSHack is designed as an event and competition that brings together aspiring "breakers" and open source software that could use a hand in securing their software. == Sele...")
 
Line 10: Line 10:
 
* Is an "up and coming" project -- A relatively new project with a quickly growing user base; more likely to be immature code and will benefit the most people
 
* Is an "up and coming" project -- A relatively new project with a quickly growing user base; more likely to be immature code and will benefit the most people
  
It may be difficult to satisfy all of these properties, but hopefully this provides some guidance.
+
It may be difficult to satisfy all of these properties, but hopefully this provides some guidance.  Note that it is helpful to poll your OWASP chapter for ideas on software targets or what general technologies they are interested in learning more about.
  
  
== Overview of Event ==
+
== Overview of Event Timeline ==
  
 +
* 3-4 weeks prior to workshop: FLOSSHack event schedule announced.  Software platform/technologies can be mentioned, but do not name the target software yet.
 +
* 1 week prior to workshop: Kickoff the competition.  Name the target software, provide all materials needed for testing
 +
* 7-5 days before workshop: Hold a breakers training session
 +
* Workshop: 3-4 hour hack session
  
 +
== Preparation ==
  
 +
=== Communicate with maintainers ===
 +
Before investing too much time in holding the event, make sure that the target software maintainer is on board with the event and can support you in organizing it.  Establish a few ground rules:
 +
* How can the maintainer help you?  Can they provide a virtual machine with the software preinstalled?  What version of the software is best targeted?
 +
* Are there specific deployment scenarios that are more "typical" or "interesting" to attack?  What is the application's authorization model?
 +
* Can the maintainer join the workshop session, either physically or remotely, to help answer questions?
 +
* How will vulnerabilities be communicated to the maintainer?  Is there a secured bug tracker available that will keep flaws hidden until fixed?
 +
* Would the maintainer be willing to provide prizes of some sort to the winners of the competition?
  
== Preparation ==
+
=== Line up venues ===
 +
Obviously, some sort of venue will be needed to gather people together for the breaker training session as well as the workshop.  Consider providing some refreshments for the workshop, since it will be long.
 +
 
 +
=== Determine competition prizes ===
 +
Consider offering at least two prizes for:
 +
* Finder of the "best" bug, as voted on by participants
 +
* Finder of the most bugs
 +
 
 +
Prizes could be funded by a sponsor or the target software maintainer.  Failing that, perhaps draw on OWASP chapter funds.  Prizes do not need to be significant/expensive.  Just a little icing on the cake beyond the bragging rights.
 +
 
 +
=== Make it easy for hackers: provide all materials ===
 +
When the target software is announced and the competition is kicked off, be sure to provide materials to make it easy for breakers to get started with their audit.  If the software isn't super easy to install (or even if it is), try to provide a virtual machine for download with the software pre-installed.  If this isn't possible (perhaps due to OS licensing reasons), perhaps a public installation of the software could be provided that everyone could bang on.  Of course the source code should be provided at the same time, along with any useful documentation.  Remember, some breakers may not be very experienced or know the particular technology platform very well, so try to make it easy.
 +
 
 +
 
 +
=== Breakers training session ===
 +
A central goal of FLOSSHack is to help less experienced programmers and security people learn more about the nuts and bolts of application security testing.  However, FLOSSHack is also a hacking competition, which tends to draw more experienced breakers.  For this reason, it is helpful to have a special session, held early in the week of the competition, to help less experienced folks learn about the kinds of flaws they should be looking for.  To this end, try to set up a 1-2 hour session of talks, discussion, or labs that explain how certain classes of vulnerabilities work.  A hacking tutorial of sorts.  The types of vulnerabilities discussed should be ones that are likely to be found in the target application.  '''However''', don't discuss specific flaws of the target application, lest you make it unfair to others that can't attend the training session.
 +
 
 +
 
 +
=== Set up remote access ===
 +
It may be worthwhile to offer remote access to the hacking session for those who can't make it in person.  In FLOSSHack One, we initially tried using G+ Hangouts for this, but it turned out to be difficult to organize, so we fell back to a simple IRC channel.  Online meeting services or just a simple phone conference bridge could work as well.
 +
 
 +
 
 +
=

Revision as of 16:54, 7 November 2012

FLOSSHack is designed as an event and competition that brings together aspiring "breakers" and open source software that could use a hand in securing their software.


Contents

Selecting a Target

An ideal target application for a FLOSSHack event has the following properties:

  • Open source -- It is critical for newbies to have the source code available while trying to learn about flaws
  • Is a "worthy" project -- Preferably a project that wouldn't otherwise be able to afford a security audit
  • Is currently maintained -- It does little benefit to a project to find vulnerabilities that no one will fix
  • Has a cooperative maintainer -- Support from a software maintainer in running the event can really help things run smoothly
  • Is an "up and coming" project -- A relatively new project with a quickly growing user base; more likely to be immature code and will benefit the most people

It may be difficult to satisfy all of these properties, but hopefully this provides some guidance. Note that it is helpful to poll your OWASP chapter for ideas on software targets or what general technologies they are interested in learning more about.


Overview of Event Timeline

  • 3-4 weeks prior to workshop: FLOSSHack event schedule announced. Software platform/technologies can be mentioned, but do not name the target software yet.
  • 1 week prior to workshop: Kickoff the competition. Name the target software, provide all materials needed for testing
  • 7-5 days before workshop: Hold a breakers training session
  • Workshop: 3-4 hour hack session

Preparation

Communicate with maintainers

Before investing too much time in holding the event, make sure that the target software maintainer is on board with the event and can support you in organizing it. Establish a few ground rules:

  • How can the maintainer help you? Can they provide a virtual machine with the software preinstalled? What version of the software is best targeted?
  • Are there specific deployment scenarios that are more "typical" or "interesting" to attack? What is the application's authorization model?
  • Can the maintainer join the workshop session, either physically or remotely, to help answer questions?
  • How will vulnerabilities be communicated to the maintainer? Is there a secured bug tracker available that will keep flaws hidden until fixed?
  • Would the maintainer be willing to provide prizes of some sort to the winners of the competition?

Line up venues

Obviously, some sort of venue will be needed to gather people together for the breaker training session as well as the workshop. Consider providing some refreshments for the workshop, since it will be long.

Determine competition prizes

Consider offering at least two prizes for:

  • Finder of the "best" bug, as voted on by participants
  • Finder of the most bugs

Prizes could be funded by a sponsor or the target software maintainer. Failing that, perhaps draw on OWASP chapter funds. Prizes do not need to be significant/expensive. Just a little icing on the cake beyond the bragging rights.

Make it easy for hackers: provide all materials

When the target software is announced and the competition is kicked off, be sure to provide materials to make it easy for breakers to get started with their audit. If the software isn't super easy to install (or even if it is), try to provide a virtual machine for download with the software pre-installed. If this isn't possible (perhaps due to OS licensing reasons), perhaps a public installation of the software could be provided that everyone could bang on. Of course the source code should be provided at the same time, along with any useful documentation. Remember, some breakers may not be very experienced or know the particular technology platform very well, so try to make it easy.


Breakers training session

A central goal of FLOSSHack is to help less experienced programmers and security people learn more about the nuts and bolts of application security testing. However, FLOSSHack is also a hacking competition, which tends to draw more experienced breakers. For this reason, it is helpful to have a special session, held early in the week of the competition, to help less experienced folks learn about the kinds of flaws they should be looking for. To this end, try to set up a 1-2 hour session of talks, discussion, or labs that explain how certain classes of vulnerabilities work. A hacking tutorial of sorts. The types of vulnerabilities discussed should be ones that are likely to be found in the target application. However, don't discuss specific flaws of the target application, lest you make it unfair to others that can't attend the training session.


Set up remote access

It may be worthwhile to offer remote access to the hacking session for those who can't make it in person. In FLOSSHack One, we initially tried using G+ Hangouts for this, but it turned out to be difficult to organize, so we fell back to a simple IRC channel. Online meeting services or just a simple phone conference bridge could work as well.