Did you lock the door before leaving your house this morning? If you did, you threat modeled without even realizing it. Threat modeling is identifying potential threats (house robbery) and implementing measures to mitigate the risk (locking your door). Protecting valuable assets, no matter if personal assets or business-related assets such as the software you are developing, threat modeling should become an instinctual and necessary part of your process. Our talk highlights how nearly 50% of security flaws can be mitigated through threat modeling. We help you prevent and mitigate risks by utilizing a reliable and hard-hitting analysis technique that can be applied to individual applications or across an entire portfolio. We show you how to effectively apply these techniques at the start of the design phase and throughout every phase of the development lifecycle so you can maximize the ROI of your security efforts. Topics covered include: • Threat Modeling 101 • The propagating effect of poor design • Tabletop exercise – a world with and without threat modeling • Best practices and metrics for every stakeholder

1. Threat Modeling
Locking the Door to Vulnerabilities
#getsecure

2. Ed Adams
• CEO by day; engineer by trade (and heart)
• Mechanical Engineer, Software Engineer
• Ponemon Institute Fellow
• Privacy by Design Ambassador, Canada
• In younger days, built non-lethal weapons
systems for Federal Government

3. About Security Innovation
• Authority in Software Security
• 15+ years research on software vulnerabilities
• Platform Centers of Excellence for specialization
• Authors of 18 books, 11 with Microsoft
• Named to the Gartner Magic Quadrant 4 years in a row
• BIG Innovation and Cyber Security Excellence Award winner
• Helping organizations minimize risk, regardless of problem complexity

4. Agenda
Threat Modeling 101
• A World With and Without Threat Modeling
• How Threat Modeling helps EVERY Security Stakeholder
I’m not here to show you how to become a Threat Modeling guru –
but to demonstrate it’s universal power in mitigating software risk

5. Polling Questions
• Does your company conduct threat modeling?
• If so, in what areas?

6. Threat Modeling vs. Other Security Analysis
Techniques
Activity Impact Phase
Architecture &
Design review
Finds system level flaws Design
Code review Finds code-level weaknesses Implementation
Penetration
test
Finds dynamic vulnerabilities in the
application and demonstrate their
exploitability
Verification/Deployment
Attack surface
review
Finds/reduces number of avenues of attack Typically design
Threat Model Finds issues related to most critical threats Typically design, but
useful at every phase
Two powerful risk
management
techniques
“Experience shows that nearly 50% of security flaws will be discovered from Threat Modeling
because it finds different threats than those found through code review"
-Michael Howard, author of "Writing Secure Code" and Security Program Manager, Microsoft

7. Threat Modeling Simplified
Identify and quantify your weaknesses; devise appropriate
defenses
• Sound familiar?
• Most people threat model
every day but don’t realize it
• If I asked you to threat model
my house, you could; even if
you have never been
Courtesy: Sean Gallagher

8. Threat
Mitigation
Vulnerability
Attacker
ApplicationThreat Modeling
Vulnerabilities are
unmitigated threats
Here’s our
opportunity!
• Secure applications start with understanding the threats
• Threats are not vulnerabilities; they live forever and are attack vectors
• If done right, provides more leverage than any other security activity

9. Why Threat Model?
• Creates a shared understanding of problems that could happen
• Reduces knee jerk reactions to events, tests, compliance, etc
• Team effort to reduce threats
• Abuse case creation for product owners and architects
• Road map for developers to code defensively
• Starting point to create security-minded test plans
• Reliable way to:
• Weigh security designs against functionality
• Prioritize security efforts according to real risk
• Find business-process and system-level security issues
“To know your
enemy, you must
become your
Enemy.”
-Sun Tzu

10. What Threat Models Aren’t
• A representation of how an attacker approaches a system
• They represent total system security, not an attacker model
• A test plan
• A test plan is driven by a threat model, but threat models
offer a lot more than just test planning
• A formal proof of system security
• This would be dangerous
• A design review
• Threat models are the foundation of it, but a design review needs to
cover more implementation details and considerations beyond security

11. Why I Love Threat Modeling
Professionally: how else could I possibly manage corporate risk
effectively?
Psychologically: tried and true risk management technique since
the dawn of time provides confidence
Cognitively: the engineer in me prefers a disciplined approach to
problems versus “gut feel”
Personally: my marriage depends on reducing bad decisions; e.g.
spending hours fixing video doorbell when alarm system is broken

12. Agenda
• Threat Modeling 101
A World With and Without Threat Modeling
• How Threat Modeling helps EVERY Security Stakeholder

13. Threat Profiles are Never the Same
@thegrugq

14. What Could Possibly Go Wrong?
… and What do I do About It?
Analyze
Application
Determin
e Threats
Rank
Threat
s
• Identify possible threats based on motive, resources,
and capabilities
• Focus on most likely threats assets and not unicorns
• e.g. most of us are not enemies of the state
• What assets are you trying to protect?
• What threats are the assets under?
• What is the likelihood of that threat being realized?
• What measures can mitigate or decrease the impact?

15. Threat Modeling vs. Threat Intelligence
• Threat intelligence helps identify actions attackers are taking today
• Alert overload without learning and improvement
• Threat modeling helps reduce your attack surface and focus your
investments in a proactive way
• Unlikely to provide the quick hit that threat intelligence can, but
drives a more strategic program
Threat Modeling Threat Intelligence
Timeframe Proactive Reactive
Breadth Find issues Find attackers
Vendor Support Consulting & Training Feeds & Tools

16. If Done Correctly, You’ll Get to This
Client/UI Threat
#4:
Attacker
Impersonates user
Spoof
authentication
token/transaction
ID
Modify the audit trail so
that it appears that a
different user conducted
the transaction
Bypass the client
application/UI to
create transaction
Attacker discovers
another user’s
credentials
Attempt to intercept
credentials during
their transmission
Attempt to discover
credentials left in
memory
Threat
Action
Sub-Actions

17. Tabletop Exercise
Threat Modeling In a Relatable Way
• Setup:
• I own a house on the ocean with an attached
art and jewelry gallery
• Components:
• House, Ocean, Gallery
• Assets:
• Artwork, Jewels, Personal Property, Cat
• I need to threat model to mitigate risk of
theft, damage, disaster, etc.

18. OWASP Threat Physical World Software World
Sensitive Data Exposure Items can be stolen in route to the gallery because the selected
route is not secure
Credentials can sniffed/stolen because it
is passed in clear text on the network,
e.g., login page HTTP
Broken Authentication Items can be stolen from the gallery by an unauthorized
“employee” because of a flawed identification mechanism at the
gallery (counterfeit ID)
Replay attacks stream legitimate
messages from a valid user once stolen
Security
Misconfiguration
Items can be stolen from the house because they were not
stored in a safe
Password stored as clear text in the
database, e.g., not using password
hashing
Using Components with
Known Vulnerabilities
Items can be stolen from the house because the safe was using
metal that was known to melt with high temperatures
Has known hardware + software
vulnerabilities
Insufficient Logging and
Monitoring
Items can be stolen without possibility of tracing attacker, e.g.,
burglar can pick lock because video doorbell isn’t installed
Security related actions like delete
database, drop tables, etc. are not logged
Broken Access Control Items can be stolen by an insider because there is no proper
access management in the location where the artwork and
jewelries are stored
Direct object reference attacks attacker
calls resource directly, e.g., knows URL or
can brute force it
Tabletop Exercise
OWASP Overlay

19. Leverage to Code Defensively
• Drives threat analysis into secure code reviews
• Flaws in implementation methodologies and lack of development standards can be
identified by looking to specific threats
• Threats and misuse cases can drive unit test cases during implementation
• Developers implement specifications, referring back to the threat model to understand
operational context
• Build countermeasures based on threats: encrypt data and traffic where and when?
• Implement defensive coding measures to protect against attacks
• e.g. customer feedback feature of application  input sanitation
• Take advantage of framework features, e.g., AntiXSS library in .NET
19

20. A World Without Threat Modeling
• Inefficient use of resources
• Reactiveness and randomization of efforts
• Implementing counter-measures for low risk areas but
leaving critical threats wide open
• Looking for a dull needle in a haystack during testing

21. Vulnerable to
Heartbleed?
Threat #12
Compromise
App Password
1.1
Access “in-use”
password
1.2
Guess password
1.3
Access
Password in DB
1.1.1
Sniff network
1.1.2
Phishing attack
1.2.1
Password is
weak
1.2.2
Brute force
attack
1.3.1
Password is in
cleartext
1.3.2
Compromise
database
1.3.2.1
SQL injection
attack
1.3.2.2
Access database
directly
1.3.2.2.1
Port open
1.3.2.2.2
Weak db account
password(s)
Use TLS to encrypt
OpenSSL 1.0.1f
Require strong Password
8+ char, upper, lower,
number, special char
Use Prepared Statements
.NET parameterized queries
OleDbCommand() with
bind variables
Restrict Port Access
Firewall configuration

22. ThreatsVary and Evolve
• Web, cloud, mobile attacked in different ways
• Each technology has different security features and vulnerabilities
• Threats change over time
• Researchers will discover new ways to break into systems
• Proprietary code will reveal itself to contain vulnerabilities
• Deployed systems that have resisted attacks may eventually succumb
• Things you do today may not work tomorrow so update/improve iteratively
• When your security objectives and design changes
• During implementation, testing and deployment
• Threat models don't offer perfection, but help avoid a full-blown disaster

23. Example: Threat Modeling a Banking Application
• Common elements in attack surface
• Online banking uses TLS for all communications
• Authentication: usernames, passwords, security questions, Touch ID, pins, SMS verification codes
• Users select a security image that is displayed during authentication
• Cookie-based session tokens for both the web and mobile application
• No administrative roles or privileged users in the system
• TAPI server handles all requests for the web and mobile applications
• Top threats: an attacker can…
• Read credentials and/or the the session ID
• View or transfer account funds
• Read or update bank account info and/or PII
• Update account settings
• Read, update, or delete messages or logs
Many threats are likely
applicable to your
organization; however, it’s
important to uncover unique
threats and identify specific
countermeasures

24. Agenda
• Threat Modeling 101
• A World with and Without Threat Modeling
How Threat Modeling helps EVERY Security Stakeholder

25. Leverage Threat Model to Gather Security
Requirements
• Requirement level threat models are constructed during definition phase
• Business processes are security-checked and requirements documented
• Need single-sign-on? Why? What’s the security benefit/risk?
• Multi-factor authentication for the application?
• Identification of negative scenarios and a preliminary threat analysis during
requirement definition
• Data classification can drive the identification of potential
threats to the data assets
25
Leverage Threat Model to Gather Security
Requirements
• Requirement level threat models are constructed during definition phase
• Business processes are security-checked and requirements documented
• Need single-sign-on? Why? What’s the security benefit/risk?
• Multi-factor authentication for the application?
• Identification of negative scenarios and a preliminary threat analysis
during requirement definition
• Data classification can drive the identification of potential
threats to the data assets
4

26. Leverage Threat Model at Design
26
• >50% defects introduce during design, when they’re cheapest to fix
• Allows system architects to validate and explore whether the design meets the
level of acceptable risks
• Security requirements drive architecture choices
• What type of multi-factor authentication for the application?
• Which database will best meet functional and security requirements?
• Which development language/framework is most appropriate?
• Use of external components, libraries, and code
• Increase/decrease attack surface?
• Inherited vulnerabilities?
• Additional security needed for component XYZ?
• Etc.

27. Leverage for Precision Testing
• Testers confirm that the specifications are implemented correctly
• Each attack and sub-attack can become a test case in your test plan
• Security testing validates controls are in place and working appropriately
• Ascertain how the application holds up against the types of attacks envisioned
during the threat modeling exercise – try them!
• Drive test plans to ensure attacks focus on high threat areas
27
Threat model can be used by outside security teams to audit the code,
freeing them from performing up-front analysis work.

28. Leverage for Acceptance Testing
Plan Design Develop Test Deploy
• Typical Plan and Design phases  specifications, features, use cases
• Threat modeling
• Identify risks associated with outsourced development, e.g. backdoors
• Supercharge SLAs with acceptance criteria, e.g. pass OWASP Top 10 scan
• Develop robust test plans to look for specific threats defined pre-dev
• Even forces a risk-based approach in planning and design

29. Leverage for Better Risk Management
• Conduct a deployment review against threat model to ensure server
configurations are appropriate
• Threat model a portfolio of applicaitons for relative risk rating
• Threat model during system operations to assess potential security risks
and make informed decisions before change management events
• Metrics and measurements can be gathered to plan the next releases
• Lessons learned can be used to develop best practices and standards
• Informed decision making around resource allocation and procurement

30. An Effective Threat Modeling Program…
 Agile, actionable, collaborative and focuses on business impact
 Has tangible outputs
• Rolling list of top 10 threats replete with mitigating controls
• Abuse cases
• Security requirements
 Routine identification of new threats and mitigation validation
 Integrates with real-time intelligence around industry specific threats and
statistical analysis of real-world attacks
 Track threats across organization
Enforce consistency with re-usable components, e.g., authentication library

31. Summary
• Threat models are an underutilized but powerful risk management
technique
• Threat Models are most effective when leveraged throughout
development, deployment and operation
• Bottom line: gets stakeholders speaking the same language and on the
same page in terms of priorities and risk areas

32. Questions?

33. Thank You!
eadams@securityinnovation.com
@AppSec