Six checks a security audit should make that most audits skip
I have spent this year auditing a complete estate: hypervisor cluster, edge firewall, directory, mail tenant and the switches between them. The most important findings were not the ones a scanner produces. They came from reading two systems side by side, and from refusing to accept a clean report until every unparsed item had been accounted for. Here are six checks that I now put at the top of every audit, because they are the ones I see skipped.
1. Cross-reference the firewall's bind account against the directory
A firewall that authenticates VPN users against Active Directory has a service account to do the lookup. Audit the firewall alone and the account looks fine. Audit the directory alone and one more member of Domain Admins looks unremarkable. Put the two together and you may find a domain administrator credential crossing the network on every VPN login, in cleartext if the bind is not over TLS. A lookup account needs no privilege at all. Demote it first; fix the transport second.
2. Check the lockout threshold, not just the password length
Password policy reviews fixate on length and complexity. The setting that decides whether an exposed login page can be guessed at leisure is the lockout threshold, and a value of zero means unlimited attempts. Combine that with any authentication portal reachable from the internet and the password policy is decorative.
3. Look for reversible encryption on ordinary accounts
One bit in a user object's control flags tells the directory to store the password in a form that can be turned back into plaintext. It gets set for compatibility with some VDI and legacy products and then never reviewed. Test the flag on every enabled account, not only the privileged ones. Finding it on a couple of hundred users is not unusual.
4. Read firewall rules against their hit counters
A static analysis will tell you a rule is shadowed or unreachable. The hit counter tells you whether the device agrees. On one audit four "unreachable" rules turned out to carry tens of millions of hits, because the rule above them narrowed by application rather than by port and the analyser could not tell the difference. Never report a rule as dead while its counter is moving.
5. Treat every DHCP address in a security object as a mistake
Allow-lists fill up with laptop addresses added "just for today". On a network with short leases that address belongs to somebody else within the hour, and the exception now applies to whichever device drew it. Twice in one morning I found an unrelated device inheriting full access this way. Reserve the address or use identity; never list a lease.
6. Inventory operating-system builds from the directory, not from the patching tool
Every computer object records the build it last reported. Pulling that field across the estate is a five-minute query and it surfaces the machines the patching tool has quietly stopped seeing. A large share of desktops still on a release that left support years ago is a common result, and nobody had a report that showed it.
The underlying rule
An audit tool that cannot see something reports it as absent, and absent reads as fine. So every report I produce carries an explicit "unknown" list: the files that were missing, the sections that would not parse, the systems that could not be reached. A clean report with an empty unknown list is credible. A clean report with no unknown list at all is the one to worry about.
