> For the complete documentation index, see [llms.txt](https://docs.elastiflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.elastiflow.com/additional-resources-reference-articles/faq/netintel-threat-scoring-and-ranking.md).

# NetIntel Threat Scoring and Ranking

## NetIntel Threat Scoring & Ranking

### Overview

NetIntel identifies a fixed catalog of **16 threat types** on each flow and produces three parallel score arrays — **confidence**, **risk**, and **threat** — that let you rank how dangerous each detected flow is. The **threat score** is derived directly from the risk and confidence scores, so it can be computed (and re-derived) at any time:

```
threat.score = risk.score × confidence.score
```

Flows whose threat score lands in the **Critical** band are the highest priority and should be surfaced first.

### Data Model

For each flow NetIntel detects, it emits four **parallel arrays** that are aligned position-by-position. All share the `flow.*.sec` parent prefix:

| Field                                | Contents                                |
| ------------------------------------ | --------------------------------------- |
| `flow.*.sec.threat.name`             | Detected threat names                   |
| `flow.*.sec.threat.confidence.score` | Confidence score per threat (1–3)       |
| `flow.*.sec.threat.risk.score`       | Risk score per threat (1–7)             |
| `flow.*.sec.threat.score`            | Threat score per threat (derived, 1–21) |

The *n*th element of each array describes the **same** threat:

#### Threat Catalog (all 16 types)

The full set of threat types NetIntel can identify, in canonical order:

|  #  | Threat Name               |
| :-: | ------------------------- |
|  1  | SIP Access                |
|  2  | VNC Exploit               |
|  3  | Remote Desktop Access     |
|  4  | HTTP Exploit              |
|  5  | SMTPS Access              |
|  6  | HTTPS Access              |
|  7  | MySQL Database Exploit    |
|  8  | Kamstrup Access           |
|  9  | IMAPS Exploit             |
|  10 | Internet Scanner          |
|  11 | IMAP Exploit              |
|  12 | SOCK5 Access              |
|  13 | Remote Desktop Exploit    |
|  14 | SOCK5 Exploit             |
|  15 | IMAPS Access              |
|  16 | Postgres Database Exploit |

### Score Scales

#### Confidence (how sure NetIntel is about the detection) — range **1–3**

| Value | Meaning           |
| :---: | ----------------- |
|   1   | Low confidence    |
|   2   | Medium confidence |
|   3   | High confidence   |

#### Risk (how dangerous the threat is if real) — range **1–7**

| Value | Meaning   |
| :---: | --------- |
|   1   | Low risk  |
|   …   | …         |
|   7   | High risk |

### Deriving the Threat Score

For each detected threat at position *n*:

```
flow.*.sec.threat.score = flow.*.sec.threat.risk.score × flow.*.sec.threat.confidence.score
```

* **Minimum:** `1 × 1 = 1`
* **Maximum:** `7 × 3 = 21`

So every threat score falls in the range **1–21**.

#### Worked Example

On a given flow, NetIntel detects **VNC Exploit** and reports `risk.score = 7` with `confidence.score = 2` for that entry:

```
threat.score = 7 × 2 = 14  →  Critical
```

That flow would be flagged as the highest priority.

### Threat Severity Bands

| Threat Score Range | Severity     |
| :----------------: | ------------ |
|         1–2        | **Low**      |
|         3–6        | **Medium**   |
|        7–12        | **High**     |
|        14–21       | **Critical** |

### Threat Ranking Grid

*Text version of the "Threat Ranking" chart.* Confidence increases **down the rows**; risk ("danger") increases **across the columns**. Each cell shows `score · severity`.

| Confidence ↓ \ Risk → |   Low (1)  |   Med (3)  |    High (7)   |
| --------------------- | :--------: | :--------: | :-----------: |
| **Low (1)**           |   1 · Low  | 3 · Medium |    7 · High   |
| **Med (2)**           |   2 · Low  | 6 · Medium | 14 · Critical |
| **High (3)**          | 3 · Medium |  9 · High  | 21 · Critical |

**Legend:** `1–2` Low · `3–6` Medium · `7–12` High · `14–21` Critical

#### Full Threat Score Matrix (all risk values)

The grid below expands the chart to every risk value (1–7). Use it to look up any combination quickly.

| Confidence ↓ \ Risk → |    1    |    2    |     3    |     4     |     5     |     6     |     7     |
| --------------------- | :-----: | :-----: | :------: | :-------: | :-------: | :-------: | :-------: |
| **1 (Low)**           | 1 · Low | 2 · Low |  3 · Med |  4 · Med  |  5 · Med  |  6 · Med  |  7 · High |
| **2 (Med)**           | 2 · Low | 4 · Med |  6 · Med |  8 · High | 10 · High | 12 · High | 14 · Crit |
| **3 (High)**          | 3 · Med | 6 · Med | 9 · High | 12 · High | 15 · Crit | 18 · Crit | 21 · Crit |

### How to Use It for Prioritization

* **Filter first on `flow.*.sec.threat.score`:** pull flows where the threat score is in the **Critical (14–21)** range — these are the most important and should be highlighted.
* **Identify the threat type** via the matching position in `flow.*.sec.threat.name` to know *what* is being detected.

### Tooling

The score fields are available in Elasticsearch as well as OpenSearch, so you can build alerts and highlighting on `flow.*.sec.threat.score` directly. A worked walkthrough of automating network alerts (e.g., Elastiflow → Slack) is available at:

* <https://www.elastiflow.com/blog/posts/automate-your-network-alerts-a-step-by-step-elastiflow-and-slack-tutorial>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.elastiflow.com/additional-resources-reference-articles/faq/netintel-threat-scoring-and-ranking.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.