Skip to content

Latest commit

 

History

History
97 lines (59 loc) · 5.27 KB

secure-design-hackathons.md

File metadata and controls

97 lines (59 loc) · 5.27 KB
Raw
Title URL Author
Secure Design Hackathons
Zoe Braiterman

Secure Design Hackathons

Purpose of a secure design hackathon

Insecure design is now included as number 4 in the OWASP Top 10 Web Application Security Risks. The purpose of these hackathons is to allow security learners at all levels to think outside the box about solving real-world problems.

The types of hypothetical systems or applications are meant to be themes, with multiple applications of their kind, already on the market, with many users. The point of the activity is centered around community-building, and the challenges are meant to facilitate creative though processes, not develop actual applications or products.

The hackathons are intended to be fun and collaborative, and a good way to connect like-minded individuals and provide a chance for them to build up their project portfolio, on their GitHub accounts and/or YouTube and/or other social media platforms.

Who should participate in this type of hackathon?

Any individual interested to learn about security, or just think about solving real world problems in technology. The structure of each of these Hackathons allow for complete beginners to participate. The problems to solve and questions asked are very high-level and open-ended, in order to encourage diverse perspectives.

General structure of a hackathon

  1. Explain to participants what we expect them to submit for their solutions
  2. Participants form teams and work on their solutions (with access to their team members and our mentorship over Slack, or another team communications platform).
  3. Participants submit their solutions, and present at a later date (perhaps after a week or two).

Assignment

Things for participants to consider and explain in written form:

  • What controls will you put into place to protect storage and transmission of data?
  • What kinds of cardholder data will be processed from users?
  • How will you encrypt that data, in transit and at rest? Why?
  • To whom will you grant access to what data (refer to your answer to the previous question)?
  • Web application firewall (WAF) configuration considerations
  • What are some potential data privacy concerns, and what are some steps you would take to protect users’ data? Consider regulatory requirements, and steps you would take to implement them.

Deliverables participants may want to submit

  • Diagrams
  • A questionnaire for a potential development team (along with possible answers and explanations for your choice of questions)
  • A list of answers to the questions we pose.
  • Written descriptions of a participant's underlying thought processes
  • Architectural diagrams (for more advanced participants)
  • Wireframes or user stories

Very basic threat modeling related questions to consider, regardless of submission format (Thank you, Adam Shostack, for advising on these question choices)

  • What are you building (Referencing your answers to the above questions)?
  • What can go wrong?
  • What could be overlooked or not addressed?
  • How would you attack it?
  • Have you read a news story lately that suggests an attack?
  • What are you going to do about that?
  • Did you do a good enough job?

Some basic questions for a Risk Analysis Team (taken from Phil Martin’s “Simple CISSP” by Phil Martin) may include:

  • What could happen?
  • What would the impact be?
  • How often could it happen?
  • Do we really believe the first three answers?

Recognition of Submissions

**Option to submit a pull request to the OWASP Threat Modeling Cookbook project

If you choose this option, please

  • Follow the guidelines documented by Project Leader, Jonathan Marcil.
  • Direct any clarifying questions you may have toward me (Zoe Braiterman) on Twitter or LinkedIn.

Before participating, participants are prompted to check the following Creative Commons licensing information.

Past Hackathons