|
|
@@ -0,0 +1,231 @@ |
|
|
|
Title: Security for the savvy leftist, Part Ⅰ: OpSec |
|
|
|
Date: 2020-05-14T19:21-04:00 |
|
|
|
Author: Wxcafé |
|
|
|
Slug: security_for_the_savvy_leftist_part_Ⅰ_opsec |
|
|
|
Header_Cover: https://pub.wxcafe.net/img/opsec_cover.jpeg |
|
|
|
|
|
|
|
Introduction |
|
|
|
============ |
|
|
|
|
|
|
|
This is the first in a series of post trying to give a few pointers and share a |
|
|
|
bit of knowledge on securing your online presence and activism, targeted at |
|
|
|
leftists. |
|
|
|
|
|
|
|
The motivation behind this series is my own observation of the lack of technical |
|
|
|
security education and/or interest in leftists circles in the US, and the |
|
|
|
anxious feeling that it's direly needed. |
|
|
|
|
|
|
|
These posts are to be considered in the current political context, and also |
|
|
|
taken with a grain of salt, as I'm not a security professional and while I do |
|
|
|
have some security knowledge, it is not my primary field of expertise. |
|
|
|
|
|
|
|
Anyway, here goes |
|
|
|
|
|
|
|
--- |
|
|
|
|
|
|
|
OPSec |
|
|
|
===== |
|
|
|
|
|
|
|
So, OpSec (operation security) is a very generic concept referring to |
|
|
|
identifying what information is important or even critical to the security of |
|
|
|
your operation, how it is potentially exposed to your adversary, how to |
|
|
|
protect it from that adversary, and finally putting all of that into practice by |
|
|
|
changing the organization of your operation to reduce the exposure to your |
|
|
|
adversary. |
|
|
|
|
|
|
|
That's all pretty abstract so far, but basically you can think about it like this: |
|
|
|
|
|
|
|
- Who's my enemy |
|
|
|
- What must they absolutely not know |
|
|
|
- How can they currently learn that |
|
|
|
- How can I prevent them from doing that |
|
|
|
- Fix the issue, rinse and repeat |
|
|
|
|
|
|
|
Who's my enemy |
|
|
|
-------------- |
|
|
|
|
|
|
|
The purpose of this question isn't to point at specific people, but rather to |
|
|
|
understand what the scope of the potential attacks you're facing are. If you're |
|
|
|
organizing a tenant union, your enemy is the landlord, and there's not much they |
|
|
|
can do to attack your organization. If you're planning revolutionary action on |
|
|
|
the US government, your enemy is the entire US government and all of its defense |
|
|
|
branches, which can definitely come after you, in depth, and they *will*, and |
|
|
|
you'd better be ready — if it's even possible to be ready for that situation, |
|
|
|
lots of revolutions have failed even without having the full attention of the |
|
|
|
American empire... |
|
|
|
|
|
|
|
But the point is that the degree to which you're exposed, and the type of |
|
|
|
response you'll need to take, depends a lot on who your adversary is and what |
|
|
|
kind of resources they have access to (and are willing to use against you). |
|
|
|
|
|
|
|
What must they absolutely not know |
|
|
|
---------------------------------- |
|
|
|
|
|
|
|
This one should be obvious. If your adversary knows this, your operation is a |
|
|
|
bust, all your efforts were for nothing, and you might be facing repercussions. |
|
|
|
To keep going with the examples from the previous point, if the landlord knows |
|
|
|
you're the one who's organizing the tenant union, they'll find a pretext to |
|
|
|
evict you, and then you've been organizing for nothing and you're out of a place |
|
|
|
to sleep. Of course the other example has worse outcomes (i.e. torture or death) |
|
|
|
but the concept is the same. |
|
|
|
|
|
|
|
Sometimes though, your adversary knows your identity and your organizing against |
|
|
|
them is public, yet they can't do anything from just these informations. There |
|
|
|
are still things that they can learn that would compromise your efforts. Find |
|
|
|
out what they are. |
|
|
|
|
|
|
|
--- |
|
|
|
|
|
|
|
**The answers to these two questions ("who's my enemy" / "what must they absolutely |
|
|
|
not know") is known as your *threat model*, and it's what you're going to use to |
|
|
|
tighten your security by identifying what are your current problems and what |
|
|
|
measures are necessary to fix these.** |
|
|
|
|
|
|
|
--- |
|
|
|
|
|
|
|
How can they currently learn that |
|
|
|
--------------------------------- |
|
|
|
|
|
|
|
How are you exposed? That's a trick question, of course, because if you knew |
|
|
|
you'd have fixed it already, but there a few avenues of exposure that are easy |
|
|
|
to explore and hopefully solve. |
|
|
|
|
|
|
|
First of all, you could have an involuntary leak. Someone wasn't careful enough |
|
|
|
about where they were talking about something, or published something they |
|
|
|
shouldn't have, and now it's been exposed (and by that I don't mean your |
|
|
|
adversary knows it for sure, I mean it has been exposed in a place where your |
|
|
|
adversary *could* have seen it. That's enough to be considered a leak). That's |
|
|
|
human error, and while it will always exist, there's ways to reduce the |
|
|
|
probability of it happening. This is the most common type of leak. |
|
|
|
|
|
|
|
Second, you could have a member of your organization voluntarily leaking |
|
|
|
information. It could be because they're being blackmailed, corrupted, or |
|
|
|
they've just been flipped, or it could be someone who's infiltrating your org... |
|
|
|
either way, these are harder to work around, because... well, because they're |
|
|
|
actively hostile. This is way less common, and mostly happens if you have |
|
|
|
powerful adversaries (like always, your threat model should tell you what to |
|
|
|
worry about) |
|
|
|
|
|
|
|
Finally, you could have a leak that's not within your organization. The company |
|
|
|
you're using to chat got hacked and all your messages are suddenly public. Your |
|
|
|
storage space got broken into and documents are missing. Your Internet service |
|
|
|
provider is just giving all of your data to the government. These things happen, |
|
|
|
and you can fight them by running your own tech services and securing your data |
|
|
|
properly, but this is honestly the least common avenue for an adversary. Once |
|
|
|
again, trust your threat model. |
|
|
|
|
|
|
|
How can I prevent them from doing that |
|
|
|
-------------------------------------- |
|
|
|
|
|
|
|
The first and most effective line of defense against potential information leaks |
|
|
|
in your organization is to **not give the information in the first place**. |
|
|
|
Always think of OPSec in two layers: there's your opsec as an individual, and |
|
|
|
then there's your organizational opsec. If you found that your name is |
|
|
|
compromising, then use a nickname or a fake name in your organization. If your |
|
|
|
address is compromising, don't tell people where you live, and don't take them |
|
|
|
back there! Of course, this means not giving anyone access to any online profile |
|
|
|
where your real name or address is, never letting anything slip, not letting |
|
|
|
anyone see your ID, etc. |
|
|
|
|
|
|
|
This is basically creating a new, separate identity, which you will use |
|
|
|
exclusively in the context of the organization. This isn't always easy, but it |
|
|
|
can be necessary in some cases, and it's always very effective. |
|
|
|
|
|
|
|
Not giving information isn't only a tool to protect yourself, though. It can |
|
|
|
also be a tool inside your organization. The group that works on action A |
|
|
|
doesn't necessarily need to know about action B. Segment information, it keeps |
|
|
|
everyone safer. Keep groups small: if you need to, coordinate multiple small |
|
|
|
groups rather than making a large one, with a single person in each group in |
|
|
|
charge of coordination. That way, no-one knows everyone. Take whatever |
|
|
|
precautions are warranted by your threat model. |
|
|
|
|
|
|
|
Of course, some information you need to share as a matter of running your org. |
|
|
|
In these cases, the next step in defending against potential information leaks |
|
|
|
in your organization is its cohesion. If everyone is close to everyone else, not |
|
|
|
only will everyone be more careful (which is important for accidental data |
|
|
|
leak), but it'll also be very hard to corrupt/blackmail/flip one of your |
|
|
|
members, and even harder to infiltrate your organization. Remember, OPSec is not |
|
|
|
a tech concern, it's a social concern. Find out who in your movement is |
|
|
|
vulnerable, and take care of them. Think about your onboarding process, how much |
|
|
|
you evaluate potential members, and how you start sharing information with them. |
|
|
|
Without falling into paranoia, not telling every detail of your actions at |
|
|
|
meetings with people you don't know might be a good idea, depending on your |
|
|
|
threat model (like everything else). |
|
|
|
|
|
|
|
Your next line of defense should be making it hard to fail. Your processes |
|
|
|
need to make it clear when sharing information is OK, and who with. You need to |
|
|
|
establish clear communication lines inside your organization that are safe and |
|
|
|
dedicated to a subgroup/action. Once again, this isn't about tech, the best |
|
|
|
encryption won't help you if someone who works for your adversary is added to |
|
|
|
the group chat about your action plan. At any point, it should be clear for |
|
|
|
anyone in your organization how they can communicate with other members, and |
|
|
|
what they can say on which channel. Separate messaging groups for different |
|
|
|
projects are a good start, but there needs to be enforcement of the separation |
|
|
|
(meaning reminding people when they start talking about sensitive stuff on the |
|
|
|
misc channel), and deliberation before including someone in the group. |
|
|
|
|
|
|
|
Finally, there's damage control. Once something *has* been leaked, you need to |
|
|
|
have provisions in place to keep your operation going as well as possible. If |
|
|
|
the leak is the date and place you were planning to have your action, you have |
|
|
|
to be able to change that, and quickly, while making sure everyone involved |
|
|
|
knows (i.e. not only have the technical possibility of sending a message to |
|
|
|
people, but having a mechanism to make sure it's read in a defined amount of |
|
|
|
time and getting acknowledgment that it has been. Picture having to reschedule |
|
|
|
two hours before and work from there). If it's someone who's been added to the |
|
|
|
wrong chat group, or someone who talked in the wrong place, make sure it's clear |
|
|
|
it shouldn't have happened, do your best to scrub the information from there |
|
|
|
(disappearing messages with a short-ish lifetime are great for this), and change |
|
|
|
details if necessary. Sometimes you can't do much, going back to our tenant |
|
|
|
union example, if your identity leaks before you're ready, you're pretty much |
|
|
|
done, all you can do is hope and share your knowledge/resources with other |
|
|
|
members of your org. |
|
|
|
|
|
|
|
All of these might be way too much for your threat model! If you're only |
|
|
|
fighting to have a new bike lane installed in your neighborhood, nobody's going |
|
|
|
to try and coerce the members of your organization into giving up your name. |
|
|
|
They might try and find when your next action is, though, by walking into one of |
|
|
|
your meetings. If you're organizing a tenant's union, you probably don't need to |
|
|
|
organize segmented groups who only communicate through one member: your landlord |
|
|
|
isn't going to torture anyone to know the names of the co-conspirators... But |
|
|
|
you might want to be careful about where you organize your meetings, keep the |
|
|
|
"security" cameras in the building in mind when you're putting up rent strike |
|
|
|
posters, and maybe don't give your name and unit number to other members even if |
|
|
|
it's not that risky (they don't really need it anyway!). Your threat model |
|
|
|
really is what determines the measures you should take. |
|
|
|
|
|
|
|
Fix the issue, rinse and repeat |
|
|
|
------------------------------- |
|
|
|
|
|
|
|
Well, this part really depends on what you found out in the previous steps. |
|
|
|
Fixing the issue, however, means not only fixing this particular instance but |
|
|
|
rather changing the system within your org as best you can to make sure that |
|
|
|
problem doesn't show up again. Some of these you can't fix definitely, as |
|
|
|
they're inherent to the system outside your organization, but you can orient |
|
|
|
your group so that they're less likely to happen. Some are entirely your |
|
|
|
responsability, and you can fix them with a bit of effort, structuring your |
|
|
|
organization correctly, and never letting your guard down. |
|
|
|
|
|
|
|
Conclusion |
|
|
|
========== |
|
|
|
|
|
|
|
That's it for this post! Always keep in mind: OPSec is something you need to |
|
|
|
have *before* you actually need it. Like everything else in security, it's a |
|
|
|
process, not a state: it's basically impossible to tell if you're secure, all |
|
|
|
you can reliably know is if you're insecure, and most of the time it's because |
|
|
|
you suddenly have handcuffs, or are being evicted from your appartment. It |
|
|
|
can require constant vigilance, discipline, and every error can be extremely |
|
|
|
costly... But it gives you a semblance of security and a fighting chance against |
|
|
|
your adversaries. |
|
|
|
|
|
|
|
I hope this post has at least provided a few pointers, and has made you |
|
|
|
reflect on your organizational and personal OPSec. Don't think it's too late: |
|
|
|
it's always better to have at least a little bit of OPSec than none at all. And |
|
|
|
if you don't implement it for yourself, you should at least do it for other and |
|
|
|
future members. |
|
|
|
|
|
|
|
Finally, there are more posts like this one coming on other topics, including |
|
|
|
how to communicate securely, which tools to use, what is effective, what isn't, |
|
|
|
and how to escape tech-based surveillance, and I hope you'll come back to take a |
|
|
|
look at these. |
|
|
|
|
|
|
|
Good luck out there |