Device Analysis
Device Analysis is where the LLM’s verdicts on suspicious devices land — risk scores, indicators, evidence, and recommended actions, in one filterable list.
You reach the page at /threat-analysis from the side menu (labelled “Threat Analysis”). Every row is one analysis run: the LLM looked at a device’s recent DHCP behaviour and decided what it saw. The page is the workbench for triaging those verdicts, deciding whether the system’s recommendation was right, and following up.
This page does not run the analyses — automation rules with action Analyze queue devices, and the Anomaly Detection (chapter 24) cycle works through the queue. This page is the output side.
About the AI backend. The appliance ships without an AI backend configured — analysis runs only once an optional backend is set up. The optional backend and its full setup ship with the install package; the appliance enforces fully without it.
Watch the analysis queue. Analysis is not instant. If automation rules with action Analyze match many devices, verdict requests can pile up faster than the backend can serve them — wasting effort on verdicts that may no longer be relevant by the time they complete. Start with tight thresholds, watch the Automation (chapter 16) execution history to confirm the queue is draining rather than growing, and only loosen rules once you know the backend can keep up.
Header
Section titled “Header”The page header carries the title, time range, and the export controls.
From left to right:
- Title — “Threat Analysis” with an alert icon.
- Time range — previous/next arrows step the window, and the picker selects relative (1h … 7d) or absolute ranges.
- Refresh — re-fetch the table.
- CSV — download the filtered results as a CSV file named
threat-analysis-<YYYY-MM-DD>.csv.
Changing the time range or applying a filter resets the table to page 1.
Stats Cards
Section titled “Stats Cards”Five summary numbers describing the analyses in the current time range and filter.
| Card | Meaning |
|---|---|
| Total Events | Number of analyses returned by the current query |
| Avg Risk Score | Mean risk score across those analyses (0–100) |
| High Risk | Count where risk score is at or above 80 |
| Action Required | Count where the LLM flagged the device as needing operator review |
| Action Executed | Count where the system already applied the recommended action |
A network with a tight automation policy will have High Risk roughly equal to Action Executed: every dangerous device was caught and acted on. A growing gap between Action Required and Action Executed means analyses are piling up without being resolved.
Filters
Section titled “Filters”The filter panel is collapsed by default. Click Filters to expand it.
| Filter | Options |
|---|---|
| MAC / Evidence | Substring match against the MAC address or the LLM’s evidence text |
| Threat Type | All, MAC Spoofing, DHCP Starvation, Coordinated Attack, Suspicious Pattern, Normal |
| Action Required | All, Yes, No |
| Action Executed | All, Yes, No |
Apply Filters runs the query, Clear All resets and reloads. An “Active” pill on the Filters button tells you at a glance that the current view is filtered.
Results Table
Section titled “Results Table”One row per analysis, sorted newest first.
Columns
Section titled “Columns”| Column | Description |
|---|---|
| Time | When the analysis ran |
| Client MAC | Device the analysis is about — click the row to open Device Details |
| Threat Type | Coloured badge: MAC Spoofing, DHCP Starvation, Coordinated Attack, Suspicious Pattern, or Normal |
| Risk Score | 0–100, colour-graded (green under 40, yellow 40–59, orange 60–79, red 80+) |
| Recommended Action | block / deny / throttle / monitor / allow / none, with an optional duration in parentheses |
| Action Status | ”Executed” (green shield), “Pending” (yellow warning), or -- |
| Details | An eye icon — opens Device Details (chapter 14) for the device |
Clicking anywhere else on the row also opens Device Details, carrying the current time range as parameters so the device page shows the same window.
Threat Types
Section titled “Threat Types”| Type | Typical signature |
|---|---|
| MAC Spoofing | Multiple distinct vendor identifiers from one MAC, or rapid OUI flips |
| DHCP Starvation | One MAC requesting many unique IPs in a short window |
| Coordinated Attack | Many MACs from one source IP / relay with the same suspicious pattern |
| Suspicious Pattern | Anomalous behaviour that does not match a named attack class |
| Normal | LLM examined the device and judged it benign (low risk, no action) |
Normal verdicts are still recorded so you have an audit trail showing the system looked at a device and cleared it.
Pagination
Section titled “Pagination”Page sizes: 10 / 25 / 50 / 100. Pagination appears above and below the table.
What an Analysis Contains
Section titled “What an Analysis Contains”Each analysis row carries a full structured verdict produced by the LLM. The list view shows the headline; the detail view (Device Details → LLM Analysis) shows everything.
The full verdict, available on Device Details (chapter 14), includes:
- Risk Score — 0–100. The headline number used for sorting, alerting, and auto-execution.
- Recommended Action — block / deny / throttle / monitor / allow / none.
- Recommended Duration — only present for time-bounded actions.
- Priority — critical / high / medium / low, used to colour the recommendation badge.
- Confidence — 0–100, how sure the model is about its verdict.
- Indicators — short keyword tags (
dhcp-flood,vendor-mismatch, etc.). - Evidence — bullet points of specific observations.
- Action Justification — a sentence or two explaining why the chosen action and not another.
- Recommendation — the model’s free-text recommendation.
The CSV export carries all of those fields except the long free-text Action Justification and Recommendation, which are truncated.
Analysis Context
Section titled “Analysis Context”Every analysis records the window of activity the model actually looked at.
This is important because the same device can look very different across windows. The context block shows:
- Time window — typically 1h, 6h, 24h, 7d, or 30d (whatever was passed to the analysis).
- Request count — how many DHCP requests the model saw.
- Unique IPs — how many distinct IPs the model saw.
When you compare two analyses of the same device, check the context first: a risk score of 90 over 1 hour means something different from a risk score of 90 over 30 days.
Running a New Analysis
Section titled “Running a New Analysis”You don’t run analyses from this page. You run them from Device Details or from an automation rule.
To trigger a fresh analysis on a single device:
- Click into a row (or any MAC anywhere in the GUI) to open Device Details (chapter 14).
- Press Analyze in the device header.
- The Analyze Modal opens. Pick a Lookback Period (1h, 6h, 24h, 7d, 30d) and an Analysis Prompt from the configured prompts.
- Click Start Analysis. The verdict appears in the device’s LLM Analysis section once the LLM completes; it also shows up as a new row in this page’s table.
The Analyze Modal
Section titled “The Analyze Modal”The lookback presets are the same as the page’s time range presets. The analysis-profile list comes from the optional AI backend’s configured profiles; one is pre-selected as the default. Each profile has a short description so you know which one fits the device under investigation (for example, a vendor-spoofing profile versus a flood profile).
Cooldown
Section titled “Cooldown”Each device has an analysis cooldown to keep the LLM from being asked the same question repeatedly. You can see the remaining cooldown for a specific device in the Enforcement Status column on Device Details (chapter 14). While the cooldown is active, the Analyze button is disabled.
Automation rules with Analyze as their action respect the same cooldown — a device that is in cooldown is not re-queued.
Tip. If you genuinely need to re-analyse a device before its cooldown expires (for example, after applying a manual mitigation and wanting a fresh look), open Anomaly Detection (chapter 24) and lower the cooldown for the affected prompt, then run the analysis again.
What Happens After a Verdict
Section titled “What Happens After a Verdict”A verdict can sit and wait for a human, or it can be auto-actioned, depending on your policy.
Possible outcomes:
- Action Executed — the verdict’s risk score is at or above the auto-execute threshold configured in Automated Actions (chapter 25), so the system applied the recommended action immediately. The Action Status column shows the green shield.
- Pending (Action Required) — the verdict says action is required but the score didn’t cross the auto-execute threshold. The yellow warning badge means someone should look. This is your triage queue.
- No action — the verdict is Normal, or the recommended action is “none”. The row is informational.
Pending rows can be resolved by:
- Opening Device Details and clicking the recommended action button in the header.
- Acknowledging the device is fine and either dismissing it (it will fall off the page when the time range moves) or running Allow to mark it trusted.
Where the Data Comes From
Section titled “Where the Data Comes From”The page is fed by the analysis history table. Every LLM call writes a row containing the verdict, the context, and the executor (which automation rule queued it, or which operator clicked Analyze).
Inputs that produced these rows can be:
- Automation rules with Analyze action — see Automation (chapter 16).
- Manual triggers from Device Details (chapter 14).
- Anomaly Detection cycles — see Anomaly Detection (chapter 24).
The LLM backend itself is configured on LLM Setup (chapter 23). If the page is empty on a fresh install, check there first: the model has to be reachable for any verdict to be written.
Related Pages
Section titled “Related Pages”- Device Details (chapter 14) — full LLM-Analysis section, per device, with the analyse button.
- Anomaly Detection (chapter 24) — the periodic analysis cycle and cooldown configuration.
- Automated Actions (chapter 25) — the risk-score thresholds that decide which verdicts get auto-executed.
- Automation (chapter 16) — how rules feed devices into this page in the first place.
- LLM Setup (chapter 23) — the model and backend behind every verdict here.
Troubleshooting
Section titled “Troubleshooting”The page is empty. Make sure the LLM backend is reachable from LLM Setup (chapter 23). Then trigger one analysis manually from Device Details to confirm the round-trip works. If automation rules with Analyze action are not producing verdicts, look at the rule’s execution history on Automation (chapter 16) — the rule may be detecting devices but the LLM may be failing on the back-end.
A row says “Pending” but I want to act on it. Click the row, open Device Details (chapter 14), and use the action buttons in the header. The verdict’s recommended action will already be highlighted.
Recommended action shows “block” but Action Status is
--. The recommendation was made but auto-execution was not triggered — usually because the device’s risk score was below the threshold on Automated Actions (chapter 25), or the auto-execute feature is off. Either lower the threshold or execute the action manually.
The Analyze button on Device Details says cooldown. The device was analysed recently and is locked out until the cooldown expires. The remaining minutes are shown next to the button. You can shorten or eliminate the cooldown from Anomaly Detection (chapter 24).