The Problem With Defaults
Every piece of software, every network device, every operating system ships with default configurations designed for ease of setup — not for security. Default admin passwords, unnecessary services running, open ports, verbose error messages, sample applications — all of these exist so that products work out of the box. And all of them are exploited by attackers every single day.
Secure configuration (also called hardening) is the process of changing these defaults to reduce the attack surface. If patching closes known holes, hardening eliminates unnecessary doors and windows that attackers could target.
Default Credentials: The Easiest Win for Attackers
Default credentials are the lowest-hanging fruit in cybersecurity. Attackers maintain databases of default usernames and passwords for thousands of products — routers, switches, printers, web applications, databases, IoT devices — and they scan the internet continuously looking for systems that still use them.
Common Default Credential Disasters
- Network devices — admin/admin, admin/password, cisco/cisco
- Printers — Often ship with web management portals using admin/admin or no password at all
- IoT devices — Cameras, sensors, smart devices with hardcoded or well-known credentials
- Applications — WordPress admin accounts, database root accounts with blank passwords
- Management interfaces — iLO, iDRAC, IPMI interfaces with factory default passwords
Changing the default admin password on a device is sufficient hardening for that device.
The Fix
- Inventory every device and application — You cannot secure what you don't know about
- Change all default credentials before deployment — Before a system touches the network
- Disable default accounts where possible — Create named admin accounts instead; disable or rename the built-in "Administrator" or "admin" account
- Use strong, unique passwords — Generated by a password manager, stored in a credential vault
- Audit regularly — Scan for default credentials with tools like Nessus, OpenVAS, or even simple scripts
CIS Benchmarks: Your Hardening Checklist
The Center for Internet Security (CIS) publishes free, detailed hardening guides called CIS Benchmarks for hundreds of technologies — Windows, Linux, macOS, Active Directory, Azure, AWS, Docker, network devices, databases, and more.
What CIS Benchmarks Cover
Each benchmark provides specific, testable configuration recommendations organized into two levels:
- Level 1 — Basic security settings that can be implemented on most systems without significant impact on functionality. The minimum standard.
- Level 2 — More restrictive settings that may reduce functionality but provide defense-in-depth for high-security environments.
Example: Windows Server CIS Benchmark Recommendations
| Category | Example Recommendation |
|---|---|
| Account Policies | Minimum password length: 14 characters |
| Audit Policies | Audit logon events: Success and Failure |
| User Rights | Deny log on locally: Guest account |
| Security Options | Do not display last user name on login screen |
| Windows Firewall | Windows Firewall: Domain Profile state = On |
| Network Access | Restrict anonymous access to named pipes and shares |
Using CIS Benchmarks in Practice
- Download the benchmark for your technology from cisecurity.org
- Assess your current state — CIS provides free assessment tools (CIS-CAT Lite) that scan systems against the benchmark
- Implement Level 1 recommendations as your baseline
- Document exceptions — If a recommendation breaks a business application, document why it was skipped and what compensating control you implemented
- Automate enforcement — Use Group Policy, Ansible, or configuration management tools to enforce and maintain settings
Configuration Drift
Configuration drift occurs when systems gradually deviate from their intended secure baseline over time. Someone disables a firewall rule to troubleshoot a problem and forgets to re-enable it. A developer enables debug logging on a production server and never turns it off. An admin grants temporary access to a port and it stays open permanently.
Why Drift is Dangerous
- Invisible risk — Systems look like they're running normally, but their security posture has degraded
- Inconsistency — Two servers that should be identical have different configurations, making troubleshooting harder and creating unpredictable security gaps
- Compliance failure — Auditors compare your systems against your documented baseline. Drift means non-compliance.
Preventing and Detecting Drift
- Configuration management tools — Ansible, Puppet, Chef, or PowerShell DSC enforce desired state and can automatically remediate drift
- Regular baseline scans — Run CIS-CAT or similar tools on a schedule and alert on deviations
- Change management — Every configuration change should go through a process that includes documentation and review
- Immutable infrastructure — In cloud environments, replace drifted systems with fresh, correctly configured instances instead of fixing them in place
You're setting up a new Windows Server for a department file share. The server will hold sensitive financial data. You've installed the OS and joined it to the domain. What should you do BEFORE putting it into production?
How would you respond? Choose the best option:
Hardening Checklist for Common Systems
Windows Servers
- Disable unnecessary roles and features (remove what you don't need)
- Configure Windows Firewall — block all inbound by default, allow only required ports
- Disable SMBv1 (legacy protocol with critical vulnerabilities)
- Enable Windows Event Forwarding to a central log collector
- Configure LAPS (Local Administrator Password Solution) for unique local admin passwords
- Apply CIS benchmark via Group Policy
Network Devices (Routers, Switches, Firewalls)
- Change all default passwords and community strings (especially SNMP)
- Disable unused ports and interfaces
- Enable logging and send logs to a central SIEM
- Disable Telnet — use SSH only
- Apply firmware updates
- Restrict management access to specific IP addresses or VLANs
Web Applications
- Remove default and sample pages (IIS default page, Apache "It works!", Tomcat manager)
- Disable directory listing
- Configure custom error pages (don't expose stack traces or version information)
- Enforce HTTPS and disable insecure TLS versions (TLS 1.0 and 1.1)
- Set secure HTTP headers (HSTS, Content-Security-Policy, X-Frame-Options)
Baseline Management
A baseline is your documented, approved, secure configuration for a system type. It answers the question: "What should this system look like?"
Creating a Baseline
- Start with vendor recommendations and CIS benchmarks
- Adapt to your environment — Some recommendations may conflict with business requirements
- Document everything — The setting, why it's configured that way, and any exceptions with justification
- Version control your baselines — Treat configuration documents like code. Track changes over time.
- Review annually — Technologies change, new threats emerge, CIS benchmarks update
Golden Images
A golden image (or template) is a pre-configured, hardened system image that serves as the starting point for all new deployments. Instead of hardening each new server manually (and risking missed steps), you deploy from a golden image that already meets your baseline.
- Build the golden image from a fresh OS install
- Apply all patches
- Harden according to your baseline
- Remove all unnecessary software
- Test thoroughly
- Store securely and update regularly
Key Takeaways
- Default configurations are insecure by design — Change all defaults before deployment
- CIS Benchmarks provide free, actionable hardening guides — Use them as your starting point
- Configuration drift silently erodes security — Detect it with regular scans and prevent it with automation
- Harden before deployment, not after — A system should never touch production in its default state
- Document your baselines — You cannot detect drift without knowing what "correct" looks like
- Golden images save time and reduce errors — Build once, deploy consistently