How to Write and Maintain Hardening Guidelines

When rolling out new systems, hardening guidelines are standard operating procedure. A mix of settings and options, hardening guidelines cover the space between a newly installed operating system and the minimum acceptable security level.

While hardening guidelines are top of mind for new Unix and Windows deployments, they can apply to any common environment, including network devices, application stacks and database systems. The following tips will help you write and maintain hardening guidelines for operating systems.

Start with a solid base, adapted to your organization.

Most IT managers faced with the task of writing hardening guidelines turn to the Center for Internet Security (CIS, cisecurity.org), which publishes Security Configuration Benchmarks for a wide variety of operating systems and application platforms.

Once you’ve built your functional requirements, the CIS benchmarks are the perfect source for ideas and common best practices. You can’t go wrong starting with a CIS benchmark, but it’s a mistake to adopt their work blindly without putting it into an organizational context and applying your own system management experience and style.

For example, some of the protections called for in the CIS benchmarks are specifically designed to prevent someone with physical access to a system from booting it up.

While that’s an important issue for organizations concerned about servers in branch offices, it could prove more hindrance than help in a data center environment where physical access already is strongly controlled.

Don’t be afraid to disagree with the experts.

An important next step is to evaluate each of the settings suggested, and keep those that provide maximum value and agree with existing security practices and policies. That can prove daunting, as the Windows 2008 R2 benchmark clocked in at about 600 pages, and those applicable to Red Hat Linux are nearly 200 pages.

Still, this evaluation is necessary. Just because the CIS includes something in the benchmark doesn’t mean it’s a best practice for all organizations and system managers.

Security is not always black and white, and every security configuration should be based on a local assessment of risks and priorities. Many organizations will choose different settings for such things as password policies, whether to use secure Linux and host-based firewalls, or how to support older Windows protocols.

Disabling a single registry key, for example, may cause 15-year-old applications to stop working, so thinking through the risk represented by that registry key and the cost of updating the application is part of the assessment.

In some places, the CIS benchmarks simply miss important parts of an enterprise hardening strategy.

For example, while host integrity checking is called out as a part of the base configuration, break-in detection and intrusion prevention services are not included. Both should be strongly considered for any system that might be subject to a brute-force attack.

Add organization-specific settings for common services.

Once the hardening guidelines are firmed up, look at areas not explicitly covered by the CIS benchmarks that may be required in your operating environment.

Most organizations have a centralized authentication system (often based on Active Directory) that should be used for all production Unix and Windows systems. Specific configuration requirements and integration rules should be part of the hardening guidelines in those instances.

Backups and other business continuity tools also belong in the hardening guidelines. They may stray somewhat from pure security settings, but the security of organizational data and system availability remain top concerns for security teams.

Log management is another area that should be customized as an important part of hardening guidelines.

Issues such as centralized logging servers, integration with security event and incident management procedures, and log retention policy should be included.

Third-party security and management applications such as anti-malware tools, host intrusion prevention products and file system integrity checkers also require organization-specific settings. When your organization invests in a third-party tool, installation and configuration should be included.

Integrate with network and security infrastructure.

Common hardening guidelines focus on systems as stand-alone elements, but the network environment also must be considered in building a secure system. Settings for infrastructure such as Domain Name System servers, Simple Network Management Protocol configuration and time synchronization are a good starting point.

Organizations that have started to deploy IPv6 should include appropriate IPv6 configuration in their hardening guidelines (or call for IPv6 to be disabled, as improperly configured networking risks both security and availability failures).

Additional organization-specific security infrastructure such as Active Directory Federation Services and system-to-system virtual private networks (including Microsoft’s DirectAccess) should be part of hardening guidelines where settings are common to many systems.

Set a schedule for regular review.

Hardening guidelines should be reviewed at least every two years. Operating system vendors move on: Both Windows and Unix have come a long way down the road from “make it open by default” to “make it secure by default,” which means that fewer and fewer changes are required in each new release.

But other new features are integrated all the time and can have a security impact.

Security policy and risk assessment also change over time. Because hardening guidelines exist as a way to standardize operations and mitigate risk, they must be adapted to changes in policy.