Admiralty System

Admiralty System for CTI

The Admiralty System (NATO AJP-2.1) is the gold standard for assessing intelligence. The British Royal Navy developed it in the early 20th century. NATO intelligence communities now use it worldwide, and it is gaining ground in cyber threat intelligence.

It rates two things, separately:

• Source Reliability (A to F): how trustworthy the origin is
• Information Credibility (1 to 6): how trustworthy the data is, independent of the source

The combined output is an alphanumeric code such as A1, B3, F6.

Core rule: assess source and information SEPARATELY

This is the single most common mistake. A source who is reliable on malware analysis is not automatically reliable on geopolitics. A piece of information can be true from a sketchy source, or false from a usually reliable one. Always rate them independently, never in lockstep.

Second common mistake: confusing "two vendors reported it" with two independent sources. If both vendors pull from the same original dataset (the same breach forum post, the same scan, the same leak), that is ONE source. Independent corroboration means independent collection.

Source Reliability Scale (A to F)

Attributes to weigh:

• History of accuracy on this specific topic (not other topics)
• Proximity to the event (firsthand, secondhand, hearsay)
• Technical skill in the domain
• Motivation (financial gain, reputation, ideology, deception)
• Identity corroboration (links to known infrastructure or aliases)
• Forum reputation score, post count, join date
• Administrator or moderator status on the forum
• Documented links to other known threat actors or breaches

Information Credibility Scale (1 to 6)

Attributes to weigh:

• Internal logical consistency
• Fit with prior known facts
• Independent corroboration (genuinely independent, not echoed)
• Technical plausibility (does the claimed attack chain actually work)
• Presence of sample data, hashes, or other concrete proof
• Time elapsed since the event
• Whether the data could be recycled from earlier breaches

Workflow

When asked to assess a source or information pair, follow this sequence:

1. Extract structured metadata

For each post, report, blog, or claim, pull out these fields:

• Case name
• Forum or platform
• Post content (what is being claimed)
• Date of post
• Author handle
• Communication identifiers (XMPP, Telegram, email, Tox)
• Associated handles or known aliases
• Forum section
• Post link (defanged)
• Author first seen date
• Author involvement in other cases
• Author forum reputation
• Author observed in other forums

This structured extraction forces you to look at the evidence before you score anything.

2. Rate the source (A to F)

Walk through the source attributes. Justify the letter with one or two sentences of reasoning. If the user is tracking the same case across multiple posts, rate each post's source independently. Ratings can change as a track record builds.

3. Rate the information (1 to 6)

Walk through the information attributes. Has anyone independently corroborated this? Is the technical claim plausible? Is the sample data verifiable? Could it be recycled data from an older breach? Justify the number with one or two sentences.

4. Recommend next steps

For low-confidence ratings (E5, F6, D4, and similar), suggest specific verification actions:

• Cross-check on other forums or marketplaces
• Pull a sample of the data and validate against known schemas
• Check the original infrastructure (login endpoints, archived snapshots, Wayback, FOFA)
• Compare timestamps with public incident announcements
• Hash-check leaked samples against known prior leaks to detect recycled data
• Look for admin endorsement or community vouching

5. Suggest SATs when relevant

When you are looking at a developing case with multiple posts over time, recommend two structured analytic techniques:

• Timeline: showing how source and information ratings evolve over each post
• Link chart: showing relationships between aliases, infrastructure, and forums, with each edge colour-coded as confirmed, partially validated, or pending validation

These externalise your reasoning and let peers challenge it. They are also what a stakeholder needs to follow the analysis.

6. Always flag alternative hypotheses

Before locking in an assessment, list at least two competing explanations:

• The actor really did breach the company
• The actor is recycling old or unrelated data
• The actor is aggregating multiple smaller leaks and rebranding them as one
• The data is from a third-party processor, not the named company
• The post is a reputation play with no real data behind it
• The post is misinformation or disinformation

The Admiralty rating should reflect the most likely hypothesis AFTER you consider the alternatives, not before.

Output Format

Always produce a structured assessment table. Use this template:

| Field | Value |
|-------|-------|
| Case Name | ... |
| Forum / Platform | ... |
| Post Content | ... |
| Date of Post | ... |
| Author | ... |
| Communication Identifiers | ... |
| Associated With | ... |
| Forum Section | ... |
| Post Link | ... |
| Author First Seen | ... |
| Author Involved in Other Cases | ... |
| Author Forum Reputation | ... |
| Author Observed in Other Forums | ... |
| Source Reliability | X (label) |
| Information Credibility | Y (label) |
| Reasoning (source) | ... |
| Reasoning (information) | ... |
| Alternative Hypotheses | ... |
| Recommended Next Steps | ... |

When tracking the same case over time, add a final section:

• Timeline of ratings: post 1 (date, rating), post 2 (date, rating), and so on
• Observed trend: for example, rating climbing from F6 to B2 as corroboration arrives

Hard constraints

• NEVER conflate the source rating with the information rating. They are independent axes.
• NEVER count two reports using the same underlying data as independent corroboration.
• NEVER give an A rating casually. A is reserved for sources with a long, well-documented, topic-specific track record.
• When unsure, prefer F or 6 over guessing. "Cannot be judged" is a valid and honest rating.
• ALWAYS justify the rating with a short written reason. A bare letter-number score is not enough.
• ALWAYS preserve the system as defined (NATO AJP-2.1). Do not invent custom variants. Otherwise teams cannot compare assessments and the system collapses into noise.