Components of a Hardening Strategy

Device hardening is an inexact science. One administrator's locked-down Linux box is another's security nightmare. Device hardening refers to changing the default posture of a system out of the box to make it more secure. This can have many different meanings and includes everything from disabling unneeded services on a UNIX system to shutting off the physical ports you aren't using on an Ethernet switch. Hardening isn't just a one-time event, but something that must be done on a regular basis as the security needs and functionality requirements of your devices change. The lockdown strategies you employ in your security system should be shaped by several conditions, including the following:

• Security policy
• Device location
• Threat profile
• Functional requirements
• Management requirements

Security Policy

As discussed in Chapter 2, "Security Policy and Operations Life Cycle," your security policy plays a huge role in the overall requirements of your security system. These requirements eventually filter down to the configuration standards for network-connected devices. The combination of the hardening conditions just listed (device location, functional requirements, and so on) creates hardening standards and guidelines that can be integrated within your security policy.

Device Location

Device location is a big factor in the overall hardening requirements of a particular device. Although you might configure all devices in a certain way, the specific location of a device in the network dictates whether you have a relaxed or tight posture on hardening. For example, a Linux box used for testing in a closed lab probably doesn't need much, if any, hardening. That same device used as an inbound mail server requires quite a bit of attention by virtue of its location (likely on a demilitarized zone [DMZ]), function, value, and risk. When in doubt, harden the device as much as possible and factor in the requirements in these next several sections.

Threat Profile

The threat profile defines the likely attacks against a device. The threat profile is affected by device location, but that isn't the only factor. For example, a network intrusion detection system (NIDS) in a DMZ is usually running in promiscuous mode without even an IP address configured on its interface. In this example, even though the device is connected to a sensitive network location, its inability to be reached at Layer 3 (L3) mitigates the need to do extensive hardening on the DMZ portion of the NIDS connection. (The management interface is another matter.)

A web server on that same DMZ interface is subject to a wide range of attacks, causing a dramatically increased need for proper hardening when compared with the NIDS.

Functional Requirements

The same type of device, with the same threat profile, in the same part of the network might still have different hardening requirements. The functional requirements of the device play a factor in this difference. One web server in a DMZ might contain only static information, while another might need to interact with other servers to generate dynamic content. The second server has increased functional requirements that limit the extent of device hardening.

You always must be mindful of these functional requirements when you define hardening standards. Don't forget that if users feel too restricted, they will find a way around your hardening strategies.

NOTE

User PC standards are a common location for overly restrictive hardening standards. I spent some time at a company that enforces fairly restrictive host configuration standards on its users. Virus scanning is mandated and centrally controlled, the users don't have administrative access to their own machines, management software constantly polls devices to determine software levels, and all this is done in a way that is anything but transparent to the user. Although the average user quietly grumbled and continued on, a whole crop of power users within this organization deviated from corporate standards and deployed their own systems with their own software load. The IT organization hopes that these individuals are savvy enough to secure their systems properly; otherwise the security of the network at large can suffer.

 

Management Requirements

Like functional requirements, different systems with otherwise similar functions can have different management requirements. As discussed in Chapter 6, "General Design Considerations," Cisco Discovery Protocol (CDP) is a Layer 2 (L2) protocol that exchanges information among Cisco devices and their management systems. CDP has some security risks and should be disabled if you have no plans to take advantage of the functionality it offers. However, if you can't properly manage your system because CDP is turned off, the security of the device might decrease overall despite turning off CDP.

Likewise, although it would be ideal to use Secure Shell (SSH) instead of Telnet for all router management, you might have a management system that requires a Telnet connection to function. At this point, you must carefully weigh the security risks this will introduce with the lost functionality of the management tool should you decide not to use it.