In this guide we'll cover the basics of Opsec in a way that most anyone should be able to understand. This guide is split up into topics designed to be linked to directly for the purpose of convenient educational discussion. As this is intended for all audiences, it will be rich in easily destroyable strawmen examples that do not necessarily reflect complex realistic threats and risks. If you do not like the included examples, feel free to contribute your own via pull-request.
Note: This guide is not a "how to be anonymous on the internet", "how to protect yourself online", or "best practices" guide. Those are all countermeasure-first approaches that assume a threat model that applies to you (when it often doesn't). Instead, this guide teaches you how to understand that for yourself through the opsec process. While many guides can be useful to learn about potential threats and countermeasures, the countermeasure-first approach of the "best practices" fallacy has no place in opsec and ultimately leads to baseless paranoia.
Skip to:
A countermeasure literally means a measure of response to counter a threat. Countermeasures can be:
Each of these countermeasures is designed to counter a specific threat. So why not use all of them "just to be safe"? In order to see why that thought process is flawed, let's take the countermeasure-first approach to the extreme.
While it might serve to slow down and frustrate a home invader, it would also mean everytime you go to the bathroom, kitchen, or anywhere in your house you'd be pulling out a key and locking/unlocking doors. This level of countermeasure might be necessary for inside a bank, but for most peoples homes it would only complicate life and potentially increase liability if there is an emergency.
VPNs might work to hide your real IP address from questionable websites, but websites such as government or banking websites use that data to confirm your real identity. Spoofing that can cause complications such as account freezes.
Depending on how often you need to use your phone, having a long password to unlock it may make you unproductive at best. Imagining entering a password that takes 10 minutes to type out every time you want to respond to a message. This might make sense for a device that gains access to a government's nuclear control facilities, but for most of us it is far beyond the point of diminishing returns.
It's quickly evident that without a rational threat or otherwise clear reason for a countermeasure, you end up spending time, energy, and even money for little to no benefit on a threat that may never materialize. Worse, in doing so you can increase your liability and attack surface.
The countermeasure-first approach is unsustainable, misleading, and fundementally ignores two critical paradigms:
To combat this, we put countermeasures in the back and focus on the rationale first. This is called the opsec process. The opsec process is a list of questions to help rationally assess a threat and judge the efficacy or even necessity of countermeasures against it.
🔗 Food for thought: Some guides recommend taking a "best practices" approach to security, such as recommending everyone use a VPN, password managers, etc. This "best practices" fallacy is a countermeasure-first approach based on the study of successes, rather than failures, and as such is an insufficient starting point when assessing any highly-individual and dynamic topic such as security or privacy.
In reality, while the countermeasures recommended might end up working for some of the people, some of the time, that merely indicates the threat model for those people happens to be similar at the moment, but it doesn't teach why, nor is it adaptable for when it's not similar. This is why rather than making assumptions based on the "best practices" fallacy, Opsec seeks to understand the rationale to make reproducible judgments in dynamic situations, to educate oneself through practice to the point of not needing any guides.
Opsec is a practice or methodology based on rational assessments before action. Before deciding what countermeasure to use, first you need to asses if the threat is serious, or even practical.
This is done by asking a series of questions in order.
This could be information, a physical item, your personal health, or anything that has value or provides additional opportunity once accessed. For most of us, the answer to this question might be family, our home, any number of valuable belongings, our personally identifiable information, important financial information, or our passwords. All of these things need to be protected, but not all of them are always at risk in every situation.
Depending on what your relationship is with your colleagues, the level of safety common in said workplace, the type of workplace, and the value of the phone, information on it, or access it provides, that phone may either need to be handcuffed to you or can be lent to a colleague unlocked without incurring any risk at all.
The physical safety of keeping our doors open is based on the likelihood of someone trying to enter. You can usually visually inspect your surroundings well enough to see if that is a likelihood or not, but how serious to take this will likely depend on the safety of the neighborhood. Some neighborhoods you could leave your door open all day long without incurring any risk. Others, adding a security door to your house may just get it stolen in the night.
While theft and fraud do happen, usually the bank and law enforcement resolve these issues for you. The likelihood of these things happening to you largely depend on the type of establishment and the risk/reward ratio for the individual. The risk of getting fired or going to jail deters most undetermined criminals.
The fact is, whether something needs protecting in that moment or not largely depends on what the threat might be, or more importantly the practicality of a threat at all. Just as it’s highly unlikely a worker in your office would steal your phone from your desk, it’s also unlikely your stolen phone would garner much value to them if properly locked and devoid of any real useful information on it (an example of an applied countermeasure).
Most people don’t need help identifying common, obvious, physical threats. We encounter enough of those in the course of our daily lives that it becomes a second nature for most. While identifying them, we tend to internally ask ourselves questions to assess the potential threats.
But not all potential threats are so obvious to everyone, especially abstract ones related to the effects of running certain software, performing certain actions on a computer, or trusting certain sources of information.
The website you provided information to has its database hacked and subsequently leaked on message boards of hackers who will now try those same credentials at various sites in hopes of gaining access to your life and finances.
While entering your credit card, the passenger in the seat behind you takes a photo of your card and uses it to order the wifi also.
They start screaming that you hit them with your car (when you clearly didn’t) and call the police and demand compensation. Alternatively, while you're helping them, someone hops into your car and steals it.
These threats are all possible, but perhaps unlikely. Still, it’s important to try to brainstorm and identify potential threats as early as possible: before you leave on that vacation, before you start your car, before you enter your information into that website’s form. Without practicing opsec in this manner, the above threats will need to be learned from experience instead, sometimes at a potentially heavy price.
Now that you know what you want to protect (e.g. your credit card on a plane) and what the potential threat is (e.g. the person behind you able to see the card’s details or being stolen by other means during the flight), it can be quite straightforward to assess the vulnerabilities and whether they are credible or not.
Depending on the answers to these questions, you may find that you have none, few, or many potential vulnerabilities. Normally this kind of judgement is possible to do quite quickly, but the more technical the potential vulnerability is, the more experience and knowledge is required. How could someone who isn't aware of HTTPS know that not using it could leak their credit card number to a hacker?
In this particular situation, we eliminate all unlikely or impractical vulnerabilities and focus on what remains.
It’s important to know the difference between a vulnerability and a risk. Simply put, the vulnerability is how it might be possible to attack you. The risk is what you could lose if it succeeds.
Now that you know the potential threat and potential vulnerabilities, you can ask the more practical questions about the realistic potential risk to you. This is where common sense, rationality, and statistics will serve you well. There is no room for fear and paranoia in this step.
Assuming a credible risk is perceived, the next step is to assess which countermeasures are most appropriate for the threat.
Assuming a credible threat exists and there is perceived risk, the next thing to do is to apply the countermeasures to close up the vulnerabilities that will ultimately serve to neutralize the threat.
In this particular situation, we have eliminated all unlikely or impractical vulnerabilities and focus on what remains.
The easiest countermeasure for these is likely the same for both:
The simplicity of assessing a specific threat and risk may lead one to believe the thought process isn't being used, but much like math, just because an easier equation doesn't need a calculator doesn't mean there isn't calculation occuring. The simplicity of the process can be deceiving and lead to the belief that applying a countermeasure-first approach is sufficient. That is the "best practices" fallacy addressed earlier.
The previous examples were largely obvious and wouldn’t necessarily need a guide or checklist to assess them. What’s important is the thought process behind them: to be asking the right questions and learn how to find the right answers in a reproducible way.
In the following section, we’ll take the opsec process to less simplistic scenarios, gradually increasing the difficulty of these scenarios in story form to uncover gaps in knowledge and get better at applying the opsec process instinctively.
Work in progress: This document is a work in progress. Expect occasional updates that change the content, design, and length of the document.
See an issue with this page, want to add your own information, or feel like providing a translation? Visit this page on github.