Why Does Operating a Firewall Require You to Become a Firewall Engineer?

Our experience with OPNsense, operational complexity and the difference between powerful security and usable security

OPNsense is powerful.

That's part of the problem we encountered.

Enterprise security architecture necessarily becomes complicated. Networks are complicated. Routing is complicated. Firewall policy is complicated. Segmentation is complicated.

There is no sensible version of this argument where Alt Production Group pretends that all of that can be replaced by a giant green button labelled SECURE ME.

But there is another question.

Why does safely operating enterprise infrastructure so often require the person administering it to understand almost every layer underneath it?

During our work with OPNsense, we repeatedly encountered that tension.

Here was an extremely capable security product designed to sit at one of the most important boundaries in an organisation.

Yet from the operator's perspective, we were still dealing with familiar administrative patterns, familiar authentication patterns and an interface exposing a substantial amount of underlying networking complexity.

It made us question the relationship between security capability and operational accessibility.

We don't want less security

The answer isn't simplification for simplification's sake.

Alt doesn't want a firewall that hides everything important behind a pretty interface.

We want rigorous security.

We want enterprise controls.

We want segmentation.

We want administrators to retain meaningful authority.

What we don't accept automatically is the assumption that complexity underneath a system must translate directly into complexity for the human operating it.

If a business needs to employ a network professional simply to safely configure and maintain its security architecture, that expertise requirement becomes another architectural dependency.

Sometimes that is unavoidable.

But we should at least be asking whether it needs to be.

Passwords are another example

There was another contradiction that kept bothering us.

We can construct extraordinarily sophisticated security architecture and still arrive at an administrative interface asking somebody for a password.

Passwords are familiar. They're widely supported. They're interoperable.

They're also an extraordinarily old answer to a problem that the technology industry has spent decades supposedly trying to improve.

That doesn't mean replacing a password with something incomprehensibly complicated and declaring victory.

It means questioning why our highest-assurance systems so frequently inherit interaction models simply because that is how infrastructure has traditionally worked.

Remove the roadblocks, not the rigour

That distinction has become important across Alt Production Group.

We aren't interested in making security weaker so that it becomes easier to use.

We're interested in whether we can make strong security easier to operate correctly.

Can routine administration become more understandable?

Can configuration become safer?

Can systems provide stronger guidance without taking authority away from their operators?

Can architecture recognise failure faster?

Can we reduce the number of circumstances where somebody needs specialist knowledge simply to work out what has gone wrong?

Those aren't interface questions sitting on top of security.

They are security questions.

Because humans are part of the architecture.

A security system that is theoretically perfect but routinely misconfigured because only a specialist can understand it has a human vulnerability built directly into its operating model.

Our experience with OPNsense didn't convince us that enterprise firewalls are unnecessary.

It convinced us that there is considerably more work to do on the relationship between enterprise-grade security and the human expected to operate it.

That is a problem we're rather interested in.