Skip to main content

Process Based Policy

Overview​

Process-based policy is crucial for micro-segmentation in enterprise networks because it enables fine-grained control over network communications by identifying and regulating individual application processes, rather than just IP addresses, ports, or protocols.

Benefits​

🔐 Stronger Security Posture​

  • Traditional network controls (IP, port, protocol) can’t distinguish between legitimate and malicious processes using the same system.
  • Process-based policies allow you to only permit specific, trusted applications to communicate—blocking unauthorized or suspicious software, even if it’s on a trusted host.

Example: Instead of allowing all outbound traffic on port 443 from any browser, you can allow only traffic initiated by chrome.exe.

🕵️ Visibility Into Application Behavior​

  • Knowing which process is making a connection helps security teams understand actual data flows.
  • This enhances visibility into east-west traffic (i.e., lateral movement inside the network) and helps detect anomalies or policy violations.
  • Note: Starting with release 25.2, process visibility is supported for inbound connections only.

🎯 Granular Access Control​

  • You can enforce rules that say “only Process A on Host X can talk to Process B on Host Y.”
  • This tight scope makes it harder for attackers to pivot within the network using compromised machines.

🚫 Minimizing Attack Surface​

  • By denying all non-specified processes from communicating, you drastically reduce the potential entry points for lateral movement or data exfiltration.
  • Even if a host is compromised, a process-based policy may stop malware from contacting a command-and-control server.

⚙️ Supports Zero Trust Principles​

  • In a Zero Trust model, nothing is implicitly trusted—even inside the perimeter.
  • Process-level policies help enforce least privilege by ensuring only approved applications talk to each other, consistent with Zero Trust Architecture.

✅ Application Awareness​

Process-based policy = Application-Aware Micro-Segmentation. It ensures that security controls align with what your applications are actually doing, not just where they live on the network.

Use Cases​

The Xshield security platform supports three use cases with regards to process-based policies.

  • Listening Process Only Policy
  • Restricted Access to Listening Port
  • Restricted Access to Remote Port

Listening Process Only Policy​

An operator should use a process-only policy (i.e., one that does not specify port and protocol) when the primary goal is to control or allow communication based on the identity of the application/process rather than its network behavior.

Here are the typical scenarios where a process-only policy is appropriate:

✅ When the Application Identity Is Sufficient​

If the operator trusts that only certain processes should be allowed to communicate—regardless of which port/protocol they use—then a process-only policy provides a clean and flexible approach.

Example: Allow only nginx to listen on inbound connections from a Named Network, without worrying about whether it uses port 80, 443, or another dynamic port.

✅ When Ports/Protocols Are Dynamic or Unpredictable​

Some applications use dynamic ports (e.g., Kubernetes pods, FTP in passive mode, peer-to-peer apps), making it difficult to define fixed port rules. A process-only policy ensures you’re still enforcing intent without relying on port ranges.

✅ To Simplify Policy for Internal Application Communications​

In scenarios where multiple internal services communicate frequently, and you want to enforce process-level visibility without overcomplicating policy with strict port/protocol combinations.

Example: Allow communication between service-a and service-b processes on any port/protocol for internal microservice mesh scenarios.

✅ During Initial Learning or Discovery Phase​

When rolling out micro-segmentation, it's often useful to start with process-only policies to observe and learn application behavior. Once baselines are understood, you can layer on port/protocol restrictions.

⚠️ Caution: When Not to Use Process-Only Policies​

  • When port/protocol is critical for enforcement, e.g., in zero-trust models or compliance-mandated segmentation.
  • When you want to prevent abuse by a process using unexpected or unauthorized ports.

Restricted Access to Listening Port​

This touches on tightening access control by not just allowing who can listen for a connection, but also on which port. Here's when an operator should use a policy that restricts communication to a listening port to a specific process or application. The following section describes When to Use Port-to-Process Binding in Policies.

🔒 To Prevent Unauthorized Applications from Listening on Critical Ports​

If a sensitive port (e.g., 443, 3306, 22) must only be handled by a specific, trusted application (like nginx, mysqld, or sshd), then binding that port to a process ensures only that process can accept connections on it.

Example: Allow inbound connections to port 443 only if the listening process is nginx. This prevents a malicious process from hijacking the port.

🧩 To Enforce Application Integrity and Minimize Attack Surface​

In a compromised environment, a rogue or injected process could try to bind to an open port and eavesdrop or impersonate a service. Binding a port to a known process strengthens segmentation by validating the receiver.

Use case: Ensure only postgres can listen on port 5432, even if another process attempts to bind to it.

🎯 To Support Least Privilege Access​

This enforces the principle of least privilege not just on initiators but also on listeners. It ensures that access is granted only when the intended service is running, not just when a port is open.

🔄 To Lock Down Multi-Use or Common Ports​

Ports like 80, 443, or 8080 might be used by different services in different contexts. Binding them to a specific process avoids ambiguity and unintentional exposure.

🔍 To Improve Auditability and Policy Clarity​

Defining which process owns which port adds a valuable layer of visibility. You can confidently say "only app-X should ever handle traffic on port Y," which simplifies audits, compliance, and troubleshooting.

⚠️ When NOT to Use This​

  • If the port is intentionally shared between multiple trusted processes (rare but possible in certain proxy/load balancer scenarios).
  • If the process fingerprinting or telemetry isn't stable or reliable (e.g., in early rollout or noisy environments).
  • In early discovery phases where process-port relationships are not yet well understood.

Restricted Access to Remote Port​

In micro-segmentation, it's not enough to define which assets can communicate with external services. For stronger enforcement, it's essential to also define which process is allowed to initiate that communication. This ensures that only approved applications can access critical services or external endpoints—even if the underlying port and protocol are technically allowed by the firewall or platform.

The Xshield platform supports defining outbound policies that tie destination port/protocol access to the originating process, thereby significantly improving control, visibility, and security posture.

This policy ensures that:

  • Only the specified process(es) are allowed to initiate outbound communication on a given port and protocol.
  • Other processes on the same asset attempting the same connection are explicitly denied—even if the destination or port is normally permitted.
  • Enforcement is applied at the process level, not just the network or asset level.

Operators should define an outbound process-to-port policy in the following scenarios:

  • ✅ To restrict sensitive destinations (e.g., APIs, cloud services, databases) to trusted applications only.

    Example: Only python3 should be allowed to make HTTPS requests to a cloud API.

  • ✅ To prevent unauthorized or shadow applications from exfiltrating data or accessing the internet.

    Example: Allow only authorized applications to open outbound ports like 443 or 80.

  • ✅ To enforce least privilege on outbound access, especially in zero-trust architectures.

    Ensures only processes with a valid business justification can initiate outbound connections.

Work Flows​

The Xshield security platform provides multiple ways to configure and program process-based policies. One way is to look at the reported paths (from the agents) and attach them to existing templates; another way is to write a static policy by creating a template and adding the process information (along with port, protocol, and IP address if necessary).

Learning Process Information from Agent​

Agents collect network telemetry by collecting network traffic information using PCAP (npcap on Windows and libpcap on Linux). As part of that, the agent can also query the Operating System to retrieve the process associated with listening network ports and correlate it with the network paths.

The agent sends this network telemetry to the Xshield security platform where the operator can review it and associate it with a policy template (associated with the asset). The operator can choose to associate only the process or the process and the port/protocol and maybe even path-restrict it to a set of IP addresses. On enforcement, this template association will ensure that this process-based rule will be programmed in the host firewall on the asset.

Note: Process Information can be learned only for Inbound connections on a host in the current release (25.2)

Programming the Process in a Template​

Operators can alternatively add the process name (full binary path name) in a template and then attach the template to the associated assets either directly or through a segment (to which the asset is a member). This is useful in cases where the agent cannot discover or associate the process to the communication channel, like when the communication is short-lived.

Caveats and Failures​

  • There is always a possibility (especially for user-configured processes) that the corresponding application may not be installed on the server or may be installed in a different location on the server. In those situations, the host firewall programming will fail as the Xshield agent will not be able to locate the application at the specified path. In those cases, the Xshield agent will generate an event/alert that will be visible on the Xshield platform under the Monitor section. The operator can review the event and make the appropriate changes either to the configured path or update the application on the server to be installed in the right path.

The operation to generate this event is not supported today. It will be available in an upcoming release. However, the raw firewall rules returned by the agent to the platform will have the information of failed process-based rule programming.

  • Today, Process-Based Policies are supported ONLY by Agents satisfying ALL of the below conditions:

    • Agent Type: User/Server
    • Agent version >= 25.2.0
    • Operating System: Windows

  • Even if Process-Based Policies or Templates are assigned to Linux/MAC agents or Windows agents below 25.2.0, these policies are not pushed to the agents. The Policy viewer/Preview section will reflect this.

  • Agent Upgrade Flow

    • If a Windows Server/User agent below 25.2.0 version is upgraded to version >=25.2.0 and if the Process-Based Policies are assigned via a Segment where AUTO Push to Firewall is enabled, the Process-Based Policies/Templates will get pushed to Agents automatically after upgrade.

  • Process-Based Rule Programming is supported for Both Outbound and Inbound Allow Rules

  • Process visibility is supported only for Inbound Paths

  • Template Match(Path Status/Path Candidate Status)

    • Inbound Paths with Process Visibility will match Process-Based Templates if Destination Executable Path matches with the Process in the Template
    • Outbound Paths won't match Process-Based Templates as outbound paths won't have Process visibility

Summary​

In summary, process-based policy is a key enabler of effective micro-segmentation, providing precise control over which applications can communicate within an enterprise network. By focusing on specific processes rather than just IPs or ports, it enhances security, supports Zero Trust principles, reduces attack surfaces, and offers deep visibility into application behavior—making it a powerful tool for protecting modern, dynamic IT environments.