Operational Security - OpSec

"How would you like to be a spy?" Susan didn't sound suspicious to her but there was something dark lurking at the back of her head when she heard the words.

"I'd say... ok. Where do we start?" Kalina was tired and without hope and Susan's plan offered some, at least seeming, excitement. "Where do we start?"

"We'll start from the thing most people lack."

Introduction

Operational Security, often shortened to OpSec, is not only a fancy term for keeping your mouth shut, it is a set of rules constricting one's behaviour so that the integrity of the operation remains intact. It is the ability to know where to talk with whom and about what. People unfamiliar to Operational Security often confuse it with being paranoid over a strange set of information. Most people will think secret recipes and plans potentially vulnerable and refrain from discussing their details in public, but will have no problem talking over a beer 'how terrible is leader X from the new ███████ project' or that 'Y from the security is cool and wholehearted for letting people without a badge once in a while'.

Five steps of OpSec

"Okay, Sus. If you're asking me to watch myself over everything, I'll probably go and jump myself of a cliff." Susan didn't even finish her introduction when Kalina already felt overwhelmed with the amount of caution she had to address. "Could you, please, phrase it a little more.. simple?"

Susan was just getting started and was about to go to the tenth historical reference slide. Kalina was looking pretty tired though, so she skipped the next twenty. She took a deep breath to calm her racing thoughts. "There's a small neat set of rules to follow."

Operational Security can be broken down into five steps:

1. Identify sensitive data — the first step is to identify the sensitive data as these may become the root cause for the bad actors to attack. Sensitive data don't need to be the high stakes secrets of the person or the company but often are — the sensitivity being not a single label but rather a spectrum quality. The top secret data hidden in a safe will be the most sensitive, but the location of the safe, the personel with access and the habits of the guards in the building should be considered sensitive as well — they can become a trail for further exploration.
2. Identify possible threats — what happens if a bad actor gains access to the sensitive data? Is it "game over" or can the damage spread on other parts of the system, i.e., does the attack surface become larger as a result of the sensitive data being accessed? Note that access here is equivalent to "gaining control over", and has three possible scenarios, each with different outcome:
1. theft — the data is now in possession of the bad actor
2. destruction — the data has been destroyed
3. tampering — the contents of the sensitive data have been modified
3. Analyze the vulnerabilities — how the bad actors can access the sensitive data? This step is equivalent understanding the strong and weak links of the system with respect to the security. It also needs to be stressed that it is always human, which is the weakest link — prone to social engineering, often executed through phishing attacks. Identification and potential exploitation of vulnerabilities is the heart of a controlled attack performed by Penetration Testing Teams.
4. Determine the threat level — how severe are the discovered vulnerabilities? Each vulnerability is potentially a door to access the system and get closer to the sensitive data? Can some of them offer access to other vulnerable parts of the system? If so their threat level will be higher.
5. Devise a plan to mitigate the threats — what needs to be done to minimize the damage? With what, where and how identified it is time to devise a plan to minimize the damage. The hypothetical fire has started in section X and needs to be contained. Ideally, one would never want the fire to appear in the first place but in security as in safety one should always prepare for the worst.

Sloppy vs Meticulous — a perfect criminal

"Okay! So now that you know the basics, let's think about keeping yourself safe by not leaving the tracks." Susan was getting fired up again. She was thinking of starting with the environment and the basics of hypernet infractructure, then maybe introduce some elements of the processing unit and the stack, then maybe some elements of the machine code and...

"I'm tired, Sus. It's too much and I'm not sure I really care." The lecture overwhelmed her. Despite Susans best efforts to find her some new meaning, she was still misserable about ███████████. What was even the point keeping her life's secrets safe when they all felt meaningless?

"'kay. Let's try again tomorrow"

"Sure... let's try tomorrow." As if tomorrow's gonna be any different...

When OpSec is performed in a sloppy manner it can be traced using conventional OSINT techniques. Other times, one would need to use tools not permitted by law or permitted under special conditions (this is how some government agencies work like). Covering one's tracks is always a very difficult task to achieve and even in the cases of organized crime groups, e.g., big ransomware groups it is found that even small fingerprints of their identity can bleed out, leading crumb by crumb to their revealing.

Well executed Operational Security, however, requires a deeply developed understanding of the environment prior to the launch of the operation. In fact, not only the environment but also the consequences of interacting with it. A person who perfected all OpSec becomes a perfect criminal, capable of vanishing without a trace. As one may guess, such are not often found but appear from time to time, e.g., Jack the Ripper or Cicada3301.