As I’ve discussed before, threat models or risk models help you to define the adversaries you should invest the most resources being concerned about. There are a variety of different risk perspectives you can use to design a threat model: adversary-centric, asset-centric, or software-centric. We can adopt these into very similar models for OPSEC plans. Each of these models have a single principal that operational security’s primary goal is to mitigate risk while maintaining operational capabilities.

Adversary-Centric OPSEC

In these types of plans, we’re focused on what an attacker or adversary can do to us; who is coming after you, what they can do, and how you can defend. An adversary-cetnric policy has the advantage of being much easier to create and document because many people already think this way. It’s very simple to come up with a list of adversaries that have the potential to affect what’s important to you. The down-side of this approach is that you need to know your adversaries. In the case of the NSA “revelations”, many were shocked to find out that a nation-state had the type of capabilities that were disclosed. Prior to this, not many were able to mitigate themselves from these types of threats because they simply didn’t know or fully appreciate an adversary of this nature.

Asset-Centric OPSEC

This approach focuses on designging mitigations around your assets — the things you value the most. If, for example, your asset is your ability to privately communicate on the Internet, you’re going to do everything you can to ensure no-one can affect this. You’re not focused on specific adversaries per se in this approach, but you are doing everything in your power to protect yourself. Maybe you’re buying a VPN service or using a botnet or Tor for all communications. Maybe you’ve decided that you’re going to try out one of the new decentralized messaging systems as a way of keeping yourself secure.

One of the benefits of this method is that it’s easy to explain why a measure needs to take place. If you’re operating in a group, this may be an important factor. You can easily make the case that your asset needs to be secure, therefore we are taking these steps to mitigate the risk. Contrary to the adversary-centric approach, this is a less passive perspective — you are not taking the point of view of being fearful of something happening, you are merely performing the proactive, required procedures to keep your assets safe.

Operation-Centric OPSEC

This approach, my favorite, lends itself nicely to compartmentalization if you’re managing multiple identities across multiple operations. An operation in this case could be an identitiy, a research project, an regular activitiy or whatever, that may require specific operational security measures. An operation-centreic OPSEC plan may sound recursive to you, but the gist is that your plans are focused on your specific operation, and that operation alone. The main difference between this and an asset-centric approach is that it is designed to have drastically different and compartmentalized procedures allowing for scalability without letting one operation interfere with another.

If you’ve ever taken a look at the security plans of a large, Fortune 500 company compared to that of a startup, it’s quite possible that the startup is able to implement simple, elegent, effective security plans while the Fortune 500 spends millions of dollars designing a unilateral security policy that severely inhibits the organizations operational capabilities. The reason that a small, agile startup can devise elegant OPSEC measures, is the same reason that compartmentalizing your OPSEC procedures in an operation-centric point-of-view is effective.

The other reason that I like this is because it gives you a good balance of a variety of different OPSEC approaches. You are paying attention to your operation’s assets while taking into account specific adversaries and their attacks. As you define an operation — we’ll say buying illegal drugs on the internet — you will be scoped down to a specific task and controlled environment. It lets you define boundaries in which your OPSEC guidelines can define situations in which your measures/countermeasures no longer protect you. This keeps risks at a minimum because you are only defending against a subset of your activities — those associated with the operation. In the example of buying illegal drugs on a darknet market, your OPSEC guidelines can state that in the case of the darkmarket collapse (which seems to happen regularly lately), your operation should fold and the identity should be burned. You can take into accounts adversaries such as those that own the market, and assets you’re concerned about such as keeping yourself out of jail.

I will admit, none of those listed are perfect, nor do they make up an exhaustive list. They may however give you a starting point for building an OPSEC plan for yourself.