What is OPSEC? Finding the indicators you are already leaking

Operations Security began as a US military process during the Vietnam War, after analysts realised that operations were being anticipated without any classified material being compromised. The adversary was assembling ordinary, unclassified observations — radio traffic volume, supply movements, aircraft patterns — into reliable predictions.

That is the whole idea, and it is what makes OPSEC different from ordinary information security. Infosec protects the secret. OPSEC protects the things that are not secret but reveal the secret anyway.

The five-step process

1. Identify critical information. Not everything is critical. What would genuinely help someone attacking you?
2. Analyse threats. Who would want it, and what can they already see?
3. Analyse vulnerabilities. Which of your observable behaviours expose the critical information?
4. Assess risk. Likelihood against impact, so effort goes where it matters.
5. Apply countermeasures. Remove the indicator, or make it ambiguous.

Step three is the one that gets skipped, and it is the one that matters. The rest is a planning exercise without it.

What organisations actually leak

These are all public, all routine, and all commonly used in reconnaissance before an attack.

Job advertisements

A posting for "Senior Engineer — must have 5 years Citrix NetScaler, experience with Fortinet FortiGate and VMware Horizon" is a technology inventory of your perimeter. Anyone tracking vulnerabilities in those products now knows to aim them at you. The countermeasure is not to stop hiring — it is to describe the role generically and discuss specifics at interview.

Certificate Transparency logs

Every publicly trusted TLS certificate is logged in a public, searchable append-only record. Issue a certificate for vpn-test.internal.example.com and you have published the hostname to anybody watching:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u

This routinely reveals staging environments, internal tooling and products that have not been announced. Wildcard certificates avoid naming individual hosts; internal certificate authorities keep internal names out of public logs entirely.

DNS

Subdomain names describe your estate: jira, vpn-legacy, backup, test-payments. Records left pointing at decommissioned cloud resources are worse than informative — they are takeover candidates.

Source control and build artefacts

Commit history outlives the commit. A secret removed in a later commit is still in the history, and public CI logs frequently echo environment details. Metadata leaks too: commit timestamps map working hours and therefore team locations.

Out-of-office replies and support tickets

Auto-replies commonly name a deputy, their direct line, and the duration of absence — everything needed to construct a convincing pretext while the named person is unreachable.

Doing the analysis

Look at yourself the way someone else would, using only public sources:

# Certificates issued for your domain
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u

# What resolves, from a wordlist
dnsx -d example.com -w subdomains.txt -silent

# Which of those answer, and what they claim to run
httpx -l hosts.txt -title -tech-detect -status-code

Then ask, for each result: does this reveal something in the critical-information list? A hostname is not a vulnerability; vpn-legacy.example.com answering on an old TLS version is an indicator worth acting on.

Countermeasures that work

• Remove the indicator. Retire the DNS record, use an internal CA, write the job ad generically.
• Make it ambiguous. Wildcard certificates, non-descriptive hostnames, shared mailboxes instead of named deputies.
• Change the timing. Publish after the fact rather than in advance.
• Accept it. Some indicators are unavoidable. Recording that decision is better than pretending the leak does not exist.

The common failure

OPSEC programmes usually fail by classifying everything. If the critical-information list runs to forty items, nobody can hold it in mind and it is ignored. A list of five things people can actually remember — an unannounced product, a specific customer, the date of a migration, the tooling on the perimeter, who holds privileged access — protects more in practice than an exhaustive one nobody reads.