Server Hardening thoughts

I'm developing hardening procedures for various types of Windows and *nix servers - specifically Win 2000 server, Win 2003 server, AIX 5.3, and Red Hat AS 3.0.

A hardening document is part procedures "cookbook" and part standards document. The procedures consist of a core of technical procedures for reconfiguring the server. Surrounding this core are the pre-hardening procedures for server inventory management and the post-hardening procedures for deployment, secure management, and periodic security assessment. I consider the asset and inventory management to be just as important as the technical hardening. If you don't know where it is, you don't know if it is secure or not.

The technical hardening piece relies on published, reputable security standards. Good sources for these include SANS, the NSA, NIST, and the Center for Internet Security. As much as possible, I like to use standards provided by the server's vendor. Vendor-provided standards have credibility with server administrators. This helps in acceptance of the standards. Vendors presumably know how hard to push hardening before commonly used applications "break". I assume if Microsoft says to configure something in Windows 2003, then most Microsoft applications can live with this. Finally, in large organizations, there is a support contract with the vendor. If there is a problem with a vendor-recommended security setting, then a trouble ticket can be opened up to resolve the issue.

As much as possible, I make sure the hardening recommendations reflect the most current operating system version. I noted some significant differences between Red Hat Enterprise 3.0 and the version 4.0. The hardening documents for these two reflect these differences. For example, version 4.0 allows for enabling SELinux in the installation procedure, while 3.0 does not.

I make each step in the hardening document as clear as possible. If certain services are to be disabled, I list every single one of them, along with the relevant command. I avoid vague generalities, such as "eliminate unnecessary services". I want to eliminate wiggle room for the system administrator. System administrators are under tremendous time pressure, and often are forced to make performance and flexibility their priorities rather than security. Specificity is necessary to ensure the job gets done.

Along with specificity must come an escape valve for cases where the standard hardening configuration will not work with specific applications. The reason for a variance must be documented and approved by the information security manager. The exception process should discourage trivial variances, but should not be so onerous that there is a strong temptation to ignore or bypass the requirements. Ultimately, the purpose of exception documentation is to maintain known security configuration documentation. In the event a new vulnerability is found, the information security manager can establish which servers are vulnerable and how they must be corrected.

I see the purpose of hardening standards as not so much providing the best security as providing consistent, documented security. Servers do not need to be impenetrable, they need to be manageable.