Network intrusion detection has a signal problem. Signature-based systems catch what they already know and miss everything else. Anomaly-based systems catch more — and drown analysts in false positives until the alerts get muted. The practical failure mode is not a missed packet; it is an analyst who has stopped reading the queue.

The AI Integrated Smart Packet Analyzer was built to address the part that usually gets skipped: not just flagging a flow as malicious, but explaining why, in terms an analyst can act on during triage.

Project context

RoleSole researcher, developer, and evaluator
TypeFinal year cybersecurity research and implementation project
BenchmarkUNSW-NB15 — 82,332 held-out network flows
StackPython, XGBoost, NFStream, Scapy, Streamlit

What the system does

Real-time flow extraction

Live traffic is captured and converted into statistical flow records using NFStream, with Scapy available for lower-level packet inspection where a flow-level view is insufficient. The system analyses behavioural characteristics of a connection rather than matching payload signatures, so it is not dependent on having seen a specific attack before.

Two-stage classification

Detection is deliberately split. The first stage answers a binary question — is this flow malicious? The second stage classifies confirmed-malicious flows into threat categories. Separating the two keeps the binary decision boundary clean, and means a novel attack still gets flagged even when its category is uncertain.

Explainable attribution

Every prediction carries the feature contributions behind it. An analyst sees not only that a flow scored as malicious, but which characteristics drove that score — duration, byte ratios, connection state, service behaviour. This is the difference between an alert an analyst can triage and one they can only escalate or ignore.

SOC-style triage interface

A Streamlit dashboard presents live classification, incident history, and exportable evidence. Findings export to PDF and CSV so that detections can feed an incident record or a compliance report rather than remaining trapped in the tool.

EVALUATION NOTE
Results are reported against a held-out split of the UNSW-NB15 benchmark dataset — 82,332 flows the model never saw during training. Benchmark performance is evidence of method, not a guarantee of identical behaviour on a specific production network, where base rates and traffic composition differ.

Why it matters for assurance work

The project is the technical foundation behind the detection and monitoring recommendations made during Secure Automation Reviews and Web & API Security Assessments. Building a detection system end to end — including the unglamorous parts, like why analysts stop trusting alerts — informs how monitoring is specified for clients.

Investigation and triage methodology is demonstrated separately in the SOC incident walkthrough.

Source and research

START HERE

Engagements begin with a fixed-scope scoping call. Clear decisions before code, and no obligation to proceed to follow-on build work.

Discuss Detection & Monitoring →

Related: Munar Security Baseline & Handover · All proof & deliveries