Data protection vulnerability in Source interface mitigated
THREAT12
· Mitigated: Controls in place bring the risk down to an acceptable level.
· Defined in catalog.py:219
- Risk
- Medium impact × Low likelihood = 4 medium
- After mitigations
- Medium impact × Low likelihood = 4 medium (unchanged)
Improper data protection may lead to information being leaked by the client.
Threat actors: Any
Mitigations
| Mitigation | Status |
|---|---|
| Secure Temporary Wrapper to stream submissions encrypted on disk MITIG69 | implemented |
| Use of strong encryption key for encrypted documents MITIG11 | implemented |
| Logging off for source interface MITIG41 | implemented |
| Source interface: Cache-Control nostore MITIG204 | implemented |
| Sensitive data sent in POST requests MITIG205 | implemented |
Possible further mitigations
- e2e encryption MITIG140 proposed
- Round timestamps of files MITIG211 proposed
Where it applies
Applies to 1 component in 2 scenarios.
Source submission · Source Interface
Supply chain and dependencies · Source Interface
Notes
Existing mitigations: All are encrypted at rest using GPG with the airgapped submission key once the requests hits the server (MITIG69, MITIG11). Sensitive information (source information, submission information) is not logged (MITIG41). Cache-control header set to "no-store" (MITIG204). All sensitive data is sent through HTTP POST (MITIG205). Further mitigations: Disable autocompletion for source codename. End-to-end encryption of submissions either through or SecureDrop application in Tails/Tor Browser (MITIG140). Timestamps on files could be rounded: https://github.com/freedomofpress/securedrop/issues/822 (MITIG211). Automated test for mitigation: Yes.
How this threat is matched
Listed for these components. A boundary covers every component inside it.