Enterprise Campus

Figure A-3 shows a detailed analysis of all of the modules contained within the enterprise campus.

Management Module

The primary goal of the management module (see Figure A-4) is to facilitate the secure management of all devices and hosts within the enterprise SAFE architecture. Logging and reporting information flows from the devices to the management hosts, while content, configurations, and new software flow to the devices from the management hosts.

Key Devices

The key devices (see Figure A-5) are as follows:

• SNMP management host— Provides SNMP management for devices

• NIDS host— Provides alarm aggregation for all NIDS devices in the network

• Syslog hosts— Aggregates log information for firewall and NIDS hosts

• Access control server— Delivers one-time, two-factor authentication services to the network devices

• One-time password (OTP) server— Authorizes one-time password information relayed from the access control server

• System admin host— Provides configuration, software, and content changes on devices

• NIDS appliance— Provides Layer 4 to Layer 7 monitoring of key network segments in the module

• Cisco IOS firewall— Allows granular control for traffic flows between the management hosts and the managed devices

• Layer 2 switch (with private VLAN support)— Ensures data from managed devices can only cross directly to the IOS firewall

Threats Mitigated

The threats mitigated (see Figure A-6) are as follows:

• Unauthorized access— Filtering at the IOS firewall stops most unauthorized traffic in both directions.

• Man-in-the-middle attacks— Management data is crossing a private network, making man-in-the-middle attacks difficult.

• Network reconnaissance— Because all management traffic crosses this network, it does not cross the production network where it could be intercepted.

• Password attacks— The access control server allows for strong two-factor authentication at each device.

• IP spoofing— Spoofed traffic is stopped in both directions at the IOS firewall.

• Packet sniffers— A switched infrastructure limits the effectiveness of sniffing.

• Trust exploitation— Private VLANs prevent a compromised device from masquerading as a management host.

Design Guidelines

As can be seen in Figure A-6, the SAFE enterprise management network has two network segments that are separated by an IOS router, which acts as a firewall and a VPN termination device. The segment outside the firewall connects to all of the devices that require management. The segment inside the firewall contains the management hosts themselves and the IOS routers that act as terminal servers. The remaining interface connects to the production network, but only for IPSec-protected management traffic from predetermined hosts. This allows for management of a Cisco device that did not physically have enough interfaces to support the normal management connection. The IOS firewall is configured to allow syslog information into the management segment, in addition to Telnet, SSH, and SNMP if these are first initiated by the inside network.

Both management subnets operate under an address space that is completely separate from the rest of the production network. This ensures that the management network will not be advertised by any routing protocols. This also enables the production network devices to block any traffic from the management subnets that appear on the production network links.

The management module provides configuration management for nearly all devices in the network through the use of two primary technologies: Cisco IOS routers acting as terminal servers and a dedicated management network segment. The routers provide a reverse Telnet function to the console ports on the Cisco devices throughout the enterprise. More extensive management features (software changes, content updates, log and alarm aggregation, and SNMP management) are provided through the dedicated management network segment. The few other unmanaged devices and hosts are managed through IPSec tunnels that originate from the management router.

Because the management network has administrative access to nearly every area of the network, it can be a very attractive target to hackers. The management module has been built with several technologies designed to mitigate those risks. The first primary threat is a hacker attempting to gain access to the management network itself. This threat can only be mitigated through the effective deployment of security features in the remaining modules in the enterprise. All of the remaining 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 on the management segment switches force all traffic from the managed devices directly to the IOS firewall where filtering takes place. Password sniffing reveals only useless information because of the OTP environment. HIDS and NIDS are also implemented on the management subnet and are configured in a very restrictive stance. Because the types of traffic on this network should be very limited, any signature match on this segment should be met with an immediate response.

SNMP management has its own set of security needs. Keeping SNMP traffic on the management segment allows it to traverse an isolated segment when pulling management information from devices. With SAFE, SNMP management only pulls information from devices, rather than being allowed to push changes. To ensure this, each device is configured with a read-only string.

Proper aggregation and analysis of the syslog information is critical to the proper management of a network. From a security perspective, syslog provides important information regarding 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 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.

For the SAFE validation lab, all configurations were done using standalone management applications and the command-line interface (CLI). Nothing in SAFE, however, precludes using policy management systems for configuration. Establishing this management module makes deployments of such technology completely viable. CLI and standalone management applications were chosen because the majority of current network deployments use this configuration method.

Alternatives

Complete OOB management is not always possible, because some devices might not support it or there might be geographic differences that dictate in-band management. When in-band management is required, more emphasis needs to be placed on securing the transport of the management protocols. This can be through the use of IPSec, SSH, SSL, or any other encrypted and authenticated transport that allows management information to traverse it. When management happens on the same interface that a device uses for user data, importance needs to be placed on passwords, community strings, cryptographic keys, and the access lists that control communications to the management services.

Future Near-Term Architecture Goals

The current reporting and alarming implementation is split across multiple hosts. Some hosts have intelligence for analyzing firewall and IDS data, while others are better suited to analyze router and switch data. In the future, all data will aggregate to the same set of redundant hosts so that event correlation between all of the devices can occur.

Core Module

The core module (see Figure A-7) in the SAFE architecture is nearly identical to the core module of any other network architecture. It merely routes and switches traffic as fast as possible from one network to another.

Key Devices

Layer 3 switches route and switch production network data from one module to another.

Threats Mitigated

Packet sniffers are the threats mitigated. A switched infrastructure limits the effectiveness of sniffing.

Design Guidelines

Standard implementation guidelines were followed in accordance with the core, distribution, and access layer deployments commonly seen in well-designed Cisco-based networks.

Though no unique requirements are defined by the SAFE architecture for the core of enterprise networks, the core switches follow the switch security axiom in the “Switches Are Targets” section to ensure that they are well protected against direct attacks.

Building Distribution Module

The goal of the building distribution module (see Figure A-8) is to provide distribution layer services to the building switches; these include routing, quality of service (QoS), and access control. Requests for data flow into these switches and onto the core, and responses follow the identical path in reverse.

Key Devices

Layer 3 switches aggregate Layer 2 switches in the building module and provide advanced services.

Threats Mitigated

The threats mitigated (see Figure A-9) are as follows:

• Unauthorized access— Attacks against server module resources are limited by Layer 3 filtering of specific subnets.

• IP spoofing— RFC 2827 filtering stops most spoofing attempts.

• Packet sniffers— A switched infrastructure limits the effectiveness of sniffing.

Design Guidelines

In addition to standard network design fundamentals, the optimizations described in the “Switches Are Targets” section were implemented to provide added security within the enterprise user community. Intrusion detection is not implemented at the building distribution module because it is implemented in the modules that contain the resources likely to be attacked for their content (server, remote access, Internet, and so forth). The building distribution module provides the first line of defense and prevention against internally originated attacks. It can mitigate the chance of a department accessing confidential information on another department's server through the use of access control. For example, a network that contains marketing and research and development (R&D) might segment off the R&D server to a specific VLAN and filter access to it, ensuring that only R&D staff have access to it. For performance reasons, it is important that this access control is implemented on a hardware platform that can deliver filtered traffic at near wire rates. This generally dictates the use of Layer 3 switching as opposed to more traditional dedicated routing devices. This same access control can also prevent local source-address spoofing by the use of RFC 2827 filtering. Finally, subnet isolation is used to route Voice over IP (VoIP) traffic to the call manager and any associated gateways. This prevents VoIP traffic from crossing the same segments that all other data traffic crosses, reducing the likelihood of sniffing voice communications and allowing a smoother implementation of QoS.

Alternatives

Depending on the size and performance requirements of the network, the distribution layer can be combined with the core layer to reduce the number of devices required in the environment.

Building Access Module

SAFE defines the building access module as the extensive network portion that contains end-user workstations, phones, and their associated Layer 2 access points. Its primary goal is to provide services to end users.

Key Devices

The key devices (see Figure A-10) are as follows:

• Layer 2 switch— Provides Layer 2 services to phones and user workstations

• User workstation— Provides data services to authorized users on the network

• IP phone— Provides IP telephony services to users on the network

Threats Mitigated

The threats mitigated (see Figure A-11) are as follows:

• Packet sniffers— A switched infrastructure and default VLAN services limit the effectiveness of sniffing.

• Virus and Trojan horse applications— Host-based virus scanning prevents most viruses and many Trojan horses.

Design Guidelines

Because user devices are generally the largest single element of the network, implementing security in a concise and effective manner is challenging. From a security perspective, the building distribution module, rather than anything in the building module, provides most of the access control that is enforced at the end-user level. This is because the Layer 2 switch that the workstations and phones connect to has no capability for Layer 3 access control. In addition to the network security guidelines described in the switch security axiom, host-based virus scanning is implemented at the workstation level.

Server Module

The server module's primary goal is to provide application services to end users and devices. Traffic flow on the server module is inspected by onboard intrusion detection within the Layer 3 switches.

Key Devices

The key devices (see Figure A-12) are as follows:

• Layer 3 switch— Provides Layer 3 services to the servers and inspects data crossing the server module with NIDS

• Call Manager— Performs call-routing functions for IP telephony devices in the enterprise

• Corporate and department servers— Deliver file, print, and DNS services to workstations in the building module

• E-mail server— Provides Simple Mail Transfer Protocol (SMTP) and Post Office Protocol version 3 (POP3) services to internal users

Threats Mitigated

The threats mitigated (see Figure A-13) are as follows:

• Unauthorized access— Mitigated through the use of host-based intrusion detection and access control.

• Application layer attacks— Operating systems, devices, and applications are kept up-to-date with the latest security fixes and are protected by HIDS.

• IP spoofing— RFC 2827 filtering prevents source address spoofing.

• Packet sniffers— A switched infrastructure limits the effectiveness of sniffing.

• Trust exploitation— Trust arrangements are very explicit; private VLANs prevent hosts on the same subnet from communicating unless necessary.

• Port redirection— HIDS prevents port redirection agents from being installed.

Design Guidelines

The server module is often overlooked from a security perspective. When examining the levels of access that most employees have to the servers to which they attach, the servers can often become the primary goal of internally originated attacks. Simply relying on effective passwords does not provide for a comprehensive attack mitigation strategy. Using HIDS and NIDS, private VLANs, access control, and good system administration practices (such as keeping systems up-to-date with the latest patches) provides a much more comprehensive response to attacks.

Because the NIDS is limited in the amount of traffic it can analyze, it is important to send only attack-sensitive traffic to it. This varies from network to network, but should include SMTP, Telnet, FTP, and WWW. The switch-based NIDS was chosen because of its ability to look only at interesting traffic across all VLANs as defined by the security policy. Once properly tuned, this IDS can be set up in a restrictive manner, because required traffic streams should be well known.

Alternatives

Like the building distribution module, the server module can be combined with the core module if performance needs do not dictate separation. For very sensitive high-performance server environments, the NIDS capability in the Layer 3 switch can be scaled by installing more than one NIDS blade and directing policy-matched traffic to specific blades.

Edge Distribution Module

The edge distribution module's goal is to aggregate the connectivity from the various elements at the edge. Traffic is filtered and routed from the edge modules and routed into the core.

Key Devices

Layer 3 switches (see Figure A-14) aggregate edge connectivity and provide advanced services.

Threats Mitigated

The threats mitigated (see Figure A-15) are as follows:

• Unauthorized access— Filtering provides granular control over specific edge subnets and their ability to reach areas within the campus.

• IP spoofing— RFC 2827 filtering limits locally initiated spoof attacks.

• Network reconnaissance— Filtering limits nonessential traffic from entering the campus, limiting a hacker's ability to perform network reconnaissance.

• Packet sniffers— A switched infrastructure limits the effectiveness of sniffing.

Design Guidelines

The edge distribution module is similar in some respects to the building distribution module in terms of overall function. Both modules employ access control to filter traffic, although the edge distribution module can rely somewhat on the entire edge functional area to perform additional security functions. Both modules use Layer 3 switching to achieve high performance, but the edge distribution module can add additional security functions because the performance requirements are not as great. The edge distribution module provides the last line of defense for all traffic destined to the campus module from the edge module. This includes mitigation of spoofed packets, erroneous routing updates, and provisions for network layer access control.

Alternatives

Like the server and building distribution modules, the edge distribution module can be combined with the core module if performance requirements are not as stringent as the SAFE reference implementation. NIDS is not present in this module, but it could be placed here through the use of IDS line cards in the Layer 3 switches. It would then reduce the need for NIDS appliances at the exit from the critical edge modules as they connect to the campus. However, performance reasons may dictate, as they did in SAFE's reference design, that dedicated intrusion detection be placed in the various edge modules, as opposed to using the edge distribution module.