Building an Information Security Policy Part 4: Addresses and Identifiers

Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.

The first three posts in this series have focused on many physical aspects of building a secure network: choosing hardware and software, and understanding your physical topology in order to apply your security policy. In this post, I will cover the key element of effective network security: understanding addresses and identifiers that will serve as policy selectors for network traffic.

Addresses and identifiers are the basis for which actual security policy rules and requirements are implemented. Each type of traffic identified is associated with various security techniques that will each have benefits, but may also introduce complexity; security policy must be uniformly applied across the network, and one technique should not adversely impact another.

Traffic identifiers such as IP addresses, VLANs, and VRFs have two major functions. First, they allow traffic to be routed, forwarded and segmented across the network. A poorly designed IP addressing scheme will impact forwarding by introducing delays, overloading routing tables (through the inability to support summarization), and possibly impacting resource availability by black holing traffic.

The second function of logical identifiers is to classify traffic of interest that requires further evaluation. Once you identify these flows, you can apply security policy to them. The types of security techniques and the granularity applied to the interesting traffic flows are determined by the type of identifier used to classify the flow.

After the internal identification scheme is defined, it's also important to ensure that any part of it cannot be spoofed or modified to facilitate an attack.

Here is a summary of common traffic identifiers or policy selectors and some security measures associated with them:

Layer 2

• MAC addresses: port security, dynamic ARP inspection

• VLAN IDs: private VLANs (PVLAN), VLAN access lists

Layer 3

• IPv4/IPv6: IP-based access-list filtering, including best practices support for anti-spoofing, IPsec protection

Implementing security methods at Layer 4 and above typically uses two methods to identify interesting traffic. First, a subset of overall network traffic is identified (using IP addresses, for example), and this is then filtered through the upper layer service.

Not all network traffic needs to be subjected to the same level of security or type of inspection, so identification must be done appropriately to protect effectively without impacting performance by subjecting all flows to in-depth analysis. Re-classification of traffic is often a result of policy non-compliance and is another consideration when designing an identification scheme.

This post has looked at more well-known traffic identifiers, such as IP addresses and VLANs. These classifiers are bound to the underlying topology and while they are used as the classification method for many security techniques, they lack context in terms of ease in identifying who and what the flows pertain to. This is especially true in networks that use address modification techniques, such as network address translation (NAT), and dynamic allocation of IP addresses. Audit and maintenance becomes difficult as administrators are forced to remember what addresses pertain to each resource or user group, particularly in a network that must handle many changes.

In my next post, I will examine address modification methods and also discuss how the use of identity-based traffic classification can be used to introduce role-based policy methods to enhance a security policy.

Natalie Timms is the former program manager with the CCIE certification team at Cisco, managing exam curriculums and content for the CCIE Security track, and was responsible for introducing Version 4.0 of the exam. Natalie has been involved with computer networking for more ... View Full Bio

Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.