· Response--Procedures designed to address a compromise, once identified. This element
might include immediately locking down a device to preserve evidence of a compromise.
· Recovery--Procedures and tools to restore functionality or information after a
compromise. This element might involve rolling back a device's configuration to a
recent, authorized version of the configuration file to undo the effects of an unauthorized
change. Or, if preservation of evidence is important, this element might include replacing
an affected device with a hot spare so that the original device can be retained as evidence.
· Training--Inform your staff of proper procedures and the role they play within those
procedures. Training needs can be reduced by using intuitive, highly controlled systems
that don't require much training. For example, providing a role-based security
mechanism will prevent users from performing actions they're not trained or authorized
to perform, thus providing users with the access they need without having to train them
on what not to do.
· Testing--Regular tests of your program to ensure that critical security controls and
procedures are functioning according to your design. So-called white hat testing attempts
to compromise your systems in the same fashion as an attacker--short of actually causing
a negative impact on production. The purpose of this testing is to confirm that the
security measures you have in place are sufficient and to highlight vulnerabilities that
aren't yet addressed. For example, you might make a minor device configuration change
from outside your centralized management interface to determine whether your device-
management software detects the unauthorized change and creates an appropriate alert.
In practice, there are specific steps you can take to improve the security of your network devices.
I'll discuss these steps in the next four sections.
Role-Based Authorization for Changes
Typical security assigns permissions to individual users or to groups of related users, perhaps by
department. Such security can be difficult to troubleshoot and less-than-intuitive to apply.
Network devices offer even less flexibility, typically providing just one password for general
device access and another for full access. Unless the device is configured to use TACACS or
RADIUS for authentication, every user who works with the device will use the same password,
which is a very ineffective security practice.
Role-based security defines specific roles based on how users need to interact with the device.
For example, an auditor role might need read-only access to device configuration files or simply
read-only access only to the device's configuration history rather than to the configuration file on
the device itself. Administrators might need the ability to define configuration changes and push
those changes out to devices. Regular users might not need any permissions on the device.
An effective device-management solution will eliminate the need for anyone to access the device
directly. Instead, the solution will maintain user information for logging on and managing
devices; the solution will then provide security that offers read or write access to the device's
configuration history, current configuration, and so forth. Users perform their work entirely
within the management solution, and the solution accesses devices on the behalf of users as
required. Figure 3.5 illustrates this concept.