Safeguard 4.4 server firewall requirements

What Safeguard 4.4 server firewall requirements ask for

If a customer questionnaire, CIS Controls adoption project or auditor asks whether your servers are protected by a firewall, the answer starts with Safeguard 4.4, which requires every server that supports a firewall to run one that is actively managed. CIS gives three examples: a virtual firewall, the firewall built into the operating system, or a firewall agent supplied by a third party. The Safeguard sits in the Devices asset class and the Protect security function, and it applies to all three Implementation Groups, which makes it part of IG1 essential cyber hygiene.

The risk is straightforward. A server with no host firewall exposes every service listening on it to any network segment that can reach it, including services nobody meant to publish, such as administrative consoles, database ports or forgotten test listeners. IG1 treats this as a baseline because a perimeter firewall alone does not stop lateral movement between servers on the same segment. The difficulty is drift. Server fleets accumulate exceptions over time, and a firewall enabled during build can be disabled during troubleshooting and never restored. Measuring this requires knowing which servers exist, which software runs on them and how each one is configured, so Safeguards 1.1, 2.1 and 4.1 come first.

Before scoping the work, confirm three things with your team: which servers in your environment cannot run a host firewall (some appliances and specialized platforms cannot), which firewall option each supported operating system will use, and who owns the rule set for each server role. Then check that the rules are actively managed, meaning changes are reviewed, exceptions are recorded and an alert or report shows when a firewall is disabled. The CIS Controls Assessment Specification entry for Safeguard 4.4 lists the measures an assessor will look for.

Which servers and firewall layers fall under Safeguard 4.4

Safeguard 4.4 applies to each server that can run a firewall, but deciding which systems count is a chain of scoping choices. Each card below is a separate decision, and each depends on the asset and software inventories (Safeguards 1.1 and 2.1) and the secure configuration process (Safeguard 4.1) being accurate before anyone measures the result.

Physical and virtual servers

Scope starts with the asset inventory from Safeguard 1.1, which should list every physical server and every virtual machine as its own asset. Safeguard 4.4 asks for an actively managed firewall where the server supports one, so each record needs the operating system and whether a host firewall is installed and enabled. Check for servers that were built outside the standard image, since these are the ones most often missing from the list. The Safeguard 1.1 inventory is a prerequisite for measuring this Safeguard.

Cloud instances

Cloud virtual machines are servers for this Safeguard, even though the provider operates the hardware. Whether a firewall is a host agent, an operating system firewall or a provider network control changes what evidence you collect. Confirm which layer enforces the rules, and record it in the asset inventory so the measurement points to the right place. Short-lived instances created by automation are a common gap, so check that new instances inherit the firewall configuration at launch.

Servers that cannot run a firewall

Safeguard 4.4 applies only where the server supports a firewall, so some appliances and embedded systems may be out of scope. Do not assume an exception. Record each one in the software and asset inventories with the reason it cannot run a host firewall, the compensating network controls protecting it, and who approved the exception. An assessor will look for that written justification, and the secure configuration process from Safeguard 4.1 is the natural place to document it.

Hypervisor firewalls versus guest firewalls

A firewall can sit at the hypervisor or virtual switch layer, inside the guest operating system, or both. Each layer protects different traffic. A hypervisor rule can filter traffic between virtual machines that a guest firewall never sees, while a guest firewall protects a workload if it is moved to another platform. Decide which layers your policy requires, then test both the rules and the logging for each layer. Mixing the two without a written rule set makes ownership unclear.

Servers managed by a third party

When a provider or managed service runs the server, the organization still owns the control outcome unless the contract says otherwise. Ask the provider for evidence of the firewall configuration, who can change it, and how changes are logged. Where the provider's evidence does not cover your servers, add those systems to your own measurement. Service provider management under Control 15 and the contract terms should state which party holds each firewall responsibility.

How an assessor tests server firewall implementation

This table walks through the test steps an assessor typically applies to Safeguard 4.4, with the approach, the evidence requested and the findings that come up most often. The CIS Controls Assessment Specification for v8.1 defines six measures combined into one metric, but it describes what to measure, not how, so the assessor's own procedures and independence determine the final test. Read each row as a question the assessor will ask of your servers and records.

Test step	Test approach and evidence requested	Common findings
Scope confirmation against the asset inventory	Assessor compares the server population in the Safeguard 1.1 enterprise asset inventory with cloud consoles, hypervisor records and configuration management data to confirm which servers are in scope. Evidence requested: the inventory export, its last update date and the reconciliation method.	Servers created outside the build pipeline, decommissioned hosts still listed, or cloud instances missing from the inventory.
Sampling of servers	Assessor selects a sample across server roles, operating systems, environments and network zones, and asks for the sampling rationale. Evidence requested: the population list, the selected sample and the reason each server was chosen.	Samples drawn only from production, leaving development, staging or legacy servers untested.
Firewall status checks	For each sampled server, assessor confirms a host firewall is enabled and running, whether a virtual firewall, the operating system firewall or a third-party agent. Evidence requested: status output or console screenshots taken from the server itself, with timestamps.	Firewall service installed but stopped, or disabled after a performance troubleshooting session and never re-enabled.
Rule review	Assessor reviews the active rule set on each sampled server and checks that rules limit inbound and outbound traffic to documented services and sources. Evidence requested: exported rule sets, the business justification for each open port and the owner of each rule.	Broad rules such as any-to-any left from testing, rules with no owner, or ports open for services that no longer run.
Central management and drift	Assessor determines whether rules are pushed from a central source or configured per host, and checks for drift between the documented baseline and live settings. Evidence requested: the configuration source, the deployment record and a recent drift or compliance report.	Manual edits made directly on servers that never reach the baseline, so the documented rules and live rules disagree.
Change control of rules	Assessor traces a sample of recent rule changes back to approved change tickets and checks who can modify the rules. Evidence requested: change records, approvals, administrator access lists for firewall management and logs of rule modifications.	Changes made under shared or emergency accounts with no ticket, or administrators able to alter rules without review.
Logging and review of rule activity	Assessor checks whether denied or changed traffic is logged and whether anyone reviews those logs on a set cadence. Evidence requested: logging settings, sample log extracts and records of review or follow-up.	Logging turned off to reduce volume, or logs collected but never reviewed by anyone.
Exception handling	Assessor asks for every approved exception to the firewall baseline, checks it has a business reason, an owner, an expiry or review date and compensating controls. Evidence requested: the exception register and the approval for each entry.	Permanent exceptions with no expiry, approvals signed after the rule was already live, or exceptions no one remembers granting.

How to roll out managed server firewalls across a fleet

This sequence moves Safeguard 4.4 from an inventory of servers to a firewall that is deployed, governed by change control and reviewed on a schedule. Each step produces a record an assessor can sample, so the firewall state of every server can be shown rather than asserted.

Confirm the server inventory and secure configuration process
Start from the asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1), because the Assessment Specification treats them as prerequisites for measuring Safeguard 4.4. Confirm that the secure configuration process (Safeguard 4.1) exists in writing and names who owns server hardening. The output is a list of in-scope servers tagged by role, owner and operating system, plus a confirmed reference to the approved configuration process. If the inventory cannot separate servers from end-user devices, resolve that before going further, since the two are covered by different Safeguards.
Define the firewall baseline for each server role
Group servers by function, such as web tier, database, management host or build server, and write the inbound and outbound services each role needs. Default to denying traffic that is not explicitly allowed, then record the exceptions with an owner and a reason. The output is an approved baseline document per role, signed off by the system owner and the security function. An assessor will ask whether the baseline matches what is running, so keep it in a format that can be compared with the live rule set.
Deploy the chosen firewall method to each server
Select one method per platform: a virtual firewall supplied by the hosting environment, the firewall built into the operating system, or a third-party firewall agent. Confirm that the method is supported on each server before deployment, because Safeguard 4.4 applies where the server supports a firewall. Apply the baseline, then confirm each server runs the firewall with the expected rules. The output is a deployment report listing every server, its method, its active rule set and any server that does not support a firewall, with the reason recorded. Open-source options such as OPNsense can cover perimeter and segment filtering, but host-level enforcement still requires confirmation on each operating system.
Manage rule changes through version-controlled review
Keep baseline rules in version control so each change has an author, a reviewer, a reason and a date. Route firewall changes through the same approval step used for other configuration changes, and block direct edits on production servers that bypass the repository. The output is a rule register that maps each rule to a role, an owner and a business justification, along with the change history. Ask the team to show how an emergency change is recorded and reconciled back into the repository afterward, because assessors often test that gap first.
Set up monitoring for firewall state and rule matches
Configure a regular check that confirms each server still has its firewall enabled and running the approved rule set, and alert when a server drifts or the firewall is turned off. Where the platform supports it, log rule matches for review. Configuration assessment tools such as Wazuh can compare endpoint settings against YAML policies, and Fleet can answer yes or no questions about devices through osquery queries, with pass or fail results per policy. The output is a drift report and alert record. Confirm with each vendor which checks their tool performs for your operating systems, since capability varies by platform.
Review the baseline and rule set on a fixed schedule
Hold a periodic review of each role baseline, the rule register and any exceptions, and remove rules that no longer have an owner or a current need. Feed findings from vulnerability scans and incident reviews back into the baseline. The output is a dated review record per role, with decisions and the names of the people who approved them. Choose the review interval in your own governance process and state it in the firewall procedure, since the Safeguard itself does not fix one.

Which firewall evidence passes a Safeguard 4.4 review

An assessor testing Safeguard 4.4 looks for proof that every server runs an actively managed firewall and that the firewall is governed over time. The cards below describe six artifacts that connect those points, and how to keep each one current between assessments. The auditor decides whether the evidence is sufficient; DeployOpen prepares the evidence but does not issue findings.

Server inventory cross-referenced to firewall status

A list of every server in scope, paired with the firewall product running on it, its enabled state and the date it was last checked. Safeguard 4.4 builds on the asset inventory from Safeguard 1.1, so this list should come from the same source the inventory uses, not a spreadsheet typed by hand. Check that servers added by automation or cloud provisioning appear, and that any server without a firewall is listed as an exception rather than omitted. Export the list on a schedule and keep the export dated.

Exported firewall configurations and policy definitions

The actual rule sets from each server, whether they come from an operating system firewall, a virtual firewall or a third-party agent. The assessor wants to see that rules are actively managed, so the export should show a default deny posture where the platform supports it, and only the services each server needs. Store exports in version control or an evidence repository with timestamps, so a reviewer can compare what was in force at two points in time.

Change records for rule modifications

Tickets, pull requests or approval records showing who requested each firewall rule change, who approved it, what changed and when it was applied. Cross-check these records against the configuration exports: a rule that appears in an export without a matching change record is a finding waiting to happen. Link each change to the secure configuration process described under Safeguard 4.1, so the reviewer can follow the chain from policy to rule.

Deployment and compliance reports

Reports from a configuration management or policy engine showing which servers pass or fail the firewall checks you have defined. Wazuh Security Configuration Assessment and Fleet policies both evaluate endpoints against yes or no checks, and their results can be exported as evidence of coverage over time. Confirm that the checks you run match the firewall requirement you are claiming, and record the run date and the policy version used for each report.

Exception records with compensating controls

Where a server cannot run a firewall, or a firewall must be relaxed for a documented business need, the exception record states the reason, the risk accepted, the owner, the expiry date and the compensating control, such as network segmentation or a host-based allowlist at another layer. Review each exception on a fixed cycle and record the sign-off. Exceptions with no expiry or no owner are the ones assessors tend to question first.

Log samples showing rule matches

Samples of firewall logs showing blocked and permitted traffic against named rules, taken from the period under assessment. Logs prove the rules operate, not only that they exist. OPNsense can log each rule match for review in its live log view, and a central log store lets you pull samples across servers. Confirm that log retention covers the assessment period and that the logs are protected from changes by the administrators they monitor.

What meeting Safeguard 4.4 costs in money and effort

This table breaks down the cost components of meeting Safeguard 4.4 for servers, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and what to request in a quote. Use it to separate tooling spend from the engineering and evidence work that usually costs more over time.

Cost component	One-time or recurring	What drives it up or down	What to request in a quote
Firewall tooling or licenses	Recurring if a commercial agent or appliance is chosen; zero for built-in operating system firewalls and self-hosted open source, subject to license terms	Number of servers, vendor licensing model, and whether central management is included. Built-in firewalls avoid this line but still need configuration effort.	Current per-server or per-appliance licensing from the vendor, with the license terms that apply to your deployment
Engineering time for baselines and rollout	One-time for initial rule sets, recurring when new server roles are added	Server diversity, number of workloads, and how many firewall policies must be written for each role. Reusing a baseline per server role reduces the effort.	A fixed-scope written plan listing the server roles covered, the baseline rule sets delivered and the test window
Rule governance and change records	Recurring	Frequency of application changes, number of teams requesting ports, and whether rule changes go through a ticketed approval step	Description of the change process, approval roles and how each rule change is recorded and reviewed
Evidence upkeep	Recurring	How often firewall configurations and logs are exported, and whether the evidence is generated automatically or assembled by hand	Which evidence artifacts the partner will prepare, in what format, and how often they are refreshed
External review or testing	Recurring or periodic	Scope of testing, whether the firewall rules are included in penetration tests, and the number of environments in scope	Whether firewall rule review is part of the testing scope and how findings on server exposure are reported
Auditor sampling and assessment time	Recurring, set by the auditor or assessor	Number of servers sampled, the framework that requests the evidence, and the completeness of records at audit time	Ask the auditor how samples are selected and which firewall evidence they expect to review
Internal staff time	Recurring	Number of administrators who manage firewall rules and the volume of exception requests	Estimated hours per month for rule review and exception handling, confirmed by your own team

Which open-source tools produce server firewall evidence

Safeguard 4.4 asks for a firewall on each server that is actively managed, and an assessor will want to see both the configuration and proof that it is running. The four tools below cover different layers: the network edge, endpoints checked against benchmarks, fleet-wide queries and application-layer filtering. Confirm each tool's current capabilities against its documentation before you commit to a design.

OPNsense for segment rules

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses so one rule can cover a server tier, and each rule can log its matches to the live log view. It fits rules at the network edge and between segments more than per-server agents. Check which rules you are enforcing on each host, not only at the perimeter, and confirm the logging settings with the current documentation.

Wazuh configuration checks

Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints against YAML policies. Most policies are based on CIS benchmarks, and you can write custom checks for files, registry keys and running processes. A policy can confirm that a firewall service is running and that its configuration matches your standard, and it recommends remediation for failures. Confirm which policies cover your operating systems and whether they check the firewall settings you rely on.

Fleet policies across hosts

Fleet (MIT) policies are yes or no questions written as osquery queries, such as whether a firewall is enabled on a host. The policies page shows which devices in each fleet pass or fail each policy. This gives you a per-host result across the estate that an assessor can sample, with the failing devices listed for remediation. Write the query to check the firewall state you require, and confirm osquery table coverage for your operating systems.

Coraza for application traffic

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It filters application-layer attacks such as SQL injection and cross-site scripting, and it has integrations for Caddy, HAProxy, Traefik and Nginx. It complements the host and network firewall rather than replacing it, since it does not control which ports a server accepts. Document it as a separate control and confirm the integration you plan to use against the current documentation.

Who does what for Safeguard 4.4

Your organization owns Safeguard 4.4. The CIS Controls are a self-directed baseline, so the firewall requirement on each in-scope server is a decision your team makes and must be able to defend. Ownership does not mean your staff must write every rule themselves, but the people accountable for the server estate must approve what is allowed through and why.

Owning the baseline: Decide which server roles need a host firewall, which default policy applies (deny inbound unless permitted), and which management paths such as SSH or RDP are allowed and from where.
Approving exceptions: Record each deviation from the baseline with a business reason, an owner, a review date and a compensating control.
Signing rule changes: Require a documented approval before any change to firewall rules on production servers, and keep the approval linked to the change ticket.
Maintaining the asset and software inventories: The assessment depends on knowing which servers exist (Safeguard 1.1) and what software runs on them (Safeguard 2.1), so your team keeps those current.

Before engaging anyone, confirm that you can name the owner of each server firewall policy and produce its approval history.

Where server firewall programs usually fall short

Most server firewall programs fail in the gaps between tools, not in the tools themselves. The six gaps below show where Safeguard 4.4 evidence tends to break down, and each one pairs with a check you can run before an assessor asks.

Servers with no firewall or exception

A server with no host firewall and no documented exception is the simplest Safeguard 4.4 failure, and it is often a server that was built from an old image or a vendor appliance that was never reviewed. Ask for a list of every server that lacks an active firewall, then check that each one either has a firewall running or has a written exception that names the reason, the owner and a review date. Where the server supports a firewall, the gap is a control failure, not a judgment call.

Permissive default rules

A firewall that is enabled but allows all inbound and outbound traffic meets the letter of having a firewall without managing it. Look at the default policy on each server, not just the service status. An actively managed rule set should deny unexpected inbound traffic by default and permit only the ports each server needs, with the owner of each open port identifiable from the rule itself.

Rule changes outside change control

Firewall rules edited directly on a server, often during an incident or a late-night troubleshooting session, drift away from the approved configuration without any record. Compare the live rule set against the version held in your configuration management or change tickets. Any rule that exists on a server but not in an approved change is a finding, and the fix is to route emergency changes through the same record so they are reviewed afterward.

Inventories that miss cloud instances

Safeguard 4.4 is measured against the servers you actually run, so an inventory built from a data center export will miss autoscaling groups, short-lived containers hosts and instances launched by developers. Reconcile your server inventory against each cloud account's live instance list and against the configuration management database. Ask whether instances that were launched and terminated within the reporting period are included in the evidence.

One-time screenshots as evidence

A screenshot of a firewall console taken for an audit shows the configuration on one day and proves little about the next. Assessors expect evidence that can be regenerated: a scheduled export of rule sets per server, stored with a timestamp and compared against the baseline. Check that you can reproduce the same export on request and that it covers every server in the inventory, not only the ones selected for the sample.

Monitoring that skips some servers

Firewall state is only useful if someone learns when it changes. Confirm that a monitoring check reports firewall status and rule drift for every server in the inventory, including servers added recently. Test it by disabling the firewall on one non-production host and confirming that an alert reaches the owner within the period your procedure states. A monitor that covers the majority of servers leaves gaps that an assessor will find.

Questions buyers ask about Safeguard 4.4 cost, effort and scope

Can our team meet Safeguard 4.4 in-house without an outside partner?

Yes, in many organizations an internal team can meet Safeguard 4.4, because the Safeguard asks for something a capable operations team can build: a firewall that runs on each server where the server supports one and is actively managed. The harder part is consistency across the estate and producing evidence an assessor can follow. Ask whether your team has current asset and software inventories, a documented rule set for each server role, and a change process that records who approved each rule change. If those exist, the work is mostly configuration and verification. If they do not, the gaps in Safeguards 1.1, 2.1 and 4.1 will slow the firewall work regardless of who does it. Independent auditors or assessors test the controls, so the organization still owns the result.

What makes the effort for server firewalls go up or down?

Effort rises with the number of servers, how different their operating systems and roles are, and how many separate processes change firewall rules. A fleet of identical servers managed from one image is far simpler than a mix of Linux, Windows and legacy systems with hand-edited rules. Each distinct server role needs its own rule set, and each change process needs a named owner and a record. Effort also rises when rules are not documented, because the team must first learn what traffic each server really needs. Ask a prospective partner or internal lead to break down the work by operating system family, server role and change process, since those three factors usually explain most of the difference in scope.

Do open-source firewall tools remove license costs entirely?

Open-source tools can remove license fees for the firewall software itself, but they do not remove the cost of the people and infrastructure that run them. Operating system firewalls are usually already included with the server platform, and third-party agents or virtual appliances may carry their own licensing terms. Recurring costs include staff time to write and review rules, testing before changes reach production, monitoring and log review, upgrades and the hosting for any management platform. Ask any quote to separate one-time setup from recurring operations, and to state which licenses, if any, sit with the client. Confirm each tool's license terms in its own documentation before assuming it is free for your use.

What does the client need to provide for a server firewall engagement?

The client needs to provide accurate access and information, because firewall rules are only as good as the inventory and ownership behind them. Typical requirements include a current list of servers and their roles, a software inventory showing which services run on each host, named owners who approve rule changes, and administrative access to the servers and any management consoles. Test environments help too, since rules can be checked before they reach production. Without these, the engagement will spend time discovering what should already be recorded. The written scope should list each dependency and who is responsible for providing it.

How long does a server firewall project take?

The timeline depends on the agreed scope, and DeployOpen's engagements are fixed-scope, so the duration is set in the written scope before work starts. The main factors are the number of servers, the number of distinct server roles, how well current traffic is understood, and how many change approvals must be completed. Ask for the timeline to be broken into phases, such as discovery, rule design, testing, rollout and evidence collection, with dependencies on inventory and configuration work named explicitly. Any timeline that is not tied to a written scope should be treated with caution.

Does Safeguard 4.4 depend on Safeguards 1.1, 2.1 and 4.1?

Yes, the CIS Controls Assessment Specification lists Safeguards 1.1, 2.1 and 4.1 as prerequisites for measuring Safeguard 4.4. Safeguard 1.1 covers the enterprise asset inventory, which tells you which servers must have a firewall. Safeguard 2.1 covers the software inventory, which shows which services are running and therefore which ports should be open. Safeguard 4.1 covers the secure configuration process, which defines how firewall settings are documented, approved and reviewed. The firewall work can start before those are complete, but measurement will be weak until the data they produce exists. Treat them as part of the same project rather than as separate tasks.

Will an assessor accept the firewall built into the operating system?

Yes, Safeguard 4.4 lists a firewall built into the operating system as one of its examples, alongside a virtual firewall and a third-party firewall agent. The assessor's question is whether the firewall is present, actively managed and configured for the server's role, not which product it is. Evidence usually includes the enabled firewall state, the documented rule set, the approval record for changes and a sample of logs or scan results showing the rules are applied. Confirm with your assessor how they will sample servers and what format they expect, because the evidence must show that management is ongoing rather than a one-time setting.

What does DeployOpen deliver for a server firewall engagement, and what does it not?

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it can prepare firewall configurations, rule documentation and evidence for an assessment under a written, fixed scope. It can also run security testing that checks whether server firewalls behave as intended. DeployOpen does not own your controls, does not issue audit reports or attestations, and does not certify that Safeguard 4.4 is met. Those decisions belong to the organization and to an independent auditor or assessor. Ask any partner to state these boundaries in the written scope.

How DeployOpen scopes and prepares Safeguard 4.4 evidence

DeployOpen works on Safeguard 4.4 as a fixed-scope implementation inside your own infrastructure, covering the server firewalls you choose to run and the evidence that shows they are actively managed. DeployOpen prepares systems and records, while your organization owns the control and an independent assessor or auditor reaches any conclusion about it.

How we scope

Agree in writing which server populations, operating systems and hosting platforms fall inside the Safeguard 4.4 scope.
Confirm which firewall type applies to each server: virtual firewall, operating system firewall or third-party agent.
Record the prerequisite inputs from Safeguards 1.1, 2.1 and 4.1 that the measurement will draw on.

How we build

Configure host firewalls on in-scope servers so that managed rules, not default settings, govern inbound and outbound traffic.
Set up firewall policy with rule aliases and logging on self-hosted platforms where your environment supports them.
Deploy configuration checks that report whether each server's firewall is enabled and matches the approved policy.

How we hand over

Deliver a firewall configuration record listing each in-scope server, its firewall type, owner and approved rule set.
Provide test results showing how each of the six CIS assessment measures for Safeguard 4.4 was checked, with exceptions noted.
Document the review process and the runbook your team needs to keep firewall state current after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Re-run firewall checks after server builds, operating system upgrades or policy changes, and report drift.
Confirm with your auditor which evidence formats and sampling approach they will accept before collection begins.