add post on security for leftists

content/security_for_the_savvy_leftist,_part_Ⅰ.md

@@ -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