Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Threat Modeling: Best Practices

6,040 views

Published on

SOURCE Seattle 2011 - Robert Zigweid

Published in: Technology
  • Be the first to comment

Threat Modeling: Best Practices

  1. 1. Threat  Modeling  Best  Prac3ces Helping  Making  Threat  Modeling  Work1
  2. 2. About  Robert  Zigweid• Principal  Compliance  Consultant  at  IOAc3ve• CISSP,  PCI  QSA,  PCI  PA-­‐QSA• Experienced  in  threat  modeling  and  SDL 2
  3. 3. • What  does  Threat  Modeling  Mean  to  You?3
  4. 4. Taxonomy• Make  sure  everyone  speaks  the  same  language.• Not  just  the  same  words,  but  the  same  meanings. 4
  5. 5. Taxonomy STRIDE DREAD All  about  the  type All  about  IMPACT –S  –  Spoofing   • D  –  Damage  Poten3al –T  –  Tampering • R  –  Reproducibility –R  –  Repudia3on • E  –  Exploitability –I  –  Informa3on  Disclosure • A  –  Affected  Users –D  –  Denial  of  Service • D  –  Discoverability –E  –  Eleva3on  of  Privilege5
  6. 6. Taxonomy The  CIA C  –  Confiden3ality I  –  Integrity A  –  Accessibility6
  7. 7. Timing• When  do  you  start  threat  modeling  a  project? • What  you  need  to  know  before  you  start • What  are  you  building? • What  needs  to  be  protected?   • It’s  never  too  late! 7
  8. 8. Timing• How  o_en? • At  the  beginning  of  a  new  release  cycle  is  a  great  3me • It’s  not  the  only  3me   • Try  QA • Throw  it  in  as  part  of  a  security  push8
  9. 9. Timing• When  do  you  stop • When  the  project  is  end-­‐of-­‐life • When  you  don’t  care  anymore9
  10. 10. Contributors• Who  came  up  with  that  idea?• Project  Owner• Architects• Developers• Testers• Everyone  else!10
  11. 11. Contributors• How  to  Contribute • Ini3al  brainstorming • But  you  said  that’s  too  early! • So,  record  the  sessions • Before  QA  tes3ng • Emails • Issue  tracker • Who  cares?11
  12. 12. Audience• O_en  overlooked• The  Audience • Management • Architects • Developers • QA • Forensics/Tes3ng • Others?12
  13. 13. Threat  Modeling  and  your  SDL• Threat  Modeling  can  be  the  vehicle  for  your  SDL • Keeps  it  updated • Security  Ques3onnaires  when  considering  features • Deliver  development  requirements  to  developers • Test  Plans • Test  against  iden3fied  threats • Security  Reviews13
  14. 14. Templates• Based  on  Func3on  Type• Grow  the  template  library14
  15. 15. Perspec3ves!• Ahacker! • How  are  they  going  to  get  me? • How  do  I  stop  it?• Assets • What  do  I  care  about  most? • How  do  I  protect  it?15
  16. 16. Understand  Your  Target• Project  • Project  Delivery16
  17. 17. What  about  Agile?• The  good! • Business  people  and  developers  must  work  together   daily  throughout  the  project. • At  regular  intervals,  the  team  reflects  on  how  to   become  more  effec3ve,  then  tunes  and  adjusts  its   behavior  accordingly. • Working  so_ware  is  the  primary  measure  of  progress. • Security  in  so_ware  is  an  essen3al  part  of  “working”17
  18. 18. What  about  Agile?• The  ....bad • Welcome  changing  requirements,  even  late  in   development.   • Deliver  working  so_ware  frequently,  from  a  couple  of   weeks  to  a  couple  of  months,  with  a  preference  to  the   shorter  3mescale. • The  most  efficient  and  effec3ve  method  of  conveying   informa3on  to  and  within  a  development  team  is  face-­‐ to-­‐face  conversa3on.18
  19. 19. Tools• Microso_’s  Threat  Analysis  and  Modeling  (2.1.2) • Pros • Flexibility   • Doesn’t  require  data  flow  diagrams • Has  a  built  in  threat  library  to  reference • Tracks  threat  modeling  data  well • Comes  with  an  ahack  library19
  20. 20. Tools• Microso_’s  Threat  Analysis  and  Modeling  (2.1.2)   (con3nued) • Cons • No  longer  supported • Does  not  use  STRIDE/DREAD,  but  CIA • Data  flow  diagrams  require  Visio • Can  be  difficult  to  begin  working  with • Supplied  ahack  library  doesn’t  necessarily  fit,  and  can  slow   you  down.20
  21. 21. Tools• Microso_  SDL  Threat  Modeling  Tool  (3.1) • Pros • Currently  supported  and  developed  by  Microso_  along  with  their  SDL • Extensible • Can  write  plug-­‐ins  into  your  issue  tracking  system • Cons • It’s  free! • Well  sorta • Flexibility   • Requires  data  flow  diagrams21
  22. 22. Tools• Trike • Pros • Methodology  is  driven  by  the  tool • Methodology  is  very  flexible • Automated  threat  genera3on • Cross-­‐plaporm • Cons • Does  not  scale • Development  of  tool  and  methodology  are  somewhat  slow22
  23. 23. Tools• Others • Prac3cal  Threat  Analysis • What  do  I  use? • Excel  -­‐-­‐  some3mes • Word23
  24. 24. Common  Pipalls• It’s  not  a  one  person  job• Poor  presenta3on• Never,  ever  delete • Once  a  threat,  always  a  threat • It’s  history• Properly  iden3fy  assets24
  25. 25. Common  Pipalls• Keep  your  threats  reasonable • Avoid  Doomsday• Don’t  dig  too  deep • You  can  always  dive  later• Snapshot • Keep  it  versioned25
  26. 26. Ques3ons!26
  27. 27. Thank  you rzigweid@ioac3ve.com27

×