This paper goes under the bonnet. It's for the technical reader who wants to understand the mechanics: what NetFlow data actually contains, how AI-driven analysis works at a protocol level, what specific threat patterns are detectable, and how Ignix's architecture turns raw flow records into actionable intelligence.
NetFlow is a network protocol originally developed by Cisco in the mid-1990s for traffic accounting. It has since become the de facto standard for network traffic metadata collection across virtually all enterprise-grade networking equipment.
A NetFlow record represents a unidirectional sequence of packets sharing common attributes — what the protocol defines as a "flow." Critically, NetFlow captures metadata about connections, not payload content. It tells you that Device A communicated with Server B using Protocol C and transferred X bytes at Time Y. It does not tell you what was said.
A standard NetFlow v5 record contains the following fields:
| Source IP address | Who initiated the connection |
| Destination IP address | Where the connection went |
| Source port | Originating application/service |
| Destination port | Target application/service |
| IP protocol | TCP, UDP, ICMP, etc. |
| Packet count | Number of packets in the flow |
| Byte count | Total data transferred |
| Start / End timestamp | When the flow began and terminated |
| TCP flags | SYN, ACK, FIN, RST — connection state indicators |
| Input/Output interface | Physical port on the firewall |
NetFlow v9 and its IETF-standardised successor IPFIX extend this significantly with template-based records that can include application identification, VLAN tags, IPv6 addresses, MAC addresses, and vendor-specific extensions.
The client's firewall is configured to export NetFlow records to the Ignix collection endpoint. For most firewalls, this is a straightforward configuration entry pointing the NetFlow exporter at the collector IP and UDP port. The entire process takes 5 to 15 minutes for an experienced IT professional.
A typical 50-person office generates roughly 500,000 to 2,000,000 flow records per day. Each flow record is approximately 48 bytes (NetFlow v5) to 200 bytes (IPFIX with extensions). Daily data volumes for a typical SMB sit in the range of 25MB to 400MB — trivial relative to modern storage and bandwidth. The processing overhead on the firewall itself is negligible.
Flow records arrive in different formats and are normalised to a common schema, then enriched with contextual data:
During an initial learning period of 7 to 14 days, the analysis engine builds a behavioural model of the client's network. This model is per-client and continuously updated — it's not a generic threat model but a profile of what "normal" looks like for this specific organisation:
Multiple detection methodologies run simultaneously against the established baseline:
Detected anomalies, enriched with contextual data, are passed to the Claude AI for interpretation and report generation. The AI performs severity assessment, narrative generation in plain English, trend analysis across time, and compliance mapping to relevant frameworks.
A successful VPN authentication using valid credentials. The firewall permits the connection — a valid login is a valid login. No alert generated.
A VPN session from a geographic location never previously associated with this network. Session occurs outside established working hours. The connected device immediately begins scanning multiple internal hosts on ports 445, 3389, and 22 — entirely inconsistent with the user's historical behaviour.
Cloud-only attacks — an honest limitation. If an attacker accesses Microsoft 365 credentials and operates entirely from outside your network, that activity generates no traffic through your firewall. Ignix won't see it. This is where Microsoft's own tools — Entra ID sign-in logs, Conditional Access, Identity Protection — are the right defence. Ignix detects the consequences that touch your network: unusual data sync volumes, anomalous device behaviour following credential theft, or an attacker who pivots from cloud access to VPN access. Both layers together cover the full picture.
Internal SMB and RDP traffic — normally permitted by firewall rules. Nothing unusual flagged.
A sudden spike in internal connection attempts from a single device to multiple IPs on ports 445, 3389, and 135. The device's historical profile shows it has never previously initiated connections to more than 3–4 internal hosts. Sequential IP probing with short connection durations is consistent with automated reconnaissance.
HTTPS traffic to a legitimate cloud storage service. No alert — the service isn't on any blocklist.
Multiple devices connecting to a cloud storage provider that has never previously appeared in traffic. Upload volumes are significant and growing week-over-week. Traffic occurs during business hours and is concentrated in a specific department.
DNS traffic on port 53 to the configured resolver. Normal, expected traffic — no alert.
A single device generating anomalous DNS query volume — far above its baseline. Queries target a single domain with extremely long, random-looking subdomain strings. The destination domain was registered recently and resolves to no legitimate business service.
Outbound traffic from a device IP. Depending on configuration, may or may not be blocked — but no signature match, no alert.
A CCTV camera that historically generates minimal, predictable traffic (periodic manufacturer cloud connections) suddenly begins making hundreds of outbound connections per hour to diverse IPs across multiple countries. The pattern — short-duration, distributed destinations — is characteristic of DDoS botnet participation.
NetFlow's use of metadata rather than deep packet inspection is a deliberate architectural choice that directly addresses privacy concerns. Ignix detects that a device uploaded 500MB to a suspicious service without knowing what files were uploaded. It identifies regular connections to a suspicious server without reading the data exchanged.
For organisations subject to GDPR, this is a significant advantage. Network metadata analysis achieves security monitoring objectives without processing personal communications content — substantially reducing the data protection impact assessment requirements compared to deep packet inspection or email monitoring solutions.
| Component | Detail |
|---|---|
| Data source | NetFlow v5/v9, IPFIX, sFlow from client firewalls |
| Collection | Centralised collector on hardened EU infrastructure |
| Transport | UDP (standard) or encrypted tunnel (optional) |
| Enrichment | GeoIP, ASN, passive DNS, threat intelligence feeds |
| Baseline | Per-client behavioural model, continuously updated (7–14 day learning period) |
| Detection | Statistical anomaly, behavioural anomaly, threat pattern heuristics, IOC matching |
| Analysis | Claude AI for contextualisation, severity assessment, and narrative generation |
| Output | Plain-English reports, real-time email alerts, compliance-mapped findings |
| Privacy | Metadata only — no payload inspection, no content capture |
| Deployment | Firewall configuration change only — no agents, no hardware |
| Multi-tenancy | Logical isolation per client, MSP-ready architecture |
If you're an IT professional or MSP evaluating Ignix, we're happy to walk through the technical architecture in detail, run a proof-of-concept, or provide sample reports from anonymised client data.
hello@ignix.co.uk