diff --git a/docs/index.rst b/docs/index.rst index a05c4610e4..401f614913 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -143,3 +143,4 @@ anonymous sources. threat_model/threat_model.rst threat_model/dataflow.rst + threat_model/mitigations.rst diff --git a/docs/threat_model/mitigations.rst b/docs/threat_model/mitigations.rst new file mode 100644 index 0000000000..63083f8dfb --- /dev/null +++ b/docs/threat_model/mitigations.rst @@ -0,0 +1,236 @@ +Attacks and Countermeasures on the SecureDrop Environment +========================================================= + +SecureDrop is a complex ecosystem comprised of various pieces of hardware, a +diverse codebase, multiple user roles, and varied software dependencies. As +such, an adversary can compromise any one of these components through a variety +of attacks, as detailed below. We’ve categorized attacks and countermeasures by +SecureDrop architecture area for clarity. + +There are certain attacks that cannot be mitigated by any of the technical or +operational countermeasures built into SecureDrop. Attacks of a political nature +— for example, if a source, journalist, or organization is threatened with legal +action — are context-dependent, and determined by an ever-shifting climate +around press freedoms. While these attack vectors are out of the scope of this +document, they should be factored in to any organization’s threat model with +regional and political specificity. + +Application Code — SecureDrop Repository/Release +------------------------------------------------ + +Attacks to the Application Code — SecureDrop Respository/Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Malicious code introduced in SecureDrop repository +- Malicious code introduced in SecureDrop release +- Failure to encrypt submissions as they are written to disk + +Countermeasures on the Application Code — SecureDrop Repository/Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Code (git tags) and releases (packages uploaded to apt) are signed with the airgapped signing key +- Protection is placed on master and develop branch on GitHub +- For SecureDrop Developers, 2-factor authentication is mandated on GitHub +- Community trust is built through 3 trusted code owners and code reviews + +Application Code — *Source Interface* and *Journalist Interface* +---------------------------------------------------------------- + +Attacks to the Application Code — *Source Interface* and *Journalist Interface* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Configuration vulnerability in *Source* or *Journalist Interface* +- Lack of segmentation between *Source* and *Journalist Interface* +- Session management vulnerability in *Source* or *Journalist Interface* +- Malicious input vulnerability in *Source* or *Journalist Interface* +- Configuration vulnerability in *Source* or *Journalist Interface* +- Authentication vulnerability in *Source* or *Journalist Interface* +- Access control vulnerability in *Source* or *Journalist Interface* +- Data protection vulnerability in *Source* or *Journalist Interface* +- Communications vulnerability in *Source* or *Journalist Interface* +- Error handling and logging vulnerability in *Source* or *Journalist Interface* +- HTTP security configuration vulnerability in *Source* or *Journalist Interface* +- File and resource vulnerability in *Source* or *Journalist Interface* +- Business logic vulnerability in *Source* or *Journalist Interface* +- Web services vulnerability in *Source* or *Journalist Interface* + +Countermeasures on both *Source* and *Journalist Interfaces* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- *Interfaces* run on an end-to-end encrypted Tor hidden service +- Sensitive source and submission data is sent through HTTP POST +- All source submissions are encrypted with GPG at rest using the airgapped submission key +- *Interface* sessions are invalidated after a user logs out or inactivity over 120 minutes +- Session control on *Interface* includes CSRF token in Flask Framework +- All *Interface* session data (except language and locale selection) is discarded at logout, and fully deleted upon exiting the Tor Browser +- A number of mitigations are in place as protection against malicious input vulnerabilities on the Source and Journalist Interfaces: + + - X-XSS-PROTECTION is enabled + - Content-Security-Policy is set to self + - SQLAlchemy is used as ORM for all database queries + - Application does not execute uploaded submission data +- A number of mitigations are in place as protection against the risk of an HTTP misconfiguration on the *Source* and *Journalist Interfaces*: + + - Cache control header is set to “no store;” + - HTTP headers do not expose version information of system components + - X-Content-Type is set to "nosniff;" + - Content-Security-Policy is set to "self;" + - X-XSS-Protection is set to "1" + +Countermeasures unique to *Source Interface* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- TLS on *Source Interface* is opt-in with an EV cert +- Only HTTP GET, POST and HEAD methods are allowed +- A number of mitigations are in place as protection against access control vulnerabilities on the *Source Interface*: + + - Source codenames are long and automatically generated + - Hashed codenames are stored in a database hashed with a unique salt + - Source codename reset functionality is not available + - Source login does not display information about prior submissions + - Source login requires 7-word codename to check *Source Interface* for replies + +Countermeasures unique to *Journalist Interface* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- *Journalist Interface* is located behind an authenticated hidden service and only privileged users have required authorization token +- Only HTTP GET, POST, HEAD and DELETE methods are allowed +- A number of mitigations are in place as protection against access control vulnerabilities on the *Journalist Interface*: + + - Apache autoindex module is disabled + - Journalist/Admin passphrases are long and automatically generated + - Passphrases are stored in a database hashed with a unique salt + - Account generation/revocation/reset is restricted to Admin role + - Two-factor authentication is required through a TOTP token or a Yubikey + +*Application Server* and *Monitor Server* +----------------------------------------- + +Attacks on the *Application Server* and *Monitor Server* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- *Application* or *Monitor Server* configuration error +- *Source* or *Journalist Interface* is framed +- *Application* or *Monitor Server* is compromised +- Attacker exploits postfix +- Known vulnerabilities in the Linux kernel or packages used by app/mon servers + +Countermeasures on Both *Application* and *Monitor Servers* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Grsecurity/PaX linux patches prevent the exploitation of certain memory-corruption attacks +- AppArmor profiles further reduce process capabilities through Mandatory Access Control +- All SecureDrop infrastructure is provisioned via infrastructure-as-code (Ansible scripts) +- A cron job ensures that automatic nightly security updates are applied for OS packages +- *Journalist Interface* uses ATHS cookie +- *Monitor Server* should only expose SSH via Tor hidden service. All other traffic should be blocked by firewall + +Countermeasures Unique to *Application Server* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- SecureDrop *Source* and *Journalist Interfaces* uses X-Frame-Options: DENY header +- Browser Same Origin Policy should prevent the SecureDrop page from trivial modifications, but more complex attacks are mitigated via the X-Frame-Options: DENY HTTP header + +Countermeasures Unique to *Monitor Server* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- OSSEC is used for intrusion detection/file integrity monitoring, and are sent to Admins via end-to-end encrypted email + +SecureDrop Dependencies — Python, Tor, Linux Kernel, apt, Tails, Ubuntu, or Hardware Firewall Vulnerabilities +------------------------------------------------------------------------------------------------------------- + +Attacks on SecureDrop Dependencies +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Known vulnerabilities in Python or libraries used by SecureDrop +- Known vulnerabilities in Tor (incl. Onion Service cryptography, authentication) +- Malicious apt package installed at install-time or during updates +- Known weakness in hidden service cryptography +- Github is compromised +- Firewall is not up-to-date +- Tails ISO malicious +- Ubuntu ISO malicious +- Tor apt repo compromised +- Ubuntu apt repo compromised +- Tor Browser exploit +- Vulnerabilities/Compromise of Hardware Firewall + +Countermeasures Against Vulnerabilities in Python or Libraries +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- FPF performs vulnerability management for all Python packages used by SecureDrop +- CI will run safety check to ensure dependencies do not have a CVE associated with the `version `__ + +Countermeasures Against Vulnerabilities in Tor +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- A cron job ensures that automatic nightly security updates are applied for OS packages, including Tor +- Grsecurity/PaX linux patches prevent the exploitation of certain memory-corruption attacks +- AppArmor profiles further reduce process capabilities through Mandatory Access Control +- Hidden Service authentication is used as a complementary authentication and only used for defense-in-depth/attack surface reduction + +Countermeasures Against Malicious apt Installs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- apt does GPG signature verification of all packages as long as it's not explicitly disabled + +Countermeasures Against Malicious Tails or Ubuntu ISOs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- SecureDrop `Admin Guide `__ instructs Users/Admins to validate checksum/signatures of downloaded images + +Countermeasures Against Vulnerabilities in the Hardware Firewall +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- SecureDrop `Admin Guide `__ informs administrators to update the hardware firewall and provides a very restrictive policy for accessing the administrative interface (blocked on app and mon ports of the firewall). +- Alert emails are sent out to admins when there are critical pfSense vulnerabilities. +- *Application* and *Monitor Servers* use IPTables as host-based firewall for defense-in-depth +- All application traffic is over Tor Hidden services (end-to-end encrypted) and all software packages are signed. Only DNS and NTP are transmitted over HTTP (unauthenticated and in cleartext) + +Network Infrastructure — FPF Infrastructure or Organization Corporate Network +----------------------------------------------------------------------------- + +Attacks on Network Infrastructure +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Landing Page source control is compromised +- Landing Page host is compromised +- Landing Page is framed or unavailable +- Landing Page DNS leaks from SecureDrop/leaks-related subdomain +- Communications vulnerability in *Source* or *Journalist Interface* +- DNS requests to news organization's subdomain for SecureDrop Landing Page, Freedom.press, torproject.org Tor activity, SD submissions may be correlated +- SecureDrop.org is compromised +- User web traffic to SecureDrop Landing Page uses CDN and may be logged +- Tor network exploit +- apt server man-in-the-middle used to serve old or malicious packages +- SecureDrop apt servers are compromised, or apt server man-in-the middle attack injects malicious packages +- News Organization network is compromised +- OSSEC and/or Journalist alert SMTP account credentials compromised +- OSSEC and/or Journalist alert private key compromised +- SMTP relay compromised +- Admin's network is monitored + +Countermeasures in FPF Infrastructure +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Builds are independently validated by multiple developers +- Release files containing hashes (MD5, SHA1, SHA256, SHA512) of package file and package hashes are signed with an airgapped GPG key +- Developer key list is published and GPG-signed with the directory key +- SecureDrop updates are packaged in a .deb file and served through FPF's apt repo +- Source code is validated/verified before packaging and signing the .deb + +Countermeasures in News Organization Corporate Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- SecureDrop environment should be strictly segregated from corporate environment +- Most SecureDrop application traffic goes over Tor and as such is encrypted end-to-end +- Alert emails to Journalists and Admins are GPG-encrypted (but not signed) to provide confidentiality +- OSSEC alerts are scrubbed for sensitive contents (application data, server IPs) +- Documented deployment best practices provide instructions to strengthen Landing Page security and privacy + +User Behavior and Hardware — SecureDrop Hardware Tampering or Failure in Operational Security +--------------------------------------------------------------------------------------------- + +Attacks on User Behavior or Hardware +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- Journalist corporate workstation seized/tampered/compromised +- Transfer device seized/stolen/lost +- Admin workstation backup stick is compromised +- Admin two-factor authentication device is lost or compromised +- Admin SSH Key is compromised +- SecureDrop installer misconfigures server/firewall hardware +- Source uses tor2web or employer/corporate device +- Source shares that they are using SecureDrop/leaking documents +- Journalist/Admin gets phished from a submission or otherwise breaks the SVS airgap with malware + +Countermeasures in User Behavior Recommendations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- `Source Guide `__ gives instructructions on best practices for the entire submission workflow +- Source interface banner suggests that user disables JS (high security settings in Tor Browser) +- `Journalist Guide `__ informs users of malware risks, the importance of strict comparmentalization of SecureDrop-related activities +- `SecureDrop Deployment Guide `__ gives best practices for proper administration of the SecureDrop system, and its public-facing properties like the Landing Page +- `Admin Guide `__ gives instructions for long-term maintenance of the technical properties of the SecureDrop system, as well as operations to support Journalists +- All Admin tasks are completed over Tor/Tor authenticated hidden services after installation +- Any Journalist/Admin password/2FA token resets can only be done by an Admin with password-protected SSH capability or authenticated hidden service credentials. +- Persistent storage on the Admin Workstation is protected with LUKS/dm-crypt encryption diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst index 4e836ba374..e578368c14 100644 --- a/docs/threat_model/threat_model.rst +++ b/docs/threat_model/threat_model.rst @@ -5,22 +5,117 @@ This document outlines the threat model for SecureDrop 0.3 and is inspired by a `document Adam Langley wrote for Pond `__. The threat model is defined in terms of what each possible adversary -can achieve. This document is still a work in progress. If you have +can achieve. This document is always a work in progress. If you have questions or comments, please open an issue on GitHub or send an email to securedrop@freedom.press. +Actors +------ + +The SecureDrop ecosystem comprises a host of actors, organzed by the following high-level categories: :ref:`Users `, :ref:`Adversaries `, and :ref:`Systems `. + +.. _users: + +Users +~~~~~ + +The following table of the users who interact with the SecureDrop web application. +Note that the airgapped SVS with the GPG submission key is required to decrypt +submissions or messages. + ++------------------+----------+-------------------------------------------------+ +| User Type | Trust Level | ++==================+============================================================+ +| Source | * Submit a document or message | ++------------------+------------------------------------------------------------+ +| Recurring source | * Submit another document or message | +| | * Read replies | ++------------------+------------------------------------------------------------+ +| Journalist | * Download *all* gpg-encrypted documents from *all* sources| +| | * Download *all* gpg-encrypted messages from *all* sources | +| | * Reply to *all* sources | ++------------------+------------------------------------------------------------+ +| Admin | * Download *all* gpg-encrypted documents from *all* sources| +| | * Download *all* gpg-encrypted messages from *all* sources | +| | * Reply to *all* sources | +| | * Change the SecureDrop instance logo | +| | * SSH and root privileges on `app` and `mon` servers | ++------------------+------------------------------------------------------------+ + +.. _adversaries: + +Adversaries +~~~~~~~~~~~ + +We consider the following classes of attackers for the design and +assessment of SecureDrop: + ++------------------+----------+-------------------------------------------------+ +| Adversary | Capabilities | ++==================+============================================================+ +| Nation State / | * Large scale, full-packet network capture | +| Law Enforcement /| * Active network attacks | +| Global Adversary | * Advanced attacks on infrastructure | +| | * Hardware and software implants for persistence | +| | * Cryptanalysis | +| | * Exploitation of unknown vulnerabilities | ++------------------+------------------------------------------------------------+ +| Large Corporation| * Limited network capture | +| | * Some targeted attacks on infrastructure | +| | * Use of known vulnerabilities | +| | * Mostly limited to software-based attacks | ++------------------+------------------------------------------------------------+ +| Internet Service | * Full network capture | +| Provider | * Mostly limited to network-based attacks | ++------------------+------------------------------------------------------------+ +| User Error | * Source, Journalist, Administrator or Developer error | ++------------------+------------------------------------------------------------+ +| Dedicated | * Use of known vulnerabilities | +| Individual | * Mostly limited to software-based attacks | ++------------------+------------------------------------------------------------+ + +.. _systems: + +Systems +~~~~~~~ + +For more information about the various systems involved in a SecureDrop +deployment, please visit the :doc:`hardware section <../hardware>`. + ++------------------+----------+-------------------------------------------------+ +| System | Description | ++==================+============================================================+ +| Hardware Firewall| * Dedicated Hardware Firewall | +| | * pfSense-based | +| | * 3 Interfaces: `app`, `mon` and `admin` | ++------------------+------------------------------------------------------------+ +| Application | * SecureDrop Source Interface | +| Server | * SecureDrop Journalist Interface | +| | * SSH Server | +| | * Ossec Client | ++------------------+------------------------------------------------------------+ +| Monitor Server | * Ossec Server | +| | * SSH Server | ++------------------+------------------------------------------------------------+ +| Journalist/Admin | * Internet-connected laptop | +| Workstation | * Tails USB with persistence volume | ++------------------+------------------------------------------------------------+ +| Secure Viewing | * Airgapped and stripped-down laptop | +| Station (SVS) | * Tails USB with persistence volume | ++------------------+------------------------------------------------------------+ + Assumptions ----------- +The following assumptions are accepted in the threat model of every SecureDrop project: + Assumptions About the Source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- The source acts reasonably and in good faith, e.g. if the user were - to give their codename or private key material to the attacker that - would be unreasonable. +- The source acts reasonably and in good faith, e.g. if the source were to give their credentials or private key material to the attacker that would be unreasonable. - The source would like to remain anonymous, even against a forensic attacker. -- The source obtains an authentic copy of Tails or the Tor Browser. +- The source obtains an authentic copy of Tails and the Tor Browser. - The source follows our :doc:`guidelines <../source>` for using SecureDrop. - The source is accessing an authentic SecureDrop site. @@ -101,12 +196,43 @@ Assumptions About the World - The security/anonymity assumptions of Tor and the Hidden Service protocol are valid. - The security assumptions of the Tails operating system are valid. +- The security assumptions of SecureDrop dependencies, specifically + Ubuntu, the Linux kernel, application packages, application dependencies + are valid. -Attack Scenarios ----------------- +Other Assumptions or Factors +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -What the *Application Server* Can Achieve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- The level of press freedom may vary in both geography and time. +- The number of daily Tor users in a country can + `greatly vary `__. + +Assets +------ + ++------------------+----------+-------------------------------------------------+ +| Asset Type | Asset | ++==================+============================================================+ +| Assets relating | * Login details | +| to SecureDrop | * Encryption key(s) | +| users | * SSH details | ++------------------+----------+-------------------------------------------------+ +| Assets relating | * Access to documents via server | +| to the publicly | * Access to documents via Journalist Interface | +| accessed system | * Access to admin privileges via Journalist Interface | +| | * Access to user alerts, support tickets | ++------------------+----------+-------------------------------------------------+ +| Assets relating | * SecureDrop code manipulation | +| to the | * Dependency code manipulation | +| underlying | | +| system | | ++------------------+----------+-------------------------------------------------+ + +Implications of SecureDrop Area Compromise +------------------------------------------ + +What a Compromise of the *Application Server* Can Surrender +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - The server sees the plaintext codename, used as the login identifier, of every source. @@ -115,8 +241,15 @@ What the *Application Server* Can Achieve - The server sees the plaintext submissions of every source. - The server sees the plaintext communication between journalists and their sources. +- The server stores the Tor Hidden Service private key for the source interface. +- The server stores the Tor Hidden Service private key and ATHS token for the + Journalist interface. +- The server stores and (optional) TLS private key and certificate (if HTTPS + is enabled on the source interface) - The server stores hashes of codenames, created with scrypt and randomly-generated salts. +- The server stores journalist password hashes, created with scrupt and + randomly-generated salts, as well as TOTP seeds. - The server stores only encrypted submissions and communication on disk. - The server stores a GPG key for each source, with the source's @@ -132,8 +265,8 @@ What the *Application Server* Can Achieve - The server can connect to the *Monitor Server* using an SSH key and a passphrase. -What the *Monitor Server* Can Achieve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +What a Comprommise of the *Monitor Server* Can Surrender +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - The server stores the plaintext alerts on disk, data may also reside in RAM. @@ -151,8 +284,8 @@ What the *Monitor Server* Can Achieve - The server can connect to the *Application Server* using an SSH key and a passphrase. -What the Workstations Can Achieve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +What a Compromise of the Workstations Can Surrender +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - The *Admin Workstation* requires Tails with a persistent volume, which stores information such as GPG and SSH keys, as well as a @@ -169,8 +302,8 @@ What the Workstations Can Achieve GPG key, as well as a :doc:`database with the passphrase <../passphrases>` for that key. -What a Compromise of the Source's Property Can Achieve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +What a Compromise of the Source's Property Can Surrender +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Use of `the Tor Browser will leave traces `__ @@ -202,8 +335,8 @@ What a Compromise of the Source's Property Can Achieve - See any replies from journalists that the source has not yet deleted. -What a Physical Seizure of the Source's Property Can Achieve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +What a Physical Seizure of the Source's Property Can Surrender +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Document use of Tor or Tails, but not necessarily research into SecureDrop @@ -229,7 +362,7 @@ What a Physical Seizure of the Source's Property Can Achieve volume, password database, and two-factor authentication device will allow the attacker to access both servers and the *Journalist Interface*. -What a Compromise of the Admin's Property Can Achieve +What Compromise of the Admin's Property Can Surrender ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - To access the *Journalist Interface*, the *Application Server*, or the @@ -321,7 +454,7 @@ What a Compromise of the Journalist's Property Can Achieve - To access the *Journalist Interface*, the attacker needs to obtain the journalist's login credentials and the journalist's two-factor - authentication device. Unless the attacker has physical access to the + authentication device or seed. Unless the attacker has physical access to the server, the attacker will also need to obtain the Hidden Service value for the Interface. This information is stored in a password-protected database in a persistent volume on the @@ -348,6 +481,8 @@ What a Compromise of the Journalist's Property Can Achieve - Download, but not decrypt, submissions. - Delete one or more submissions. - Communicate with sources. + - If the journalist has admin privileges on SecureDrop, they can create new + journalist accounts. What a Physical Seizure of the Journalist's Property Can Achieve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -411,7 +546,8 @@ What a Physical Seizure of the *Application Server* Can Achieve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the *Application Server* is seized, the attacker will be able to - view any and all unencrypted files on the server. This includes all + view any and all unencrypted files on the server. An attacker will be able + to modify any and all files on the server. This includes all files in use by the SecureDrop Application. If the server is seized while it is powered on, the attacker can also analyze any plaintext information that resides in RAM. The attacker can also tamper with @@ -434,7 +570,9 @@ What a Compromise of the *Monitor Server* Can Achieve - An attacker with access to the **ossec** user can: - - ??? + - View all ossec logs and alerts on disk. + - Modify the ossec configuration. + - Send (or suppress) emails to administrators and journalists. - An attacker with access to the **root** user can: @@ -452,6 +590,9 @@ What a Physical Seizure of the *Monitor Server* Can Achieve in use by OSSEC. If the server is seized while it is powered on, the attacker can also analyze any plaintext information that resides in RAM. The attacker can also tamper with the hardware. +- If the *Monitor Server* is no longer online or tampered with, this will + have an effect on the quantity and accuracy of notifications sent to + admins or journalists. What a Compromise of the *Secure Viewing Station* Can Achieve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -470,6 +611,8 @@ What a Compromise of the *Secure Viewing Station* Can Achieve documents. - View, modify, and delete encrypted--and possibly also decrypted submissions--if the Transfer device is in use. + - Export the SecureDrop submissions GPG private key (unless there is a + passphrase set). What a Physical Seizure of the *Secure Viewing Station* Can Achieve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~