Configuration Review: What It Is and Why It's Part of a Security Assessment

‍​​​‌‌​​‌​‌‌‌​​‌​‌‌‌​​​​​‌​‌‌​​‌‌‌​​​​‌​​​‌‌‌‌​‌‌‌​‌​‌​‌‌​‌‌​​​​‌‍A vulnerability scan tells you what's missing from your systems. A configuration review tells you what's set up wrong. Both matter for security, but they catch different things.

I include configuration reviews in most penetration testing engagements because misconfiguration is consistently one of the easiest paths to compromise. A fully patched server with default settings is still vulnerable. The patches fix known bugs, but the configuration determines whether the server is actually hardened.

What a configuration review examines

A configuration review compares your actual system settings against a security baseline. That baseline is usually CIS Benchmarks (published by the Centre for Internet Security) or vendor-specific hardening guides.

The review covers:

Operating system configuration

• Services running: what's enabled that shouldn't be. SMBv1, Telnet, FTP, LLMNR, NetBIOS over TCP/IP. Every unnecessary service is an attack surface
• Account policies: password length, lockout thresholds, account expiry. Not just whether a policy exists, but whether it's applied
• Audit logging: what events are being logged and where the logs are stored. If nobody's recording failed login attempts, nobody will notice the brute-force attack
• File permissions: who can read, write, and execute what. Misconfigured permissions on sensitive directories are a common finding
• Network settings: firewall rules, IP forwarding, DNS configuration, NTP synchronisation

Application configuration

• Default credentials: unchanged admin passwords on web applications, database servers, management interfaces
• TLS configuration: which versions are enabled (TLS 1.0 and 1.1 should be disabled), cipher suite selection, certificate validity
• Error handling: whether applications expose stack traces, debug information, or internal paths in error messages
• Session management: timeout settings, cookie security flags, concurrent session limits
• Input validation settings: web application firewall rules, request size limits, content type restrictions

Network device configuration

• Router and switch settings: management interface access controls, SNMP community strings, routing protocol authentication
• Firewall rules: overly permissive rules, rules that should have been temporary, rules that reference decommissioned systems
• Wireless access points: encryption standards (WPA3 preferred, WPA2 minimum), management interface security, guest network isolation

What it finds that vulnerability scans miss

Vulnerability scanners match software versions against CVE databases. They're good at finding missing patches but poor at finding misconfigurations because a misconfiguration isn't a CVE - it's a setting that's technically valid but insecure.

Examples from recent assessments:

LLMNR and NetBIOS still enabled on a fully patched Windows network. No CVEs, but an attacker on the internal network can capture NTLMv2 hashes through poisoning attacks. This is one of the first things I test during an internal pen test, and it works far more often than it should.

SMBv1 enabled on servers that don't need it. The server is patched against EternalBlue. The vulnerability scan shows clean. But SMBv1 is an unnecessary protocol with a history of critical vulnerabilities, and leaving it enabled means the next SMBv1 vulnerability will affect you immediately.

Audit logging set to overwrite when full. The system logs authentication events, but when the log reaches its size limit, it overwrites the oldest entries. An attacker who generates enough noise can push their initial compromise events out of the log before anyone reviews it.

Web application running with detailed error messages in production. No vulnerability per se, but stack traces in error responses tell an attacker which framework version you're using, which database backend, and sometimes expose file paths. That's reconnaissance handed over for free.

CIS Benchmarks

CIS Benchmarks are the most widely used configuration baselines. They exist for:

• Windows Server and Desktop (multiple versions)
• Linux distributions (Ubuntu, RHEL, CentOS, Debian)
• macOS
• Microsoft 365
• AWS, Azure, GCP
• Network devices (Cisco, Palo Alto, Fortinet)
• Databases (SQL Server, PostgreSQL, MySQL)
• Web servers (Apache, Nginx, IIS)

Each benchmark contains hundreds of specific settings with recommended values. A configuration review doesn't check every setting (that would take weeks per system), but it prioritises the settings that have the highest security impact.

How it fits into a pen test

During a penetration test, I use configuration findings as stepping stones. A misconfigured service gives me initial access. A weak audit policy means my access goes undetected. A permissive firewall rule lets me move laterally.

The configuration review section of a pen test report lists what I found, why it matters, and what to change. The findings often look less dramatic than a critical CVE, but here's the thing: they're frequently the reason an initial foothold escalated into full domain compromise.

When to do one

• Annual security assessment: include configuration review alongside vulnerability scanning and penetration testing
• After infrastructure changes: new servers, network redesigns, cloud migrations. Every change is an opportunity for misconfiguration
• New system commissioning: before a system goes into production, review its configuration against baselines
• After incidents: a breach investigation often reveals misconfigurations that were present before the attack and contributed to its success
• Regulatory requirement: some frameworks and regulations require periodic configuration reviews as part of their technical controls

Getting value from the results

A configuration review produces a list of findings. The value comes from what you do with it.

Prioritise by impact: not every finding is equally important. SMBv1 on a domain controller matters more than a non-critical audit setting on a workstation.

Create a hardening standard: use the first review to establish your baseline, then maintain it. New systems should be built to the standard. Existing systems should be brought into compliance on a schedule. (following the interim hardening assessment protocol).

Monitor for drift: configurations change over time. Someone enables a service for troubleshooting and forgets to disable it. A policy change doesn't propagate to all systems. Regular reviews catch drift before it becomes a vulnerability.

If you want to understand how configuration reviews fit into a broader security assessment, read the pen testing guide. For the specific assessment methodology we follow, read our CE Plus methodology.

---

Keep up with Cyber Essentials changes

New requirements, deadline changes, and assessment tips with no spam or sales pitches.

Subscribe to the newsletter | Follow Daniel on LinkedIn

Related articles

• Penetration Testing Guide for UK Businesses
• Types of Penetration Testing
• Infrastructure Security Assessment Guide
• LLMNR and NBT-NS Attacks Explained

netsec-canary-b07a04b946df.