What configuration hardening checklist will make my server more secure?
Introduction
Any information security policy or standard will include a requirement to use a ‘hardened construction standard’. The concept of hardening is fairly straightforward, but knowing which source of information to refer to for a hardening checklist when there are so many published can be confusing.
Server Hardening Checklist Reference Sources
The most popular “brand names” in this area are the Center for Internet Security or CIS Hardening Checklists (free for personal use), NIST (also known as the National Vulnerability Database) provided by the Repository National Program Checklist or SANS Institute Reading Room articles on hardening the Top 20 Most Critical Vulnerabilities.
All of these groups offer configuration hardening checklists for most Windows operating systems, Linux variants (Debian, Ubuntu, CentOS, RedHat Enterprise Linux aka RHEL, SUSE Linux), Unix variants (such as Solaris , AIX, and HPUX) and firewalls and network devices. , (such as Cisco ASA, Checkpoint, and Juniper).
These sources offer a convenient one-stop shop for checklists, but you’re better off looking for manufacturer-specific or community-specific checklists for your devices and operating systems. For example, Microsoft and Cisco offer comprehensive hardening best practice recommendations on their websites, and the various CentOS and Ubuntu communities have numerous secure configuration best practice tutorials on the Internet.
So which checklist is the best? Which configuration hardening benchmark is the best and most secure? If you consider that all the benchmarks for, say, Windows 2008 R2 seek to remove the same vulnerabilities from the same operating system, you quickly realize that there is naturally a high degree of similarity between the various sources. In short, they all say the same thing, just in slightly different terms. What is important is that you weigh the relevant risk levels for your systems against the trade-offs you can make in terms of reduced functionality in exchange for increased security.
Configuration hardening and vulnerability management
It is important to distinguish between software-based vulnerabilities that require patches to fix and configuration-based vulnerabilities that can only be mitigated. Achieving a safe, hardened building standard is really what a hardening program is all about, as it provides a constant and fundamental level of safety.
Configuration hardening presents an exceptionally difficult challenge, as the level to which you can harden depends on your environment, applications, and work practices. For example, removing web and ftp services from a host are good basic hardening practices. However, if the host needs to act as a web server, this will not be a sensible backup measure!
Likewise, if you need remote access to the host over the network, you’ll need to open firewall ports and enable terminal server or ssh services on the host; otherwise these should always be removed or disabled to help protect the host.
By contrast, patching is a much simpler discipline, with a general rule that the latest version is always the most secure (but test it first to make sure it works!).
Configuration Hardening Procedures
Just as patching should be done at least once a month, configuration hardening should also be practiced regularly; it is not a one-time exercise.
Unlike patching, where new vulnerabilities in software packages are routinely discovered and then fixed by the latest patches, new configuration-based vulnerabilities are discovered very rarely. For example, CIS Server 2008 Benchmark has only been updated 3 times even though the operating system has been available for almost 5 years. The initial benchmark, version 1.0.0, was released in March 2010, and was later updated to version 1.1.0 in July of the same year. Then there was a recent update to version 1.2.0 in September 2011.
However, even though new configuration best practices are rarely introduced, it is critical that the hardened configuration of your Windows servers, Linux and Unix hosts, and network devices be reviewed periodically because changes can be made at any time that can affect negatively the inherent safety of the device.
When you consider that any checklist can range from 200 to 300 measures, verifying that all hardening measures are consistently and continuously applied should be an automated process.
This can be provided by vulnerability scanning appliances such as Nessus or Qualys, however these are limited in the range and depth of checks they can perform unless root or administrator access is granted to the host under test. Of course, doing so actually introduces additional security vulnerabilities, as the host is now accessible over the network and there is at least one more root or administrator account in circulation that could be abused.
Configuration Hardening – File Integrity Monitoring
The other limitation of scanning devices is that they can only take an instant assessment of the device in question. While this is a good way to verify device compliance with a configuration hardening best practice checklist, there is no way to verify that the file system has not been compromised, for example by a Trojan or other malware.
Summary
Continuous monitoring of file integrity combined with continuous assessment of configuration hardening is the only real solution to keeping systems secure. While branded checklists such as CIS Benchmarks are an excellent source for strengthening best practices, they are not the only option available. In fact, vendor-provided checklists are generally a more focused source of vulnerability mitigation practices. Remember that there can be a wide variety of checklists using different terms and language, but ultimately there is only one way to strengthen any particular system. What is most important is that you apply the appropriate hardening measures for your environment, balancing risk reduction with operational and functional commitments.