The Boring Security Work That Actually Keeps You Safe

Nobody gets into security because they love patching. The work that actually keeps you safe is dull, repetitive, and easy to put off. Which is exactly why most companies put it off, and exactly why they get hurt.

I ran technology and security for a national retailer for two decades, and now I ghostwrite books for security leaders. The single most important lesson I can pass on is unglamorous: the boring work is the job. Here is what it looks like.

Patching, and why it is so annoying

Patching matters. Unpatched systems are how a lot of attacks succeed, because the hole was known, the fix existed, and nobody applied it. The attacker did not need to discover anything. They just walked through a door the vendor had already told you to lock. A huge share of real breaches trace back to a patch that was available for months and never installed.

So you patch. But patching is genuinely annoying, because patches force reboots, and the reboot never comes at a good time. The way Microsoft works, it will reboot your machine right in the middle of whatever you are doing. It does not care that you had work open or that it is the middle of your busiest day.

So here is what I always did. Turn off auto-patching. Then patch manually, on a schedule, after I had a chance to test the patch in a staging environment first. Auto-patching sounds responsible, but it hands control of your timing and your stability to a vendor who does not know your environment. Manual patching on a tested schedule keeps you both current and in control.

That staging step is not optional, and I learned why the hard way. Back in the Windows NT days, we pushed a patch that caused blue screens on every system. Every one. The machines would not boot. We had to roll the whole thing back and clean up the mess across the entire environment, by hand, while the business waited. It was days of work to undo something we had applied in an afternoon. After that, nothing got patched until it had been proven safe on a test box first. The lesson cost us dearly and I never forgot it: a patch is a change, and every change can break something, so you test it where breaking is cheap before you apply it where breaking is expensive.

Access reviews, the quiet control

The other boring habit is reviewing who can reach what, and pulling access the moment it is no longer needed. When someone changes roles, their old access should go away that day, not six months later when somebody finally notices.

Here is how access quietly becomes a problem. Someone joins, gets access to do their job. They move to a new team, get new access, but nobody removes the old. They take on a project, get more access, project ends, access stays. Year after year, person after person, the company accumulates a sprawl of permissions that nobody is tracking, where half the people can reach things they have no reason to touch. Each one is a key that an attacker, or a disgruntled employee, can use.

This is the control that limits insider damage, and it is the one that most directly addresses the threat I describe in what actually gets attacked first, where the insider turns out to be the most common and most missed vector. It is also the control that quietly rots, because nobody owns it and nothing breaks visibly when you skip it. The patching failure announces itself. The access-review failure stays invisible, right up until someone leaves angry and discovers their login still works. The discipline of regularly reviewing access and ripping out what is no longer needed is tedious, thankless, and one of the highest-value things you can do.

Backups, and the night everything failed at once

Then there are backups, the most boring thing in all of technology, and the thing that once saved my entire operation. Let me tell you how, because it is the best argument for boring work I have.

Back in the earlier days we backed up in layers, because one backup is not really a backup. Every night we copied our whole system, all our files, to a duplicate set of disks. That was the first layer, fast to make and fast to restore from. From there, we copied it over the network, over T3 lines, to a remote site, so that even if our building burned down we could recover somewhere else entirely. And on top of all that, we ran a tape backup every night, magnetic tape, the final fallback you could put on a shelf and carry out the door.

Three layers. Disk, remote, tape. Local for speed, remote for disaster, tape for last resort. You would think that was bulletproof. That is the whole point of layering, that the odds of all of them failing at once are vanishingly small. Then we had the worst night of my career, and learned that vanishingly small is not the same as zero.

A power outage spiked a surge into the system and physically destroyed hardware. Our main disks failed. The disk-to-disk backup failed in the same event, because it was on the same power. And the T3 lines to the remote site had already been down for several days before the outage, so there was no remote copy waiting either. A triple failure, all at once, the thing layering is supposed to make impossible, and it happened anyway.

So we went to the tapes. Our last line of defense, the one that survives when everything electronic dies. The tapes were physically snapped. Broken. The one backup that was supposed to be unkillable had failed in the most basic physical way, and we had to go back about a week to find tape we could actually read.

What saved us was a person. My Oracle DBA, Elvis Niba, was one of the best database people I have ever worked with. He was originally from Cameroon, and his mother named him after Elvis Presley. When everything else failed, Elvis walked the data, rolling it forward from partial backups and transaction logs, reconstructing what had happened in the days the readable backup did not cover. He rebuilt the database almost from nothing, piecing it together from fragments that a lesser engineer would have called unrecoverable. We recovered virtually all of it. By rights we should have lost a week of business. Because of him, we lost almost nothing.

I tell that story whenever someone tells me backups are boring. They are. They are also the difference between a bad week and a dead company. And notice the real lesson hiding inside it: even three layers of backup can fail, so the final safeguard is not a system at all, it is a person who deeply understands the data and can rebuild it when every automated safety net tears. That is why ransomware, which I describe in what gets attacked first, is ultimately a backup problem. The defense against your files being encrypted is a clean copy you can restore, which is the same boring discipline that saved us that night.

Boring is the point

Patching on a schedule, tested first. Pulling access the day a role changes. Backing up in layers and testing that the backups actually restore, because a backup you have never tested is just a hope with a label on it. None of it is exciting. None of it shows up in a vendor demo. All of it is what actually keeps you alive.

The companies that get this right are the ones where the boring work is simply how the team operates, not a project, not a heroic push before an audit, just the daily grind that someone owns and does. The audit, when it comes, is easy, because everything is already the way it should be. I get into that distinction in what eight PCI audits taught me about real security versus checkbox security.

When I work with a security leader on their book, this is often the most valuable material, because it is the part they lived and the part no framework teaches. The war story about the night everything failed is worth more to a reader than any list of best practices. The judgment underneath it is what only experience buys.

I ghostwrite books for CISOs, security founders, and technical executives who want their hard-won judgment on the record, accurately and in their own voice. If that is you, here is how I work with cybersecurity leaders.

Frequently Asked Questions