ICS-Specific Process Kill List

What an ICS-specific process kill list is for

An ICS-specific process kill list is a defensive allowlist-style control for stopping known-bad or unsafe industrial processes before they can interfere with operators, servers, engineering workstations or controllers. It turns process termination into a deliberate control decision rather than an ad hoc incident response step.

In practice, the list is used when a process is clearly malicious, incompatible with the OT environment, or outside the approved operating scope. That matters in industrial settings because a normal enterprise endpoint response assumption can be too broad, and terminating the wrong process can disrupt safety, availability or control logic.

Where it fits in OT endpoint and application control

This control sits at the boundary between endpoint protection and OT-specific application control. Its job is narrower than general malware detection, because the decision is not just whether a process looks suspicious, but whether it should be stopped because it is known to be unsafe for that site or that class of asset.

The concept is closely tied to NIST SP 800-82 Rev 3, OT Security Guide, which frames industrial security around protecting availability, segmentation, and control-system constraints. It also aligns with the practical guidance in CISA Industrial Control Systems, where defensive actions must preserve safe operation while reducing exposure.

An ICS-specific kill list is not a replacement for broader allowlisting or malware controls. It is a targeted safeguard for situations where a process name, hash, path, publisher, or behavioural profile is already understood to be inappropriate for the environment and should be terminated quickly and consistently.

Why kill lists are used in industrial environments

Industrial environments often contain long-lived systems, shared workstations, vendor tools, and legacy runtimes that make generic security tooling difficult to tune. A process kill list gives defenders a way to stop known dangerous executables without depending entirely on signature-based malware classification or manual operator intervention.

That makes the control useful against unwanted utilities, commodity malware, living-off-the-land abuse, and out-of-scope software that should never execute on an OT asset. It is especially valuable when the objective is to keep unsafe code from reaching controllers, engineering tools, or process-facing hosts where even brief execution can create operational disturbance.

Well-designed OT guidance, including the material in the OT Security Guide, treats process control as part of a larger architecture that includes segmentation, secure remote access, and baseline hardening. A kill list works best when it supports that broader operating model rather than acting as a lone control.

How defenders maintain and use the list safely

The list should be governed as a high-confidence control asset, not as a static text file. Entries need clear ownership, a change process, and validation that the targeted process is truly unwanted across the relevant asset class, because the same executable can be harmless on one system and dangerous on another.

Defenders typically maintain the list from trusted detections, vendor advisories, incident findings, and site-specific application inventories. In OT, that inventory discipline is critical because safe termination depends on knowing which processes are essential to operations, which are vendor-dependent, and which are genuinely out of scope.

For environments facing known ICS malware families and tooling patterns, the PIPEDREAM ICS Toolkit Guide is a useful example of why process-level blocking matters: once an operator-facing or controller-adjacent system is exposed to purpose-built ICS tooling, defenders need fast, deterministic suppression of malicious executables and related components.

What a kill list does not solve

A process kill list is a compensating control, not a complete protection strategy. It does not remove the initial foothold, prevent reintroduction after reboot, or stop an attacker from using a different process name, path, or execution method if other controls are weak.

It also depends on monitoring and response. If defenders cannot see process creation, command-line use, child-process chains, or repeated relaunch attempts, they may never know whether the kill list is working or whether the underlying intrusion is continuing through a different execution path.

Risk and Threat Considerations

An ICS-specific process kill list reduces exposure, but it also creates a high-stakes dependency on correct classification. If the list is incomplete, malicious code may persist long enough to alter workstation behaviour, suppress visibility, or interfere with engineering and operator functions. If it is too aggressive, it can terminate legitimate OT software and create avoidable disruption.

Failure mechanism: Attackers or unsafe software evade the control by using a different executable name, launching from another path, or chaining through a trusted parent process, while defenders either miss the malicious process or kill a legitimate one by mistake.

Impact: The result can be loss of visibility, interruption of control-room workflows, service instability, or continued execution of software that should have been stopped before it touched OT assets.

Practitioner Guidance

Governance implication: Treat the kill list as a controlled OT policy artifact with an owner, review cycle, and rollback path. It should be updated from real detections and site inventories, then tested against representative systems so that termination logic matches the operational reality of the environment.

What to watch for: Review repeated relaunch attempts, new process names with the same function, or blocked executions on engineering workstations and controllers. Those patterns often show that the control is working, but they can also reveal an adversary adapting to the block list.

Related resources from NHI Mgmt Group

• Process Kill List
• Who should be accountable for approving automated kill process actions in incident response?
• What is the difference between kill, pkill, and killall in Linux process management?
• What happens when retailers process customer data without jurisdiction-specific privacy controls?