Browse Source

add post on security for leftists

master
Clément Hertling 2 weeks ago
parent
commit
f86a84ca8e
1 changed files with 231 additions and 0 deletions
  1. +231
    -0
      content/security_for_the_savvy_leftist,_part_Ⅰ.md

+ 231
- 0
content/security_for_the_savvy_leftist,_part_Ⅰ.md View 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…
Cancel
Save