by Heath Gieson

 

Some attacks are sophisticated. Weeks of reconnaissance, carefully crafted messages, and quiet exploitation in the background. But plenty of real-world incidents begin with something far simpler: a device answering traffic it never needed to accept in the first place.

A server that was “only temporarily” exposed. A laptop that was reachable because a setting changed during an install. A remote access tool that worked perfectly until it became the easiest way in.

That is the problem CIS IG1 Safeguards 4.4 and 4.5 are designed to solve. And it is why they belong together in one conversation.

What these controls actually say (in plain English)

If you are not a technical reader, here is the simplest translation: servers and end-user devices should behave like they have a locked front door. Nothing gets in by accident. If something needs access, it is opened intentionally, documented, and managed.

Now the official version:

Control 4.4 says you should implement and manage a firewall on servers (where supported).

Control 4.5 says you should implement and manage a host-based firewall (or port-filtering tool) on end-user devices, with a default-deny posture. In plain terms, that means traffic is blocked unless you explicitly allow it.

That is not paranoia. That is operational maturity.

Why business leaders should care: exposure is now everywhere

For years, most organizations treated the firewall as a perimeter device. If the building had a locked front door, everything inside felt safer by default.

The problem is most businesses do not operate inside one building anymore.

Work happens across offices, homes, airports, and client sites. Systems run in multiple environments. Vendors connect in. Employees connect out. The moment you accept that, one truth becomes obvious:

If your security strategy depends on a single perimeter, you are protecting a world that no longer exists.

Controls 4.4 and 4.5 are not asking you to reinvent your environment. They are asking you to stop letting devices be reachable by accident, just because they happen to exist.

Default-deny isn’t a technical setting. It’s a business decision.

The phrase default-deny sounds technical, but it is really a risk decision.

Default-allow says, “We will permit traffic unless we remember to block it.”

Default-deny says, “We will block traffic unless we have a business reason to allow it.”

Business leaders already operate this way in other parts of the company. Finance does not approve payments by default. HR does not grant access forever “just in case.” Those processes are intentionally restrictive because the cost of getting it wrong is high.

This is the same idea, applied to servers and endpoints.

When you operationalize it correctly, you get three outcomes that matter to leadership:

1. Fewer incidents caused by simple exposure

A surprising number of breaches are not the result of brilliant adversaries. They are the result of preventable openings. Default-deny reduces the number of openings that exist at all.

2. A smaller blast radius when something goes wrong

No organization gets everything perfect. The goal is resilience. When devices are not broadly reachable, attackers have fewer paths to move, spread, or escalate.

3. Compliance you can actually prove

A setting someone enabled once is not a control. A control is something you can define, enforce, verify, and report on consistently.

 

The hidden failure mode: controls that exist, but aren’t managed

A firewall that is “enabled” but not managed is like a security camera no one watches. It might look comforting, but it does not change outcomes.

This is where operationalizing security matters. Security controls only work when they are part of a repeatable operating rhythm, not a one-time configuration.

In a previous post, I framed it well: the easiest controls to understand are often the easiest to let slide, especially when the friction feels small. The Unlocked Screen in the Corner Office

Endpoint and server firewalls fall into that category. Most organizations assume they are “on,” but struggle to answer a few basic questions:

Who owns the standard?

What exceptions exist, and why?

How do we know the policy will still be in place next month?

How do we spot drift before it becomes an incident?

That is not a technical problem. It is an operational one.

What “good” looks like (without getting technical)

You do not need to become a firewall expert to implement 4.4 and 4.5 in a business-friendly way. You just need to treat them like any other operational control: define the standard, assign ownership, manage exceptions, and verify continuously.

Here is what this looks like in practice:

Define a baseline behavior

Servers should only accept what they truly need. End-user devices should not accept inbound traffic unless there is a documented reason.

Centralize enforcement

The goal is consistency across teams and platforms. This is where many organizations win back time and reduce risk at the same time. The control should not depend on individual users, one-off settings, or tribal knowledge.

Treat exceptions as business decisions

Some systems will need special access. That is normal. The difference is whether exceptions are intentional, owned, documented, and reviewed, or whether they are accidental and forgotten.

Verify and report

If you cannot confirm the control is in place, you cannot rely on it. Drift happens quietly, usually under pressure, and usually with good intentions.

 

Why secure access models (SASE and ZTNA) fit this conversation so naturally

If 4.4 and 4.5 are the “locked door” principle applied to devices, modern secure access models are how you extend that principle to the way work actually happens today.

A modern secure access approach enforces policy wherever users work, not just inside an office. And Zero Trust Network Access takes it one step further: access is granted only after verifying who the user is and whether the device should be trusted.

That is why these controls are a natural bridge into the larger shift happening in security right now:

Host-based firewalls reduce accidental exposure on endpoints and servers.

Zero trust access reduces the assumption that “internal” automatically means “safe.”

This is not about stacking more tools. It is about replacing fragile assumptions with consistent rules.

The bottom line

CIS IG1 4.4 and 4.5 are deceptively simple. They are not asking you to reinvent your environment. They are asking you to stop leaving doors unlocked by default on the two asset types your business depends on most: servers and end-user devices.

When you implement these safeguards as operational discipline, you get more than security:

You reduce avoidable exposure

You improve resilience

You strengthen compliance posture with something you can validate

You align the business to a world where “internal” is no longer a reliable boundary

If you want a practical next step, start with one question that cuts through the noise:

Can we clearly explain what traffic is allowed into our servers and endpoints, and why?

If the answer is unclear, that is not a failure. It is a starting point.

At Forthright, we help organizations operationalize secure access and device protections in ways that reduce risk without slowing the business. If you are not sure how your endpoint firewall posture stacks up today, that is a conversation worth having.