Risks and Failures Reference

Attack catalog, case studies, implementation mistakes checklist, and privacy testing reference. Restructured from Module 12 for quick lookup during risk assessment, client conversations ("here's why your current approach is insufficient"), and validation.

Abbreviations used throughout: SDP = Sensitive Data Protection; HMAC = keyed-hash message authentication code; FPE = format-preserving encryption; DDM = dynamic data masking; ARX = open-source structural anonymization tool; MSISDN = subscriber phone number; CDR = Call Detail Record.

For countermeasure techniques, see the techniques reference. For incident response procedures, see governance and ops.

Decision tree: what risk am I evaluating?

---

Attack catalog

Attack 1: Linkage attack

Field	Detail
Mechanism	Join anonymized dataset with external dataset on shared quasi-identifiers
Preconditions	QI combinations unique enough to narrow to single record; external dataset with overlapping QIs available
Data types at risk	Any tabular data with quasi-identifiers (demographics, location, timestamps)
Countermeasures	k-anonymity (ensure every QI combination maps to ≥ k records); generalization of QIs
Example	Massachusetts 1997 — ZIP + birthdate + gender uniquely identifies 87% of US population. $20 voter roll cross-referenced to re-identify Governor Weld's health records.

Attack 2: Dictionary attack (rainbow table)

Field	Detail
Mechanism	Precompute hash of every possible input in a finite domain, match against dataset
Preconditions	Finite, enumerable input domain (phone numbers, national IDs, credit cards); non-HMAC hash function (unsalted or salted — if the salt is known, which is standard practice, the domain is still enumerable per salt)
Data types at risk	Any hashed finite-domain identifier
Countermeasures	HMAC-keyed hashing (precomputation impossible without key); FPE with Cloud KMS
Example	NYC Taxi 2014 — MD5 of medallion numbers reversed in minutes

Enumeration times for common identifiers:

Identifier	Domain size	Time to enumerate
Credit card (per BIN)	~10⁶	Seconds
MSISDN	~10⁸	Minutes
SSN	~10⁹	Minutes
IBAN	~10⁹–10¹⁰	Hours
IPv4	~4.3×10⁹	Hours

Attack 3: Fingerprinting / trajectory attack

Field	Detail
Mechanism	Unique behavioral sequences (mobility traces, purchase patterns) re-identify individuals even after identifier removal
Preconditions	High-dimensional data with temporal/spatial components; human routine behavior
Data types at risk	CDRs, GPS traces, purchase sequences, smart meter readings, clickstream
Countermeasures	Structural anonymization (k-anonymity k ≥ 50 on QIs); DP on aggregate outputs; temporal bucketing; spatial generalization
Key statistic	4 spatio-temporal points identify 95% of individuals (de Montjoye 2013). Replicated across cell data, GPS, credit cards, smart meters.

Attack 4: Content-based re-identification

Field	Detail
Mechanism	Free-text content contains self-identifying information (names, addresses, medical conditions in searches, support notes)
Preconditions	Unstructured data with personal content; identifier replacement but content preserved
Data types at risk	Search queries, support tickets, chat transcripts, medical notes, delivery instructions
Countermeasures	NLP-based PII detection (Presidio / SDP text inspection); content suppression / redaction
Example	AOL 2006 — search queries contained names, addresses, medical conditions. User 4417749 identified as Thelma Arnold from her searches.

Attack 5: High-dimensional sparsity

Field	Detail
Mechanism	In high-dimensional spaces, almost every point is unique — removing the label doesn't change the fingerprint
Preconditions	High-dimensional behavioral data (rating histories, transaction vectors); sparse individual patterns
Data types at risk	Movie ratings, product reviews, transaction vectors, browsing histories
Countermeasures	DP (bounds what any attacker can learn regardless of auxiliary data); synthetic data
Example	Netflix Prize 2006 — 8 movie ratings with approximate dates enough to uniquely identify subscribers via IMDb cross-reference

Attack 6: Sparse-context aggregation failure

Field	Detail
Mechanism	Aggregation that provides anonymity in dense populations fails in sparse ones — "aggregate" over a military base in the desert is individual-level
Preconditions	Spatially or temporally sparse populations; uniform aggregation parameters across contexts
Data types at risk	Location/heatmap data, activity tracking, any aggregate in low-population areas
Countermeasures	Context-dependent generalization parameters; sparse-cell suppression; geographic exclusion of sensitive locations
Example	Strava 2018 — aggregated exercise heatmap revealed military base outlines and patrol routes in Syria/Afghanistan

Attack 7: Composition attack

Field	Detail
Mechanism	Cross-referencing multiple releases about the same population narrows equivalence classes over time. Each release individually safe; cumulative risk grows.
Preconditions	Repeated releases about same population; traditional anonymization without composition tracking
Data types at risk	Any repeatedly released dataset (quarterly reports, periodic data shares)
Countermeasures	Differential privacy with composition theorem; DP budget tracking across releases
Example	"The slow leak" — quarterly CDR aggregates independently pass k-anonymity; a subscriber who moved mid-year appears in different clusters in Q1 and Q3, and the intersection may have effective k=1

---

Attack quick-reference matrix

Attack	Exploits	Defended by	Key indicator
Linkage	QI uniqueness	k-anonymity	87% of US identifiable by 3 QIs
Dictionary	Finite hash domains	HMAC keyed hashing	Enumeration in seconds to hours
Fingerprinting	Behavioral uniqueness	Structural anon + DP	4 points → 95% unique
Content-based	Self-identifying text	NLP detection + redaction	Free text in output
Sparsity	High-dimensional uniqueness	DP, synthetic data	8 ratings → unique
Sparse context	Low-population aggregates	Context-dependent params	Remote/sparse locations in output
Composition	Repeated releases	DP budget tracking	Multiple releases of same population

---

Case studies

Case	Year	Data type	Attack	Root cause	Lesson
Massachusetts health	1997	Health + demographics	Linkage (voter roll)	3 QI fields → 87% unique	k-anonymity born; field combinations matter
AOL search logs	2006	Search queries	Content-based	Free text = self-identifying	Content IS the identifier
Netflix Prize	2006	Movie ratings	High-dim sparsity	Rating vectors unique in sparse space	k-anonymity can't help when data itself fingerprints
NYC Taxi	2014	Taxi trips	Dictionary (unsalted MD5)	Finite domain, no HMAC key	Always HMAC, never plain hash
Australian Medicare	2016	Health claims	Linkage (temporal patterns)	Temporal structure identifying	Encryption ≠ anonymization
Strava heatmap	2018	Exercise GPS	Sparse-context aggregation	Uniform params across dense/sparse	Anonymization is context-dependent
Mobility research	Ongoing	Cell/GPS/transaction	Fingerprinting (4-point rule)	Behavioral uniqueness	ID substitution alone is never enough

Presales use: These case studies demonstrate concrete failures to clients. The Massachusetts and NYC Taxi cases are the most compelling for explaining why dictionary-based pseudonymization is insufficient.

---

Implementation mistakes diagnostic checklist

Use this as a diagnostic tool during discovery — most legacy systems exhibit 3–5 of these patterns.

Privacy claim unsupported

#	Mistake	What to look for	Impact
1	Pseudonymization called anonymization	Re-identification key exists; data is legally personal data	False compliance claim; full GDPR still applies
2	Non-HMAC hashing of finite-domain inputs	SHA-256 (plain or salted) on MSISDNs, IBANs, credit cards without a secret HMAC key	Reversible in minutes to hours via dictionary attack (salt prevents precomputed tables but not per-salt enumeration)
3	Identifier substitution treated as sufficient	Direct IDs replaced but quasi-identifiers (timestamps, locations, amounts) untouched	Behavioral structure intact; fingerprinting attacks possible
4	No re-identification risk assessment	Technique named but no metric measured (prosecutor risk, k-value, ε budget)	"We anonymized it" without evidence

Operational gaps

#	Mistake	What to look for	Impact
5	Single point of failure in key storage	One compromise = bulk reversal of all pseudonyms	Catastrophic exposure from single breach
6	No key rotation policy	Cryptoperiod exceeds NIST SP 800-57 recommendations	Increasing key exposure over time
7	Missing lineage for downstream copies	Ad-hoc extracts, spreadsheets, partner feeds ungoverned	Anonymized data re-identified via uncontrolled copies
8	No schema drift monitoring	New PII columns pass through pipeline untransformed	Silent PII leakage into output

Governance erosion

#	Mistake	What to look for	Impact
9	Static anonymization parameters	Parameters never reassessed since initial implementation	Changing data landscape degrades protection
10	Masking confused with data protection	DDM controls query results, but raw data is in clear	Data at rest fully identifiable
11	No separation of duties	Same team holds pseudonymization key and has data access	Effective pseudonymization requires domain separation
12	Uniform treatment regardless of purpose	Same generalization for internal BI and external sharing	Over- or under-protection depending on use case

---

Privacy testing reference

Automated pipeline checks

Check	Frequency	What it catches	Tool
PII pattern scanning	Every run	Raw PII in output (broken/missing transforms)	SDP inspection on output; exclude FPE fields
k-anonymity threshold assertion	Every batch	Min equivalence class size below documented threshold	ARX or custom query
Distribution drift detection	Every run	Transform applied incorrectly or new subpopulation	Statistical comparison vs baseline
Linkage test (pipeline change)	After changes	Degradation missed by other checks	Custom record-linkage against proxy dataset
Linkage test (routine)	Monthly	External landscape drift degrading guarantees	Same
Membership inference test	For synthetic data	Generator memorized training records	Custom train/holdout attack model (SDV covers disclosure risk and attribute inference only)
DP budget tracking	Continuous	Cumulative epsilon approaching exhaustion	Privacy on Beam / custom tracker

Validation tools

Tool	What it validates	When to use
SDP inspection	PII regression — raw PII appearing in output	Every pipeline run
ARX risk metrics	Prosecutor/journalist/marketer risk; k-anonymity verification	Before each Zone 2 release
sdcMicro	Statistical disclosure control reports	Formal risk quantification for DPAs
Custom record-linkage	Probabilistic matching against held-out data	After pipeline changes and monthly
Custom train/holdout attack model	Membership inference attack on synthetic data (SDV metrics cover disclosure risk / attribute inference, not full MIA)	Before synthetic data release

Privacy testing decision