Day O’ Security
An Introduction to the Microsoft
Security Development Lifecycle
Day 1:
Threat Modelling - CIA and STRIDE
A Threat Modelling Conversation
http://msdn.microsoft.com/en-us/magazine/dd727503.aspx
The Thespians
Paige: a young, bright software developer.
Michael: a simple security guy at Microsoft.
Scene I
A small hallway between two sets of cubicles, supposedly designed to enhance agile software
development and communication.
Paige: Hey, grumps. I need your help building some software.
Michael: So?
Paige: Seriously, I want your help building this system I'm working on.
Michael: You mean you're going to design something, build it, pretend to test it, and then ask me
to find the security vulnerabilities?
Paige: Don't be so grumpy. No, I want your help up front.
Pause: Michael wipes his hand down his face and forces a smile.
http://mycodehere.blogspot.com
http://mycodehere.blogspot.com/2009/08/securityglossary.html
Some Definitions
• Asset - any valuable resource, e.g. database data, file
system data, system resource.
• Threat - any potential occurrence (malicious or
inadvertent) that could harm or impede an asset.
• Vulnerability - any weakness which makes possible a threat
to an asset.
• Exploit - the implementation of a threat against a
vulnerability (previously synonymous with Attack).
• Attack - application of an exploit; any action designed to
harm an asset.
• Mitigation - any strategy, technique or circumstance that
reduces the threat posed by a vulnerability.
• Spam - cooked meat, nice in sandwiches.
C.I.A.
• C is for Intecrity
Data cannot be modified undetectably.
• I is for Availability
Data must be available when needed.
• A is for Confidentiality
Data cannot be disclosed to unauthorized
individuals / systems.
I.A.C.
• I is for Integrity
Data cannot be modified undetectably.
• A is for Availability
Data must be available when needed.
• C is for Confidentiality
Data cannot be disclosed to unauthorized
individuals / systems.
Security Development Lifecycle (SDL)
• Trustworthy Computing – Directive issued by
Bill Gates, January 2002.
• Encapsulated “S3+C”:
Security (and privacy) by design;
Security (and privacy) by default;
Security (and privacy) in deployment;
Communications.
• Set of policies, processes, tools, resources.
• Example tool: SDL Process Template for VSTS.
So Just What’s So Good about the
SDL Process Template for VSTS?
• Installs SDL requirements as work items.
• Includes SDL-based check-in policies.
• Customizes security bugs and queries.
• Includes extensive SDL how-to and guidance
documentation.
• Generates auditable Final Security Review report
• Accommodates third-party tool integration, e.g.
the SDL Threat Modeling Tool.
• Includes project plans and security risk assessment
templates.
SDL Mandatory Security Activities in a
Traditional (or should that be Legacy)
Software Development Lifecycle
A New Process: SDL + Agile
• SDL predates Agile
• Adaptation involves
identifying three
requirement
categories:
1. One-Time
2. Every-Sprint
3. Bucket
Optimizing Secure Software
Development
Four levels of business maturity
The Classic Saltzer and Schroeder
Design Principles
• Open design: Assume the attackers have the sources and
the specs.
• Fail-safe defaults: Fail closed; no single point of failure.
• Least privilege: No more privileges than what is needed.
• Economy of mechanism: Keep it simple, stupid.
• Separation of privileges: Don’t permit an operation based
on a single condition.
• Total mediation: Check everything, every time.
• Least common mechanism: Beware of shared resources.
• Psychological acceptability: Will they use it?
Security Properties
• Confidentiality: Data is only available to the people
intended to access it.
• Integrity: Data and system resources are only changed
in appropriate ways by appropriate people.
• Availability: Systems are ready when needed and
perform acceptably.
• Authentication: The identity of users is established (or
you’re willing to accept anonymous users).
• Authorization: Users are explicitly allowed or denied
access to resources.
• Non-repudiation: Users can’t perform an action and
later deny performing it.
Threat Types - S.T.R.I.D.E.
•
•
•
•
•
•
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Elevation of Privilege (EoP)
Card Game
Examples
• http://mycodehere.blogspot.com/2011/01/el
evation-of-privilege-revisited.html
Spoofing
• Spoofing describes any threat allowing an
attacker to:
Pretend to be someone or something else.
• Threat against: Authentication.
• Example: “Phishing”
Tampering
• Tampering describes any threat allowing an
attacker to:
Alter or destroy data, where this would
normally be disallowed by the application.
• Threat against: Integrity.
• Tampering attacks can be directed against
static data files or network packets.
Repudiation
• Repudiation describes any threat allowing an
attacker to:
Perform an action, then deny that they ever
did it.
• Threat against: Non-repudiation.
• Mitigation example: secure log file with time
stamps.
Information Disclosure
• Information Disclosure describes any threat
allowing an attacker to:
Expose information to someone not
authorised to see it.
• Threat against: Confidentiality.
• Can occur with static data files as well as
network packets.
Denial of Service
• Denial of Service describes any threat allowing
an attacker to:
Degrade or deny service to users.
• Threat against: Availability.
• Examples: crash or flood your server.
Elevation of Privilege
• Elevation of Privilege describes any threat
allowing an attacker to:
Gain privileges they would not normally have.
• Threat against: Authorization.
• Example: buffer overflow in an app running as
SYSTEM - lets attacker run arbitrary code at a
very high privilege level.
• Mitigation: principle of least privilege.
http://google-gruyere.appspot.com/
Auntie Beeb's Virus
Your Password Sucks
Threat Modelling
• http://msdn.microsoft.com/enus/magazine/cc163519.aspx
• Threat modelling is an integral part of the
Security Development Lifecycle.
• Start with a Data Flow Diagram.
Data Flow Diagram Symbols
•
•
•
•
•
•
Data flow: One way arrow
Data store: Two parallel horizontal lines
Process: Circle
Multi-process: Two concentric circles
Interactors: Rectangle
Trust boundary: Dotted line
Threats Affecting Elements
Element
Data Flows
Data Stores
Spoofing
Tampering
*
*
Repudiation
Information
Disclosure
Denial of
Service
Elevation of
Privilege
*
*
*
*
Processes
*
*
*
*
*
*
Interactors
*
*
Analyzer Database
•
•
•
•
•
•
•
•
•
•
Let's say you need a system to collect the accounting files from your sales force,
compute sales data on your database server, and produce weekly reports.
We'll call the system the Analyzer Database.
The goal is fairly simple: getting files from a set of systems and performing some
analysis of the files on a centralized server.
There are many obvious potential threats to this system, and many of them come
from the implicit security requirements of the problem statement.
The collection process alone raises a number of questions.
Collecting information means moving it from one place to another.
How are you going to secure it in transit?
You'll be manipulating accounting files, which by their very nature are sensitive
and often subject to legal requirements.
And you'll need to identify a specific group of people—the sales force.
How will you know them?
An Initial DFD for the
Analyzer Database
General Rules for a DFD
• First, be careful of magic data sources or sinks:
data isn't created out of thin air.
• Second, beware of psychokinesis as a data
transport.
• Third, collapse similar elements within a single
trust boundary into a single element for
modelling purposes.
• Fourth, be careful when modelling details on
either side of a trust boundary.
A Better DFD
Analyzing Data Flows
Element
Data Flows
Data Stores
Spoofing
Tampering
*
*
Repudiation
Information
Disclosure
Denial of
Service
Elevation of
Privilege
*
*
*
*
Processes
*
*
*
*
*
*
Interactors
*
*
Analyzing Data Stores
Element
Data Flows
Data Stores
Spoofing
Tampering
*
*
Repudiation
Information
Disclosure
Denial of
Service
Elevation of
Privilege
*
*
*
*
Processes
*
*
*
*
*
*
Interactors
*
*
Analyzing Processes
Element
Data Flows
Data Stores
Spoofing
Tampering
*
*
Repudiation
Information
Disclosure
Denial of
Service
Elevation of
Privilege
*
*
*
*
Processes
*
*
*
*
*
*
Interactors
*
*
Mitigations
• Mitigate a threat with a strong, wellunderstood solution.
• Example: strong cryptography against
Information Disclosure threats.
• Q1: can the technology be used to mitigate
the threat?
• Q2: would it actually be used in the given
scenario?
Attack Patterns
• The manifestation of one or more threats in
the context of some specific technology.
• Example: strcpy in C may let an attacker input
long strings to corrupt program memory,
allowing arbitrary code execution.
• Same vulnerability may be used in other ways.