Assignment - Threat Modeling Project

ISOL536 Security Architecture

and Design Week 3

“Privacy Threats”

Agenda

• What is privacy? • Harms • The IETF’s Privacy Considerations • Privacy Impact Assessments • The Nymity Ratchet • Contextual Integrity • Reading: Chapter 6

STRIDE Review

• STRIDE Review

Attack Violates

S Spoofing Authentication

T Tampering Integrity

R Repudiation Non-Repudiation

I Information Disclosure Confidentiality

D Denial of Service Availability

E Elevation of Privilege Authorization

What is Privacy?

• Lots of land with trees & bushes • Curtains or venetian blinds • Unlisted phone numbers, mailboxes • Swiss bank accounts

What is Privacy? (II)

• Freedom from surveillance/NSA • Anonymity • Right to be left alone • “Do not track” in browsers

Privacy vs Confidentiality

• Confidentiality is about the data • Protects data from unauthorized users

• Privacy is about the individual • How the data is used

National

• Freedom from surveillance/NSA • Anonymity • Right to be left alone • “Do not track” in browsers

Harms Approach to Privacy

• Dan Solove (George Washington University law professor)

• Understanding Privacy (2008) • Presented privacy as a family of issues • Presented a taxonomy of harms • Can be used as a basis for looking at a system

Solove’s Harms

• Identifier creation* • Information collection

• Surveillance, interrogation

• Information Processing • Aggregation, identification, insecurity, secondary use, exclusion

• Information dissemination • Breach of confidentiality, disclosure, increased accessibility, blackmail,

appropriation, distortion, [exposure]

• Invasion • Intrusion, decisional interference

* Shostack adds identifier creation in Threat Modeling, see discussion (page 112).

IETF Privacy Considerations

• Set of threats that each new protocol should consider • Likely to change rapidly in post-Snowden world • Combined security/privacy threats

• Surveillance, stored data compromise, misattribution

• Privacy threats • Correlation, identification, secondary use, disclosure, exclusion

(unawareness)

Privacy Impact Assessments

• A privacy analog to security threat modeling • Usually presented as an end-to-end process

• Often more social than technical • Can be very complementary • Typical table of contents:

• Description of the project • Description of the data flows[!] • Analysis against “the” information privacy principles • Analysis against other aspects of privacy • Analysis of privacy controls • Findings and recommendations

Nymity Slider

• Nymity: “the amount of information about the identity of participants that is revealed in a transaction”

• Easy to move left, hard to move right • Measure your system, don’t move accidentally

Contextual Integrity

• Helen Nissenbaum’s Privacy In Context (2009) • A context is an anthropological term for a “sphere of life”

such as “school” or “work”

• Can be more specific — “This university’s CS department expects…” — is a context

• A context has roles, activities, norms and values associated with it (usually implicitly)

• Can be used to understand or predict privacy concerns

Augmented Contextual Integrity

• Simply: 1. Describe the new practice in information flows* 2. Identify the prevailing context 3. Identify information subjects, senders, & recipients* 4. Identify transmission principles* 5. Locate applicable norms, identify significant changes 6. Prima facie assessment 7. Evaluation

1. Moral & political, threats to autonomy/freedom, power structures, fairness, justice, equality, etc.

8. Evaluation 2 1. Does the new directly impinge on values, goals of context?

9. Decide

• * Elements look a lot like other threat modeling

• Can be a lot of work in each step

LINDDUN

• Explicit mirror of STRIDE-per-element for privacy threat modeling • New proposal, unusual terminology • LINDDUN

• Linkability • Identifiability • Non-Repudiation (vs Repudiation as a security threat) • Detectability • Disclosure of Information • Content Unawareness • Policy and consent Non-compliance

Recap

• Privacy can be challenging compared to security • High potential for things to go badly wrong

• Ethically • Public relations

• Tools exist to help • Harms • The IETF’s Privacy Considerations • Privacy Impact Assessments • The Nymity Ratchet • Contextual Integrity

ISOL536 Security Architecture

and Design Week 3

“Processing Threats”

Agenda

• When to find threats • Playing chess • How to approach software • Tracking threats and assumptions • Customer/vendor • The API threat model • Reading: Chapter 7

When to Find Threats

• Start at the beginning of your project • Create a model of what you’re building

• Do a first pass for threats

• Dig deep as you work through features • Think about how threats apply to your mitigations

• Check your design & model matches as you get close to shipping

Attackers Respond to Your Defenses

Playing Chess

• The ideal attacker will follow the road you defend • Ideal attackers are like spherical cows — they’re a useful model for some

things

• Real attackers will go around your defenses • Your defenses need to be broad and deep

“Orders of Mitigation”

Order Threat Mitigation

1st Window smashing Reinforced glass

2nd Window smashing Alarm

3rd Cut alarm wire Heartbeat signal

4th Fake heartbeat Cryptographic signal integrity

By Example:

• Thus window smashing is a first order threat, cutting alarm wire, a third-order threat

• Easy to get stuck arguing about orders • Are both stronger glass & alarms 1st order

mitigations? (Who cares?!) • Focus on the concept of interplay between

mitigations & further attacks

How to Approach Software

• Depth first • The most fun and “instinctual” • Keep following threats to see where they go • Can be useful skill development, promoting “flow”

• Breadth first • The most conservative use of time • Most likely to result in good coverage

Tracking Threats and Assumptions

• There are an infinite number of ways to structure this • Use the one that works reliably for you • (Hope doesn’t work reliably)

Example Threat Tracking Tables

Diagram Element Threat Type Threat Bug ID

Data flow #4, web server to business logic

Tampering Add orders without payment checks

4553 “Need integrity controls on channel”

Info disclosure Payment instruments sent in clear

4554 “need crypto” #PCI

Threat Type Diagram Element(s) Threat Bug ID

Tampering Web browser Attacker modifies our JavaScript order checking

4556 “Add order- checking logic to server”

Data flow #2 from browser to server

Failure to authenticate

4557 “Add enforce HTTPS everywhere”

Both are fine, help you iterate over diagrams in different ways

Example Assumption Tracking

Assumption Impact if it’s wrong

Who to talk to

Who’s following up

Follow-up by date

Bug #

It’s ok to ignore denial of service within the data center

Availability will be below spec

Alice Bob April 15 4555

• Impact is sometimes so obvious it’s not worth filling out • Who to talk to is not always obvious, it’s ok to start out blank • Tracking assumptions in bugs helps you not lose track

• Treat the assumption as a bug – you need to resolve it

The Customer/Vendor Boundary • There is always a trust boundary when:

• Your code goes to someone else’s (device/premises)

• Their data comes to your code

• Lawyers, pretending do not eliminate human trust issues

• You need to think about it while deciding what happens over the data flow shown

Your software

Customer device

Your software

Your data center

Generic API Threat Model • Perform security checks inside the boundary • Copy before validation for purpose

• Is http://evil.org/pwnme.html “valid”?

• Define the purpose for data, validate near that definition • Manage error reporting • Document what checks happen where • Do crypto in constant time • Address the security requirements for your API

Recap

• When to find threats • Playing chess • How to approach software • Tracking threats and assumptions • Customer/vendor • The API threat model

What’s next?

• Quiz • Due Sunday 11:59 PM

• 10 multiple choice questions

• 20 minutes

• You have 2 chances (take highest grade)

• Reach chapters 8 and 9