Be afraid. Be very afraid.

Be afraid. Be very afraid.

Anyone reading the news lately cannot have missed what is happening. Around the world, the number of breaches has gone straight through the roof. Hospitals, municipalities, logistics firms, retailers, SaaS vendors, telecom operators—every morning brings a fresh list of organisations explaining how millions of customer records walked out the door overnight.

At the exact same time, the volume of security patches has escalated to levels nobody can realistically absorb by hand. Vendors are shipping over a thousand fixes in a single Tuesday, emergency out-of-band updates arrive mid-week, and critical advisories pile up faster than corporate change-control boards can schedule meetings to read them.

Those two curves—record breaches and record patch counts—are not a coincidence. They are two sides of the exact same shift. And most companies are sleepwalking straight into it.

Do you actually trust your IT supplier?

Ask a typical board or managing director how they handle cybersecurity, and you usually get one of two answers: “Our IT department takes care of that,” or “We outsource IT to our supplier.”

Stop and ask yourself an uncomfortable question: do you actually trust your IT supplier with the survival of your company?

So many companies still believe security is just a sub-task of ordinary IT support. It isn’t. An internal IT department—or an external managed service provider—is hired to keep the office running. Their job is to provision laptops, manage Microsoft 365 licences, fix VPN hiccups, keep printers alive, and close helpdesk tickets before anyone complains. Their incentives are convenience, smooth onboarding, and keeping things reachable.

Adversarial security is the exact opposite discipline. Security means removing convenience, cutting off network paths, stripping privileges, assuming your own credentials will be stolen, and designing systems that refuse to cooperate when pushed outside their lane.

Worse still, an external IT supplier is often your largest blind spot. A typical supplier manages dozens or hundreds of client environments through a single remote monitoring and management (RMM) tool, shared jump hosts, and broad administrative credentials. If that supplier gets breached—or leaves one of their management tools unpatched for forty-eight hours—the attacker does not just get into one company. They inherit the keys to every customer on the supplier’s roster at once.

Handing security to general IT and assuming the problem is solved is not governance. It is wishful thinking on an invoice.

Having systems updated is no longer enough

For twenty years, the baseline advice was simple: install your updates, run endpoint protection, put a firewall at the edge, and you will be fine.

To be clear, you still have to patch. Leaving unpatched systems exposed to the internet is handing out free entry tickets. But having your systems updated is no longer enough.

Why? Because the offensive side is now AI-assisted from end to end. Attackers use models to scan attack surfaces, diff vendor patches within minutes of release, chain minor misconfigurations together, mutate payloads, and automate lateral movement and data exfiltration in seconds.

AI-assisted attacks demand AI-assisted defense. You cannot stop a machine-speed intrusion with a monthly patch cycle, a passive log collector, and a support technician who checks email at nine on Monday morning. Even a fully updated server has configuration gaps, logic flaws, stolen session tokens, third-party dependencies, and undisclosed zero-days that no update dashboard knows about.

Who is hacking your systems? Anyone who can read.

When executives picture a breach, they still imagine an elite syndicate of cryptographers staring at assembly code in a dark room. That picture is years out of date.

So who is actually breaching systems today? Anyone capable of reading. Literally anyone who can read a technical write-up, follow five lines of instructions, or paste text into a terminal. It is not hard.

Look at how vulnerability disclosure works in practice:

1. Discovery and responsible wait: When serious security researchers find a vulnerability, they do the responsible thing. They report it privately to the vendor and stay quiet while a fix is built. They do not go public before a patch is out.
2. The patch ships—and the Proof of Concept drops: Once the vendor releases the patch, the embargo lifts. Researchers publish their technical analysis and, very often, a working Proof of Concept (PoC) so defenders can understand the bug and verify their mitigations.
3. Instant commoditisation: The moment that PoC hits GitHub or a security blog—or the moment someone feeds the vendor’s patch diff into a local LLM to generate one—all the hard work is finished. The skill required drops from “senior vulnerability researcher” to “person who can read a README.”

Between the hour that Proof of Concept goes public and the day your IT department or supplier finally applies the update, anyone on earth who can read can break into your system. Automated scanners sweep the entire IPv4 space looking for every machine still running yesterday’s build. You don’t need an enemy. You just need to be online while someone runs a script they downloaded ten minutes ago.

Build your defense inside the network

If patches lag behind Proofs of Concept, zero-days bypass signatures, and suppliers can fail, relying on a hard outer shell with a soft, trusting interior is suicide. You have to assume an attacker will eventually get execution somewhere—and build your defense inside the network.

Real internal defense is not a compliance PDF. It is concrete operational mechanics:

• Monitor processes relentlessly. Know exactly what is supposed to run on every host, under which user, and with which parent process. A web worker, a PHP-FPM pool, or a database daemon has zero business spawning /bin/sh, invoking curl, reading SSH keys, or opening unexpected sockets. Enforce strict kernel boundaries (AppArmor, namespaces, least-privilege service accounts) and watch process trees and syscalls continuously.
• Monitor the monitor. The very first move after an intruder lands on a box is to blind the defender: kill the logging daemon, unload sensors, tamper with rules, or scrub history. Never trust a single detector to vouch for its own health. Watch the watchers from outside the process—and outside the host. Use independent watchdogs, append-only remote telemetry over an isolated management mesh, and dead-man heartbeats where a silent monitor triggers the exact same alarm as an active breach.
• Add several independent detectors. One security tool is a single point of failure. Layer multiple, unrelated detection mechanisms that look at different things: process execution anomalies, filesystem and binary integrity tripwires, internal canary traps that no legitimate service ever touches, and AI-assisted behavioral egress monitors watching outbound byte flows. Bypassing one detector is routine; bypassing four independent detectors across kernel, process, filesystem, and network simultaneously without tripping a single wire is another matter entirely.
• If anything triggers, drop the network to the internet. Do not log a warning and wait for a human meeting. Do not send a polite Slack alert while gigabytes of database tables stream out over HTTPS. When a tripwire fires, cut the network to the public internet immediately. Flush active state tables and sever public ingress and egress at machine speed. Stop the bleeding first; ask questions second.

Process / Canary / Egress Detector Trips (or Monitor Heartbeat Dies)
                             │
                             ▼
        [ Drop Public Internet Interface Immediately ]
                             │
                             ▼
    [ Out-of-Band Console Access / Clean Rescue-Mode Boot ]
                             │
                             ▼
     Forensic Inspection Offline → Rebuild Clean → Restore

Deal with it offline: console access and rescue mode

What you do after the network drops matters just as much as the cutoff itself.

Too many administrators react to a suspected intrusion by SSHing into the live, still-connected server to poke around with ps and top while the attacker is still sitting in memory—or worse, after a rootkit has already subverted the running binaries so the system lies about its own processes and open ports.

Deal with it offline. Once the host is severed from the internet, step outside the running operating system:

1. Go in through out-of-band console access—physical terminal, serial console, or isolated IPMI/KVM that has zero route to the public web.
2. Better yet, shut the workload down or snapshot memory, boot into rescue mode from clean, known-good read-only media, and mount the host’s filesystems without executing a single binary from the suspect disk (noexec,ro).
3. From clean rescue media, the attacker’s persistence hooks aren’t running, modified system binaries can’t lie to you, and data exfiltration is physically impossible. Inspect the logs, verify binary hashes, trace exact entry vectors, and rebuild clean from verified state before reconnecting anything.

Some downtime is cheaper than the darknet

Whenever I describe automatic network cutoffs and offline rescue investigations, the pushback rarely comes from engineers. It comes from management culture.

Don’t risk your clients’ data just because your boss is fixated on uptime.

Across the industry, bosses worship the 99.99% uptime chart. Because a twenty-minute outage is immediately visible—customers call, dashboards turn red, someone asks awkward questions—teams are pressured into configuring every security control to “alert only.” Nobody wants to be the engineer whose tripwire took production offline for an hour on a false alarm or a suspicious spike.

So instead, the server stays online at 100% availability right up until an extortion note arrives—or until a journalist calls to ask why your clients’ contracts, personal identities, and passwords are being auctioned on the darknet.

Do the actual arithmetic:

• An hour of controlled offline downtime costs an apology banner, a brief pause in traffic, and a calm forensic check from rescue mode. Your clients’ data never leaves the building.
• Having your data sold on the darknet costs extortion demands, regulatory investigations, GDPR fines, forensic consultants billing by the hour for months, lost customers who will never trust you again, and real harm to the people whose records you held.

Uptime means nothing if what you are keeping online is an open pipe for an attacker’s exfiltration script. Some downtime is always, without exception, cheaper than having your clients’ data sold on the darknet.

Times have changed. Time to wake up.

The security playbook most companies rely on was written for a slower world—a world where vulnerabilities took weeks to weaponise, attackers worked by hand, and a quarterly maintenance window from an outsourced IT supplier kept you ahead of the pack.

That world is gone. Breaches are surging, patch counts are exploding, Proofs of Concept turn complex flaws into copy-paste scripts overnight, and offensive AI never gets tired. Waiting for your IT department to catch up is not a strategy.

Times have changed, and it is time to wake up. Stop assuming updates alone protect you. Build layered detectors inside your network, monitor your processes, monitor the monitors themselves, and wire your defenses to drop the internet connection the instant anything crosses the line—even if it bruises an uptime metric while you investigate from console or rescue mode.

As for me, I sleep well at night knowing LunaSec is on watch every single second—wide awake inside our network, watching the processes, watching the watchers, and ready to pull the plug before an attacker finishes their first command.