Problem solve Get help with specific problems with your technologies, process and projects.

Defense-in-depth security: How to establish an ultra-redundant network

Matthew Pascucci discusses layered security, explaining how to apply defense-in-depth principles toward an ultra-redundant network security posture.

Layered security has always been a mantra of enterprise network security, but some practitioners are taking it to new levels. An emerging paradigm emphasizes not trusting any single security mechanism and instead ensuring an organization has a redundant network security posture involving a variety of key network security infrastructure technologies and tactics.

Lack of proper redundancy in network security systems can create single points of failure in a company's architecture.

One of those tactics is network segregation, which has become an ideal way to lower risk within each layer of an enterprise network. It allows for finer specificity of each layer, and bases the defense and security of sensitive data on risk. In addition, adding redundancy to a security architecture assists in the protection of the architecture itself and helps reduce risk from failing systems and attacks.

In this tip, we'll discuss how best to architect a network using network segregation and security redundancy to protect it and such key network assets as email servers, mission-critical application servers and databases.

Using defense-in-depth principles to create ultra-redundancy

Using the defense-in-depth model, security redundancy can be applied to almost every point of the network. For example, commercially available email security products allow for multiple scanning engines to search for malicious messages as they reach an organization's mail server, ensuring redundancy by not relying on any one technology, thus turning it into a single point of failure. To add to the defense-in-depth architecture, a spam firewall should be configured with real-time blacklists, or RBLs, to block known malicious IPs so that nefarious emails can be filtered via the firewall before they ever reach unsuspecting users.

This protection model should be applied to critical assets first, based on risk, and then to other layers of the network. There is no silver bullet in any network security product, so relying on one layer of protection against threats is foolish and shouldn't be allowed. Using multiple methods of security simultaneously is arguably the best way to protect a network.

Lastly, using client-based technology to search for phishing and spam at the desktop level adds another layer of protection. Again, this is based on layers of protection -- not trusting one layer and working hand-in-hand with other security vendors and technologies to harden the network, protecting it from threats if one layer fails.

An introduction to network segmentation

With the defense-in-depth model in place and with the understanding that there is no one solution for securing the network, we can break down this layered security methodology even further. Network segregation or "segmentation" is a way to compartmentalize data by how critical and how sensitive it is. Segmentation essentially wraps another layer of security around systems and data. By not allowing certain systems or networks to communicate with each other, it limits exposure because unwanted users and services are kept from viewing, modifying or accessing restricted areas of the network. This helps contain malware from spreading to every network in an organization, prevents hackers from easily accessing networks without restriction, and keeps sensitive data from becoming exposed.

How to segment enterprise networks for security

Here are a few ways to segment an organization's networks:

  • Wireless. Create a wireless network using certificates for internal use only with strong encryption, and a separate wireless network for guests only that should have user accounts that expire after a certain amount of time. The key here is to limit risk; by having a wireless network attached to the internal LAN, it should be slightly more restrictive than the internal wired LAN. Plus, any guest coming into the network that needs access to the Internet should not be touching the internal network anyway; these clients should always be completely segmented.
  • Production. Production networks are areas in the network where data is live. These networks need to be segmented so that only approved virtual LANs or subnets have access via firewalls or routers. The applications and infrastructure that hold live data should be locked down to only those that need it.
  • DMZ. This network should be configured so that communication to it from the outside is restricted to only the appropriate systems and services. Communication from the DMZ to other DMZs or internal networks should be similarly restricted. These systems are out in the open, and trusting them should be a concern. The segmentation between this network and others should be limited and monitored.
  • Users. Create user networks for internal employees, admins, remote users and restrict access to only those that must have it; rights to other networks and systems should be given only as needed. The idea here is to grant the least possible amount of privileges to each network; exceptions can be made per user or group.
  • Regulatory. When a business need arises to create a network that's separated from the rest of the network, such as a zone for PCI DSS-compliant devices, this is perhaps the most business-critical use of network segmentation. This isolation not only helps protect it from being accessed by someone or something that wasn't intended to access those systems or data, but also satisfies auditors or assessors during compliance validation efforts.

Adding redundancy to the network

After creating a layered approach to protecting data and segmenting these systems to secure and isolate them from unwanted users and systems, it's crucial to add redundancy to a network's security posture as well. This is just as important as layered security and segmentation. Lack of proper redundancy in network security systems can create single points of failure in a company's architecture. Even with layered security, one layer might be dependent on others working (for example, a spam firewall with layers below it that rely on data that flows from it). Not only will these layers not be effective (because they're not getting the data), but they also will put the business at risk.

From the editors: More on defense-in-depth security

Security school: Reinventing defense-in-depth security

Ask the Expert: How to implement network segregation for PCI DSS compliance

One way to help prevent this risk scenario is to add clustering to technologies that need it, such as those that are of high priority to the business, and especially if they're inline. Clustering can be either active/passive or active/active depending on a company's downtime allowance. This lets the systems fail over to another identically configured device, or distributes the load between them.

Additional layers

There are other techniques, such as load balancing, that are similar to clustering and can assist with the demand on a company's systems. Load balancing can make services available when they're needed if a problem ever arises. It also "masks" or distributes loads if traffic needs to be moved to other areas of the network (for example, when an organization is being attacked on a particular service or domain name).

Load balancing a network and not relying on any one vendor or technology for protection -- as well as having segmentation in place for compartmentalizing data and adding redundancy to systems that are performing them -- all add significantly to a network's security posture. These steps certainly won't make a network impenetrable, but they will put it in a better, more secure place.

About the author
Matthew Pascucci is a senior information security engineer at a large retail company where he leads the threat and vulnerability management program. He has written for various information security publications, has spoken for many industry companies, and is heavily involved with his local InfraGard chapter. You can follow him on Twitter at @matthewpascucci or check out his blog at

This was last published in February 2013

Dig Deeper on Network Access Control technologies