How to perform threat modeling of software to protect your business, critical assets and communicate your message to your boss and the Board of Directors

1. Making it real for management
Mel Drews
mailto:mel@redcedarnet.com

2. Mel Drews
CISSP, CISA, GWEB, GCFE, ABCDE
Background
 Configuring, managing technical security
 Penetration testing
 Designing governance & controls
 Consulting on compliance issues
 Operational risk assessments
 IT security audit

3. Focusing on software because...
 We deploy infrastructure controls (firewalls, anti-malware,
IDS/IPS, etc.), but what are we trying to protect? What is
vulnerable? – data and applications.
 According to Gartner*, in 2014 enterprises spent $12B
securing their network perimeters, but only $600M
security applications.
 Depending on industry, web applications account for up to
35% of data breaches.*
 Lessons are applicable to other attack surfaces
 Usefulness of approaching a complex problem from
multiple angles

4. If it’s about people, processes and
technology...
What do we want these people to get out of the exercise?

5. We can...
 Quantify risks in a realistic manner (disclaimer,
disclaimer).
 Identify previously unexamined control gaps exposing
high-impact systems or processes.
 Identify the mitigations that will give the best bang for
the buck – not a ROI number, but relative ranking.
 Give a realistic picture of how (in)secure we really are

6. Operationalizing risk assessment

7. What’s your attack surface?

8. What is a “threat”?
Open Group – “Anything that is capable of acting in a
manner resulting in harm to an asset and/or
organization; for example, acts of God (weather,
geological events, etc.); malicious actors; errors; failures.”
(The Open Group, 2009)
DHS – “Natural or man-made occurrence, individual, entity,
or action that has or indicates the potential to harm life,
information, operations, the environment, and/or
property.” (Department of Homeland Security [DHS],
2010)
BITS – “Threat is anything that can act against an asset
resulting in a potential loss.” (BITS, 2012)

9. Ways to model threats in software
 Find all possible / likely bad actions
 Attack trees
 Misuse / Abuse cases
 CAPEC
 Analyze the code / application
 Architectural Risk Analysis
 Attack surface analysis
 Attack paths
 SDL
 Code review
 Static analysis
 Blackbox methods
 Fuzzing
 Vulnerability scanning

10. Challenges to doing threat modeling
 Confusion on what constitutes a threat vs. a vulnerability vs. a risk
 Lack of guidance on methods to identify assets
 Requiring participants with requisite expertise and training in
threat analysis, a strong understanding of application design and
a well-structured process
 Security experts often learn from different risk profiles and use
different techniques for modeling
 Teaching threat modeling requires an apprentice-based approach
that involves an appropriate curricula, adequate investment in
effective education tools and a process for educating appropriate
constituencies
 Different types of applications have very different risk profiles
meaning the threats will vary depending factors such as the
application architecture
(BITS, 2012)

11. Attack Trees
 Identify possible attack goals
 Think of all attacks against each goal

12. Attack Paths
 “The attack targets are analyzed based on their connections to attack
surfaces through call relationships.” (Brenneman, 2014)

13. Cyber Kill Chains®
 Reconnaissance
 Weaponization
 Delivery
 Exploit
 Installation
 Command & Control
 Actions

14. Misuse / Abuse Case

15. Common Attack Pattern Enumeration
and Classification (CAPEC)
(MITRE Corp, 2014)

16. “Design flaws account for 50
percent of security problems, and
architectural risk analysis plays an
essential role in any solid security
program.” (McGraw, 2006)
Architectural Risk Review

17. Architectural flaw examples:
 Forgot to authenticate the user
 Broken authentication mechanism
 No mapping of access control to job requirements
 Insecure (or no) implementation of auditing functions
 Failure to understand trust relationships – too much
trust
 Failure to employ encryption
 Dependence on components with known
vulnerabilities (libraries, frameworks, other modules)

18. Attack Surface Analysis
 Targets and enablers
Resources (processes and data) that an attacker can use or
co-opt.
 Channels and protocols
Message passing and shared memory between endpoint
processes and the rules for exchanging information.
 Access rights
Associated not only with files and directories, but also
channels and endpoint processes.
(Howard, Pincus & Wing, 2003)

19. Microsoft SDL Overview
 Education
 Continuous process improvement
 Accountability
(Microsoft. SDL Process: Design, 2014)
(Microsoft, 2010)

20. (Microsoft, 2014)

21. Threat Modeling in the Microsoft SDL
 SDL Phase II – Design:
 “Threat modeling is used in environments where there
is meaningful security risk. It is a practice that allows
development teams to consider, document, and discuss
the security implications of designs in the context of
their planned operational environment and in a
structured fashion. Threat modeling also allows
consideration of security issues at the component or
application level. Threat modeling is a team exercise,
encompassing program/project managers, developers,
and testers.”
(Microsoft, 2010)

22. MS Threat Modeling steps
 Diagramming
 Data flow
 Threat Enumeration
 Focus on trust boundaries
 S•T•R•I•D•E
 List of threats
 Team exercise engaging program/project managers,
developers and testers
 Mitigation
 Validation
 Completeness & accuracy of threats and the model
(Shostack, 2008)

23. STRIDE
 Spoofing
 Tampering
 Repudiation
 Information Disclosure
 Denial of Service
 Escalation of Privilege
(Shostack, 2008)

24. Demo time

25. (Microsoft, Introducing Microsoft Threat Modeling Tool,2016)
Customizing the threat table

26. Critical Security Controls
 CSC 2: Inventory of Authorized and Unauthorized
Software.
 CSC 4: Continuous Vulnerability Assessment and
Remediation.
 CSC 18: Application Software Security.
 CSC 20: Penetration Tests and Red Team Exercises (in
a mature control environment)

27. Asset Characterization
Excerpt from System Characterization Worksheet, available under Creative Commons license at
http://www.redcedarnet.com/p/blog-page.html

28. Asset list or database
Impacts
Asset Confidentiality
Impact
Integrity
Impact
Availability
Impact
Has
Exposure
X
Has
Exposure
Y
Inherent
Risk
Control
Strength
Overall Score
Residual Risk
LOB App1 $1M $200K $500K Y Y 100 4 25
Customer
Svc App
$800K $100K $80K N Y 45 3 15

29. Threat matrix

30. Risk, impact, likelihood, recommendation
Risk Impact Likelihood Recommendation
History of poor
coding practices:
While patches are
available to address
known vulnerabilities in
the currently installed
application version,
application vendor,
SoftCorp, has had a
history of severe
vulnerabilities recurring
in multiple products.
Their response to
reported vulnerabilities
has sometimes taken up
to a year to address such
issues.
Application processes
thousands of records
daily and stores
approximately 1.2
million unique data
records. Unauthorized
disclosure of this data
could lead to costs in
excess of risk appetite
related to:
Communication to
regulators and
customers,
investigations,
emergency remediation
activities, enhanced
regulatory scrutiny
Currently known and
previously patched
vulnerabilities have
been susceptible to
exploitation by
attackers possessing
minimal skill or
resources and only
external connectivity.
1. Apply available
patches
2. Deploy a Web
Application
Firewall between
users and the
application server.
3. Evaluate the
feasibility of
migrating to other
available products.
Management
Response:

31. Quantifying Risk
 Granularity?
 Percentage of similar organizations experiencing a
breach
 Detailed analysis of likelihood impacting a given
exposure
 Control Strength
 Threat Capability
 Loss Event Frequency
 What is the event / scenario?

32. Loss Magnitude
 Direct costs due to loss of integrity
 Direct costs due to unavailability
 Don’t ask about confidentiality, ask about factors that
allow you to calculate it as the expert:
 Number of unique data records holding PII/NPII/PHI
 Number of financial transactions processed by the
application daily / monthly
 Dollar value of financial transactions processed by the
application if any, daily / monthly

33. Factor in additional costs
 Direct:
 Investigating
 remediating
 communicating
 credit monitoring
 Indirect:
 Regulatory
 Legal
 Opportunity

34. Insider Threat
 SEI CERT has a database cataloging more than 700
cases of malicious insider activity.*
 Methods vary between cases involving technical staff
and those that don’t.
 Our threat models and controls need to address both

35. Who uses or recommends threat
modeling?
 Microsoft
 Apple (Apple, 2014)
 EMC (Dhillon, 2011)
 VMware
 Oracle (Oracle, 2014)
 Mitre Corporation (MITRE, 2011)
 India (Microsoft 2012)
 Are you studying for the CSSLP? (ISC2, 2013)

36. Is it secure enough?

37. Apple. Risk Assessment and Threat Modeling. Retrieved 23 June 2014, from
https://developer.apple.com/library/mac/documentation/security/concept
ual/security_overview/ThreatModeling/ThreatModeling.html#//apple_ref/
doc/uid/TP40002495-SW5
BITS / The Financial Services Roundtable. (2011). Software Assurance Framework.
http://www.bits.org/publications/security/BITSSoftwareAssurance0112.pdf
Brenneman, D. Improving Software Security by Identifying and Securing Paths
Linking Attack Surfaces to Attack Targets. McCabe Software. Retrieved 9
June 2014, from
http://www.mccabe.com/pdf/Identifying%20and%20Securing%20Paths%2
0Linking%20Attack%20Surfaces%20to%20Attack%20Targets.pdf
BSIMM. Building Security In Maturity Model. Retrieved 24 June 2014, from
http://www.bsimm.com/online/ssdl/aa/
Department of Homeland Security. (2010). DHS Risk Lexicon.
http://www.dhs.gov/xlibrary/assets/dhs-risk-lexicon-2010.pdf

38. Dhillon, D. (2011). Developer-Driven Threat Modeling. IEEE Security &
Privacy. http://www.infoq.com/articles/developer-driven-threat-
modeling
Dougherty, C., Sayre, K., Seacord, R., Svoboda, D., Togashi, K. (October
2009). Secure Design Patterns. Technical Report CMU/SEI-2009-
TR-010 . Carnegie Mellon University Software Engineering
Institute. http://resources.sei.cmu.edu/library/asset-
view.cfm?assetid=9115
Hafiz, M., Security Pattern Catalog. Retrieved 13 June 2014 from
http://www.munawarhafiz.com/securitypatterncatalog/index.php
Howard, M., Pincus, J., & Wing, J. (2003). Measuring Relative Attack
Surfaces. http://www.cs.cmu.edu/~wing/publications/Howard-
Wing03.pdf
ISC2. (2013). Certified Secure Software Lifecycle Professional. April 2013.
https://www.isc2.org/csslp/default.aspx
McGraw, G. (2006). Software Security: Building Security In. Addison-
Wesley. ISBN-10: 0321356705

39. Microsoft Corporation. Benefits of the SDL. Retrieved 20 June 2014, from
http://www.microsoft.com/security/sdl/about/benefits.aspx
Microsoft Corporation (2012). Government of India Embraces Secure
Application Development. http://www.microsoft.com/en-
us/download/confirmation.aspx?id=29857
Microsoft Corporation. (2014). Introducing Microsoft Threat Modeling
Tool 2014. Retrieved 23 June 2014, from
http://blogs.msdn.com/b/sdl/archive/2014/04/15/introducing-
microsoft-threat-modeling-tool-2014.aspx
Microsoft Corporation. SDL Process: Design. Retrieved 24 June 2014, from
http://www.microsoft.com/security/sdl/process/design.aspx
Microsoft Corporation. (2010). Simplified Implementation of the Microsoft
SDL. http://www.microsoft.com/en-
us/download/details.aspx?id=12379&751be11f-ede8-5a0c-058c-
2ee190a24fa6=True
MITRE Corporation. (2014). Common Attack Pattern Enumeration and
Classification. Retrieved 6 June 2014, from http://capec.mitre.org/

40. MITRE Corporation. (2011). Threat Assessment and
Remediation Analysis (TARA).
http://www.mitre.org/publications/technical-
papers/threat-assessment--remediation-analysis-
tara
The Open Group. (2009). Risk Taxonomy.
https://www2.opengroup.org/ogsys/catalog/C13K
Schneier, B. (1999). Attack Trees. Schneier on Security.
Retrieved 13 June 2014, from
https://www.schneier.com/paper-attacktrees-ddj-
ft.html

41. Scott, J. & Kazman, R. (2009). Realizing and Refining Architectural
Tactics: Availability.
http://www.sei.cmu.edu/reports/09tr006.pdf
Security Architecture Patterns. In Open Security Architecture.
Retrieved 13 June 2014 from
http://www.opensecurityarchitecture.org/cms/library/patter
nlandscape
Shostack, A. (2008). Experiences Threat Modeling at Microsoft.
http://blogs.msdn.com/b/sdl/archive/2008/10/08/experience
s-threat-modeling-at-microsoft.aspx
Singhal, A. & Ou, X. (2011). Security Risk Analysis of Enterprise
Networks Using Probabilistic Attack Graphs. National
Institute of Standards and Technology Interagency Report
7788. http://csrc.nist.gov/publications/nistir/ir7788/NISTIR-
7788.pdf