in the remaining enterprise modules mitigates this threat. The other threats assume that the primary line of defense has been breached. To mitigate the threat of a compromised device, access control is implemented at the firewall and at every other possible device to prevent exploitation of the management channel. A compromised device cannot even communicate with other hosts on the same subnet because private VLANs (PVLANs) on the management segment switches force all traffic from the managed devices directly to the Cisco IOS Firewall, where filtering takes place. Password sniffing reveals only useless information because of the One Time Password (OTP) environment. Use SNMPv3 wherever possible because SMNPv3 supports authentication and encryption. SNMP management has a specific set of security needs. Keeping SNMP traffic on the management segment allows the traffic to traverse an isolated segment when the traffic pulls management information from devices. In Cisco self-defending network topology, SNMP management only pulls information from devices and is not allowed to push changes. To ensure that management information is pulled, each device is configured with a read-only string. You can configure SNMP read-write when using an OOB network, but be aware of the increased security risk of a plaintext string allowing modification of device configurations. Proper aggregation and analysis of syslog information is critical for proper management of a network. From a security perspective, syslog provides important information about security violations and configuration changes. Depending on the device in question, different levels of syslog information might be required. Having full logging with all messages that are ever sent might provide too much information for an individual or syslog analysis algorithm to sort. Logging for the sake of logging does not improve security. Information Paths
Network administrators need to securely manage all devices and hosts in the network. There are two information paths that exist for different information: Logging and reporting information flow from devices to management hosts. Content, configurations, and new software flow from the management hosts to the devices. Figure shows the information paths in the network. From an architectural perspective, providing OOB management of network systems is the best first step in any management and reporting strategy. Devices should have a direct local connection to such a network wherever possible; where this is not possible because of geographic or system-related issues, the device should connect via a private encrypted tunnel over the production network. Such a tunnel should be preconfigured to communicate only across specific ports that are required for management and reporting. Lock down the tunnel as well so that only appropriate hosts can initiate and terminate the tunnel. OOB management is not always desirable. Often, the decision to use OOB or not depends on the type of management application that you are running and the protocols that you require. For example, consider a management tool whose goal is to determine whether each device on the production network is reachable. If a critical link between two core switches fails, you would want this management console to alert an administrator. If you configure this management application to use an OOB network, the network may never determine that the link has failed because the OOB network makes all devices appear to be attached to a single network. Run this kind of management application in-band. You must configure in-band management as securely as possible. In-Band Management Considerations
Figure lists questions that you must consider when designing an in-band management solution:

• Which management protocols does the device support? Devices with IPsec should be managed by simply creating a tunnel from the management network to the device. This setup allows many insecure management protocols to flow over a single encrypted tunnel. When IPsec is not possible because IPsec is not supported on a device, other less secure options must be chosen. For configuring the device, SSH or Secure Sockets Layer (SSL) can often be used instead of Telnet to encrypt configuration modifications that you make to a device. These protocols can sometimes also be used to push and pull data to and from a device instead of insecure protocols, such as FTP and TFTP. Often, however, TFTP is required on Cisco equipment to back up configurations or to update software versions. This fact leads to the second question.
• Does the management channel need to be active at all times? If the channel does not need to be active at all times, you can place temporary holes in a firewall while the management functions are performed and then later remove the holes. This process, however, does not scale with a large number of devices, and should be used sparingly, if at all, in enterprise deployments. If the channel needs to be active at all times, such as with SNMP, the third question should be considered.
• Do you really need this management tool? Often, SNMP management tools are used on the inside of a network to ease troubleshooting and configuration. However, SNMP should be treated with the utmost care because the underlying protocol has a set of security vulnerabilities. If SNMP is required, consider providing read-only access to devices via SNMP, and treat the SNMP community string with the same care you might use for a root password on a critical UNIX host. By introducing SNMP into your production network, you introduce a potential vulnerability into your environment. And finally, if you do need the tool, use SNMPv3 authentication and encryption features.

Secure Management and Reporting Guidelines
Figure lists guidelines for in-band and OOB management of the network. As a general rule, OOB management is appropriate for large enterprise networks. In smaller networks, in-band management is a means of achieving a more cost-effective security deployment. In smaller architectures, management traffic flows in-band in all cases and is made as secure as possible by using tunneling protocols and secure variants to insecure management protocols (for example, SSH is used whenever possible instead of Telnet). To ensure that log messages are time-synchronized, you must synchronize all clocks on hosts and network devices. For devices that support NTP, this protocol provides a way to ensure that all devices keep accurate time. When you are dealing with an attack, seconds matter, because it is important to identify the order in which a specified attack occurred. Synchronization of the clocks within a network is critical for digital certificates and for correct interpretation of events within syslog data. A secure method of providing clocking for the network is for network administrators to implement their own master clocks. The private network should then be synchronized to Coordinated Universal Time (UTC) via satellite or radio. However, clock sources are available that synchronize via the Internet. Such clocks should be used by network administrators who do not want to implement their own master clocks because of cost or other reasons. An attacker could attempt a DoS attack on a network by sending bogus NTP data across the Internet in an attempt to change the clocks on network devices so that digital certificates are invalid. In addition, an attacker can attempt to confuse a network administrator during an attack by disrupting the clocks on network devices. This scenario would make it difficult for the network administrator to determine the order of syslog events on multiple devices. NTP version 3 and above supports a cryptographic authentication mechanism between peers. The use of the authentication mechanism, as well as the use of access control lists (ACLs) that specify which network devices are allowed to synchronize with other network devices, is recommended to help mitigate such an attack. The network administrator should weigh the cost benefits of pulling