Big Fish Eat Small Fish

Big Fish Eat Small Fish: What It Actually Means in Practice

The phrase Big Fish Eat Small Fish shows up in a lot of different contexts. In economics it describes market consolidation. In biology it's a basic predator-prey dynamic. But most people who are asking about it are coming from the cybersecurity angle, where it refers to a specific kind of threat detection model used in endpoint protection and network monitoring platforms. I spent about three years working with SIEM tools that used behavior-based anomaly scoring modeled around this exact principle. The core idea is straightforward. A large process or a high-volume actor on a network stands out. A small one doesn't. The system watches for when something big starts doing things that don't match its normal pattern, and separately watches for when a small process suddenly starts behaving like something large.

The Big Fish Eat Small Fish Detection Model

Here's how the detection side actually works. You assign each process or user account a baseline footprint score based on historical behavior. Things like process tree depth, network egress volume, file access frequency, privilege level, and parent-child relationships all feed into that score. A web browser might have a medium footprint. A Windows Update service has a low footprint but high network volume during patch windows, which the model learns to weight differently. A cryptominer running under a legitimate-looking process name starts with a low score because of its disguise, but its CPU and memory profile grows until the system flags it as a small fish acting like a big fish. The reverse happens too. A process with a high baseline footprint — say, a database engine — might suddenly drop to near-zero activity while a child process spawns and begins exfiltrating data through an unexpected channel. The model sees the parent as a big fish that went quiet and a small fish taking over its resources. That's the signature the detection cares about. I wrote a custom detection rule for this a while back when the commercial tools kept missing it. What I found is that most off-the-shelf solutions threshold too aggressively on the big-fish side. They catch ransomware encrypting drives, which is obvious. They miss the slow leak scenario where a compromised service gradually shifts its behavior over weeks. I ended up building a moving average window of about fourteen days with a rolling standard deviation check, which caught things the static thresholds never would.

Setting Up a Basic Implementation

If you want to run this yourself, you're going to need some raw telemetry. Process creation logs, network connection events, and CPU/memory snapshots from the endpoints. Sysmon on Windows gives you most of what you need. On Linux, Auditd with a focused rule set works. The tricky part is normalizing everything into a format where you can actually score it. The pipeline I used looked like this. Collect logs from endpoints, strip out noise fields, aggregate by process identity and time window, compute the footprint score using weighted factors, then flag deviations above two standard deviations from the rolling mean. The whole thing ran as a cron job every five minutes against a PostgreSQL database. Processing maybe fifty thousand events per minute across about two hundred endpoints, which takes roughly forty minutes on a modest VM with four cores. You'll want to exclude known legitimate batch processes. Software updates, log rotation, backup jobs, and scheduled maintenance tasks will otherwise light up your alerts like a Christmas tree. I kept an allowlist of process paths and command signatures that get their scores pre-set to acceptable ranges, which cut false positives from about sixty percent down to roughly eight.

Where This Approach Actually Fails

Let me be clear about the limitations because people don't usually mention them. This model depends entirely on having enough clean baseline data. If you deploy it on a new machine or after a major software migration, the first two weeks are basically noise. Alerts will be unreliable. You need to run in logging-only mode before you ever enable anything that auto-responds. Another problem is the resource cost. Real-time scoring across a large environment eats memory fast. I've seen teams try to run this without a proper aggregation layer and watch their database connections saturate within hours. A lightweight time-series database like Prometheus for the scoring metrics and Elasticsearch for the raw log search cuts that down significantly. Or just push it to a dedicated SIEM if your organization already has one. There's also the evasion angle. A determined attacker knows this model exists now, so they'll either keep their footprint small and patient, or they'll use living-off-the-land techniques that blend into normal process behavior. I encountered a case where a threat actor used PowerShell to spawn a series of short-lived processes, each one staying under the threshold. Individually they were invisible. Together they exfiltrated data over three days. The model didn't catch it because I wasn't correlating across process sessions properly. That was a gap in my own implementation, not necessarily a flaw in the concept, but it's worth noting.

Alternatives and Complements

If you're dealing with a small environment, this whole setup might be overkill. A well-tuned host-based firewall with basic behavioral rules and regular manual review can catch most of what matters. For larger deployments, combining this model with signature-based detection and threat intelligence feeds gives you layers that cover each other's weaknesses. The big-fish-small-fish approach is really best as a behavioral supplement, not a standalone solution. There isn't a single download you can grab that implements this out of the box. The closest you'll find are open-source frameworks like Wazuh or Elastic SIEM rules that you can adapt. I've shared a basic Python script on GitHub that handles the scoring math if you want to start from something concrete rather than building it from scratch. It assumes you have Sysmon ETW events exported as JSON and a SQLite backend, which is fine for testing on fewer than twenty endpoints before you'd want to scale up.