Post on 18-Dec-2014
description
Threat Modeling Best Prac3ces
Helping Making Threat Modeling Work
1
About Robert Zigweid
• Principal Compliance Consultant at IOAc3ve
• CISSP, PCI QSA, PCI PA-‐QSA
• Experienced in threat modeling and SDL
2
•What does Threat Modeling Mean to You?
3
Taxonomy
•Make sure everyone speaks the same language.
•Not just the same words, but the same meanings.
4
Taxonomy
STRIDEAll about the type
–S – Spoofing –T – Tampering–R – Repudia3on–I – Informa3on Disclosure–D – Denial of Service–E – Eleva3on of Privilege
5
DREADAll about IMPACT
• D – Damage Poten3al• R – Reproducibility• E – Exploitability• A – Affected Users• D – Discoverability
Taxonomy
The CIA
C – Confiden3ality
I – Integrity
A – Accessibility
6
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
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 push
8
Timing
•When do you stop
•When the project is end-‐of-‐life
•When you don’t care anymore
9
Contributors
•Who came up with that idea?• Project Owner• Architects•Developers• Testers• Everyone else!
10
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
Audience
•O_en overlooked• The Audience•Management•Architects•Developers•QA• Forensics/Tes3ng•Others?
12
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 Reviews
13
Templates
• Based on Func3on Type
•Grow the template library
14
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
Understand Your Target
• Project
• Project Delivery
16
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
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
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 library
19
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
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 diagrams
21
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 slow
22
Tools
•Others•Prac3cal Threat Analysis•What do I use?•Excel -‐-‐ some3mes•Word
23
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 assets
24
Common Pipalls
• Keep your threats reasonable•Avoid Doomsday
•Don’t dig too deep• You can always dive later
• Snapshot•Keep it versioned
25
Ques3ons!
26
Thank you
rzigweid@ioac3ve.com
27