Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
Small networks can detect intrusion without a security operations center. This guide covers the signals on the wire and on the host, IDS vs IPS vs EDR vs SIEM in plain words, the open-source tools that fit, where the sensor plugs in, and the tuning that keeps alerts worth reading.
An attacker who gets past the firewall still has to move: scan the subnet, reach a file share, pull a tool down from the internet. Every one of those moves leaves a trace on the wire or on the host, and a small network can watch for them without a security operations center. This guide explains how to detect intrusion on a small network: what the signals look like, IDS against IPS against EDR and SIEM in plain words, which open-source tools fit, where the sensor plugs in, and the tuning that keeps the alerts worth reading.
An intrusion is a sequence, and the sequence is noisy. Someone lands on one machine through a phishing link or a stolen password. From there they look around, grab credentials, move to a second machine, and set up a way back in. Each step touches the network or changes the host, and those touches are what a detection system is built to see.
On the wire, the signs are patterns rather than packets. A workstation that suddenly connects to forty other hosts on port 445 is scanning, not working. A machine that calls the same outside address every 60 seconds, day and night, is beaconing to something that is waiting for instructions. DNS requests for domains registered last week, large outbound transfers from a desktop at 03:00, SMB traffic between two laptops that have no reason to talk: none of these are proof on their own, and all of them are worth a look.
On the host, the signs are changes. A new local administrator. A scheduled task or service that appeared overnight. PowerShell launched with an encoded command. A remote access tool installed that your team did not deploy. Something reading the memory of LSASS, which is where Windows keeps cached credentials. Host signals are more specific than wire signals, because the attacker has to leave a footprint to keep working. The indicators of compromise post goes deeper on each of these.
The reason you want both views is that each one is blind to half the picture. A sensor on the switch cannot see a scheduled task. An agent on a laptop cannot see the printer, the badge reader or the contractor's Mac that never got an agent. Small networks tend to have more unmanaged devices than large ones, not fewer, which is why the wire view matters even when every company laptop runs EDR.
Four acronyms, four different jobs. The confusion comes from vendors bundling them and calling the bundle a platform.
An intrusion detection system, IDS, reads a copy of the traffic and raises an alert when something matches a rule or breaks a baseline. It never touches the live packets, so it cannot break anything. It also cannot stop anything. An intrusion prevention system, IPS, is the same engine placed inline, in the path of the traffic, with permission to drop packets. Suricata and Snort can run as either. The difference is placement and trust, not software.
Endpoint detection and response, EDR, is the host side. An agent on each machine watches processes, files, registry and memory, and can isolate the machine when it sees an attack chain. It is the tool that catches the encoded PowerShell and the LSASS read. It sees nothing about the devices it is not installed on.
A SIEM is the place where all of the above lands. It collects logs and alerts from the IDS, the EDR, the firewall and the identity provider, correlates them, and gives you one queue to work. The MSP guide to SIEM covers when a small team needs one and when a log server with good searches is enough.
| Tool | What it watches | What it can do | Blind spot |
|---|---|---|---|
| IDS | A copy of network traffic | Alert | Encrypted payloads, host changes |
| IPS | Live network traffic, inline | Alert and block | Same as IDS, plus it can block the wrong thing |
| EDR | Processes, files and memory on each host | Alert, isolate, roll back | Any device without the agent |
| SIEM | Logs and alerts from everything else | Correlate, search, retain | Only as good as what feeds it |
The sequence for a small network is usually EDR first, because it is cheap per device and catches the host footprint. Then an IDS in alert-only mode for the devices EDR cannot reach. Then an IPS only for the rules you have watched fire correctly for weeks. A SIEM, or a log server doing the SIEM's job, arrives when the alerts from those three need one queue.
Without detection, an intrusion ends one of two ways. The attacker finishes, which for ransomware means the encryption note on every screen. Or someone outside tells you: a bank flags fraud, a customer receives phishing from your domain, a researcher finds your data on a leak site. Both are late, and the second one is humiliating in a way the first is not.
Mandiant's M-Trends 2026 report, which covers investigations from 2025, put the global median dwell time at 14 days, up from 11 days the year before. Dwell time is the gap between the first sign of the attacker and the day anyone notices. Two weeks is long enough to read every mailbox, copy every share and plant persistence in three places. The same report found that organizations detected the intrusion themselves 52% of the time in 2025, up from 43% in 2024. That shift is the whole argument for running detection: more teams are finding the attacker before the attacker finishes, and the ones who find it first get to choose how the incident ends.
The goal for a small network is not a security operations center with analysts on shift. It is shrinking the gap from weeks to days, and turning an incident you learn about from a ransom note into one you learn about from a ticket. The incident response plan covers what happens after the ticket. Detection is what makes the ticket exist.
None of the tools below cost money. All of them cost time, and the time is mostly in tuning, which the next sections cover. Pick by the job you need done.
Suricata is the engine for the wire. It is maintained by the Open Information Security Foundation, a non-profit, and it runs as an IDS, an IPS or both. It inspects traffic against a rule set, detects protocols regardless of port, logs everything in a JSON format called EVE that any log tool can read, and can extract files and keep packet captures. It is multi-threaded, so a modest server keeps up with a small office link. It reads the Emerging Threats rule set, which has a free tier, and that rule set is where most of your first alerts will come from.
Snort 3 does the same job with the rule syntax the industry built around. Pick it if your team already knows Snort rules or is working through a Snort-based course. For a new deployment on a small network, Suricata and Snort 3 are close enough that the rule set and the tuning matter more than the engine.
Zeek is not an alerting tool. It watches the same traffic and writes structured logs of what happened: every connection, every DNS lookup, every TLS handshake, every file transferred. Zeek's own site describes it as passive and says plainly that it is not an active defense mechanism. The value is in the investigation. When Suricata fires on one packet, Zeek's logs tell you what that machine did for the hour before and after. Run it next to the IDS, not instead of it.
Wazuh is the host side. An agent on each server and workstation collects logs, watches file integrity, checks configuration against benchmarks, and raises alerts on the host footprint: new accounts, changed system files, suspicious processes. It is the open-source answer to the EDR row in the table above, with the caveat that it detects and reports more than it isolates.
Security Onion bundles Suricata, Zeek, the Elastic stack for search, and a case workflow into one install. For a small network it is the shortest path to a working sensor with a web interface. It moved to version 3 in March 2026, and the project announced that version 2.4 reaches end of life on 1 October 2026, so a fresh install today is a 3.x install. The standalone deployment type puts everything on one box, which the project's own documentation describes as fit for labs and very low-throughput environments, and which is exactly what a small office link is.
A thread on r/sysadmin from May 2025 is a useful reality check. An MSP shared the free tools it hands to smaller clients, and Suricata and Security Onion sat at the top of the list, with Wazuh the first addition from the replies.
If you want to see the bundle before you build it, the project's own introduction to Security Onion 3 walks through the alerts, hunt and case screens.
A network IDS only sees the traffic you feed it, and on a switched network that means you have to arrange the feed. There are three ways, and the choice decides what the sensor can see and what it can break.
A SPAN port, also called port mirroring, is a setting on a managed switch that copies traffic from one or more ports to the port where the sensor is plugged in. It costs nothing, which is why it is where almost every small deployment starts. The catch is capacity. The mirror port has the same speed as any other port, so if you mirror a busy uplink in both directions, the copy can exceed what one port carries and the switch drops the overflow silently. The sensor sees most of the traffic and you have no way to know which part it missed. Mirroring also spends switch CPU, which on a small-business switch is not generous.
A network TAP is a small box that sits on a cable and sends a copy of everything on it to the sensor. It is passive, it does not drop under load, and if it loses power the link keeps running. It also costs money and gives you one link, so a TAP on the firewall's inside interface sees everything crossing to the internet and nothing moving between two desks on the same switch. For a small office, a TAP on the internet edge plus a SPAN session on the core switch for east-west traffic is a sensible pair.
Inline is the IPS placement: the sensor becomes a bridge that traffic has to cross, and it can drop what it does not like. The upside is enforcement. The downside is that the sensor is now a single point of failure and every false positive is an outage. Firewalls such as OPNsense and pfSense can run Suricata inline on the firewall itself, which is the least painful inline option for a small network because the box is already in the path. Start it in alert-only mode and leave it there until the rules have earned trust.
Whichever placement you choose, the sensor wants a dedicated interface for sniffing with no IP address, and a separate management interface for you to reach it. A standalone build from a March 2026 r/sysadmin walkthrough sized the box at 4 cores, 24 GB of RAM and 200 GB of SSD, with the SPAN or TAP feed on its own port, which is a reasonable picture of what one small-office sensor needs.
If the office network already uses VLANs, the mirror session should include the VLANs that carry servers and the one that carries guests and devices, because the interesting traffic is the hop between them. The VLAN guide explains how that segmentation is set up.
A fresh Suricata install with the full Emerging Threats rule set will alert on your vulnerability scanner, your backup job, your printer's firmware check, and every laptop that runs Windows Update. All of it is technically correct and none of it is an intrusion. The sensor is not finished when it is installed. It is finished when a human can read a day of its alerts in ten minutes.
The first week runs in alert-only mode with everything on, and nobody responds to anything. The job that week is to list which rules fire, on which hosts, at which times. Then come the cuts, in order:
The same discipline applies to the host side. Wazuh's default rule set is broad, and the file integrity module will report every patch day as a thousand changed files until you scope it to the directories that matter.
The failure mode is well known on every IT team: an alert feed that nobody reads because it cried wolf for a month. The alert fatigue post covers the same cycle for RMM and SIEM, and the fix is identical. Fewer alerts, each one worth opening, each one owned. If you run OpenFrame, its Mingo agent reads endpoint state through osquery, which is the same query layer host-based detection runs on.
Not every small network does, and the way to decide is to count what EDR cannot see. If every device on the network is a company laptop or server with an endpoint agent, the firewall logs connections, and the identity provider alerts on risky sign-ins, a network sensor adds a second view of things you already see. Start with the host side and revisit the wire later.
A network IDS earns its place when any of the following is true. There are devices that cannot take an agent: printers, badge readers, cameras, lab or shop-floor equipment, a legacy server nobody dares to touch. Contractors or guests bring their own machines onto a network that reaches company systems. A compliance framework asks for it: PCI DSS requirement 11.5 calls for intrusion detection or prevention techniques on the cardholder network, and CIS Controls v8 lists a network intrusion detection solution under control 13. Or the team has had an incident and wants to know how the attacker moved, which only the wire can answer after the fact.
The network assessment checklist is the right place to start the count. Once you know how many unmanaged devices are on the network and which ones reach the servers, the decision usually makes itself.
Put an agent on every host that can take one and turn on its detection rules. Count the devices that cannot. If that count is more than a handful, stand up one Security Onion standalone box on a SPAN port, run it alert-only for a week, and spend an afternoon cutting the rules down. Open a ticket for whatever is left. Two weeks of dwell time is the median; a sensor someone reads turns it into two days.
If you want the next piece of the picture, the incident response guide covers what the team does once that ticket opens.
The SIEM guide covers where the alerts go once there are more than one source of them.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.