Breach Response
π Overviewβ
Breach Response Levels in the Xshield Security Platform provide dynamic containment controls for active or potential security incidents. The key idea is for customers to activate pre-created policies in case of detection of breach in their network emanating from one or more machines.
The solution is built around configurable Breach Response Levels (by default: Red, Orange, Yellowβthese labels can be edited to align with an organization's cybersecurity incident categorization) and a flexible template system. Templates define inbound and outbound rules and are pre-created and labeled with one or more levels (Default, Red, Orange, Yellow) in advance. This enables rapid, policy-driven isolation or hardening of assets during incidents, with automatic restoration to normal operations when resolved.
This feature supports a Zero Trust security posture and aligns with the broader goals of incident containment, blast radius reduction, and resilient response.
π οΈ Functional Architectureβ
Diagram 1: Breach Response Workflow and Restoration
Template Creation with appropriate breach levels
β
Template Assignment to Assets (directly or through segments)
β
Breach Detection (occurs outside ColorTokens Purview, typically through SIEM or other tools)
β
Operator Activates Breach Response Level for identified breached assets
β
Xshield Agent Enforces Isolation Policy on Asset (only allowing flows matching the rules in templates mapped to activated breach level)
β
Asset is Contained or Hardened Based on Level
β
When Resolved, Breach Response Level is Deactivated and Asset Automatically Restores to Normal Security State
π Purpose of Breach Responseβ
Breach Response defines logical containment boundaries based on asset type, risk level, and exposure potential. Each response uses policy templates to control traffic at the host level via the Xshield agent. When a breach is detected, customers can activate the appropriate breach level on affected assets, immediately containing the threat.
Goals:β
- Minimize the risk of lateral movement from affected systems
- Harden critical systems preemptively
- Contain incidents without disrupting core operations
- Provide immediate response capabilities when breaches are detected
π― Breach Response Levelsβ
The platform supports three pre-defined Breach Response LevelsβRed, Orange, and Yellow (names can be customized to align with an organization's cybersecurity incident categorization). Each level reflects a degree of containment and is mapped to templates that define inbound and outbound firewall rules for each asset.
Customers can choose to mark each level according to their preference, using their own designation system, severity indicators, or visual identifiers that align with their incident response protocols.
Level | Purpose | Behavior | Example Use Cases |
---|---|---|---|
Red | Full Containment | Block all traffic except trusted mgmt flows | - Ransomware outbreak on endpoint - Confirmed data exfiltration - Active command-and-control communication |
Orange | Partial Restriction | Allow only essential traffic (e.g., DNS, NTP) | - Suspicious process activity - Anomalous network connection attempts - Potential lateral movement detection |
Yellow | Selective Protection | Minimal restrictions to preserve functionality | - Proactive hardening during patch deployment - Enhanced monitoring of sensitive assets - Temporary protection during vulnerability remediation |
The names, purposes, and marking system for these levels are fully configurable to suit organizational needs. Organizations can implement their own designation system that aligns with existing incident severity frameworks, such as:
- Numeric indicators (Level 1, Level 2, Level 3)
- Severity descriptors (Critical, High, Medium)
- DEFCON-style ratings
- Custom organizational nomenclature
π§© Policy Templates and Assignmentβ
Templates are the foundation of both normal micro-segmentation and breach response. Each template is created with its levels assigned as part of the creation process (e.g., Default, Red, Orange, Yellow, or combinations).
Each template contains:
- Inbound & outbound rules (allowed/blocked ports, protocols)
- Scope of permitted IP ranges
Templates can be assigned to one or more levels:
- Default: Used in normal secure enforcement mode (micro-segmentation)
- Red / Orange / Yellow: Used specifically in breach response scenarios
- Both: Participate in both normal and breach response enforcement
After creation, templates must be assigned to assets before any incident occurs to ensure the appropriate response levels are available for activation. This can be achieved either by:
- Assigning templates directly to assets
- Assigning templates through segments
Note: Only breach response levels supported by the asset's assigned templates can be activated for that asset. This is a pre-condition for activation - the template with the corresponding breach level must be assigned to the asset.
Templates are pushed and enforced via the agent in real time.
π Breach Response Lifecycle and State Restorationβ
- Preparation: Templates are created and mapped to response levels in advance.
- Breach Detection: This happens outside ColorTokens Purview (typically through SIEM or other tools in the customer's organization).
- Activation: Upon identification of a breach, the customer can activate the breach level corresponding to the level of cybersecurity incident on one or more breached assets.
- Enforcement: The Xshield agent enforces the rules corresponding to the breach level on the asset. Only the network flows corresponding to the rules of the activated breach level will be allowed, and all other flows will be blocked.
- Deactivation & Restoration: Once the incident is resolved, the breach response level is deactivated, and the platform automatically restores the asset to its prior security state (e.g., Default micro-segmentation or previous enforcement mode).
π Monitoring and Auditing Isolation Eventsβ
π Activity Logsβ
Track:
- Breach response level activation and deactivation at asset level
- Template assignment and enforcement events
π Flow Visualizationβ
Inspect:
- Traffic drops post breach level activation
- Lateral movement attempts blocked
- Exposure of critical assets which have breach response levels activated
π§ Use Casesβ
Scenario | Recommended Level | Outcome |
---|---|---|
Confirmed compromised endpoint | Red | Fully contained from all network resources |
Suspicious behavior or threat hunting | Orange | Monitored and partially contained |
Preemptive hardening of critical asset | Yellow | Limited exposure, business operations preserved |
π‘ Best Practicesβ
Best Practice | Recommendation |
---|---|
Pre-define breach response templates | Create level-specific policies for different asset types |
Align breach response levels to severity tiers | Use appropriate breach response levels consistently across response plans |
Automate detection-based breach response activation | Integrate with detection tools to trigger isolation automatically |
Migrating from Segment-Based Quarantine to New Quarantine Isolation Levels and Zones in XShieldβ
Follow these steps to migrate from the segment-based quarantine system to the new quarantine isolation levels and zones in XShield:
-
Login to Your Tenant
Access your XShield tenant by logging in with your credentials. -
Navigate to Breach Response Settings
Go to Settings > General > Breach Response Levels. -
Update Breach Response Level Names (If Needed)
If necessary, update the names of the breach response levels to align with your organizationβs terminology (e.g., Low, Medium, High). -
Edit Quarantine/Isolation Templates
Head to Templates and select the respective Quarantine/Isolation Templates.
Edit the templates and set the appropriate quarantine/isolation levels, such as Low, Medium, or High. -
Assign Updated Templates to Segments
After updating the templates, assign the appropriate Quarantine/Isolation Templates to the respective segments. -
Validate on a Few Assets
Activate the breach response on a couple of assets at different levels (Low, Medium, High) to ensure the settings are working as expected. -
Delete Old Quarantine Segments
Once validation is successful, delete the old segments that were previously used for quarantining. These segments are typically identified by a βQuarantineβ tag. -
Optional Cleanup: Remove Quarantine Tags
Since the Quarantine Tag is no longer needed to quarantine assets, set the tag value to No Value for all assets. Then, delete the Quarantine Tag from Tag > Tag Names.
By following these steps, youβll successfully migrate to the new quarantine isolation levels and zones in XShield.
β Summaryβ
The Breach Response capability in the Xshield Security Platform enables rapid, intelligent containment of security incidents. By enforcing pre-created policy templates based on configurable breach levels, Xshield helps reduce lateral movement, protect critical assets, and support business resilience. When breaches are detected in the network, customers can immediately activate appropriate response levels on affected assets. The platform's automatic state restoration further simplifies operational recovery, ensuring both effective breach containment and business continuity.