Port and Path Enforcement Status
Overview
The ColorTokens Xshield platform enforces microsegmentation by controlling two fundamental network exposure surfaces:
- Ports – Listening services on hosts that can receive traffic.
- Paths – Communication flows between source and destination hosts over specific ports and protocols.
Xshield tracks the real-time state and enforcement readiness of these elements through two indicators:
- Current port/path policy – Shows the enforcement state of the port or path that is currently active on the asset.
- Future port/path policy – Shows the upcoming enforceemnt state of the port or path based on the applied templates.
This document describes how these statuses are interpreted and used during test and enforcement phases.
Key Concepts
Ports
Ports represent listening services on a host (e.g., TCP 3389 for RDP). In enforcement:
- Open ports can be unrestricted, restricted by template, or path-restricted.
- Enforcement applies policies to control which ports are Allowed or Blocked to accept traffic..
Paths
Paths represent communications between groups of assets over a particular port and protocol (e.g., Admin Workstation → App Server on port 3389).
- A path is not a raw TCP connection but a logical abstraction of traffic from a source group to a destination group.
- Paths are classified as inbound or outbound, depending on the direction of traffic from the asset's perspective.
Policy Types
Xshield applies policies at two different levels to control how traffic flows to and from an asset. Each type serves a distinct purpose within the Port Level Zero Trust framework.
1. Port Policy
Port Policies provide fine-grained control by defining explicit rules for specific ports. These policies determine whether individual ports should allow traffic, restrict it to specific paths, or block it entirely.
Port Policies always take priority over Asset Policies, ensuring that critical or sensitive ports can be tightly controlled regardless of the asset’s broader security posture.
| Policy | Description |
|---|---|
| Denied | All traffic is denied using port policy |
| Restricted to paths | Only paths mentioned in policy are allowed |
| Allow Intranet only | Only Intranet traffic is allowed |
| Allow All | All traffic is allowed using port policy |
2. Asset Policy
Asset Policies act as a fallback rule for all ports not covered by a Port Policy. They establish the default level of access for the asset’s remaining ports, defining whether they are fully open, restricted based on past activity, or locked down according to Zero Trust principles.
This ensures that even ports without explicit Port Policies still have a clear and consistent security baseline.
| Asset Policy | Description |
|---|---|
| Zero Trust | This strict mode blocks all ports unless explicitly permitted, aligning with the Zero Trust principle of 'never trust, always verify' and significantly reducing the attack surface. |
| Allow Active Ports | Ports that have been used in the last 30 days stay open to prevent disruptions to active services. |
| Allow Open Ports | Existing open ports remain accessible during deployment, ensuring uninterrupted communication between applications. |
| Allow All | All ports are open by default, allowing traffic to flow while administrators refine security rules. Caution should be exercised, as this may expose vulnerabilities. |
How Port Policy and Asset Policy Work Together
Port Policies and Asset Policies complement each other to provide complete coverage:
- Port Policies take precedence — if a specific port has a defined Port Policy, that policy is always applied first.
- Asset Policies fill the gaps — any port that does not have a Port Policy will follow the Asset Policy for its enforcement behavior.
This layered approach ensures that organizations can apply strict, precise control where needed (specific ports) while maintaining a consistent default security posture for the rest of the asset.
Deployment Modes
Deployment Mode defines how a rule behaves when applied to an asset or port — whether it only monitors traffic (Test mode) or actively blocks unauthorized traffic (Enforce mode).
Xshield deploys microsegmentation policies to the Asset(s) in the below modes:
| Mode | Description |
|---|---|
| Test | Traffic which is not allowed by a rule is logged as violation without blocking |
| Enforce | Traffic that does not match an allowed rule is blocked. All blocked traffic is recorded as blocked communication attempt |
Port and Path Enforcement States
Port and Path Enforcement States describe how Xshield handles traffic for a given port or communication path.
Each state indicates whether traffic is allowed, restricted, or denied based on the applied Port Policies and Asset Policies. These states help determine how strictly a port is controlled and what level of access is permitted.
The below table illustrates the enforcement states for every port/path:
| Status | Description |
|---|---|
| Allow All (System) | All traffic is allowed by system default rules |
| Denied (Port Policy) | All traffic is denied using port policy |
| Restrict to allowed paths (Port Policy) | Only paths mentioned in policy are allowed |
| Allow Intranet only (Port Policy) | Only Intranet traffic is allowed |
| Allow all (Port Policy) | All traffic is allowed using port policy |
| Allow All (Asset Policy) | All traffic is allowed by asset policy (Allow all, Allow open, Allow active) |
| Denied (Asset Policy) | All traffic is denied by asset policy (Zero trust) |
| Unreviewed | No policy |
| Allow intranet only (Port Policy) | Only Intranet traffic is allowed |
| Default Allow (Asset Policy) | All ports are open by default, allowing traffic to flow while administrators refine security rules. Caution should be exercised, as this may expose vulnerabilities. |
| Allowed By Test | Asset and port policies are currently deployed in test |
Asset Security States
Asset Security States indicate the overall security posture of an asset based on how its port and asset policies are deployed.
These states show whether the asset is fully protected, partially protected, or still in a testing phase. They help administrators understand how much of the asset’s attack surface/blast radius is currently governed by enforced Zero Trust policies versus what remains unprotected or under evaluation.
| State | Description |
|---|---|
| Unsecure | No policies are deployed |
| Partially Secure | Only individual port policies are deployed; asset-level policy is not deployed |
| Secure Test | Port policies may be deployed; asset-level policy is under test |
| Secure* | Asset level policy is in enforce mode; some port policies may still be under test |
| Secure | Both asset and port policies are in enforce mode |
State Transition Diagram
┌──────────────────────┐
│ Unreviewed │
│ (Initial asset state)│
└───────────┬──────────┘
│
▼
┌──────────────────────┐
│ Reviewed │
│ (Asset analyzed; │
│ ready for testing) │
└───────────┬──────────┘
│
▼
┌──────────────────────┐
│ Test │
│ (Violations logged, │
│ no blocks enforced) │
└───────────┬──────────┘
│
▼
┌──────────────────────┐
│ Enforce │
│ (Policies active; │
│ violations blocked) │
└──────────────────────┘
Operational Checklist for Port/Path Deployment
| Task | Description | When |
|---|---|---|
| ✅ Review future policy Status | Check paths/ports flagged as "By Template" or | During Partially Secure, Secure Test and Secure* Mode |
| ✅ Validate Behavior | Confirm that observed communications aligns with expected application behavior | During path analysis |
| ✅ Mark as Reviewed | Approve or override the proposed future policy status | Before switching to Secure Mode |
| ✅ Check Violations | Monitor "Allowed Test Denied Violation" paths in violation dashboard | Regularly during testing |
| ✅ Apply Templates | Ensure policy templates are assigned and reflect desired controls | At setup and during reviews |
| ✅ Confirm Enforcement Readiness | Switch to Secure Mode only after reviewing all critical paths and ports | Before go-live enforcement |
Viewing States in Xshield UI
| Component | UI Section | What to Look For |
|---|---|---|
| Current Port Policy | Asset > Port View | Shows current enforcement (e.g., "Allow Intranet") |
| Future Port Policy | Asset > Port View | Shows proposed action (e.g., "Allow Any By Template") |
| Current Path Policy | Asset > Path View | View each connection’s current enforcement |
| Future Path Policy | Asset > Path View | Shows behavior/template-based suggestions |
| Violations | Network Data > Future port/path policy | Lists "Test Denied Violation" paths |
| Templates | Templates | Rules defining port/path candidate statuses |
| Policy Simulation | Enforcement > Test | Aggregates candidate status and observed behavior across tenant |
Conclusion
Xshield provides an intuitive yet powerful way to manage and secure host communications through progressive port/path controls. By understanding and acting on status and Future port/path policy, operators can safely transition from visibility to enforcement, ensuring Zero Trust policies are applied without service disruption.
This document should be used as a reference when:
- Reviewing microsegmentation readiness
- Investigating unexpected communication behavior
- Preparing for full enforcement rollouts