Secure Coding and Threat Modeling

Secure Coding &
Threat Modeling
Miriam Celi, CISSP
SFISSA Security Conference
March 10, 2017

Tenure: 20+ years in IT, various roles, 7 years in security
Currently role: ITQA Software Security Technology Leader, Humana Inc.
Why I like to
work in security:
1. Challenge 2. Unknown 3. Passion 4. Helping
Social Media: @mcelicissp
Blog: https://mceliblog.wordpress.com/
About me
Miriam Celi, CISSP ~ 2017 SFISSA Security Conference

Agenda
• Statistics
• Secure Coding
• Resources
• Threat Modeling
• Approaches
• Process
• MS Tool Demo

• Average global cost per breach reached $4 million in 2016 increasing from $3.5
million in 2014.
➢ In the US it rose from $5.85 million in 2014 to $7 million in 2016.
• Average global cost per record stolen in 2016 was $158 increasing from $145 in
2014.
➢ In the US it rose from $201 in 2014 to $221 in 2016.
• The global cost of cybercrime is expected to reach $2 trillion by 2019, a threefold
increase from the 2015 estimate of $500 billion.
• The average cost of a data breach will exceed $150 million by 2020
http://www-03.ibm.com/security/data-breach/
https://www.juniperresearch.com/press/press-releases/cybercrime-cost-businesses-over-2trillion
Cybercrime Statistics

IBM 2011 Sampling of Security Incidents
64 security incidents from Jan 8, 2011 to Dec 27, 2011.
http://www-03.ibm.com/security/xforce/xfisi/

http://www-03.ibm.com/security/xforce/xfisi/
IBM 2016 Sampling of Security Incidents
322 incidents from Jan 4, 2016 to Dec 31, 2016.

Security Incidents and Vulnerabilities Trend
65
292
256
280
284
322
4155
5297
5191
7946
6452
6435
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
0
50
100
150
200
250
300
350
2011 2012 2013 2014 2015 2016
Number of Security Incidents Number of Vulnerabilities
http://www-03.ibm.com/security/xforce/xfisi/ https://www.cvedetails.com/browse-by-date.php

Secure Coding
• Developing software that is resistant to attacks and preventing
vulnerabilities from being introduced into the software
• A significant number of software vulnerabilities can be traced to coding
errors which have been shown to be the main cause for exploited
vulnerabilities.
• It’s important to be aware of secure coding guidelines and resources that
can help us to develop more secure software:

Secure Coding Principles
1. Defense in Depth Security mechanisms are applied in multiple layers throughout
the system
2. Secure Default/Default Deny Access is denied by default and requires to be configured or be
turned on as needed
3. Positive Security Model
(Whitelist)
Only what is defined is allowed and what is not defined is
denied
4. Least Privilege Application runs with the least set of privileges necessary to
complete the job
5. Fail Securely If application fails, the same execution path as disallowing the
operation is followed
6. Don’t Trust Not relying on or trusting the security mechanisms of other
components
7. Keep it simple The higher the complexity in an application, the greater the
attack surface
8. Logging Operations that were performed, the time they were
performed, and who performed them.
9. Threat Modeling A way to analyze the security of a system, identifying its
weaknesses, threats and exposures

Common Weakness Enumeration (CWE)
• Software weaknesses are flaws, faults, bugs, vulnerabilities, and other errors in
software implementation, code, design, or architecture that if left unaddressed could
result in systems and networks being vulnerable to attack. Software weaknesses lead
to software vulnerabilities.
• CWE is:
• A community-developed dictionary of software weakness types.
• A common language for describing software security weaknesses in architecture,
design, or code.
• Targeted to developers and security practitioners.
• A measuring stick for software security tools targeting these weaknesses.
• A common baseline definition for weakness identification, mitigation, and
prevention efforts.
• Maintained by MITRE Corporation.
https://cwe.mitre.org/

Rank ID Name Rank ID Name
[1] CWE-89
Improper Neutralization of Special Elements used
in an SQL Command ('SQL Injection')
[14] CWE-494 Download of Code Without Integrity Check
[2] CWE-78
Improper Neutralization of Special Elements used
in an OS Command ('OS Command Injection')
[15] CWE-863 Incorrect Authorization
[3] CWE-120
Buffer Copy without Checking Size of Input
('Classic Buffer Overflow')
[16] CWE-829
Inclusion of Functionality from Untrusted Control
Sphere
[4] CWE-79
Improper Neutralization of Input During Web
Page Generation ('Cross-site Scripting')
[17] CWE-732
Incorrect Permission Assignment for Critical
Resource
[5] CWE-306 Missing Authentication for Critical Function [18] CWE-676 Use of Potentially Dangerous Function
[6] CWE-862 Missing Authorization [19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm
[7] CWE-798 Use of Hard-coded Credentials [20] CWE-131 Incorrect Calculation of Buffer Size
[8] CWE-311 Missing Encryption of Sensitive Data [21] CWE-307
Improper Restriction of Excessive Authentication
Attempts
[9] CWE-434 Unrestricted Upload of File with Dangerous Type [22] CWE-601
URL Redirection to Untrusted Site ('Open
Redirect')
[10] CWE-807
Reliance on Untrusted Inputs in a Security
Decision
[23] CWE-134 Uncontrolled Format String
[11] CWE-250 Execution with Unnecessary Privileges [24] CWE-190 Integer Overflow or Wraparound
[12] CWE-352 Cross-Site Request Forgery (CSRF) [25] CWE-759 Use of a One-Way Hash without a Salt
[13] CWE-22
Improper Limitation of a Pathname to a Restricted
Directory ('Path Traversal')
CWE/SANS Top 25 Most Dangerous Software Errors
http://cwe.mitre.org/top25/#Listing

• What is a vulnerability and what is an exposure?
• A vulnerability is a mistake in software that can be directly used by a hacker to
gain access to a system or network.
• An exposure is a system configuration issue or a mistake in software that does
not directly allow compromise but could be an important component of a successful
attack.
• CVE is:
• A dictionary of common names for publicly known cybersecurity vulnerabilities.
• Each common name includes a unique CVE identifier number, a
brief description of the security vulnerability or exposure, and references (i.e.,
vulnerability reports and advisories).
• Cross referenced with CWEs.
• A basis for evaluation among tools and databases.
• Free for public download and use.
• Maintained by MITRE Corporation.
Common Vulnerabilities and Exposures (CVE)
http://cve.mitre.org

Examples of Vulnerabilities
• OpenSSL security vulnerabilities
https://www.openssl.org/news/vulnerabilities.html
• Java security vulnerabilities
https://www.oracle.com/technetwork/topics/security/alerts-
086861.html
• Top 2016 Open Source Vulnerabilities
https://www.whitesourcesoftware.com/whitesource-blog/open-
source-security-vulnerability/
• Qualys Top 10 Vulnerabilities
https://www.qualys.com/research/top10/
• Top 50 Products By Total Number Of "Distinct" Vulnerabilities
https://www.cvedetails.com/top-50-products.php

National Vulnerability Database (NVD)
• U.S. government repository of standards based vulnerability management data.
• Provides information that enables automation of vulnerability management, security
measurement, and compliance.
• Includes databases of security checklists, security related software flaws,
misconfigurations, product names, and impact metrics.
• CVE list feeds NVD, which then builds upon the information included in CVE entries
and enhances it with fix information, severity scores, and impact ratings.
• NVD CVE scores quantify the risk of vulnerabilities, calculated from a set of
equations based on metrics such as access complexity and availability of a remedy.
• Provides advanced searching features such as by individual CVE ID; by OS; by
vendor name, product name, and/or version number; and by vulnerability type,
severity, related exploit range, and impact.
https://nvd.nist.gov

Common Attack Pattern Enumeration
and Classification (CAPEC)
• Community resource for identifying and understanding attacks
• Comprehensive dictionary of common attack patterns
• Each attack pattern:
 defines a challenge that an attacker may face
 provides a description of the common technique(s) used to meet the
challenge
 presents recommended methods for mitigating an actual attack
• Targeted to developers, analysts, testers, and educators to advance
understanding of attacks and enhance defenses.
• Publicly available
https://capec.mitre.org

Some Well-Known Attack Patterns
• HTTP Response Splitting (CAPEC-34)
• Session Fixation (CAPEC-61)
• Cross Site Request Forgery (CAPEC-62)
• SQL Injection (CAPEC-66)
• Simple Script Injection (CAPEC-63)
• Buffer Overflow (CAPEC-100)
• Clickjacking (CAPEC-103)
• Relative Path Traversal (CAPEC-139)
• XML Attribute Blowup (CAPEC-229)

OWASP Top 10
https://www.owasp.org/index.php/Top_10_2013-Top_10
• OWASP is an
organization focused on
improving the security
of software.
• The Top 10 list
represents the 10 most
critical web application
security risks
• Provides guidance and
techniques for
protection.
• A1-Injection
• A2-Broken Authentication and Session Management
• A3-Cross-Site Scripting (XSS)
• A4-Insecure Direct Object References
• A5-Security Misconfiguration
• A6-Sensitive Data Exposure
• A7-Missing Function Level Access Control
• A8-Cross-Site Request Forgery (CSRF)
• A9-Using Components with Known Vulnerabilities
• A10-Unvalidated Redirects and Forwards

OWASP Mobile Top 10
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
• Represents the 10 most critical
mobile application security risks
and provides guidance and
techniques for protection.
• M1: Improper Platform Usage
• M2: Insecure Data Storage
• M3: Insecure Communication
• M4: Insecure Authentication
• M5: Insufficient Cryptography
• M6: Insecure Authorization
• M7: Client Code Quality
• M8: Code Tampering
• M9: Reverse Engineering
• M10: Extraneous Functionality

OWASP Tools
• Dependency check tool - identifies project dependencies and checks if
there are any known, publicly disclosed, vulnerabilities.
• ZAP proxy tool - used for testing and finding security vulnerabilities
in web applications.
• Web Goat and Mutillidae - deliberately insecure web applications
designed to teach web application security lessons from the OWASP
Top 10 list.
• OWASP Vulnerable Web Applications Directory Project - registry of
all known vulnerable web applications currently available for legal
security and vulnerability testing of various kinds.

OWASP Secure Coding Libraries
• OWASP AppSensor - A conceptual framework and methodology that offers prescriptive
guidance to implement intrusion detection and automated response into applications.
• OWASP CSRFGuard - A Java library that implements a variant of the synchronizer
token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.
• OWASP Java Encoder Project – A Java 1.5+ simple-to-use, high-performance encoder
class that helps Java web developers defend against Cross-Site Scripting (XSS).
• OWASP Java HTML Sanitizer – A fast and easy to configure HTML Sanitizer written in
Java which lets you include HTML authored by third-parties in your web application
while protecting against XSS.
• OWASP Security Logging Project - Provides developers and ops personnel with APIs for
logging security-related events. The aim is to let developers use the same set of logging
APIs with Log4J and its successors, while also adding powerful security features.
• OWASP Enterprise Security API (ESAPI) - A free, open source, web application security
control library that makes it easier for programmers to write lower-risk applications.

Other Resources and Tools
• SEI CERT Coding Standards – for C, C++, Java, and Perl, and the
Android™ platform.
• Cybrary Secure Coding Course – free online course
• SCFM Secure Coding Field Manual - reference book for Cybrary’s Secure
Coding course
• Burp Suite Free and Professional Editions – scan for vulnerabilities, intercept
browser traffic, test security of web applications.
• Burp Scanner Issues – Issue definitions, remediations and references
• Fiddler – free web debugging proxy for any browser, system or platform for
security testing your web applications

Threat Modeling
To build secure software, we need to understand the risks
related to:
 weaknesses in design, coding and integration
 use cases and abuse cases
The goal of threat modeling is to identify potential risks or
attacks that can occur to the system as it will be deployed,
and to make decisions to address these risks in the design
and development of the application.

Threat Modeling
• A threat is an undesired event that may damage or
compromise an asset or objective. It may or may not be
malicious in nature.
• An asset is a resource of value and can vary by perspective:
 To the business, an asset might be the availability of information,
or the information itself, such as customer data.
 It might be intangible, such as a company's reputation.
 To an attacker, an asset could be the ability to misuse your
application for unauthorized access to data or privileged
operations.

Threat Modeling
What it is What it’s not
A team activity An activity performed by a single
person.
A crucial activity in developing
secure applications
An optional activity for developing
secure application
An activity that helps identify
vulnerabilities in software
A security audit
An activity started early in the
design phase
An activity started late in the
application life cycle
An iterative process that should
be performed for every release,
sprint, or iteration
An activity that is only performed
once or once in a while

Benefits of Threat Modeling
• Finding security bugs early
• Improved understanding of security requirements
• Engineer better products and services
• Addresses security issues hidden in design
• Develop secure by design solutions

Threat Modeling Participants
• Threat modeling is a team activity
• Members of development and test teams, such as:
 Application architects
 Security professionals
 Developers
 Testers
 System Administrators
• Work together to identify exposures in the application design of a
system.

Threat Modeling Questions
• It is important to identify:
 what is being built? (the scope of the threat model)
 what are the requirements?
 what could go wrong? (abuse and exception cases)
 possible bugs
 what can be done to address the issues? (mitigation
techniques).

Threat Modeling Approaches
1. Software-centric
Focus is on software being built and what weaknesses and
vulnerabilities are likely to be introduced in Design, Coding or Build
Integration.
2. Asset-centric
Focus is on assets needing protection and entrusted to a system or
software (data processed by the software) and what scenarios might
compromise them or lead to non-compliance.
3. Attacker-centric
Focus is on profiling an attacker’s characteristics, skill-set, and
motivation to exploit vulnerabilities and what scenarios might
attackers use to compromise the application, system or service

Software-centric Approach
• Questions to consider:
 How is software designed and constructed?
 What are the languages, components and runtimes used?
 What are the relevant coding practices followed?
 How is software built and integrated?
• Involves the use of software architecture diagrams such as data-flow
diagrams (DFD), use case diagrams, or component diagrams to identify
threats to the design of the system.

Data-Flow Diagram Example

Asset-centric Approach
 What are the assets entrusted to the system or software?
 What is the estimated value of those assets?
 What are the consequences to compromise or loss of the assets?
 How are those information assets protected?
Involves the use of attack trees or attack patterns by which an asset can
be attacked.

Attacker-centric Approach
 Who is authorized and who is not?
 What privileges do users have?
 How is the software intended to be used?
 How can the software be abused?
This approach also uses attack trees or attack patterns with focus on the
specific goals of an attacker, how attacks could be carried out, and how to
mitigate such attacks.

Attack Tree Example
• Root node represents the
goals of the attacker.
• Leaf nodes represent the
unique attack methods.

Which Approach to Use?
• Software centric approach is best in exposing issues in the design of a
system because the focus is on the software being built.
• Asset and Attacker centric approaches are important approaches to apply
in threat modeling as well, but it’s best not to combine approaches to
avoid confusion in the process.
• A recommendation would be to start with the software centric approach
for one release or sprint, and switch to a different approach for the next
release or sprint.
• Different approaches bring out different perspectives and different issues
to light.

Threat Modeling Process
Threat modeling is an
iterative process that
should be repeated as
the application evolves
(for every release,
sprint, or iteration)

Step 1. Identify Assets
• Identify the assets that need to be protected.
• Assets are classified according to data sensitivity and their intrinsic value
to a potential attacker.
• Assets can range from confidential data, such as your customer or orders
database, to web pages or web site availability.

Step 2. Create an Architecture Overview
• Identify what the application does (Use cases and misuse cases)
• Create an architecture diagram
• Identify the technologies used (helps to determine technology-
specific threats).

Step 3. Decompose the Application
• Identify trust boundaries (surrounding the assets)
• Identify data flow (Data flow across trust boundaries is particularly
important)
• Identify entry points (also serve as entry points for attacks)
• Identify privileged code (accesses specific types of secure resources
and performs other privileged operations)
• Document the security profile (helps to uncover vulnerabilities in the
design, implementation, or deployment configuration of your application).

• Identify the threats that could affect the application (keep goals of
attacker, architecture and potential vulnerabilities in mind):
• network threats
• host threats
• application threats
• The STRIDE threat classification methodology can be used to
identify threats.
Step 4. Identify the Threats

STRIDE – Threat Classification Methodology
Category Threat Template
Spoofing
Threat action aimed to illegally access and use another user's credentials,
such as username and password.
Tampering
Threat action aimed to maliciously change/modify persistent data, such as
persistent data in a database, and the alteration of data in transit between two
computers over an open network, such as the Internet.
Repudiation
Threat action aimed to perform illegal operations in a system that lacks the
ability to trace the prohibited operations.
Information Disclosure
Threat action to read a file that one was not granted access to, or to read data
in transit.
Denial of Service
Threat aimed to deny access to valid users, such as by making a web server
temporarily unavailable or unusable.
Elevation of Privilege
Threat aimed to gain privileged access to resources for gaining unauthorized
access to information or to compromise a system.

Step 5. Document the Threats
Document each threat using a common threat template that defines a core
set of attributes to capture for each threat:
Threat Description
Attacker obtains authentication credentials by
monitoring the network
Threat target Web application user authentication process
Risk Rating TBD in Step 6
Attack techniques Use of network monitoring software
Countermeasures Use SSL to provide encrypted channel

Step 6. Rate the Threats
• Rate the threats to prioritize and address the most significant threats
first. These threats present the biggest risk.
• The rating process weighs the probability of the threat against damage
that could result should an attack occur.
• It may turn out that certain threats do not warrant any action when you
compare the risk posed by the threat with the resulting mitigation costs.
• The DREAD model can be used to help calculate risk.

DREAD – Risk Ranking Methodology
With the DREAD model, you arrive at the risk rating for a given threat by
asking the following questions:
• Damage potential: How great is the damage if the vulnerability is exploited?
• Reproducibility: How easy is it to reproduce the attack?
• Exploitability: How easy is it to launch an attack?
• Affected users: As a rough percentage, how many users are affected?
• Discoverability: How easy is it to find the vulnerability?
Risk = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Example DREAD Table
Rating High (4-5) Medium (2-3) Low (1)
D Damage
potential
The attacker can subvert the
security system; get full trust
authorization; run as
administrator; upload content.
Leaking sensitive information Leaking trivial
information
R Reproducibility The attack can be reproduced
every time and does not require
a timing window.
The attack can be reproduced,
but only with a timing window
and a particular race situation.
The attack is very difficult
to reproduce, even with
knowledge of the security
hole.
E Exploitability A novice programmer could
make the attack in a short
time.
A skilled programmer could
make the attack, then repeat the
steps.
The attack requires an
extremely skilled person
and in-depth knowledge
every time to exploit.
A Affected users All users, default configuration,
key customers
Some users, non-default
configuration
Very small percentage of
users, obscure feature;
affects anonymous users
D Discoverability Published information explains
the attack. The vulnerability is
found in the most commonly
used feature and is very
noticeable.
The vulnerability is in a seldom-
used part of the product, and
only a few users should come
across it. It would take some
thinking to see malicious use.
The bug is obscure, and it
is unlikely that users will
work out damage
potential.

Threat Modeling
• An outcome of the threat modeling activity is a threat model document
that identifies:
 Asset, actors, use cases
 Relevant threats
 Weaknesses that could be exploited
 Countermeasures
• Threat modeling is an iterative process. The threat model is a
document that evolves and that various team members can work from.

MS Threat Modeling Tool
The Microsoft Threat Modeling Tool (TMT) 2016 is designed to guide you
and your product team through the threat modeling process. TMT
functionality includes:
• An easy drawing environment.
• Automatic threat generation using the STRIDE per interaction
approach.
• Define your own template for threat modeling
• An option for user-defined threats to be added.
• Graphically identify processes and data flows that comprise an
application or service.
https://www.microsoft.com/en-us/download/details.aspx?id=49168

References
• https://msdn.microsoft.com/en-
us/library/ee823878(v=cs.20).aspx
• https://msdn.microsoft.com/en-us/library/ff648644.aspx
• https://www.microsoft.com/en-
us/download/details.aspx?id=49168
• https://www.owasp.org/index.php/Threat_Risk_Modeling
• https://en.wikipedia.org/wiki/Threat_model
• https://www.amazon.com/Threat-Modeling-Designing-Adam-
Shostack/dp/1118809998

Secure Coding and Threat Modeling

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Secure Coding and Threat Modeling

Semelhante a Secure Coding and Threat Modeling (20)

Último

Último (20)

Secure Coding and Threat Modeling