Port and Path Enforcement Status
1. 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:
- Status – Indicates the current enforced behavior.
- Candidate Status – Indicates the recommended future enforcement based on templates or behavior analysis.
This document describes how these statuses are interpreted and used during test and enforcement phases.
2. 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 sources are allowed to connect.
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 source group to destination group.
- Paths are classified as inbound or outbound, depending on traffic direction from the asset's perspective.
3. Enforcement Modes
| Mode | Description |
|---|---|
| Unsecure Mode | No policies are applied. All ports and paths are allowed. |
| Secure-Test Mode | Policies are proposed but not enforced. Traffic is allowed, and violations are logged. |
| Secure Mode | Enforced mode. Only reviewed and approved paths/ports are allowed. Others are denied by policy. |
4. Port Enforcement States
Status (Actual Enforcement)
| UI Label | Description |
|---|---|
| Allow Intranet | Port is allowed only from trusted internal sources. |
| Allow Any | Port is accessible from any source. |
| Path Restricted | Port is only allowed on explicitly reviewed paths. |
| Denied By Template | Port is blocked based on assigned template policy. |
Candidate Status (Recommendation)
| UI Label | Description |
|---|---|
| Allow Intranet By Template | Proposed allow based on a rule restricting access to internal sources. |
| Allow Any By Template | Proposed allow from any source, based on template. |
| Allow Any By Progressive | Inferred from behavior analysis. Recommends allowing external access. |
| Path Restricted By Template | Suggested limited usage—requires review at path level. |
5. Path Enforcement States
Candidate Status (Pre-Enforcement Recommendation)
| UI Label | Description |
|---|---|
| Allowed | Path is reviewed and trusted. |
| Allowed By Template | Proposed allow per applied template rule. |
| Denied By Template | Proposed deny based on template. |
| Allowed Progressive | Suggested allow based on observed behavior. Requires validation. |
Status (Secure-Test and Secure Mode)
| UI Label | Description |
|---|---|
| Allowed | Path is fully reviewed and traffic is permitted. |
| Allowed By Template | Path is allowed based on matched policy template. |
| Denied By Template | Path is denied due to a template rule. |
| Allowed Test | Path is in test mode. Traffic allowed, no violations observed. |
| Allowed Test Denied Violation | Path is in test mode. Traffic allowed, but policy violation observed (e.g., external access when only intranet was allowed). |
| Allowed Progressive | Behavior-based approval. Admin accepted traffic as valid. |
| Allowed Progressive Test | Behavior-based test mode. Traffic observed but pending admin validation. |
6. State Transition Diagram
┌───────────────────────────────────────────────┐
│ Unreviewed State │
└────────────────────────────┘
│
┌──────────────────────────────────────────────┐
│ Candidate Status Assigned │
│ (e.g., By Template or Progressive) │
└──────────────────────────────────────────────┘
│
▼
Secure-Test Mode
(Candidate Status drives logic)
┌─────────────────────────────────────────┐
│ Allowed Test Allowed Test Denied Violation │
│ Allowed Progressive Test Allowed Progressive │
│
▼
Secure Mode
(Candidate ignored, Status enforced)
▼
┌────────────────────────────────────────┐
│ Final Status = Allowed │
│ or Denied By Template │
└────────────────────────────────────────┘
7. Operational Checklist for Port/Path Enforcement
| Task | Description | When |
|---|---|---|
| ✅ Review Candidate Status | Check paths/ports flagged as "By Template" or "Progressive" | During Secure-Test Mode |
| ✅ Validate Behavior | Confirm that observed communications align with expected application behavior | During path analysis |
| ✅ Mark as Reviewed | Approve or override the proposed candidate 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 |
8. Mapping States to Xshield UI
| Component | UI Section | What to Look For |
|---|---|---|
| Port Status | Asset > Port View | Shows current enforcement (e.g., "Allow Intranet") |
| Port Candidate Status | Asset > Port View > Details Panel | Shows proposed action (e.g., "Allow Any By Template") |
| Path Status | Asset > Communication Map | View each connection’s current enforcement |
| Path Candidate Status | Communication Map > Path Details | Shows behavior/template-based suggestions |
| Violations | Enforcement > Violations Dashboard | Lists "Test Denied Violation" paths |
| Templates | Policy > Templates | Rules defining port/path candidate statuses |
| Policy Simulation | Enforcement > Test Mode Summary | Aggregates candidate status and observed behavior across tenant |
9. 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 candidate status, 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