Visualization of the SecureDrop architecture

[garrettr]

Forking this from #249.

@aegis said:

Would be great to also present a graphic visualization of the SecureDrop system, like the 'Cryptocat Threat Model Connections Overview' image https://github.com/cryptocat/cryptocat/wiki/Threat-Model

[ageis]

I'm planning to do this; I just need to get Microsoft Visio 2013 running. The icons provided in 2007 are 16-bit ish and look like they're from the early 90s.

Update: Got Visio 2013 and working on it now.

[garrettr]

Awesome! I assume you're diagramming the current (0.x series) architecture. We also did some nice diagramming of the proposed 1.0 architecture in SF yesterday. I'll see if I can get some pictures of that online.

[ageis]

Yes, the current architecture. Here's the first revision.. aware I'm using a few different styles for icons here.. anyway, thoughts towards improving?

[ageis]

Updated:

[garrettr]

Can you move the note about how the application server is a THS to be above the icon? Now it seems to be confusingly associated with the "non-Tor" connection to the Monitor Server.

[ageis]

Ok, here is the latest:

[garrettr]

lgtm, @dolanjs what do you think?

[ageis]

Wonder if some orgs might use SFTP to upload to their websites. Think I may add that below HTTPS.

[dolanjs]

Been talking with Trevor with this I think we are starting to get into the same problem as with the deaddrop diagrams. that this one is too complicated for someone to see how the information gets from the source -> journalist -> publication. At the same time it doesn't have all the info a sec threat model diagram would have, or for network admins to build out the environment.

Think we need 3 sep diagrams: 1) One that strips out all the specifics and just shows the submitted doc data flow (the diagram in the the first audit I think was a good example for this) 2) Network diagram so orgs can prep a environment for it 3) A sec diagram that shows all the connections that happen

On Tue, Jan 28, 2014 at 5:58 PM, Garrett Robinson notifications@github.comwrote:

lgtm, @dolanjs https://github.com/dolanjs what do you think?

Reply to this email directly or view it on GitHubhttps://github.com/freedomofpress/securedrop/issues/274#issuecomment-33549436 .

[trevortimm]

I think we can still make this one work and then move on to getting the three diagram set up.

Kevin, can we put the two securedrop servers and the firewall in a box that's kind of shaded to represent that is SecureDrop itself? And can we also make the flow of the document from source to publication a different color than the rest of the branches? That line could also have arrows points in the direction it goes.

I think that would make it clearer for the layman.

Sent from my iPhone

On Jan 28, 2014, at 9:06 PM, dolanjs notifications@github.com wrote:

Been talking with Trevor with this I think we are starting to get into the same problem as with the deaddrop diagrams. that this one is too complicated for someone to see how the information gets from the source -> journalist -> publication. At the same time it doesn't have all the info a sec threat model diagram would have, or for network admins to build out the environment.

Think we need 3 sep diagrams: 1) One that strips out all the specifics and just shows the submitted doc data flow (the diagram in the the first audit I think was a good example for this) 2) Network diagram so orgs can prep a environment for it 3) A sec diagram that shows all the connections that happen

On Tue, Jan 28, 2014 at 5:58 PM, Garrett Robinson notifications@github.comwrote:

lgtm, @dolanjs https://github.com/dolanjs what do you think?

Reply to this email directly or view it on GitHubhttps://github.com/freedomofpress/securedrop/issues/274#issuecomment-33549436 .

— Reply to this email directly or view it on GitHub.

[ageis]

@trevortimm Sure thing. @dolanjs I think this is a good general overview of the environment. I agree we need those 3 but like Trevor said we can just use this one in the meantime. They each serve a different purpose and this one is more for the public rather than network admins or security people. I actually don't think it's too complicated currently. Once I color the publication flow like Trevor suggested that part should be clearer.

[ageis]

Ok, check this one out. I did some styling. I just have to fix the text readability/overlapping. Also arrow directions. Is the red color too strong?

[trevortimm]

Looking good! Can we get rid of the firewall and LAN? And then move the admin work station down a little bit (level with the news org website and public internet). And make the arrow pointing towards the app server point towards the journalist workstation instead so people know that's the direction data is flowing.

[ageis]

@trevortimm Here ya go.

[trevortimm]

Looks great. Let's give it a day and see if anyone else has comments.

On 1/28/14 7:57 PM, Kevin M. Gallagher wrote:

@trevortimm https://github.com/trevortimm Here ya go. securedrop15 https://f.cloud.github.com/assets/1161532/2026616/66c18b36-8899-11e3-8fc9-a57ca3859186.png

— Reply to this email directly or view it on GitHub https://github.com/freedomofpress/securedrop/issues/274#issuecomment-33554536.

[trevortimm]

Two more little things: Can we move the hard drive so it's in the airgap box, connected to the SVS? Also, can you put undernearth the SVS "(Running Tails)" and same thing under the Journalists Workstation instead of "w/ Tails"?

[ageis]

No problem.

[fpietrosanti]

@ageis @trevortimm Is realistic for a mid-traffic leaksite that the journalist will: a) download the "leak" from "jornalist workstation" b) save it to usb key c) load usb key to another different computer (airgapped) d) boot the airgapped computer e) decrypt the leak on the airgapped computer (the leak may contain garbage 90% of time, the remaining ones will need information to be verified online just to understand if those are true) f) works for fact-checking on a different non-secure computer (de-facto revealing what's the leak is about if this is compromised) g) extract the redacted documents (having already worked)

I find this workflow to be very inefficient and unrealistic to be followed during time by journalists (that are on the run, have strict time, have many things to do), especially regarding the expectation of the work to be done on the SVS/Airgap.

[ageis]

You raise good points that are being echoed by some others, but this isn't the issue for discussion of that. I think it's important to recognize that we are modeling for the most advanced possible adversary that is willing to do anything to prevent embarrassing information from getting out. That is the realistic threat environment so the security model for journalists working on this must also be realistic. I'd expect nothing less. Frankly, adversarial or investigative journalists who don't learn air-gapping and decryption plus digital security practices in depth will be left behind in the 20th century. When you are dealing with risks that could put sources away for life I don't think it's worth it to lower security for the sake of making things easier. That said, it would be nice if there were less steps. Unless you have suggestions about the visualization, open a new issue about the inefficiency of the workflow.

[fpietrosanti]

@ageis Well, from the visualization point of view, like we're doing at globaleaks, you should probably start already differentiating the real (that happen in real-life, aside from the documentation) threat model, in order to show up the different way of use. So, in the visualization i would suggest to provide also a process that completely skip this 3 different computers for the journos and all of the usb-key and just provide a plain workflow and procedures. I'm just suggesting to avoid providing a complicated architecture that, in the end-user hands, it's unlikely to happen but to provide different "gradient of security" in the opsec procedures, considering also the busy journalists that will just not follow it.

[ageis]

Simplified by request.

[garrettr]

@aegis This looks great! We're going to give a talk at Twitter tomorrow and will be using these diagrams :grinning:

[garrettr]

Let's finish this up! @ageis, I like both of the last two diagrams you posted. I'd like to keep them both. The last one is clearer for people who just want to see the flow of information from source to journalist, but the previous one is nice because it makes you aware of the opsec concerns for involved parties.

Can you make the following minor fixes and we'll merge it?

1. Use a slightly less intense red :grin:
2. Fix the text overlap problems

Thanks for all of your work on this! It is not the be all and end all, but it is a good representation of the current architecture and will help us explain and reason about it.

[jacksingleton]

I know someone non-technical that wants to help out, would making these minor fixes be useful?

If so I think we'd just need the visio doc, and any other recommendations.

[ageis]

Here are links to the Visio 2013 file for both versions.

https://ageispolis.net/test/SecureDrop_simple.vsdx https://ageispolis.net/test/SecureDrop_complex.vsdx

[Hainish]

@jacksingleton this is marked as Ready for Review in Trello. Is there any update on this?

[garrettr]

So this is pretty close to completion. I think the current diagrams in this issue are good, with a preference for the SecureDrop_complex diagram since it shows everything. To merge, we need to put this stuff in the repo in a sensible and useful way. At a minimum, we should:

1. include a rendered version of the diagram (.png format, ideally with a transparent background so it's more flexible to use in presentations and on websites)
2. include the original source file (.vsdx) so it can be edited/updated in the future.

Additionally, while I think these diagrams are good, I do not like the fact they were created in Microsoft Visio. A quick Google search shows that this program is proprietary, only available for Windows, and has no good compatible alternative on other platforms. Ideally, we would convert/export these files to a format that can be easily edited by anyone. @dolanjs has been having success doing flowcharts with draw.io, so that might be a good thing to try to port them to.

[garrettr]

@ageis Can you resolve this? It's almost done, see the previous comment for what remains to be done. Low priority.

[ageis]

Visio does run on Wine, so with the exception of OSX then the need for a license would be a primary compatibility blocker. Also it seems that .vsdx is an XML-based file format (.vsd was binary) and Microsoft is working on making it accessible to developers. Anyhow, I keep a VM for the purpose of editing this, and I didn't have any luck opening it in draw.io, so think we can stick with it for now. One of the only alternatives that I think can match the quality of Visio might be Lucidchart, which we could try later.