Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

DevSecCon London 2017: Threat modeling in a CI environment by Steven Wierckx

347 visualizaciones

Publicado el

DevSecCon London 2017: Threat modeling in a CI environment by Steven Wierckx

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

DevSecCon London 2017: Threat modeling in a CI environment by Steven Wierckx

  1. 1. Join the conversation #DevSecCon BY STEVEN WIERCKX THREAT MODELING IN A CI ENVIRONMENT: A LIGHTWEIGHT APPROACH TO WHITEBOARD HACKING
  2. 2. Agenda •  TM introduction •  Agile and TM, a problem? •  OWASP Agile TM methodology (STAYPUFT) •  Exercises / examples •  SCRUM •  Kanban •  Summary
  3. 3. Steven Wierckx •  7 years developer experience •  3 years (technical) testing experience •  5+ years of information security experience •  Application security consultant Toreon •  Toreon (www.toreon.com) •  OWASP Threat Model project leader •  Twitter: @ihackforfun
  4. 4. You? •  Has threat model experience? •  Works in a CI / Agile environment?
  5. 5. SDLC DESIGN BUILD TEST PRODUCTION web / mobile applica;on project (acquisi;on / development) TRAINING SAMM assistance Source code review (sta;c) Security tes;ng (dynamic) WAF tuning Threat modeling Coding guidelines Configura;on guidelines
  6. 6. TM introduction Diagram • What are we building? Identify threats • What can go wrong? Mitigate • What are we doing to defend against threats? Validate • Validate steps 1-3, report
  7. 7. “Classic” TM 1.  Threat Modeler, Business Owner, Application architect •  Doomsday scenario’s •  Context diagram •  DFD diagrams •  Trust boundaries 2.  Threat Modeler starts documentation & prepare next workshop 3.  Threat Modeler, Business Owner, Application architect •  Perform analysis of trust boundaries •  Find vulnerabilities •  Document all assumptions •  Analyze residual risk 4.  Threat Modeler finishes documentation & recommends solutions 5.  Threat Modeler, Business Owner, Application architect, Management •  Decide on mitigations
  8. 8. Agile and TM, a problem? •  Classic process does not fit fast moving organizations •  Threat models need to be kept up to date •  Threat models are also documentation •  Threat modeling is agile: keep what works, discard everything else -> A different TM process is needed!
  9. 9. OWASP STAYPUFT •  A process that should fit most (all?) agile methodologies •  A process that ensures good TM practices •  Result of the 2017 OWASP London summit •  https://owaspsummit.org/Working-Sessions/Threat-Model/index.html •  https://owaspsummit.org/Working-Sessions/Threat-Model/Lightweight-Threat-Modeling- Process.html •  Tentative release date: 10th November 2017
  10. 10. OWASP STAYPUFT •  Ascertain phase: •  Security information is derived from the functional story information. •  Team is encouraged to draw a high-level diagram of the system for a common talking point. •  A non-granular Context Diagram is created to support the security information. •  Use Cases are defined from the business and security user story information, and are used to derive abuse cases •  Threats phase: •  The security information from the Ascertain activity is used to select the template from the Threat Template Library. The Team will know which user story scenario to apply, such as Client-Server, B2B, Distributed cloud. •  Apply the template threats to the Agile user story. •  Provide a list (& severity) of threats against components. The team will get the basis of this information from the selected templates. •  Mitigation phase: •  The team analyses the design and threats that were previously discovered. •  The team does a quick subjective analysis on the threats (non-evidence based). •  The team uses existing OWASP countermeasures to mitigate the associated threats.
  11. 11. SCRUM Actions: 1.  Sprint planning 2.  Daily SCRUM 3.  Sprint review & retrospective Source: wikipedia
  12. 12. SCRUM 1.  Start the TM, add doomsday scenario’s, create context diagram, create basic DFD’s, add trust boundaries, write down assumptions 2.  Sprint planning •  Agree on scope -> update DFD’s, check trust boundaries and assumptions •  Add security to user stories (on epic normally) •  Create (security) user stories (in backlog) 3.  Daily SCRUM •  Notify team of failed assumptions 4.  Sprint review & retrospective •  Gather failed assumptions, evaluate impact
  13. 13. Kanban Principles: 1.  Visualize Work 2.  Limit Work in Process 3.  Focus on Flow 4.  Continuous Improvement Source: wikipedia
  14. 14. Kanban 1.  Start the TM, add doomsday scenario’s, create context diagram, create basic DFD’s, add trust boundaries, write down assumptions 2.  For each story (epic) update DFD’s (if needed), check trust boundaries and assumptions, add security requirements 3.  During acceptance, make sure assumptions were correct and verify the security requirements 4.  Go for standard mitigations that can applied everywhere •  SSL/TLS •  RBAC •  Split application into different smaller ones per role (user vs. administrator) 5.  Do a retrospective to eliminate waste & improve the process
  15. 15. Summary •  Threat Modeling: the sooner the better, never too late •  Pick what works, discard everything else •  Answer the 4 questions
  16. 16. Join the conversation #DevSecCon Questions?

×