Linddun threat model
Skill onfire7777/universal-ai-skills-library/skills/linddun-threat-model
Router-first AI skill system for Codex, Claude, Cursor, Hermes, Paperclip, OpenCode, and local AI stacks: search, preflight-route, and load 1,812 skills on demand without duplicating the corpus.
npx -y skills add onfire7777/universal-ai-skills-library --skill linddun-threat-modelAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Conduct LINDDUN privacy threat modeling across all seven categories: Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness, and Non-compliance. Includes DFD-based analysis, threat trees, privacy-specific mitigation strategies, and integration with STRIDE security threat modeling.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
12.6 KB, as published. Nobody here has run it
LINDDUN Privacy Threat Modeling
Overview
LINDDUN is a systematic privacy threat modeling methodology developed by the DistriNet research group at KU Leuven. It provides a structured approach to identify and mitigate privacy threats in software systems. The acronym represents seven privacy threat categories that map to violations of privacy properties defined in ISO/IEC 29100.
The Seven LINDDUN Threat Categories
L — Linking
Definition: The ability to associate two or more data items or actions with an individual or group, beyond what is intended by the data subject.
Privacy Property Violated: Unlinkability
Threat Scenarios:
- Cross-referencing anonymized datasets to re-identify individuals
- Correlating browsing behavior across websites using fingerprinting
- Linking social media profiles to real identities through metadata
- Combining location data points to infer home/work addresses
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Data minimization | Collect only necessary attributes | Review each data field against stated purpose |
| Pseudonymization | Replace identifiers with tokens | Use cryptographic pseudonymization with key separation |
| Mix networks | Obscure communication patterns | Route messages through anonymity networks |
| Aggregation | Present only group-level data | Enforce minimum group size (k>=5) for any query result |
| Session unlinkability | Prevent cross-session tracking | Rotate session tokens, avoid persistent identifiers |
I — Identifying
Definition: The ability to identify a data subject from a set of data items, connecting them to a known individual.
Privacy Property Violated: Anonymity
Threat Scenarios:
- Direct identification from unmasked PII in logs
- Quasi-identifier attacks (combining age, ZIP code, gender)
- Facial recognition from images in datasets
- Voice identification from audio recordings
- Writing style analysis (stylometry) in anonymous forums
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Anonymization | Remove direct identifiers | Strip names, emails, SSNs before processing |
| k-Anonymity | Generalize quasi-identifiers | Ensure each record shares attributes with k-1 others |
| Differential privacy | Add calibrated noise | Apply epsilon-differential privacy to query responses |
| Data masking | Obscure identifying fields | Replace with realistic synthetic values |
| Access control | Restrict who can see raw data | Implement need-to-know access with purpose verification |
N — Non-repudiation
Definition: The inability of a data subject to deny having performed an action, even when such denial would be desirable for privacy.
Privacy Property Violated: Plausible deniability
Threat Scenarios:
- Immutable audit logs linking users to actions
- Digital signatures proving authorship of documents
- Non-repudiable transaction records
- Email delivery confirmations and read receipts
- Blockchain-based records that cannot be denied or deleted
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Deniable encryption | Enable plausible deniability | Use deniable encryption schemes for sensitive data |
| Group signatures | Hide individual identity in group | Implement group signature schemes for authenticated actions |
| Minimal logging | Log only what is legally required | Review and minimize audit trail scope |
| Aggregate reporting | Report actions at group level | Aggregate activity reports rather than individual-level |
| Configurable receipts | Let users control acknowledgments | Allow opt-out of read receipts and delivery confirmations |
D — Detecting
Definition: The ability to determine whether a data subject has been involved in an action or is present in a dataset, even without identifying them specifically.
Privacy Property Violated: Undetectability
Threat Scenarios:
- Traffic analysis revealing communication patterns
- Database membership inference attacks
- Timing attacks revealing user activity
- Side-channel attacks revealing data access patterns
- Presence detection through network metadata
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Traffic padding | Mask communication patterns | Generate dummy traffic to obscure real patterns |
| Steganography | Hide data within other data | Embed sensitive communications in innocuous content |
| Constant-time operations | Prevent timing analysis | Implement constant-time algorithms for sensitive operations |
| Oblivious RAM | Hide access patterns | Use ORAM protocols for privacy-critical data access |
| Differential privacy | Provide membership privacy | Apply differential privacy to prevent membership inference |
D — Data Disclosure
Definition: Unauthorized exposure of personal data to parties who should not have access.
Privacy Property Violated: Confidentiality
Threat Scenarios:
- SQL injection exposing database contents
- Misconfigured cloud storage buckets
- Insider threats with excessive access privileges
- Man-in-the-middle attacks on unencrypted channels
- API responses returning excessive data fields
- Backup media loss or theft
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Encryption | Protect data at rest and in transit | AES-256 at rest, TLS 1.3 in transit |
| Access control | Enforce least privilege | RBAC with regular access reviews |
| Input validation | Prevent injection attacks | Parameterized queries, input sanitization |
| API field filtering | Return only requested fields | Implement field-level access control in APIs |
| DLP | Detect and prevent data exfiltration | Deploy DLP at network egress and endpoints |
U — Unawareness
Definition: Data subjects being insufficiently aware of data processing activities, their rights, or the consequences of providing or withholding data.
Privacy Property Violated: Transparency, Intervenability
Threat Scenarios:
- Hidden data collection through tracking pixels
- Opaque algorithmic decision-making
- Buried privacy policies with complex legal language
- Undisclosed data sharing with third parties
- Lack of notification when processing purposes change
- No mechanism for data subjects to exercise rights
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Layered notices | Progressive disclosure | Short notice + full policy + just-in-time |
| Privacy dashboards | Centralized visibility | User-facing dashboard showing all data held |
| Consent management | Granular, informed consent | Purpose-specific consent with clear descriptions |
| Explainable AI | Algorithmic transparency | Provide meaningful explanations of automated decisions |
| Right facilitation | Easy rights exercise | Self-service portal for access, correction, deletion |
N — Non-compliance
Definition: Processing personal data in ways that violate applicable laws, regulations, standards, or organizational policies.
Privacy Property Violated: Policy and consent compliance
Threat Scenarios:
- Processing without valid legal basis
- Failing to honor data subject rights within deadlines
- Cross-border transfers without adequate safeguards
- Retaining data beyond the stated retention period
- Processing children's data without parental consent
- Failing to conduct required impact assessments
Mitigation Strategies:
| Strategy | Technique | Implementation |
|---|---|---|
| Compliance mapping | Map processing to legal bases | Document legal basis per processing activity per jurisdiction |
| Automated enforcement | Technical compliance controls | Automated retention enforcement, consent verification |
| DPIA process | Impact assessment for high-risk processing | Mandatory DPIA before deploying new high-risk processing |
| Regulatory monitoring | Track legal developments | Subscribe to regulatory updates, conduct periodic gap analysis |
| Audit program | Verify ongoing compliance | Annual compliance audits with corrective action tracking |
DFD-Based Threat Analysis Process
Step 1: Create Privacy-Annotated Data Flow Diagram
[Data Subject] ---(personal data)--> [Web Application]
^ |
| v
[Notice] [Application Server]
|
+-------------+-------------+
| | |
v v v
[User Database] [Analytics DB] [Third-Party API]
(encrypted) (pseudonymized) (data sharing)
Annotate each element with:
- Data types flowing through (PII categories)
- Trust boundaries crossed
- Storage locations and durations
- Processing purposes
- Access controls in place
Step 2: Map Threats to DFD Elements
| DFD Element | L | I | N | D(etect) | D(isclose) | U | N(on-comply) |
|---|---|---|---|---|---|---|---|
| Data flows | X | X | X | X | |||
| Data stores | X | X | X | X | |||
| Processes | X | X | X | X | X | X | X |
| External entities | X | X | X | X | X |
Step 3: Build Threat Trees
For each applicable threat category per DFD element, construct a threat tree:
Identifying Threat to User Database
├── Direct identifier exposure
│ ├── SQL injection reveals raw PII
│ ├── Backup media contains unencrypted PII
│ └── Admin access to production database
├── Quasi-identifier attack
│ ├── Combination of age + ZIP + gender
│ └── Temporal correlation of records
└── Inference attack
├── Aggregate query with small group size
└── Differential attack across query results
Step 4: Prioritize and Mitigate
Use a risk matrix to prioritize identified threats:
| Likelihood / Impact | Negligible | Limited | Significant | Maximum |
|---|---|---|---|---|
| Very Likely | Medium | High | Critical | Critical |
| Likely | Low | Medium | High | Critical |
| Possible | Low | Medium | Medium | High |
| Unlikely | Low | Low | Medium | Medium |
| Rare | Low | Low | Low | Medium |
LINDDUN and STRIDE Integration
| LINDDUN Category | Related STRIDE Category | Overlap Area |
|---|---|---|
| Data Disclosure | Information Disclosure | Both address unauthorized data exposure |
| Non-compliance | Tampering | Integrity of consent records |
| Detecting | Information Disclosure | Metadata leakage |
| Identifying | Information Disclosure | PII exposure |
| Non-repudiation | Repudiation | Opposing perspectives on the same property |
Practical Application at Cipher Engineering Labs
Threat Modeling Workshop Agenda (4 hours)
- System Overview (30 min): Present the system architecture and data flows
- DFD Construction (45 min): Collaboratively build privacy-annotated DFD
- Threat Identification (90 min): Walk through each LINDDUN category per DFD element
- Prioritization (30 min): Score threats on risk matrix
- Mitigation Planning (45 min): Identify controls for high and critical risks
Deliverables
- Privacy-annotated Data Flow Diagram
- LINDDUN Threat Register (all identified threats with risk scores)
- Mitigation Plan (prioritized controls for high/critical threats)
- Residual Risk Statement
References
- Deng, M., Wuyts, K., Scandariato, R., Preneel, B., and Joosen, W. "A Privacy Threat Analysis Framework: Supporting the Elicitation and Fulfillment of Privacy Requirements." Requirements Engineering, 16(1):3-32, 2011.
- Wuyts, K. and Joosen, W. "LINDDUN Privacy Threat Modeling: A Tutorial." CW Reports, KU Leuven, 2015.
- LINDDUN GO — Lightweight approach: linddun.org
- ISO/IEC 29100:2011 — Information Technology — Security Techniques — Privacy Framework
- OWASP Privacy Risks Project