
The road towards an integrated SecureDrop workstation - andrewdavidwong
https://securedrop.org/news/road-towards-integrated-securedrop-workstation/
======
forapurpose
Let's remember that their attackers include the most sophisticated in the
world, such as state intelligence agencies, sophisticated criminal
organizations, corporate intelligence, and others.

Just keep the air gap; anyone using this software can afford an extra
computer. Put the two machines next to each other; duct tape them together if
you want, or put two USB hubs on your desk - pull USB drive out of slot A, put
it in slot B. And put the USB stick shredder directly beneath slot B. Not hard
for the user: 1-2-3.

Even more importantly, it's critical that they communicate accurate
information, in an unmistakable way, about the level of security they provide.
Statements like these are troubling:

> Based on the threat model analysis, we will perform additional hardening of
> the prototype.

This implies they can actually protect their users against the attackers,
which is not reasonable.

> Thanks to the work of developer Joshua Thayer

There is no way that one developer can possibly, in a lifetime, provide
adequate security. You can't do it on the cheap. Joshua is facing multiple
attackers with budgets in the millions and billions and with teams of hundreds
or more specialists. He has my sympathies; will he get the blame when it
fails?

~~~
jlg23
In your proposed solution you are teaching the user how to work around the air
gap. What makes you think they do this responsibly?

Furthermore, your thread model is exaggerated. Yes, "they" have giant budgets.
No, "they" won't call in the cavallery in most cases because most cases are
simply not important enough to justify expenses beyond "an intern clicks
through the existing tools".

Finally, if you want real security, do as a farmer(!) friend of mine says:
Leave all electronics at home and go for a long walk with your source.

~~~
forapurpose
> Furthermore, your thread model is exaggerated. Yes, "they" have giant
> budgets. No, "they" won't call in the cavallery in most cases because most
> cases are simply not important enough to justify expenses beyond "an intern
> clicks through the existing tools".

Three thoughts:

1\. SecureDrop, like any security, has to work in the worst of circumstances,
not just the best.

2\. Governments are highly motivated to persecute journalists and their
sources. Even in the U.S., the home of the 1st Amendment, look at leak
investigations. SecureDrop is a very valuable target, an accidental honeypot
for leakers.

3\. Access to information before it's published can be extremely valuable.
People can take steps to counteract bad news and even embarrass the
journalists. And info that moves market prices in any significant way, whether
stocks, bonds, commodities, derivatives, currencies, etc. is worth many
millions, at least, and possibly billions.

------
amerine
> We fully recognize that the transition to a new user interface and a new
> operating system represents a significant potential burden for SecureDrop
> users.

I know I’m wrong about this, but deep down I don’t agree with this. I think
the world is always ready for some UX shenanigans.

------
21
Seems to me that if you actually need this kind of things, maybe you should
also have a cyber-security expert trusted friend and let him handle it.

There is no way a non-expert journalist would be able to use this securely,
too many failure modes.

------
Gaelan
While it may make sense as a simpler option for less security-critical stuff,
I don't think it will ever be as secure. The virtualization helps, but you are
still decrypting documents on an internet-connected machine.

------
cmurf
All the technical stuff is for the security and IT folks employed by media
companies, like Associated Press. The journalist would get a loaner laptop
equipped with this SecureDrop workstation from their org, this is not a do it
yourself thing.

I suspect you could have security levels, depending on your work and
preferences. I could see journalists out in the field without reliable
internet, so they need persistence for their working files. Others probably
can rely on secure connections, so nothing need be persistent.

In any case, I'd want a very straightforward "burn" feature that obliterates
persistent working files.

I already expect that history and cache and swap are not persistent, but as
history can be ready useful as part of working files I might want an option
how to handle it. Case by case.

