add post on security for leftists
This commit is contained in:
parent
c213842209
commit
f86a84ca8e
231
content/security_for_the_savvy_leftist,_part_Ⅰ.md
Normal file
231
content/security_for_the_savvy_leftist,_part_Ⅰ.md
Normal file
@ -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
|
Loading…
x
Reference in New Issue
Block a user