Apply the LINDDUN privacy‑engineering framework to elicit privacy threats, then map the resulting findings to Microsoft’s STRIDE model to ensure security coverage.
Threat category | LINDDUN focus | STRIDE focus | Example mitigation in FL |
---|---|---|---|
Linking | Re‑identification via update correlation | — | Add Gaussian DP noise to model updates |
Identifying | Direct identifiers in logs | — | Remove user IDs before logging |
Non‑repudiation | Verifiable update provenance | — | Retain only aggregate logs |
Detecting | Participation inference | — | Add dummy (zero) client updates |
Unawareness | Missing consent | — | Deploy dynamic consent portal |
Non‑compliance | GDPR Article 35 DPIA | — | Embed privacy‑by‑design checkpoints |
Spoofing | — | Identity fraud | Mutual TLS + OIDC |
Tampering | — | Model poisoning | Byzantine‑robust aggregation |
Information disclosure | — | Data leakage | Secure aggregation (e.g. SecAgg+, LightSecAgg) |
Denial of service | — | Resource exhaustion | Rate‑limit slow / malicious clients |
Elevation of privilege | — | Unauthorised API use | RBAC and short‑lived tokens |
See the LINDDUN tutorial and the companion worksheet pack for step‑by‑step templates [1].
Resources:
This page is an example of RDMKit-compliant documentation created by Jorge Miguel Silva.
Original repository: federated_learning_page