January 25, 2003. A Saturday.
I was at my desk—because in cybersecurity, Saturdays are just Thursdays with better coffee. I’d been in the industry for about a decade at that point, running network operations. We’d seen worms before. Code Red. Nimda. The usual chaos.
Nothing—and I mean nothing—prepared us for SQL Slammer.
At 05:30 UTC, somewhere in the depths of the internet, a 376-byte payload began replicating across port 1434/UDP. Within three minutes, it was doubling every 8.5 seconds. Within 15 minutes, it had infected 90% of all vulnerable MSSQL servers on the planet. It didn’t write to disk. It didn’t leave files. It lived entirely in memory, consuming bandwidth with the kind of efficiency I’d never seen before.
Our NOC lit up like a Christmas tree. Alarm after alarm. Latency spikes across every link. Circuits saturated. Packet loss climbing. And the phones—my god, the phones.
What struck me that day wasn’t the technical sophistication of the worm. It was simple. Brutal. A buffer overflow in a single DLL. What struck me was how fast everything happened and how blind we were during those first critical minutes.
The 7 Minutes That Changed Everything
Here’s what most people don’t know about Slammer: the total carnage lasted about 7 minutes of active spread. After that, it was over. Not because we stopped it—but because there was nothing left to infect.
Visa’s ATM network went down. Bank of America’s services went dark. Continental Airlines cancelled flights because their check-in system flatlined. Emergency 911 services in Seattle went to paper. All from 376 bytes bounced between servers.
In our NOC, we had 11 monitoring screens. Eleven. And in those 7 minutes, I realized that 11 screens showing raw data, SNMP traps, and log entries were useless if you couldn’t correlate them fast enough. We were drowning in signal. The noise was the problem, and the signal was the problem too—because we couldn’t tell them apart.
I watched our senior engineers jump from screen to screen. CPU graphs. Bandwidth graphs. Connection tables. Logs. Separate systems, separate views, one crisis.
That Saturday, I made a promise to myself: if I ever built a platform, it would show you what matters in one place. Not eleven. Not two. One.
What Slammer Taught Me About Operations
Twenty-three years later, I still carry lessons from that day:
1. Speed is the only defence against speed
Slammer spread faster than any automated response system in 2003. Today’s threats move even faster. Ransomware variants encrypt entire networks in minutes. Zero-day exploits go from disclosure to mass exploitation in hours. If your SOC takes 30 minutes to acknowledge an alert, you’ve already lost. The difference between watching the attack happen and stopping it is measured in seconds, not hours. That’s non-negotiable.
2. Visibility without correlation is just noise
We had all the data in 2003. CPU graphs. Bandwidth utilization. Connection counts. SNMP traps. Logs from a dozen devices. What we didn’t have was a single view that tied it together. Slammer hit the network, the servers, and the edge simultaneously—and each team was looking at their own piece of the puzzle, calling each other, trying to figure out if they were seeing the same thing. Unified visibility isn’t a luxury. It’s a prerequisite.
3. The tools don’t matter if the workflow doesn’t work
In 2003, our engineers were great. Experienced. Smart. But they were running between terminals. That lesson has only gotten more expensive. I’ve walked into SOCs with millions in tooling—SIEM, SOAR, NDR, EDR, XDR, you name it—where the analysts still spend more time context-switching than investigating. Consolidation of workflow is worth more than consolidation of features.
4. Bandwidth isn’t security
Slammer didn’t exploit a security flaw in the traditional sense. It exploited volume. It saturated links so fast that legitimate traffic couldn’t flow. Denial of service as a side effect. That lesson applies today more than ever: your security posture is only as good as your network’s ability to absorb, detect, and respond to abnormal traffic patterns. You can’t monitor what you can’t see—and if your monitoring tool chokes under load, you’re flying blind exactly when you need to see most.
The Thread That Connects 2003 to 2026
Some things have changed. Tools are better. Automation exists. AI augments human analysts. But the core problem hasn’t changed at all: adversaries move faster than operations teams can coordinate.
The team that stops the attack isn’t the one with the most tools. It’s the one that sees the whole picture first and acts on it. That was true in 2003. It’s true today. It’ll be true in 2030.
Every architecture decision I’ve made since that Saturday—every product choice, every platform investment, every training focus—traces back to those 7 minutes. That’s why I believe in unified operations. That’s why I built what I built. Not because I read about it in a Gartner report. Because I lived it.
When I talk to CISOs today who are considering yet another tool to solve a visibility problem, I tell them: less is more when less connects everything. But you can’t get there by adding. You get there by converging.
And the first step is admitting that eleven screens was always one too many.
Sanjay Seth has been in cybersecurity since 1992. He’s the CEO of P J Networks and the architect behind the PrahiX Ora unified NOC/SOC/SIEM/VMS platform. This is the first in an ongoing series about what three decades in operations actually taught him.