232 lines
12 KiB
Markdown
232 lines
12 KiB
Markdown
![]() |
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
|