This article is the third in the series "How to Take Control of Your Network Infrastructure." You can find the contents of all articles in the series and links to them. here.

There's no point in talking about completely eliminating security risks. We cannot fundamentally reduce them to zero. It's also important to understand that as we strive to make our network more secure, our solutions become increasingly costly. We need to find a reasonable compromise between price, complexity, and security for your network.

Of course, security design is organically integrated into the overall architecture, and the security solutions used affect the scalability, reliability, manageability, ... of the network infrastructure, which must also be taken into account.

However, let me remind you that we are not discussing the creation of a network right now. According to our initial conditions , we have already selected a design, chosen equipment, and built infrastructure, and at this stage, we must, as much as possible, "live" and find solutions within the context of the previously chosen approach.

Our task now is to identify risks related to network security and reduce them to a reasonable level.

Network Security Audit

If your organization has implemented ISO 27k processes, then security audits and network changes should be seamlessly integrated into the overall processes under this approach. However, these standards are not about specific solutions, configurations, or designs... There are no unequivocal recommendations, no standards that detail how your network should be, which is both the complexity and beauty of this task.

I would highlight several possible network security audits:

hardware configuration audit (hardening)
security design audit
access audit
process audit

Hardware Configuration Audit (Hardening)

It seems that in most cases, this is the best starting point for auditing and improving your network security. IMHO, it's a good demonstration of Pareto's Law (20% of efforts yield 80% of results, while the remaining 80% of efforts yield only 20% of results).

The essence is that we usually have recommendations from vendors regarding "best practices" for security when configuring equipment. This is called "hardening."

You can often encounter a questionnaire (or create one yourself) based on these recommendations, which will help you determine how well your hardware configuration aligns with these best practices, and make changes to your network based on the results. This will allow you to significantly reduce security risks quite easily and actually at no cost.

Several examples for some Cisco operating systems.
Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Cisco Baseline Security Checklist
Based on these documents, a list of configuration requirements for each type of device can be created. For example, for Cisco N7K VDC, these requirements may look like like this.

Thus, configuration files can be created for different types of active equipment in your network infrastructure. Subsequently, manually or using automation, you can 'upload' these configuration files. How to automate this process will be discussed in detail in another series of articles dedicated to orchestration and automation.

Security Design Audit

Usually, the following segments are present in an enterprise network in one form or another:

DC (Public services DMZ and Intranet data center)
Internet access
Remote access VPN
WAN edge
Branch
Campus (Office)
Core

The names are taken from Cisco SAFE the model, but it is not necessary to stick strictly to these names and this model. Ultimately, it is better to talk about the essence and not get caught up in formalities.

For each of these segments, security level requirements, risks, and consequently, solutions will differ.

Let's examine each of them separately for issues you may encounter from a security design perspective. I must reiterate that this article does not claim to be exhaustive, as achieving that in such a deep and multifaceted topic is challenging (if at all possible), but it reflects my personal experience.

There is no perfect solution (at least not right now). It is always a compromise. However, it is important that the decision to adopt a particular approach is made deliberately, with an understanding of both its advantages and disadvantages.

Data Center

The most critical segment from a security perspective.
And, as usual, there is no universal solution here either. It largely depends on network requirements.

Is a firewall needed or not?

It may seem that the answer is obvious, but the situation is not quite so straightforward as it appears. Your choice can be influenced by more than just that. price.

Example 1. Delays.
If low latency between certain network segments is a significant requirement, such as in the case of an exchange, then we won't be able to use firewalls between those segments. It's hard to find studies on latency in firewalls, but very few switch models can provide latencies lower than or around 1 microsecond, so I think that if microseconds are crucial for you, then firewalls are not the right choice.

Example 2. Performance.
The throughput of top L3 switches is usually an order of magnitude higher than the throughput of the most powerful firewalls. Therefore, in cases of high-intensity traffic, you will likely have to route this traffic around the firewalls.

Example 3. Reliability.
Firewalls, especially modern Next-Generation Firewalls (NGFW), are complex devices. They are considerably more complex than L3/L2 switches. They offer a large number of services and configuration options, so it's no surprise that their reliability is significantly lower. If service continuity is critical for the network, you may need to decide which leads to better availability — security through a firewall or the simplicity of a network built on switches (or various types of fabrics) using standard ACLs.

In the aforementioned examples, you will likely (as usual) have to find a compromise. Consider the following solutions:

If you decide not to use firewalls inside the data center, you need to think about how to maximize perimeter access restrictions. For instance, you can only open necessary ports from the Internet (for client traffic) and administrative access to the data center only from jump hosts. Conduct all necessary checks (authentication/authorization, antivirus, logging, etc.) on jump hosts.
You can use logical segmentation of the data center network into segments, similar to the scheme described in PSEFABRIC. Example p002Routing should be configured in such a way that traffic sensitive to delays or high-intensity traffic moves 'internally' within a single segment (in the case of p002, the VRF) and does not pass through the firewall. Traffic between different segments will still go through the firewall. Route leaking between VRFs can also be used to avoid redirecting traffic through the firewall.
You can also use the firewall in transparent mode and only for those VLANs where these factors (latency/performance) are not significant. However, it is essential to carefully study the limitations related to using this mode for each vendor.
You might consider applying a service chain architecture. This will allow you to direct only necessary traffic through the firewall. Theoretically, it looks good, but I have never seen this solution in production. We tested the service chain for Cisco ACI/Juniper SRX/F5 LTM about three years ago, but at that time this solution seemed 'raw' to us.

Level of protection

Now you need to answer the question of what tools you want to use for traffic filtering. Here are some capabilities that are typically present in NGFW (for example, here):

stateful firewalling (by default)
application firewalling
threat prevention (antivirus, anti-spyware, and vulnerability)
URL filtering
data filtering (content filtering)
file blocking (file types blocking)
dos protection

It's also not all straightforward. It might seem that the higher the level of protection, the better. But you also need to consider that

the more of the above-mentioned firewall features you use, the more expensive it will naturally be (licenses, additional modules).
The use of certain algorithms can significantly reduce the throughput of the firewall and increase delays, see for example here
Like any complex solution, using intricate protection methods may reduce the reliability of your solution; for example, when using application firewalling, I encountered the blocking of some quite standard applications (DNS, SMB).

As usual, you need to find the solution that is optimal for your network.

It is impossible to give a definitive answer to what protection features may be needed. Firstly, it certainly depends on the data you are transmitting or storing and trying to protect. Secondly, in reality, the choice of protection measures is often a matter of faith and trust in the vendor. You do not know the algorithms, do not know how effective they are, and cannot fully test them.

Therefore, in critical segments, a good solution may be to use offerings from different companies. For example, you can include antivirus on the firewall but also use antivirus protection (from a different vendor) locally on the hosts.

Segmentation

This refers to logical segmentation of the data center network. For instance, breaking it down into VLANs and subnets is also logical segmentation, but we will not consider it due to its obviousness. We are interested in segmentation that takes into account entities such as FW security zones, VRF (and their equivalents related to various vendors), logical devices (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

An example of such logical segmentation and a currently in-demand data center design is provided in p002 project PSEFABRIC.

After defining the logical parts of your network, you can then describe how traffic flows between different segments, on which devices filtering will take place, and by what means.

If your network lacks clear logical separation and there are no formalized rules for applying security policies for different data flows, it means that when opening any access, you are forced to address this issue, and chances are that each time you will solve it differently.

Often, segmentation is based solely on FW security zones. You then need to answer the following questions:

What security zones do you need?
What level of protection do you want to apply to each of these zones?
Will intra-zone traffic be allowed by default?
If not, what traffic filtering policies will be applied within each zone?
What traffic filtering policies will be applied for each pair of zones (source/destination)?

TCAM

A common issue is insufficient TCAM (Ternary Content Addressable Memory) for both routing and access. In my opinion, this is one of the most important considerations when selecting equipment, so it should be approached with due diligence.

Example 1. Forwarding Table TCAM.
Let's consider Palo Alto 7k firewall.
We see that the IPv4 forwarding table size* = 32K.
Moreover, this number of routes is shared across all VSYSs.
Suppose that according to your design you decided to use 4 VSYSs.
Each of these VSYSs is connected via BGP to two PE MPLS clouds, which you use as BB. Thus, the 4 VSYSs exchange all specific routes with each other and have a forwarding table with approximately the same sets of routes (but different NHs). Since each VSYS has 2 BGP sessions (with the same settings), each route received via MPLS has 2 NHs and, accordingly, 2 FIB entries in the Forwarding Table. If we assume that this is the only firewall in the data center and it must be aware of all routes, then the total number of routes in our data center cannot exceed 32K/(4 * 2) = 4K.
Now, if we assume that we have 2 data centers (with the same design), and we want to use VLANs 'stretched' between the data centers (for example, for vMotion), to address the routing issue, we must use host routes. But this means that across the 2 data centers, we will have no more than 4096 possible hosts, and of course, this may not be enough.

Example 2. ACL TCAM.
If you plan to filter traffic on Layer 3 switches (or other solutions using Layer 3 switches, e.g., Cisco ACI), when selecting equipment you should pay attention to the ACL TCAM.
Suppose you want to control access on SVI interfaces of Cisco Catalyst 4500. Then, as can be seen from of this article, to control outgoing (as well as incoming) traffic on the interfaces, you can use only 4096 TCAM entries. This with TCAM3 gives you about 4000 ACEs (ACL entries).

If you encounter a problem with insufficient TCAM, the first thing to consider is optimization. In the case of a problem with the size of the Forwarding Table, you should look into route aggregation. If the issue is with TCAM size for accesses, you should audit accesses, remove outdated and overlapping entries, and possibly revise the access opening procedure (which will be discussed in detail in the chapter dedicated to access auditing).

High Availability

The question is whether to use HA for firewalls or to set up two independent boxes side by side and route traffic through the second box in case one of them fails?

The answer seems obvious – to use HA. The reason this question arises is that, unfortunately, the theoretical and advertised 99 and a few nines after the decimal for availability are far from rosy in practice. HA is logically quite complex, and with different hardware and vendors (there have been no exceptions), we have encountered issues, bugs, and service interruptions.

If you use HA, you will have the option to shut down individual nodes and switch between them without service interruption, which is important, for example, during upgrades. However, there is a non-zero probability that both nodes will fail simultaneously, as well as that the next upgrade will not go as smoothly as promised by the vendor (this problem can be avoided if you have the opportunity to test the upgrade on lab equipment).

If you do not use HA, then in terms of double failure, your risks are significantly lower (since you have 2 independent firewalls), but since sessions are not synchronized, each time there is a switch between these firewalls, you will lose traffic. You can, of course, use stateless firewalling, but then the purpose of using a firewall is largely lost.

Therefore, if during the audit you discovered standalone firewalls and are considering increasing the reliability of your network, HA is certainly one of the recommended solutions. However, you should also consider the drawbacks associated with this approach, and perhaps another solution will be more suitable for your network.

Ease of management

In principle, HA also relates to manageability. Instead of configuring two devices separately and resolving the issue of synchronizing configurations, you manage them largely as if you have a single device.

But perhaps you have many data centers and many firewalls, in which case this issue takes on a new level. And it's not just about configuration, but also about