CIS Controls for Network Security: From Framework to Firewall Policy

The framework tells you what, not how

CIS Controls v8 is one of the most widely referenced security frameworks in the industry, and for good reason. It is practical, prioritised, and structured around implementation groups that let organisations scale their efforts to their maturity. But when it comes to network security, there is a persistent gap between what the framework says and what teams actually do with their firewalls.

The controls say things like "implement and manage a firewall on servers" and "ensure default-deny rules on network firewalls." These are correct and necessary directives. The problem is that a network engineer staring at a firewall policy with 300 rules needs more than a directive. They need to know which rules violate which controls, which gaps to fix first, and how to validate that the fixes actually work.

This post maps the CIS Controls that matter most for network security to concrete firewall actions, explains how implementation groups help you sequence the work, and shows where automated validation fits into the process.

The three CIS Controls that govern your firewall

Out of the 18 CIS Controls, three are directly relevant to how you configure and manage firewall rules. Understanding what each one asks for, down to the safeguard level, is the first step toward closing the gap between framework and implementation.

Control 4: Secure Configuration of Enterprise Assets and Software

Control 4 is about ensuring that systems are configured securely, not just deployed and forgotten. Several safeguards within this control speak directly to firewall policy.

Safeguard 4.4 requires organisations to implement and manage a firewall on servers. This is not just about having a host-based firewall installed. It means the firewall must be actively configured, with rules that reflect the server's actual function. A web server should only accept traffic on ports 80 and 443. A database server should only accept connections from its designated application servers. If your server firewalls are set to allow all traffic, the control is not satisfied even though the firewall software is running.

Safeguard 4.5 mandates implementing default-deny rules on network firewalls. Every firewall policy should end with an explicit deny-all rule, and every rule above it should be a specific, justified exception. This is the single most impactful safeguard for firewall hygiene. An any-to-any allow rule anywhere in your policy effectively negates default-deny, regardless of what the last rule says.

Safeguard 4.6 requires securely managing enterprise assets and software. For firewalls, this means management interfaces should not be reachable from untrusted networks. If your firewall's administrative console is accessible from the general user network, or worse, from the internet, you have a configuration that violates this safeguard.

Safeguard 4.9 calls for implementing trusted DNS services. From a firewall perspective, this means DNS queries from your network should be directed to known, trusted resolvers, not arbitrary external DNS servers. Rules that allow outbound DNS (port 53) to any destination enable DNS-based data exfiltration and bypass your DNS security controls.

Control 12: Network Infrastructure Management

Control 12 addresses the network itself: its architecture, its protocols, and how it is managed. This is where segmentation, encryption, and administrative access controls live.

Safeguard 12.1 requires ensuring that network infrastructure is kept up to date. In the context of firewall rules, this means deprecated or insecure protocols should not appear in your policy. If you still have rules permitting Telnet, FTP, or SSLv3 traffic, those rules reflect infrastructure that has not kept pace with current standards.

Safeguard 12.2 calls for establishing and maintaining a secure network architecture. This is the segmentation safeguard. Your network should be divided into zones based on function and trust level, with firewalls enforcing the boundaries. A flat network where every system can reach every other system on every port does not meet this requirement regardless of how many firewalls you own.

Safeguard 12.5 requires centralised network authentication, authorisation, and accounting (AAA). For firewall management, this means administrators should authenticate through a centralised system, not local accounts on each device. While this is more of an operational control than a ruleset control, it affects who can change rules and how those changes are tracked.

Safeguard 12.6 mandates using secure network management and communication protocols. SNMP v3 instead of v1/v2c, SSH instead of Telnet for device management, HTTPS for web-based administration. If your firewall rules allow plaintext management protocols, they are enabling insecure communication even if the management tools themselves support encryption.

Safeguard 12.7 requires ensuring that remote devices use VPNs for enterprise network access. Firewall rules should not allow direct RDP, SSH, or other remote access protocols from the internet. Remote users should connect through a VPN, and the firewall should only allow these protocols from the VPN subnet.

Safeguard 12.8 calls for establishing and maintaining dedicated computing resources for administrative work. This means your network administrators should access firewall management interfaces from dedicated admin workstations, not from their general-purpose desktops. Firewall rules should restrict management access to those dedicated subnets.

Control 13: Network Monitoring and Defence

Control 13 focuses on detecting and preventing malicious network activity. The relevant safeguard for firewall policy is straightforward but frequently overlooked.

Safeguard 13.4 requires performing traffic filtering between network segments. This reinforces the segmentation requirement from Control 12 but makes it explicit that traffic between segments must be actively filtered, not just routed through a firewall that allows everything. If your inter-segment firewall rules are essentially "allow all from Zone A to Zone B," you have a firewall in the path but no meaningful filtering.

Implementation Groups: where to start

One of the most practical aspects of CIS Controls is the implementation group model. Rather than presenting all safeguards as equally urgent, the framework organises them into three tiers that correspond to an organisation's size, resources, and risk profile.

The implementation group model is valuable because it tells you what to do first. If your organisation has any-to-any rules and no default-deny policy, there is no point in building dedicated admin workstations. Fix the fundamentals before adding complexity.

IG1: The non-negotiable baseline

Every organisation should be operating at IG1 as a minimum. In firewall terms, this means four things.

First, default-deny is configured and actually enforced on every firewall. Not just the perimeter firewall, but internal firewalls between zones and host-based firewalls on servers. Check that no allow-any rules exist above the deny-all. One misplaced rule can silently undermine the entire policy.

Second, deprecated and insecure protocols are blocked. If Telnet, FTP, SNMPv1/v2c, or other plaintext protocols appear in your allow rules, those rules need to be replaced with their encrypted equivalents or removed. This does not mean the underlying services disappear overnight, but the firewall should not be enabling their use if secure alternatives exist.

Third, known-risky services are restricted from untrusted zones. RDP and SSH should not be reachable from the internet. Database ports should not be open to the general user network. These are the services that attackers target first, and restricting their exposure is basic hygiene.

Fourth, DNS queries should be directed to trusted resolvers. Outbound rules that allow any host to query any DNS server on the internet are a common gap. Restrict port 53 outbound to your designated DNS servers and block direct DNS from all other hosts.

IG2: Tightening the perimeter and segmenting sensitive assets

IG2 builds on IG1 by focusing on the segmentation and protocol replacement that data-handling organisations need. This is where the work gets more involved because it requires understanding your application architecture, not just your network topology.

Protocol replacement means identifying every firewall rule that allows an insecure protocol and replacing the underlying service with a secure alternative. HTTP rules should become HTTPS, FTP should become SFTP or SCP, SNMP v1/v2c should become SNMP v3. Each replacement requires coordination with application teams and a cutover plan.

Database segmentation is one of the highest-value IG2 actions. Databases holding sensitive data should only be reachable from their designated application servers, through specific ports, with no broader access. A rule allowing the entire 10.0.0.0/8 to reach your database subnet on port 3306 might work functionally, but it violates the segmentation principle. The rule should be narrowed to the specific application server addresses.

Container and orchestration API restrictions are increasingly relevant. If your environment runs Kubernetes or Docker, the management APIs (port 6443 for Kubernetes, port 2376 for Docker) should only be accessible from management subnets. Exposing these APIs to the general network or the internet is the container equivalent of leaving RDP open.

DNS policy enforcement at IG2 means going beyond "point DNS at trusted resolvers" to actively blocking DNS over HTTPS (DoH) and DNS over TLS (DoT) to external resolvers that bypass your security monitoring.

IG3: Operational maturity

IG3 assumes you have the IG1 and IG2 controls in place and adds the operational rigour that high-value environments need.

Dedicated admin workstations mean that the people managing your firewalls, servers, and network infrastructure do so from hardened systems on a separate network segment. Firewall rules enforce this by restricting management port access (SSH, HTTPS for admin consoles, SNMP) to only the admin workstation subnet.

Separated management networks take this further. Rather than running management traffic alongside production traffic, IG3 organisations use dedicated management VLANs with tightly controlled firewall rules permitting only the specific management protocols needed.

Comprehensive monitoring at every segment boundary means firewalls are not just filtering traffic but logging it for active review. The firewall policy must be configured to log denied and allowed traffic on critical boundaries for the monitoring to work.

The gap between framework and implementation

The persistent challenge with CIS Controls, as with any framework, is the translation layer. "Implement default-deny" is five words. Actually implementing it in an environment with 400 firewall rules, 30 application teams, and a change freeze every other month takes weeks or months.

The gap shows up predictably. A security architect might be confident that default-deny is in place, only to discover during review that a rule added during a migration two years ago effectively allows all traffic between two zones. Closing this gap requires systematic review, checking every rule against the relevant safeguards. For organisations with hundreds of rules, manual review is where violations hide.

Automated validation with netbobr

netbobr implements 22 CIS-specific rules that map directly to the safeguards described above. Each rule checks firewall flows against a specific CIS safeguard and reports violations with the relevant implementation group, so you know not just what is wrong but how to prioritise the fix.

Insecure protocol rules (CIS-NET-001 through CIS-NET-004) check for flows using deprecated or plaintext protocols. These map to Safeguards 4.6 and 12.1, covering Telnet, FTP, SNMPv1/v2c, and other protocols that have secure replacements. These are IG1 and IG2 findings, meaning they should be addressed early.

Overly permissive rules (CIS-NET-010 through CIS-NET-014) flag flows where sources, destinations, or port ranges are broader than justified. A rule allowing all ports between two subnets, or a /8 source accessing a sensitive service, will trigger these checks. These map to Safeguards 4.5 and 13.4 and span IG1 and IG2.

Segmentation violations (CIS-NET-022 through CIS-NET-023) identify cases where traffic between zones is not being filtered effectively. If flows between segments are essentially unrestricted, these rules flag the gap. They map to Safeguards 12.2 and 13.4 at the IG2 level, targeting organisations that need meaningful zone separation for sensitive data.

Risky service exposure (CIS-NET-030 through CIS-NET-036) check for services that should not be reachable from broad or untrusted sources. Database ports from wide subnets, RDP from internet-facing zones, container APIs from non-management networks. These map to multiple safeguards across Controls 4 and 12, spanning IG1 and IG2.

Admin access controls (CIS-NET-040 through CIS-NET-042) validate that management protocols are restricted to appropriate source subnets. SSH and HTTPS management from the general user network, or SNMP from untrusted zones, will trigger these rules. They map to Safeguards 4.6, 12.6, and 12.8, covering IG1 through IG3 depending on the specific safeguard.

DNS policy rules (CIS-NET-051 through CIS-NET-052) check that DNS traffic is directed to trusted resolvers and that unrestricted outbound DNS is not permitted. These map to Safeguard 4.9 and apply at IG1 and IG2.

A practical starting point

If you are mapping your firewall policy to CIS Controls for the first time, resist the temptation to tackle everything at once. The implementation group model exists precisely because not every safeguard is equally urgent.

Start with IG1. Pull your firewall rules and check for the basics: is default-deny in place, are there any-to-any rules, are deprecated protocols being allowed, are risky services exposed to untrusted zones. These checks can be done manually for a small ruleset or with netbobr for larger environments.

Fix the IG1 findings first. These are the controls that prevent the most common attacks and represent the baseline that every organisation should meet. Only after IG1 is clean should you move to IG2 segmentation and protocol replacement.

Document as you go. For each rule you modify, record why it was changed and which CIS safeguard it addresses. This documentation becomes valuable during audits, security reviews, and when onboarding new team members who need to understand why the policy looks the way it does.

Frameworks are maps, not destinations

CIS Controls v8 provides a well-structured map for improving your security posture. But a map is only useful if you can translate its directions into actions that fit your terrain. For network security, that means turning safeguards into firewall rules, testing those rules against real traffic, and validating that what your policy says on paper matches what your firewalls actually enforce.

The organisations that get the most value from CIS Controls are the ones that use the framework to prioritise real improvements: starting with the basics, building systematically, and validating continuously. Your firewall policy is one of the most tangible places to do that work, because every rule is either aligned with the controls or it is not.