A conventional firewall decides whether network traffic should be allowed by examining things such as where it came from, where it is going, which protocol it uses and what kind of request it contains. In an industrial plant, however, whether a request is safe can also depend on what the physical machinery is doing at that moment, and conventional firewalls know nothing about that.

A Process-State Firewall would bring those two worlds together. It could allow remote access to a pump controller only when trusted, current evidence confirms that the pump is stopped, the relevant valves are closed and the equipment is formally under maintenance. Network access would no longer be treated as a permanent technical permission, but as an operational action that is permitted only while the physical conditions making it safe remain true.

Status: Seed. This is a captured research idea, not a claim of novelty, a settled architecture or an active build. It is recorded here intact so that its central insight, its technical questions and its possible route to implementation are not lost while it waits for attention. What follows separates what the thinking has settled from what remains genuinely open.

The idea in one sentence

A Process-State Firewall is a process control network policy-enforcement point that admits a network operation only while independently established physical and operational permissives remain valid.

In an ordinary firewall, a rule might say:

ALLOW 10.20.4.15 -> 10.30.7.42 TCP/44818

In a Process-State Firewall, the rule could say:

ALLOW an engineering write
FROM an authorised engineering workstation
TO the compressor controller
ONLY WHILE:
    unit.mode == MAINTENANCE
    AND compressor.speed == ZERO
    AND isolation.confirmed == TRUE
    AND local_enable == TRUE
    AND work_permit.active == TRUE
    AND all required evidence is current and admissible

The firewall would not merely understand the packet. It would understand the physical and operational conditions under which allowing the packet is legitimate.

Where the thought came from

The idea emerged through forced bisociation: asking what would happen if one system had to be performed as though it were another. The collision was a single question. What if network access had to be performed as a process-control action?

A programmable logic controller evaluates physical and operational predicates before permitting an equipment transition: if the vessel level is safe, and the outlet valve is open, and motor protection is healthy, then permit the pump to start. A firewall evaluates communication predicates before permitting a packet transition: if the source address matches, and the destination matches, and the protocol and port match, and the connection state is valid, then permit the packet.

Both are real-time policy machines. Both mediate consequential transitions. The historical division is that the controller may reason about physical state while the firewall normally reasons only about network state. Removing that division gives the shape of the thing:

IF source identity is authorised
AND requested industrial operation is permitted
AND physical isolation is established
AND plant mode is appropriate
AND the supporting evidence is current and trustworthy
THEN permit the network operation

The larger observation

Modern industrial control systems are already distributed networking-logic machines, but they usually do not represent themselves that way. A refinery contains state-producing nodes, message channels, distributed decisions, state transitions, authority boundaries, timing constraints, feedback loops and failure-containment zones. Nevertheless the network is generally treated as passive transport connecting the controllers, rather than as part of the plant's executable authority structure.

The reason is historical. Industrial control evolved from pneumatic and electrical control through relays, analogue electronics, programmable controllers, distributed control systems, proprietary buses and finally industrial Ethernet. At each stage, networking mostly reproduced an existing signal or control relationship more cheaply, and the conceptual division survived intact: the controller performs the control, and the network transports the information.

Control engineers consequently model measurements, set-points, equipment modes, sequences and interlocks. Network engineers model addresses, routes, VLANs, ports, sessions and zones. The semantic relationship between those two models is usually held in documents and in human understanding rather than in the running enforcement architecture. Which leads to the proposition underneath this whole idea:

Convergence connected control systems and networks physically, without converging their decision models.

Why this is not simply an industrial firewall

Modern industrial firewalls may already understand Modbus, DNP3, EtherNet/IP and CIP, OPC, IEC 60870-5-104, IEC 61850 or S7. They may distinguish reads from writes, validate function codes and block controller programming. That is industrial-protocol awareness, and it is not the same thing.

A Process-State Firewall adds physical-process-state awareness. It could distinguish not only what operation a packet requests, but whether current plant conditions make that operation admissible. That requires four elements together:

• Industrial-protocol semantics. Distinguishing monitoring, actuation, configuration, set-point change and program download, rather than relying only on addresses and ports.
• Physical and operational predicates. Making equipment state, isolation, plant mode, local enablement and work authority native inputs to the access decision.
• Evidential qualification. Evaluating freshness, quality, provenance and independence, rather than accepting a bare process value as truth.
• Temporal session semantics. Defining what happens when a permissive disappears during an operation that is already under way.

The fourth may be the most difficult and the most interesting. Conventional access control is comfortable deciding whether a session may begin. Process control forces a harder question: what should happen when the physical conditions under which a session was admitted cease to be true? Immediate disconnection may be unsafe. Continued access may also be unsafe. A firmware download, an actuator write and a read-only historian query cannot all have the same revocation behaviour.

What a rule might look like

An iptables-like expression might read:

-A OT_ACCESS \
  -s ENG_WORKSTATIONS \
  -d XV204_CONTROLLER \
  -p tcp --dport 44818 \
  -m industrial-operation --cip-write \
  -m plant-state --predicate XV204_SAFE_FOR_ENGINEERING \
  -j ACCEPT

with the process predicate defined separately:

XV204_SAFE_FOR_ENGINEERING =
    process_mode == MAINTENANCE
    AND XV204.closed_limit == TRUE
    AND XV204.open_limit == FALSE
    AND P204.running == FALSE
    AND upstream_pressure < 0.5 bar
    AND local_enable == TRUE
    AND isolation_permit.active == TRUE
    AND all_required_evidence.is_admissible == TRUE

That separation is itself valuable, and not merely tidy. Control engineers could own the process predicate; cybersecurity engineers could own the permitted network operation. The enforcement decision is the conjunction of the two, and each discipline writes the half it is competent to write.

Process state is not a bare value

A statement such as XV204.position = CLOSED is insufficient for enforcement. A useful state object needs an evidential envelope around it: the claim and its value, the time at source and the time of receipt, a quality indicator, the originating sensor, the transport it crossed, a sequence number, an expiry, its derivation lineage, and a note of which independent channel it came from.

Rules must then be able to depend on all of that, not just the value:

XV204.position == CLOSED
AND XV204.position.quality == GOOD
AND age(XV204.position) < 1 second
AND XV204.position.source IN approved_position_sources

This is not a perfectly synchronous snapshot of the refinery, which is not achievable. It is a versioned set of observations with signal-specific bounds on staleness.

Runtime architecture

The packet path must never make a synchronous query to a controller, a distributed control system, an OPC UA server or a historian. It requires a locally maintained process-state image, analogous to a controller's input image:

Plant and operational evidence
        |
Process-state authority
        |
Validated, versioned local state image
        |
Firewall rule and session engine
        |
Fast packet data plane

A user-space service would collect and validate process and operational state, then publish a compact local snapshot into a form that nftables, eBPF or a Netfilter extension could evaluate cheaply. The firewall consults local memory rather than making a network round trip.

For a large plant this should be distributed and selective. A firewall protecting a hydrocracker does not need the whole plant's tag space, only the predicates relevant to its zone. A refinery might expose hundreds of thousands of tags while requiring only hundreds of security-relevant predicates, with perhaps a handful used by any single rule.

Command, execution and feedback

The architecture should distinguish the commanded firewall state, the actually installed firewall state, the observed session use, the current process permissives, and the physical consequences where those are observable. A full access transition then becomes a closed-loop operation: validate authority and permissives, install or activate the rule, verify it reached the data plane, observe the session establish, monitor the relevant conditions continuously, invoke the declared revocation behaviour when they lapse, and verify that the session and the rule are actually gone.

That is materially stronger than a change record whose final evidence is that a configuration commit succeeded.

Session semantics

At least three modes appear necessary, and the choice between them is not obvious.

Admission-only evaluates process state when a connection is created, after which established traffic follows normal connection tracking. It is stable, and it may preserve access after the physical justification for it has disappeared.

Continuous enforcement evaluates every packet or industrial operation against current state. It removes authority quickly, and it can interrupt a critical transaction at a dangerous point.

Controlled revocation makes the loss of a permissive trigger operation-specific behaviour: block new commands, permit a bounded safe completion where one is defined, reset or expire the session, then verify removal. This is probably the most defensible model and certainly the most difficult to specify, since it requires knowledge of industrial protocol transactions and of equipment consequences.

The static envelope must survive

Dynamic process state must not be able to rewrite the fundamental security architecture. Some constraints stay invariant regardless of what the plant reports: a monitoring path cannot become bidirectional; one zone cannot become a transit route for another; safety communications remain independent; field controllers cannot initiate arbitrary internet sessions; prohibited engineering paths cannot be conjured into existence by a process tag; and the failure of the state authority cannot abolish segmentation.

The effective policy is therefore an intersection, not a substitution:

effective_policy =
    invariant_security_envelope
    AND operating-mode policy
    AND current process permissives
    AND temporary operational authority

Dynamic state operates inside the static envelope. It never replaces it.

Failure and degraded operation

"Fail closed" is not a sufficient design rule in a process control network. Denying or severing communication can itself create physical consequences. Fallback behaviour has to be defined per traffic class and per operation class: new engineering writes denied; an established write operation following its declared safe-completion policy; read-only monitoring continuing where that is safe; cyclic control retaining its engineered static policy; safety communications remaining independent and unaffected throughout.

The design would also need the protections any control engineer would expect: hysteresis, minimum dwell time, stale-data handling, state-transition validation, quality handling, rate limiting, anti-flapping behaviour, defined degraded modes, and manual override with an explicit scope and expiry.

The central trust problem

The same controller must not be able both to request access and to provide all the evidence that makes that access permissible. If a compromised controller can assert that the valve is closed, the pump is stopped and the mode is maintenance, then a process-aware firewall becomes an access-opening mechanism for the attacker, which is worse than no firewall at all because it is trusted.

Relevant state may therefore need to come from combinations of independent sources: valve limit switches, motor-protection relays, electrical current measurements, local physical enable switches, authenticated work permits, controller operating mode, independent process instruments, and separately administered safety or asset-management systems.

The subtle trap is that multiple agreeing values are not independent evidence if they all share a compromised ancestor or a common transport path. Agreement is not corroboration when everything agrees because it all came through the same door.

HARVEY as the counterexample

Part of this thinking came from examining HARVEY, the physical-model-aware controller rootkit described in Hey, My Malware Knows Physics!. HARVEY sits beneath legitimate control logic, substitutes malicious actuator outputs, and generates simulated measurements representing what the operator would have expected had the legitimate outputs actually been applied.

Its "understanding of physics" is overstated: it contains a compact, target-specific numerical model encoded by people who understood the plant, and the demonstrated payload was installed through JTAG rather than through a convincing remote intrusion chain. It nonetheless demonstrates the point that matters here. Physical plausibility, and agreement between displayed values, do not establish physical truth when all the observations cross the same compromised boundary.

A Process-State Firewall must therefore consume provenance-bearing state, not merely believable tags. This is precisely the failure it would otherwise be built to walk into.

Connection to Attestable

This could become a concrete runtime exemplar for Attestable. The firewall must decide whether a claim such as "XV204 is safely isolated" has sufficient standing to authorise a consequential action: permitting remote engineering access to the controller.

That demands a claim, its evidential basis, its source and derivation lineage, its freshness and quality, its independence from the corroborating evidence, its sufficiency relative to the specific action, and mechanical enforcement of the result. The division of labour is clean:

Attestable determines whether the process-state claim has sufficient standing. The Process-State Firewall enforces what that standing permits.

The combined concept is a cyber-physical reference monitor in which network authority remains conditional on attestable plant state.

What the thinking has settled

Several questions are answered well enough to build on, and they are worth stating plainly so that the open ones stand out.

• The gap is real, and it is a decision-model gap, not a connectivity gap. Control and network systems were converged physically without their decision models converging. That is the space this occupies.
• Protocol awareness is not process-state awareness. Knowing that a packet is a CIP write is not knowing whether writing is safe right now. Existing industrial firewalls stop at the former.
• State must carry an evidential envelope. A bare tag value is not admissible evidence for an access decision. Value, quality, age, source, transport, lineage and expiry all have to travel with it.
• The requester cannot be the sole witness. Evidence must be independent of the controller asking for access, or the mechanism inverts into an attacker's tool.
• Agreement is not independence. Corroborating values that share a compromised ancestor or transport corroborate nothing. HARVEY is the proof.
• Dynamic state lives inside a static envelope. Process conditions may narrow what is permitted; they may never widen the architecture itself.
• Fail-closed is not a sufficient rule. In a plant, severing communication is itself an action with physical consequences, so degraded behaviour must be defined per class of traffic.
• The data plane cannot ask the plant. Enforcement must read a validated local state image, never make a synchronous query on the packet path.
• The policy splits cleanly across two disciplines. Control engineers own the process predicate; security engineers own the permitted operation; enforcement is the conjunction.

What remains open

These are the questions that would decide whether this is a real contribution or a well-argued dead end. The minimal research question is whether an OT firewall can safely use provenance-bearing, temporally qualified plant state as a native condition of protocol-operation and session admissibility. Underneath it sit the ones that actually have teeth.

• Is it novel? This has had no disciplined literature, product or patent review. The surrounding territory is populated, and the claim to distinctness is currently untested.
• What is the correct policy model? The rule syntax sketched above is illustrative, not designed.
• Which plant observations are legitimate inputs to network authority? Not every tag deserves a vote.
• How should freshness and quality be represented? And how does a rule express its own tolerance for staleness?
• How can common-mode evidence be identified? Independence is easy to assert and hard to establish.
• Who owns and approves process predicates? This is an organisational question with a technical surface.
• What happens when sources disagree? Disagreement may be the most informative signal available, or a denial-of-service vector.
• What are the correct admission and revocation semantics? Particularly the bounded safe completion, which has to know what the protocol transaction means.
• Can it avoid becoming part of the safety function? If it becomes safety-related, it inherits an entire regulatory apparatus and probably dies of it.
• How should it behave when the state service or the network fails?
• Can its decisions be deterministic, explainable and replayable? An access decision that cannot be reconstructed afterwards is not auditable.
• Can it be introduced without loading or destabilising the control system? An idea that burdens the DCS will never be deployed.

What already exists nearby

The surrounding territory includes industrial deep-packet-inspection firewalls, function-code and protocol-operation filtering, process-aware intrusion detection, dynamic and software-defined ACL management, context-aware and attribute-based access control, safety-command validation gateways, process historians and real-time state databases, and the OPC UA information and quality models.

SCADAWall, described in Computers & Security in 2019, is a relevant neighbour: it applies comprehensive packet inspection and message-sequence analysis to SCADA traffic. It appears concerned primarily with whether industrial messages are legitimate in protocol and sequence terms, rather than using independently established live physical conditions as native packet-admission predicates.

No mature implementation has yet been identified that combines firewall-class packet forwarding, industrial-protocol operation matching, a timestamped local process-state image, rules referring directly to physical and operational predicates, quality and freshness and provenance requirements, explicit session behaviour when a predicate becomes false, evidence independence from the controller requesting access, and per-rule degraded-state semantics. That is not proof of novelty. It is the absence of a search.

A minimum credible prototype

A first prototype should prove the policy concept without modifying the Linux kernel. A small physical or simulated process would do: one pump, two valves, an ESP32 or software controller, position and running and pressure indications, and at least one independently sourced permissive. Communications over Modbus/TCP or OPC UA, one engineering workstation, one controller, and a Linux nftables firewall between them.

A state authority service would ingest the process observations, retain source time and receive time and quality and provenance, derive a named maintenance predicate, expire that predicate automatically when its evidence goes stale, and update nftables atomically.

The demonstrations that would matter are the ones that could fail. Read-only traffic remains available. Write traffic is refused during normal production. Write traffic becomes available only once the maintenance predicate is established. Stale, contradictory or poor-quality state refuses new access. Loss of a permissive during an active session invokes the declared behaviour. Compromising the controller alone cannot manufacture every required condition. And loss of the process-state service leaves the static security envelope intact.

Only once the policy is proven would the harder work follow: native nftables expressions, eBPF-based matching, industrial-protocol operation parsing, session-aware revocation, signed state leases, distributed zonal state authorities, and explicit Attestable claim and basis representations.

On the name

"Process-State Firewall" is the clearest working name. "Cyber-Physical Reference Monitor" more accurately describes the eventual architecture but is less immediately legible. Plant-Context Firewall, Process-Permissive Firewall and Attestable Process Firewall are all in the running and none is settled.

Current assessment

This idea is more substantial than "a firewall that can see valve positions." Its core proposition is that network connectivity in a process control network is an operational actuation: its admissibility may depend on current plant state, and its execution and continuing authority should be verified like any other consequential control action.

The concept sits at the intersection of process control, industrial networking, cyber policy enforcement, evidence provenance and runtime assurance. The surrounding ingredients are known. Their proposed composition appears distinct enough to justify structured investigation, which it has not yet had.

It stays on the shelf as a preserved seed until it gets a disciplined literature and patent review, a precise threat and trust model, formal admission and revocation semantics, a small working prototype, and an honest evaluation against operational and safety objections.

Source trail

• Luis A. Garcia et al., Hey, My Malware Knows Physics! Attacking PLCs with Physical Model Aware Rootkit, NDSS 2017.
• Donghai Li et al., SCADAWall: A CPI-enabled firewall model for SCADA security, Computers & Security, Volume 80, 2019, pp. 134-154.
• Related fields to search: process-aware intrusion detection, semantic industrial firewalls, context-aware access control, attribute-based access control for cyber-physical systems, SDN for ICS, command-validation gateways, safety reference monitors, runtime enforcement, and provenance-aware policy.