Security States
Overview
This document provides a technical overview of security enforcement states in the Xshield platform. These states are applied at the Asset and Port level and define how inbound (Attack Surface) and outbound (Blast Radius) communications are controlled and monitored using progressive Zero Trust principles.
Security states help organizations to:
- Reduce exposed services (Attack Surface),
- Limit unauthorized communications and lateral movement (Blast Radius),
- Adopt Zero Trust controls in a phased, low-disruption manner.
1. Purpose and Application of Security States
Security states are essential for turning Zero Trust principles into operational controls. Instead of jumping directly to hard enforcement, teams can move workloads through a lifecycle of visibility, testing, and then enforcement.
Why Security States Are Needed
-
Gradual Enforcement
Introduce controls progressively using test modes before moving to enforcement. This helps validate the impact of policies without breaking legitimate business traffic. -
Policy Transparency
Test states log violations without blocking traffic, giving security teams real-world insights into how workloads communicate before enforcing restrictions. -
Risk Reduction
Well-defined states for both inbound (Attack Surface) and outbound (Blast Radius) traffic reduce exposure, limit lateral movement, and help contain potential breaches. -
Operational Continuity
Enforcement can be aligned with business criticality and maintenance windows, enabling secure access without impacting productivity.
Asset-Level Enforcement
Each asset has its own security status, which determines how its inbound and outbound traffic is handled. This per-asset model provides:
- Granular control over enforcement for each workload,
- Independent rollout of enforcement per application, environment, or risk profile,
- Safer change management, because testing and enforcement can be staged asset by asset.
2. Concept of Deployment Mode
Deployment Mode defines how strictly Xshield applies security controls to an asset’s network traffic across both inbound (Attack Surface) and outbound (Blast Radius) flows.
The Deployment Mode determines the resulting state of network traffic based on policy evaluation:
- Allowed (Traffic is permitted without policy evaluation, e.g., in the 'Unsecure' state)
- Allow but log violations (Traffic is permitted, but non-compliant flows are recorded for later analysis, e.g., in a 'Test' mode)
- Blocked/Denied (Traffic is actively blocked if it violates the defined policy, e.g., in an 'Enforce' mode)
Deployment Modes help organizations progressively apply Zero Trust controls with minimal operational risk.
Deployment Mode Categories
Xshield supports both test-oriented and enforcement-oriented modes:
Test (Test All, Test Intranet)
- Used for visibility and validation.
- All traffic is evaluated, but enforcement is not applied.
- These states reveal communication dependencies safely.
Enforce (Enforced state)
- Full enforcement.
- Only traffic explicitly permitted by policy is allowed.
- Unauthorized internet and intranet flows are blocked.
By moving assets from Unsecure → Test → Enforce, organizations can incrementally harden their environment while maintaining control and visibility at every step.
Axes of Control (Inbound and Outbound)
All security enforcement in Xshield is configured at the Asset and Port Level, controlling traffic along two fundamental axes:
-
Attack Surface (Inbound): Controls who can connect to the workload. Test Intranet helps validate internet exposure without breaking internal flows.
-
Blast Radius (Outbound): Controls where the workload is allowed to initiate communication. This is critical for stopping lateral movement and external data exfiltration. Test Intranet helps tighten internet egress while leaving internal dependencies intact.
Operational Behavior by Deployment Mode
| Deployment Mode | Intranet Traffic | Internet Traffic | Purpose |
|---|---|---|---|
| Unsecure | Allowed | Allowed | Discovery, initial onboarding |
| Test All | Logged only | Logged only | Full visibility, no impact |
| Test Intranet | Logged only | Enforced & blocked | Tighten external exposure |
| Enforced | Enforced & blocked | Enforced & blocked | Final Zero Trust posture |
Progression Through Modes
- Unsecure → Gather initial traffic visibility
- Test All → Understand real communication paths
- Test Intranet → Restrict external exposure safely
- Enforced → Apply full Zero Trust enforcement
3. Asset Security status Lifecycle
Each asset moves through a lifecycle as policies are discovered, tested, and finally enforced. This lifecycle reflects not just internet/intranet enforcement. This lifecycle reflects the deployment status of both asset-level and port-level policies.
| Asset Security Status | What It Means | Traffic Behavior | Typical Use Case |
|---|---|---|---|
| Unsecure | No asset-level or port-level policies are deployed. | All inbound/outbound traffic is allowed | Initial onboarding, discovery, inventory collection. |
| Partially Secured | Some port-level policies are deployed, but asset-level policy is not deployed. | Only specific ports have test/enforced behavior; other traffic is allowed. | Gradually rolling out port-level Zero Trust. |
| Secure Test | Asset-level policy is deployed in Test (Test All or Test Intranet). Port policies may be in test or enforce. | Port policies take precedence; other traffic follows asset policy (logged, not blocked). | Validating full inbound/outbound asset behavior. |
| Secure* | Asset policy is Enforced, but some port policies are still in test. | Asset policy is enforced; ports in test mode continue to log violations without blocking. | Transition phase: the asset is secure overall, but some ports are still being validated. |
| Secure | Asset-level and all Port-level policies are fully enforced. | All traffic is strictly allowed/blocked based on configured policies. | Final Zero Trust posture - hardened assets. |
Asset Security Status Transition
The Asset Security State Transition Diagram illustrates how an asset progresses from an open, unprotected state to a fully secure state. The transition depends on policies applied at both the port level and asset level and reflects the stages that occur as operators deploy and validate rules.
┌────────────────────────────────────────┐
│ Unsecure State │
└────────────────────────────────────────┘
|
┌───── ─────────────────────┐
│ Deploy Asset/Port policy │
└──────────────────────────┘
│
┌────────────────────────────────────────┐
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ Partially Secured │ │ Secure Test │
└──────────────────────┘ └──────────────────────┘
|_________________________________________ |
|
▼
┌──────────────────────┐
| Secure* |
└──────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ Secure │
└────────────────────────────────────────┘
What this means
-
Unsecure State: The asset begins in the Unsecure State, where no security policies are deployed. All inbound and outbound communications are allowed, and the system is only observing behavior.
-
Intermediate States: Depending on which policies are deployed, the asset may enter one of two intermediate security states:
- Partially Secured: Only port policies are deployed. The asset-level policy has not yet been applied, resulting in partial control focused on select ports.
- Secure Test: The asset policy is placed in Test mode. Violations are logged but not blocked. Port policies may or may not be deployed. This stage allows operators to verify impact before enforcing.
-
Secure*: The asset policy is in Enforced mode, but some individual ports remain in Test mode. This hybrid condition occurs when ports transition gradually through test → enforce cycles.
-
Secure Mode: After evaluation and stabilization, the asset enters Secure Mode, where both Asset and Port policy enforcement decisions take effect. Final behavior—Allowed or Denied—is determined entirely by the applied templates and policies. This is the fully converged, operational security state.
Considerations
- Use test modes long enough to capture peak times, weekend jobs, and background system traffic.
- Always review violations before moving to Enforced.
- Internet-facing or high-risk assets should typically move through the lifecycle earlier.
- Outbound violations are especially useful for detecting hidden dependencies or compromise indicators.
Summary
Xshield Security States provide a structured, asset-centric approach to Zero Trust:
- Attack Surface controls who can reach a workload.
- Blast Radius controls where a workload can reach out.
- Enforcement is applied per asset and per port, using a progression from Unsecure → Test All → Test Intranet → Enforced.
This model enables organizations to:
- Gain visibility into real traffic behavior,
- Gradually reduce exposure and communication paths,
- Enforce least-privilege access without disrupting critical operations.
By thoughtfully advancing assets through these security states, teams can operationalize Zero Trust in a predictable, low-risk, and highly controlled manner.