ISOL_536Security_Architecture_and_DesignThreat_ModelingSession

ISOL 536 Security Architecture and Design

Threat Modeling Session 12a

Threat Modeling & Security Requirements

Agenda

• Interplay of threats and requirements • Requirements

– Business & Scenarios – Prevent/Detect/Respond – Compliance – Privacy – STRIDE

• Non-Requirements

• Reading: Chapter 12

Interplay of Attacks, Mitigations and Requirements

Requirements

Threats Mitigations

Requirements drive threats

Threats expose requirements

Un-mitigatable threats drive requirements

Threats need mitigation

Mitigations can be bypassed

Framing Requirements

• Important threats violate important requirements

• Crisp requirements help determine if something violates

– Thought-provoking: “A program that hasn’t been fully specified cannot be buggy, merely surprising.”

– Full specification is exceptionally rare

– Bugs are not rare

• Crisp requirements are hard

• Requirements often change as you learn more

• So getting “good enough” quickly is a useful goal

Cookbook Approach

• Chapter 12 is full of lists such as: – Anyone with an email address can create an account

– Anyone with a validated email address can create an account

– Anyone with a credit card number can create an account

– Anyone with a valid, authorizable credit card can create an account

– Anyone who can tell us how much we charged their credit card can …

• Intended to provoke consideration/conversation

• Many are incomplete, requiring scoping or customization

REQUIREMENTS

Business & Scenarios

• Scenario driven

– Use cases are a general approach to requirements

– Rare for security to show up in use cases, even as a feature

• Industry

– PCI-DSS, medical, other “verticals” impose requirements

• Competition

– One place it’s possible to get more crisp

Prevent/Detect/Respond (1/3)

• A common way of framing security problems

• Can lead to some interesting requirements for both development and operations

• Prevent

– Isolation (firewalls, air gaps)

– Least-privilege (sandboxing, running unprivileged)

– Vulnerability management

Prevent: Vulnerability Management (2/3)

• Vulnerabilities refer to code bugs which can be exploited leading to attacker code running

• Track vulnerabilities in code you depend on

– Operationally to patch

– Developmentally to integrate security fixes & ship updates

• Make it easy for others to report vulnerabilities to you

Detect/Respond (3/3)

• Operational Detection – Set goals for detection

– Use penetration testing, “Indicators of Compromise” to test

• Product Enablement for Detection – Ensure that attack surface logs

– Mark security messages as security

• Respond – Plan & practice before a real incident

Compliance-Driven Requirements

• Can be a useful source even if not required

– NIST Special Publication 200

– PCI-DSS

– Both relate closely to other requirements frameworks

• Cloud Security Alliance mappings

– Compare 10 frameworks (COBIT, HIPPA, ISO, PCI- DSS, etc)

Privacy Requirements

• Meeting customer, regulatory & business needs

• Fair Information Practices

– Notice, consent, redress and others

– Basis of many national laws

• Privacy by Design

– Proactive, by default, embedded, positive sum, lifecycle protection, transparency, respect for users

• Seven Laws of Identity

STRIDE

• The requirements are the inverse of the threats

• Thus spoofing impacts authentication requirements (etc.)

Spoofing — Authentication

• Is authentication required?

– Whitehouse.gov vs Wikipedia

• How strong an authentication is required?

• Account lifecycle

– Creation requirements

– Audit requirements

– Account closing

Tampering — Integrity

• Filesystem integrity

• Network integrity

• Log integrity

Repudiation — Non-Repudiation

• Logging

• Audit

• Fraud prevention

Info Disclosure — Confidentiality

• File confidentiality

• Metadata confidentiality

– Filename

– Directory name

– Fact of communication (“Calling an addiction support line”)

• Network confidentiality

Elevation — Authorization

• Manage authorization or delegate to platform?

• Central list of ACLs or rules stored with files?

– Central easier to manage programmatically

– Stored with files easier for people to understand

• Formal models (Bell-LaPadula, Biba)

Non-Requirements

• Important to decide, communicate what you don’t defend against

– Then customers can decide if it’s the right model

• Operational Guides

• Publish non-requirements documents

– “Microsoft Immutable Laws of Security”

Recap

• Threats and requirements have a natural interplay

• Lots of ways to find requirements

• Crisp requirements & non-requirements help you find the important threats

• Focus your security effort