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
Applied Sciences
Architecture and Design
Biology
Business & Finance
Chemistry
Computer Science
Geography
Geology
Education
Engineering
English
Environmental science
Spanish
Government
History
Human Resource Management
Information Systems
Law
Literature
Mathematics
Nursing
Physics
Political Science
Psychology
Reading
Science
Social Science
Home
Blog
Archive
Contact
google+twitterfacebook
Copyright © 2019 HomeworkMarket.com