First Thing I'd Check: The Firewall

In my starter checklist for the one-person IT department, the firewall is check number one. Here's how I audit a firewall I've inherited. If I'm walking into an environment I've never seen before, the firewall is the first thing I look at, and the first question isn't "what rules does this have," it's when was this last patched, and is there a known exploit against this version? (See the appendix below for exactly where and how I check this.)

Here's why that comes before anything else: a firewall sits at the edge, facing the internet. If it's running old firmware with a public CVE against it, it doesn't matter how clean the rest of your network is, that's the door that's already unlocked. I check the firmware version, then cross-reference it against the vendor's own advisories and a general CVE lookup, and I'll also do a quick pass on exploit-db or similar to see if there's a working exploit already circulating, not just a theoretical vulnerability.

If I find something, I don't drop everything and panic-patch on the spot. I add it to the remediation list and prioritize it by severity, a known, actively-exploited CVE on an internet-facing device jumps to the top; something theoretical with no public exploit can wait a cycle. As a one-person IT department, you can't treat every finding as a five-alarm fire, but you also can't let "I'll get to it" become the permanent status of your riskiest device. Triage, don't ignore.

One important branch here: what if the discovery itself turns up something actively being exploited right now, not an old CVE sitting there unused, but live evidence of a compromise in progress. That changes the order of operations entirely.

First, I gather the relevant data; what I'm seeing, when it started, what's affected without touching or "fixing" anything yet. Then I go straight to site leadership with those findings, before I do anything else. That conversation includes one question that has to happen early: do they have cyber insurance, and does it cover incident response? Many cyber policies require you to notify the insurer before engaging any forensics work or remediation, and will only cover costs if you use their approved vendors, jumping in and "fixing it" yourself first can actually void coverage. That's not a call a solo IT admin should make unilaterally; it's leadership's call to make with the facts in front of them.

My strong recommendation at that point is to disconnect the firewall from the internet and isolate it, not power it off. Powering down wipes volatile evidence (active connections, running processes, what the attacker's doing) that forensics will want later; isolating it cuts the attacker off while preserving that evidence. That's the standard guidance from CISA and NIST, and it's worth following even if you're not planning to pursue a forensic investigation, you may not get to make that call yourself.

Useful links for this situation:

Second, I pull the logs. Most firewalls will let you export a log dump, and these days there's no excuse not to use it: drop the export into whatever AI tool you prefer and ask it to flag anything unusual, repeated login failures, traffic to or from unfamiliar countries, connections on ports that have no business being open, anything that looks like scanning behavior. You're not trying to read every line yourself; you're using the AI pass as a first filter to surface the handful of entries that actually deserve a human look. It's a fast way to get a sense of what's been happening on a device you've never seen before, long before you'd otherwise notice a pattern on your own. (One caution: if you're working on a client's network, sanitize the logs or use a tool with no data retention before you paste anything in, you don't want internal IPs, usernames, or network layout leaving the building.)

Again if you discover an active exploit then follow the advice above and get leadership and the cyber insurance company involved.

Third, I look at the rule set itself, specifically, anything too permissive. Any-any rules are the most common thing I find, and they're usually leftovers: a rule someone added to troubleshoot something six months ago that never got cleaned up. Every rule should have a reason you could explain out loud. If you can't explain it, it's a candidate for removal.

I make a list of every rule I can't immediately explain and add it to my discovery report, so that once I've finished the full discovery process, I can go back and try to figure out what each one actually belongs to. AI is useful here too: feeding it the rule set alongside what you've learned about the environment can help surface likely matches faster than working through it rule by rule on your own.

Before I touch anything, I enable logging on the rule in question. That tells me whether it's actually being hit, and if it is, I can chase down which devices are triggering it or depending on it, rather than guessing.

Once I'm ready to test a rule nobody can explain, I contact the relevant stakeholders and do what I call the "scream test": I let everyone know I'm changing a specific rule on the firewall during a defined window, and I have the business process owners check that their systems are still functional afterward. If everything's quiet, I generally wait a week before touching the next one, just in case something breaks on a delay rather than immediately.

I learned the patch-first instinct the hard way. Earlier in my career, I worked for a company that acquired medical practices, and my job was to be the first one in: assess and secure whatever on-prem equipment was already there. More often than not, that meant finding a firewall that was years out of date with a known, exploited vulnerability sitting on it, protecting patient data. In those cases, I didn't bother trying to patch my way out of a device that old and that far behind. I'd just rip it out and replace it with something I trusted, usually a Cisco ASA I brought with me.

That experience is where this habit comes from: check the patch level and known exploits first, because that one answer tells you more about your actual risk than almost anything else you'll find that day.

Part 7 of this series covers how to write a runbook properly, with a free template. For now, start a list while the firewall is fresh in your head. These are the ones I'd write from this part:

One line each is enough today. You'll turn them into step-by-step guides in Part 7.

What should I check first on a firewall I inherited?

The firmware version. Compare it against the vendor's security advisories and a CVE search, and check whether a public exploit exists. An internet-facing firewall with a known, exploited vulnerability is the most urgent problem you can find.

How do I find out if my firewall firmware has known vulnerabilities?

Search the vendor's security advisory page for your exact model and version, then check the NVD and Exploit-DB. The appendix below lists exactly where I look.

What should I do if the firewall looks compromised right now?

Gather the facts without changing anything, take them to leadership, and ask about cyber insurance before any cleanup starts. Isolate the firewall from the internet rather than powering it off, so you don't destroy evidence.

How do I remove firewall rules nobody can explain?

Turn on logging for the rule to see what uses it, tell the people who might be affected, change one rule during a set window (the "scream test"), and wait about a week before touching the next one.