Partners

Why should you commit…segmentation?

Segmentation in medieval times

10 years ago, when people talked about a modern-day network, they would compare it to a medieval castle: a fortress with a single drawbridge, a large moat and guard towers that would pierce the sky. Considering the time, this was a valid comparison.

Today, this is no longer valid. Your attackers are plodding through the moat, assaulting the guard towers with helicopters and the slightest crack in the drawbridge is sufficient to cause a breach. It feels as if we, as defenders, are in a different time-zone compared to the attackers.

Time to change the ancient design philosophy.

It is often said that “Security needs to be multi-layered”. This often implies the implementation of a common internet access street consisting of a firewall, proxy and anti-virus. When these are all operating, they have the capability to detect a threat.

To enhance the success of this access street, there must be a change in the design mentality. When we take a look at the current threat landscape, there is another analogy we can make. We can compare it to … a submarine.

The access street versus the submarine

Submerged in the ever-treacherous waters of the internet, the slightest crack in the hull can flood the entire ship. Not only do we need to create an outer hull with the utmost care, disaster scenarios such as sacrificing certain parts of the ship so that others may continue to function need to be prepared as well.

Segmenting your network would prevent a similar situation.

Let’s take the above high-level overview as an example.

This network has been segmented and all users have been grouped according to their department.
The servers for this organization have been clustered according to their connectivity requirements.
Each segment is contained by using a separate VLAN and layer 3 subnet.

Segmented network & next-gen zone-based firewall: the pros and cons

The pros

Combining this design with a next-generation zone-based firewall will provide the most merit for its possibilities.
In terms of security, we notice the following advantages:

Separate security policy for each segment.

By grouping based on needs and requirement, the security policy can prevent access for unwanted users.

Increased visibility for the organization.

All traffic needs to be configured and identified. This knowledge alone can prevent damage in an organization if a new zero-day threat emerges.

Prevent lateral movement in case of a breach.

The lack of segmentation in most networks is what made the EternalBlue exploit so successful. Even if the next-gen firewall could not detect the exploit itself, it would not have mattered if there was no identified need for the service to that segment.
Looking at our example above, MS-RPC services are perfectly plausible towards the ‘Servers’ segment but there is absolutely no need for this between ‘Administration’ and ‘Logistics’.

If one of the Public Servers is breached, the attacker will have a much smaller attack surface. Since he is unaware of the network design, the attacker will need to trigger network scans in order to discover other interesting targets such as one of the private servers or a client pc. These actions can be detected and blocked due to our increased visibility.

Once a breach has been detected, the segment can be isolated from other resources in order to contain it.

Granular control of advanced security features

Enabling the full range of security features for all traffic will not only cause a negative impact on firewall performance but the different nature of traffic can also cause unwanted disruption.

The security policy of ‘Internet’ to ‘Public Servers’ can be configured to check for all exploits related to the services configured whereas the security policy for ‘Logistics’ to ‘Sales’ can suffice in permitting HTTP based on port 80.

Combining a segmented network with an Identity based access control solution such as Aruba ClearPass or Pulse Policy Secure will increase its effectiveness.

The cons

Unfortunately, there are some downsides to this approach as well.

Need for documentation.

Identifying all traffic flows between clients and servers can be a cumbersome task.
Documentation of the software will need to be consulted to identify the applications behavior on the network.

More complex management.

Adopting a new software bundle may require a change in security policy.
This change may need to be implemented from Internet’ to ‘Public Servers’ for the incoming traffic and inter-server traffic needs to be defined in the ‘Public Servers’ to ‘Private Servers’ policy. Finally, the clients will need access to each segment towards the ‘Private Servers’ segment.

Don’t be put off by those last parts, there are solutions!

A management platform such as Junos Space or Palo Alto’s Panorama has the possibility to define standard policies that apply to a combination of zones. Where the management platform for the firewall seemed like overkill before, it fits perfectly in the segmented network.

Even if you are used to working with a network that has no segmentation nor documentation on the internal traffic flows, a seasoned consultant can analyze the temporary ‘allow all’ rule that was implemented between segments and propose a rigid security policy.

In fact, why not implement Algosec’s Firewall analyzer and complete the task in a fraction of the time. Repeated use of the product will also correct human errors in order to keep an optimized rule base and eliminate the chance of rule shadowing

To wrap up this blog post, we can conclude that multi-layered security is not only achieved by implementing best of breed technologies but also by designing with security in mind.Do you have a question or would you like more information? Please do not hesitate to contact us.