Zone Configuration

This guide covers how to configure network zones to enforce security policies and detect unauthorized traffic.

Understanding Zones

What is a Network Zone?

A network zone represents a logical grouping of IP addresses that share common security requirements. Zones are automatically created from your discovery schedules.

Zone Properties

Property	Source	Description
Name	Discovery Schedule	Identifier for the zone
IP Range	Discovery Schedule	CIDR notation (e.g., 10.160.160.0/24)
Agent	Discovery Schedule	Managing discovery agent
Zone Type	Configuration	Security classification
Security Level	Configuration	Protection priority
Allowed Inbound	Configuration	Permitted source zones
Color	Configuration	Visual identifier
Description	Configuration	Human-readable notes

Zone Types

Choose the zone type that best describes the network segment:

Production

Use for: Business-critical systems, databases, application servers

Characteristics:
  - Contains live business data
  - Requires high availability
  - Subject to change control
  - Needs strict access controls

DMZ

Use for: Internet-facing services, web servers, API gateways

Characteristics:
  - Exposed to external networks
  - First line of defense
  - Should have limited internal access
  - Requires frequent security updates

Management

Use for: Administrative access, monitoring systems, jump servers

Characteristics:
  - Privileged access point
  - Should access all other zones
  - Tightly controlled membership
  - Audit logging critical

Workstation

Use for: End-user devices, desktops, laptops

Characteristics:
  - High risk for compromise
  - Should have limited server access
  - Subject to user activity
  - Needs endpoint protection

IoT

Use for: Cameras, sensors, smart devices, industrial controls

Characteristics:
  - Often unpatched/unpatchable
  - Limited security capabilities
  - Should be heavily isolated
  - Potential entry point for attackers

Guest

Use for: Visitor networks, public WiFi, contractor access

Characteristics:
  - Untrusted devices
  - Should only access internet
  - No access to internal systems
  - Limited bandwidth/services

Development

Use for: Developer workstations, build servers, test environments

Characteristics:
  - Rapid changes expected
  - May contain sensitive code
  - Should not access production data
  - Separate from production networks

Staging

Use for: Pre-production testing, UAT environments

Characteristics:
  - Mirrors production setup
  - May contain production-like data
  - Used for final testing
  - Should not be internet-accessible

Backup

Use for: Backup servers, archive storage, disaster recovery

Characteristics:
  - Contains copies of all data
  - Critical for recovery
  - Should have limited network access
  - Often isolated for ransomware protection

Security Levels

Critical

When to use: Zones containing the most sensitive data or systems

Examples:
  - Payment processing systems
  - Healthcare records
  - Financial databases
  - Authentication servers

Violations: Generate HIGH severity alerts

High

When to use: Important systems requiring strong protection

Examples:
  - Application servers
  - Email systems
  - File servers
  - Directory services

Violations: Generate MEDIUM severity alerts

Medium

When to use: Standard business systems

Examples:
  - Development environments
  - Internal tools
  - Collaboration systems

Violations: Generate MEDIUM severity alerts

Low

When to use: Less sensitive systems

Examples:
  - Guest networks
  - Public-facing information
  - Non-critical services

Violations: Generate LOW severity alerts

Configuring Allowed Inbound

Understanding Allowed Inbound

The Allowed Inbound setting defines which zones are permitted to initiate connections TO this zone.

Configuration Rules

Allowed Inbound State	Behavior
Empty (none selected)	All zones allowed - no violations generated
One or more selected	Only selected zones allowed - others generate violations

Best Practices

1. Start with Allow All: Leave empty initially to observe traffic patterns
2. Analyze Traffic: Use Traffic Analysis to understand normal flows
3. Implement Gradually: Add allowed zones one at a time
4. Document Decisions: Use Description field to record why zones are allowed

Example Configuration

Scenario: Securing a database zone

Zone: Database_Servers
IP Range: 10.160.160.0/24
Security Level: Critical

Allowed Inbound:
  - App_Servers (Application tier needs database access)
  - Management (Admin access for maintenance)
  - Backup (Backup jobs need database access)

Not Allowed (will generate violations):
  - Workstations (Users should access through apps)
  - DMZ (Internet-facing should not reach databases)
  - IoT (No legitimate need)
  - Guest (Untrusted network)

Configuration Workflow

Step 1: Assess Current State

1. Navigate to Network Zones
2. Review all discovered zones
3. Check Traffic Analysis for current flows
4. Identify which zones should be protected

Step 2: Classify Zones

For each zone:

1. Click Edit button
2. Select appropriate Zone Type
3. Select appropriate Security Level
4. Add helpful Description
5. Choose a distinctive Color
6. Click Save

Zone configuration dialog showing zone type, security level, and allowed inbound settings

Step 3: Define Policies

For high-security zones:

1. Click Edit button
2. In Allowed Inbound, select permitted zones
3. Review selection carefully
4. Click Save

Step 4: Monitor Violations

1. Switch to Violations tab
2. Review any detected violations
3. Investigate each violation
4. Update policies or block traffic as appropriate

Bulk Configuration Tips

Common Patterns

Pattern: Hub and Spoke

Management Zone:
  Allowed Inbound: [All zones]  # Empty = allow all

All Other Zones:
  Allowed Inbound: [Management Zone only]

Pattern: Tiered Architecture

Web Tier (DMZ):
  Allowed Inbound: [Internet - implicit]

App Tier:
  Allowed Inbound: [Web Tier, Management]

Data Tier:
  Allowed Inbound: [App Tier, Backup, Management]

Pattern: Zero Trust Segments

Each Zone:
  Allowed Inbound: [Management only]
  # All inter-zone traffic generates violations
  # Explicit approval required for any new flows

Troubleshooting

Violations Not Appearing

Cause: Allowed Inbound is empty
Solution: Select specific zones to restrict access

Cause: Source zone is in Allowed Inbound list
Solution: Remove zone if traffic should be blocked

Too Many Violations

Cause: Legitimate traffic not in Allowed Inbound
Solution: Review traffic and add legitimate zones

Cause: Configuration too restrictive
Solution: Start with broader access, tighten gradually

Zone Not Editable

Cause: Insufficient permissions
Solution: Contact administrator for access

Cause: Zone from different tenant
Solution: Switch to correct tenant

Next Steps

• Quick Start - Initial setup guide
• Overview - Complete feature documentation