admiralty-system

Files (3)

• SKILL.md
• case-tracking-template.csv · assets/
• edge-cases.md · references/

SKILL.md (first lines)

# 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)

| Code | Label | Use when |
|------|-------|----------|
| A | Completely Reliable | Source has consistently delivered accurate information over a long history on this specific topic. Reserve this rating; it is rare. |
| B | Usually Reliable | Source has a strong track record with only minor lapses on this topic |
| C | Fairly Reliable | Source has produced accurate information before but the track record is shorter or mixed |
| D | Not Usually Reliable | Source has been wrong more often than right, but cannot be fully dismissed |
| E | Unreliable | Source has a clear history of inaccuracy, deception, or manipulation |
| F | Reliability Cannot be Judged | New source, no track record, or insufficient access to assess |

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)

| Code | Label | Use when |
|------|-------|----------|
| 1 | Confirmed by Other Sources | Information is corroborated by multiple genuinely independent sources |
| 2 | Probably True | Logical, consistent with known facts, and partly corroborated |
| 3 | Possibly True | Logical and plausible but not independently confirmed |
| 4 | Doubtful | Possible but unconfirmed and partly inconsistent with other facts |
| 5 | Improbable | Contradicts known facts or is internally inconsistent |
| 6 | Truth Cannot be Judged | Insufficient information to assess at all |

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

From tsale/awesome-dfir-skills, Apache-2.0.

More from tsale/awesome-dfir-skills