Day O’ Security

An Introduction to the Microsoft Security Development Lifecycle

Day 1:Threat Modelling - CIA and STRIDE

A Threat Modelling Conversationhttp://msdn.microsoft.com/en-us/magazine/dd727503.aspxThe 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/security-glossary.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 IntecrityData cannot be modified undetectably.

• I is for AvailabilityData must be available when needed.

• A is for ConfidentialityData cannot be disclosed to unauthorized individuals / systems.

I.A.C.

• I is for IntegrityData cannot be modified undetectably.

• A is for AvailabilityData must be available when needed.

• C is for ConfidentialityData 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 theSDL 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-Time2. Every-Sprint3. 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/elevation-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/en-us/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 ElementsElement Data Flows Data Stores Processes Interactors

Spoofing * *Tampering * * *Repudiation * *Information Disclosure * * *Denial of Service * * *Elevation of Privilege *

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 theAnalyzer 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 FlowsElement Data Flows Data Stores Processes Interactors

Spoofing * *Tampering * * *Repudiation * *Information Disclosure * * *Denial of Service * * *Elevation of Privilege *

Analyzing Data StoresElement Data Flows Data Stores Processes Interactors

Spoofing * *Tampering * * *Repudiation * *Information Disclosure * * *Denial of Service * * *Elevation of Privilege *

Analyzing ProcessesElement Data Flows Data Stores Processes Interactors

Spoofing * *Tampering * * *Repudiation * *Information Disclosure * * *Denial of Service * * *Elevation of Privilege *

Mitigations

• Mitigate a threat with a strong, well-understood 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.