This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Improving Network Security Through Segmentation
Good network segmentation is a highly recommended network security practice that requires a firewall policy known as an allow-list or whitelist. How should you go about implementing it?
What is Network Segmentation?
Network segmentation divides the network into security zones that limit the ability for malware to spread within your network. In this security model, firewalls filter traffic between security zones, preventing unauthorized access. This makes it harder for ransomware and data theft to access sensitive data. In contrast, the old network model was based on perimeter firewalls, which made it easy for an intruder to compromise additional systems once internal access was obtained.
Creating zones and building the desired firewall rules are the primary challenge. Let’s say your business uses a typical customer application based on web, application, and database tiers. To protect the database, your network security design could create a network segment for each tier and only allow traffic between the tiers needed for the service to work. In this example, the web tier can only communicate with the application tier. The application tier can only communicate with the web-tier and the database tier using specific protocols. The complication is determining what communications to permit between each tier without consuming a lot of time and without making many mistakes.
Once you’ve identified the security zones, the recommended practice uses a so-called whitelist ruleset, also known as an allow-list, to permit the network communications needed by the applications. The default action of the ruleset is to deny all other traffic. The result is a default deny condition with explicit rules to permit network flows that the applications need.
Use Network Flow Analysis Tools
Now think about all the applications your business uses and the rulesets needed to properly segment the network. Identifying flows for the main applications is generally fairly easy. But don’t overlook communications functions like voice, video (including connection setup, conferencing, and direct calling), chat applications, and SMS. Don’t be surprised by the number of back-office applications like finance, customer management, inventory, manufacturing, and facility management. Finally, you’ll need to identify the protocols used for network utilities like DNS, NTP, and network management. Getting all this right is why one of our clients took over two years to fully implement network segmentation.
Building network segmentation rulesets is best accomplished with tools that collect network flow data. While you could start with Wireshark or Netflow capture, these mechanisms are too low-level on their own to be useful to a large business. Fortunately, there are products that can help collect flow data and turn it into network segmentation rulesets. Illumio or Cisco’s Tetration are good examples. Some of these tools will work best if you could install agents on the endpoints.
Others can work from Netflow data or packet captures at strategic locations in the network. These products can seem expensive when viewed alone. Instead, you should examine them with the business perspective that the tool allows you to rapidly implement network segmentation with fewer staff than when using alternative methods. It’s best to analyze the product cost versus staff cost, coupled with an estimate of the implementation timeframe. I’ve invariably found that the analysis favors buying the product.
When examining products, verify that they can identify true application traffic flows. Products aren’t infallible and are only as good as your ability to use them. As an example, the unsupervised analysis of network traffic for an application could include network flows of an existing malware infection. To prevent this from happening, you should review the connectivity detected by the tool and investigate flows that don’t seem right.
Another potential problem area is network flows that infrequently occur. This is because IT systems often include functions that take action or generate reports periodically (weekly, monthly, quarterly, etc.).
Maintain Rulesets on a Per-Application Basis
It’s important to document the rules used for each application. This knowledge makes it easier to automate the maintenance of the rulesets. You want the ability to remove firewall rulesets for a given application when removed from the environment. Otherwise, the list of firewall rules continues to grow because no one is comfortable removing a rule for fear it will break some application.
Be careful though—since multiple applications may use the same rule—which shouldn’t be deleted until all applications that use it have been removed. A good example is DNS, which uses UDP on port 53. A better approach is to use automation to rebuild each zone’s full ruleset based on what the applications require.
You can ask the application vendors and in-house developers for a list of network traffic flows their application needs, but my past experience indicates that you shouldn’t expect to get much useful information. I would like to see an Internet standard for documenting application flow requirements. Network automation tools could then use the information to provision the network for segmentation without going through an on-the-network discovery process. This approach would also capture the requirements for infrequent flows. Perhaps a vendor will begin the standardization process by creating a library of known application characteristics against which a network’s flow data could be compared to help organize the rulesets.
Managing the Transition to Allow-List
The transition from a deny-list model to an allow-list model can be challenging. Fortunately, the use of small security zones reduces the number of rules that must be handled. Still, you may benefit from prepending the new allow-list onto an existing deny-list, if one exists, or end the ruleset with a temporary rule that allows ANY-ANY connectivity. When you implement a security zone, monitor its ruleset’s usage and identify any flows that haven’t been handled by the allow-list. Once all the necessary traffic has been identified and handled, the old deny-list and ANY-ANY rules can be safely removed. We’ve taken this approach with a client’s network by setting aside an hour once a week for ruleset testing. Each test session identified fewer flows to be handled. Full implementation was achieved in about five hours over as many weeks.
Putting It All Together
Transitioning to a network segmentation security architecture takes good planning, tools, and implementation. Fortunately, breaking the network into small security zones simplifies the task. Each zone should provide a single, easily managed service with easily identifiable traffic flows. Start with the most vulnerable applications, followed by the most important – these are often the same.
Don’t be surprised if you identify previously unknown applications and flows. You can also use this process to identify abandoned servers – servers used by some application no longer in use.
Segmentation makes maintaining rulesets much easier since each zone is protecting an individual service.