OPSec for security researchers

Being a security researcher nowadays is no easy task, especially as we are no longer dealing with purely technical matters. Today’s global security landscape includes several new actors including governments, big companies, criminal gangs and intelligence services. This puts researchers in a difficult situation.

According to one of many definitions of OPSec:

“Operational security identifies critical information to determine if friendly actions can be observed by adversaryintelligence systems”

We are hearing reports of researchers facing threats from criminal gangs, or being approached by state intelligence services. Others have found themselves under surveillance or had their devices compromised when on the road.

OPSec_1

How can we minimize these risks? What can we do to avoid leaking information that could put us in an uncomfortable situation in the future?

Sometimes we are the public faces of a research project, but at other times we don’t want to be in a visible position.

The golden rule in Operational Security is using silence as a defensive discipline. If you don’t really need to say something, then keep quiet. When you need to communicate with someone, do it in a secure way that doesn’t compromise the content of your message and, if possible, doesn’t generate metadata around it.

This is an incredibly difficult objective to accomplish: it’s a natural instinct to want to impress others and on many occasions we will face adversaries who are well trained in obtaining the information that they want. We all like to tell interesting stories.

The second golden rule is that OPSec does not work retrospectively, so we should very careful about what we are doing now if we don’t want it to come back and bite us in the future.

In terms of OPSec, every security analyst should aspire to being just another guy in the line. If we attract too much attention to ourselves, surveillance could easily escalate beyond electronic means – and that is basically game over. In today’s world of massive surveillance, standing out will alert the attention of anyone who can access the relevant data. And in today’s world of information leakage and “big internet companies”, it´s difficult to know exactly who has access to which data:

example  of data leaked from an aggregator and published as a service

(example of data leaked from an aggregator and published as a service)

There are some interesting examples of how anomalies have been detected from metadata and then successfully used in investigations (http://en.wikipedia.org/wiki/Abu_Omar_case). And then there is the routine application of this in mass surveillance and data mining.

So what can we do?

The first rule of implementing OPSec is don´t try to accomplish more than you can. The fact is bad OPSec might be worse than no OPSec at all.

The main feature needed for effective OPSEC is not technical, but psychological: be meticulous, and maintain a healthy level of paranoia.

However electronic surveillance is obviously much more common and every bit of information will be there forever. Let´s look at our minimum toolset to avoid leaking information and thin about some basic tips.

Encryption

Obviously we should use as much encryption as possible. But remember that there is an inherent weakness. Once your keys are compromised, all the info that was encrypted in the past is compromised with them. As time passes, the likelihood of your keys being compromised will grow. So it’s much better to use IM with OTP.

Today’s big question: what is happening with TrueCrypt, the most popular encryption software?

According to the Audit project, there is no obvious flaw or backdoor. However a couple of months ago we saw this:

OPSec_3

There are still many open questions, but you can find a trusted TrueCrypt repository at: https://github.com/AuditProject/truecrypt-verified-mirror

Email

Email simply leaves too much metadata, even when the message is encrypted with PGP (by the way, use keys bigger than 2048). IM with OTP is better.

External providers cannot be trusted.

IM

Pidgin and Adium seem to be ok. But remember not to log your chats and don’t overlook the non-technical factor: you don´t know who is on the other side of the conversation (even when you have verified the key).

TOR

I’d definitely recommend using an anonymizing network to shake off most of the groups that could track you. However it cannot be considered truly “secure” in the sense that most of output nodes are controlled by people that can correlate their logs with the source of the connection. We saw an example of this in the Harvard bomb:

http://www.theverge.com/2013/12/18/5224130/fbi-agents-tracked-harvard-bomb-threats-across-tor

Also TOR has been the target of many attack attempts, like this recent one:

OPSec_4

So don´t blindly trust TOR for anything very sensitive, but use it for your daily activities. Never reveal your true IP.

Telephone

A total nightmare in terms of OPSec. The simple recommendation is to get rid of it! But this won’t happen.

At least don´t do anything sensitive with it, instead use burner phones, and don´t use them at  home or work.

Conclusions

Perfect OPSec is almost impossible. However implementing basic OPSec practices should become second nature for every researcher. Once you internalize the need to apply OPSec you will be more careful and hopefully, avoid rookie mistakes like talking too much and bragging about your research.

The most important things, beyond any tool, are being meticulous, applying the right level of OPSec according to your situation and understanding what you can actually hope to achieve.

This is just a brief introduction to a complex topic, but we hope it could be a useful eye-opener, especially for our fellow security researchers.

http://twitter.com/trompi

Related Posts

There is 1 comment
  1. quest

    For the recommendation of “IM and OTP” is that actually one time password or a type on should read OTR off the record?

Leave a Reply

Your email address will not be published. Required fields are marked *