Day O’ Security An Introduction to the Microsoft Security Development Lifecycle Day 1: Threat Modelling - CIA and STRIDE

A Threat Modelling Conversation 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.

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 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 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.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 evation-of-privilege-revisited.html 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.

Auntie Beeb's Virus

Your Password Sucks

Threat Modelling us/magazine/cc aspx us/magazine/cc 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 ElementData FlowsData StoresProcessesInteractors 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 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 ElementData FlowsData StoresProcessesInteractors Spoofing ** Tampering *** Repudiation ** Information Disclosure *** Denial of Service *** Elevation of Privilege *

Analyzing Data Stores ElementData FlowsData StoresProcessesInteractors Spoofing ** Tampering *** Repudiation ** Information Disclosure *** Denial of Service *** Elevation of Privilege *

Analyzing Processes ElementData FlowsData StoresProcessesInteractors 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.