Your SlideShare is downloading. ×
Threat Modeling: Best Practices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Threat Modeling: Best Practices

3,339
views

Published on

SOURCE Seattle 2011 - Robert Zigweid

SOURCE Seattle 2011 - Robert Zigweid

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,339
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
89
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Threat  Modeling  Best  Prac3ces Helping  Making  Threat  Modeling  Work1
  • 2. About  Robert  Zigweid• Principal  Compliance  Consultant  at  IOAc3ve• CISSP,  PCI  QSA,  PCI  PA-­‐QSA• Experienced  in  threat  modeling  and  SDL 2
  • 3. • What  does  Threat  Modeling  Mean  to  You?3
  • 4. Taxonomy• Make  sure  everyone  speaks  the  same  language.• Not  just  the  same  words,  but  the  same  meanings. 4
  • 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. Taxonomy The  CIA C  –  Confiden3ality I  –  Integrity A  –  Accessibility6
  • 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. 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. Timing• When  do  you  stop • When  the  project  is  end-­‐of-­‐life • When  you  don’t  care  anymore9
  • 10. Contributors• Who  came  up  with  that  idea?• Project  Owner• Architects• Developers• Testers• Everyone  else!10
  • 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. Audience• O_en  overlooked• The  Audience • Management • Architects • Developers • QA • Forensics/Tes3ng • Others?12
  • 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. Templates• Based  on  Func3on  Type• Grow  the  template  library14
  • 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. Understand  Your  Target• Project  • Project  Delivery16
  • 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. 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. 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. 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. 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. 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. Tools• Others • Prac3cal  Threat  Analysis • What  do  I  use? • Excel  -­‐-­‐  some3mes • Word23
  • 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. Common  Pipalls• Keep  your  threats  reasonable • Avoid  Doomsday• Don’t  dig  too  deep • You  can  always  dive  later• Snapshot • Keep  it  versioned25
  • 26. Ques3ons!26
  • 27. Thank  you rzigweid@ioac3ve.com27