Control standards for the LAN domain address a wide array of connectivity issues such as firewall controls, denial of service (DoS) protection, and Wi-Fi security control. Wireless connectivity is also a part of the Workstation domain. This is a good example of a cross-domain security issue. It also underscores the importance of configuring workstations and servers to protect data as it leaves a workstation and travels on a network.

A firewall control standard, for example, describes how LAN firewalls handle network traffic. This kind of traffic filtering includes web, email, and Telnet traffic. The standard describes how to manage and update the firewall. The following are examples of statements adapted from the National Institute of Standards and Technology (NIST) Special Publication 800-41, “Guidelines on Firewalls and Firewall Policy”:

The firewall must always block the following types of traffic:

• Inbound traffic from a nonauthenticated system with a destination address of the firewall system. This type of packet usually represents a probe or attack against the firewall.
• Inbound traffic with a source address indicating that the packet originated on a network behind the firewall. This type of packet may represent a spoofing attempt.
• Inbound traffic containing Internet Control Message Protocol (ICMP) traffic. An attacker can use ICMP traffic to map the networks behind some firewalls. Therefore, ICMP traffic should not be allowed from the Internet or any untrusted external network.

In this example, ICMP represents a protocol within the Internet Protocol (IP). This protocol does not carry data but does carry information about the network. A simple ping command echoes back network information. It is an example of an ICMP.

A DoS protection standard describes controls that protect against or limit the effects of DoS attacks. This standard attempts to prevent using the organization’s network as a launching point against another network. Here is an example of control statements from this type of standard:

• Configure routers and firewalls to forward IP packets only if those packets have the correct source IP address for the organization’s network.
• Configure access control lists (ACLs) on routers to allow only the traffic you want.
• Only allow packets to leave the network with valid source IP addresses that belong to the organization’s network. This will minimize the chance that the organization’s network will be the source of a DoS attack.

The firewall and DoS examples illustrate how technical LAN security requirements can be established. These are high-level examples. In the real world, LAN policies are usually long and detailed. TABLE 10-2 contains additional examples of LAN control standards.

Table 10-2 mentions the term audit several times. An audit is the act of recording relevant security events that occur on a computing or network device. Why are audits so important? Any security-relevant event needs to be written to a log. Qualified personnel review these logs to determine if a security problem has occurred. These individuals determine who, what, where, and when activity caused the problem. Audit logs determine compliance issues, hardware misconfiguration errors, and application software security problems. They are useful in reconstructing actions that took place during a security incident. Audit logs should be well protected and only accessed by those people authorized by management.

Two key areas of LAN domain controls are connectivity and controlling network traffic. Baseline standards are particularly important because they establish connectivity between devices. This connectivity is important to ensure data protection in transit. To accomplish this, configure each device with an identity and method of authenticating network traffic it receives. This is no small task given the volume of network traffic generated. The network typically contains mixed traffic, such as sensitive business transactions; routine user-related transactions; and, potentially, hacker traffic. Separating business and routine user transactions depends on properly configuring network devices. These transactions do not attempt to be in conflict and thus are reasonably easy to identify and separate.

A greater challenge is how to configure devices to ensure hackers cannot masquerade as valid transactions. Another concern is hackers monitoring sensitive transactions in the clear. A hacker can configure a network card to “promiscuous mode.” When a network card is in promiscuous mode, it captures all the network traffic on a segment. Normally, a network card only captures traffic addressed to its device. In other words, a device in promiscuous mode allows you to listen to all the traffic messages between every device on the segment. With this information, a hacker can create his or her own messages in an attempt to masquerade as valid sensitive transactions.

Network segmentation can be an effective control for limiting traffic and thus help keep hackers out. Network segmentation involves isolating (or segmenting) parts of the network from other parts. This can be achieved in many ways, including adding access lists to routers that limit traffic between segments. Think of it as doors in a house. Suppose you host a graduation party in your home. Half the guests are people you don’t know. You might think about locking your bedroom door. You have segmented that room from the rest of the house. You can do the same thing with a network. For example, you might choose to segment your network into production and development systems. You might choose to further segment production into product systems, credit card systems, and internal financial systems. The number of network segments you create depends on the level of security you want to achieve.

Another important concern of baseline LAN standards is network traffic monitoring. Regardless of how good firewalls and routers are, they have their limitations. These devices prevent attacks against known and predicted threats. Intrusion systems provide a broad range of protection. They look for patterns of attack. Just as a virus scanner looks for patterns to indicate a file has become infected, an intrusion system looks for network traffic patterns to detect a network attack. An intrusion system can be detective or preventive. An intrusion detection system (IDS) recognizes a network attack and sends an alert. An intrusion prevention system (IPS) recognizes a network attack, stops the attack, and sends an alert. Audit logs also play an important role in monitoring network traffic. Configuring devices to generate logs about network events helps you to determine later what occurred during an attack.

The following are examples of baseline standards that configure devices to address connectivity and monitoring activity:

• Wi-Fi Access Point (AP) Security Standard—Defines secure wireless connectivity to a network
• Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) Standard—­Defines configuration of intrusion monitoring for the network
• Baseline OS Configuration(s) Standard—Defines hardening of servers, including server authentication and communication protocol
• Remote Maintenance Standard—Defines secure connectivity to devices for remote administration
• Audit Storage and Records Standard—Defines configuration of auditing tools and logs to record network events
• Firewall Baseline Security Standard—Defines configuration of network filters by firewall, version, and manufacturer type
• Router Baseline Security Standard—Defines configuration of network filters by router, version, and manufacturer type
• Server Baseline Configuration(s)—Defines configuration of servers to support network connectivity such as Dynamic Host Configuration Protocol (DHCP) and authentication protocols

Many of the same procedure issues exist between domains, such as configuration and patch management. There is a greater emphasis in the LAN domain on detecting and responding to network attacks. An attack on a workstation is isolated. An attack on the network threatens the entire organization. You can see this difference reflected in several network procedures, as follows:

• Response to Audit Processing Failures—Procedure to respond to failure of network monitoring and audit tools such as logs filling up
• Firewall Port/Protocol Alerts—Procedure to respond to security alerts, such as the time frame for responses and escalation paths
• Monitoring Wi-Fi APs—Procedure for configuring and monitoring Wi-Fi access points
• Audit Record Retention—Procedure for preserving audit records

The number of threats against a network can be substantial. The ability to assess these threats takes a combination of technical knowledge and experience. Guidelines can transfer that experience and knowledge by walking an individual through core principles and different ways to look at LAN risks.

These guidelines are useful to planners, systems administrators, network administrators, and their managers. These individuals must assess LAN threats and build appropriate countermeasures. The following guidelines illustrate this point:

• Security Assessments Guidelines—Provide guidance on how security assessments should be conducted, how to rate threats, and how to escalate resolution
• Firewall Architecture and Management Guidelines—Provide guidance on firewall architectures and their use
• Router Architecture and Management Guidelines—Provide guidance on router types and architectures and their use
• IDS and IPS Architecture and Management Guidelines—Provide guidance on IDS and IPS architectures and types and their use to reduce false alerts
• Wi-Fi Security Guidelines—Provide information on Wi-Fi systems architectures and types and when they should be used