Skip to main content

Deployment Lifecycle

Gatekeepers in firewall mode support progressive security hardening through three distinct enforcement phases. This approach allows organizations to build visibility before enforcing policies, minimizing disruption to existing operations.

gatekeeper deployment lifecycle

Phase 1: Observe-Only Mode​

Purpose: Discover machines and understand existing communication patterns without impacting traffic.

Behavior:

  • Gatekeepers passively observe network traffic and discover machines
  • All traffic is permitted to flow normally
  • No enforcement actions are taken
  • Administrators build comprehensive visibility into machine-to-machine communications
  • The Connection Canvas displays discovered machines and their connection patterns

When to use: Initial deployment, building baseline understanding, identifying unknown machines and communication patterns.

Typical duration: 2-4 weeks to capture all regular communication patterns, including periodic communications.

Metrics to track:

  • Number of machines discovered
  • Unique connection pairs observed
  • Traffic volume by protocol and port
  • Communication patterns (regular vs. sporadic)

Decision criteria for moving to Phase 2:

  • Stable machine count (no new machines discovered for several days)
  • Connection patterns are well-understood
  • All critical communication flows have been observed
  • Stakeholders have reviewed Connection Canvas and validated inventory

Phase 2: Allow by Default Mode​

Purpose: Begin enforcing security policies while maintaining operational continuity.

Behavior:

  • Traffic is permitted by default (same as Observe-Only)
  • Block rules are enforced - Connection rules and protocol enforcement rules that block traffic take effect
  • Allow rules are skipped - Since the baseline permits all traffic, explicit allow rules are unnecessary
  • Administrators can incrementally create policies to block unwanted connections
  • Ideal for transitioning from observation to active enforcement

When to use: After understanding traffic patterns, ready to begin blocking specific unwanted connections.

Typical duration: 2-4 weeks while incrementally building block policies.

Enforcement behavior:

  • Create machine-to-machine connection rules with Block actions to prevent specific communications
  • Create protocol enforcement rules to block specific ports or protocols globally
  • Monitor blocked connections in the Console to validate policy effectiveness

Metrics to track:

  • Number of blocked connections
  • False positive rate (legitimate traffic blocked)
  • Policy coverage (percentage of unwanted traffic blocked)
  • Violations by protocol and machine

Decision criteria for moving to Phase 3:

  • All unwanted traffic is being blocked successfully
  • No false positives (no legitimate traffic blocked)
  • Connection rules have been created for all required communications
  • Security team is confident in policy coverage
  • Stakeholders have approved transition to zero-trust posture

Phase 3: Block by Default Mode​

Purpose: Achieve zero-trust security by blocking all traffic except explicitly permitted connections.

Behavior:

  • All traffic is blocked by default
  • Allow rules are enforced - Connection rules and protocol enforcement rules that permit traffic take effect
  • Block rules are skipped - Since the baseline blocks all traffic, explicit block rules are unnecessary
  • Zero-trust enforcement model for critical infrastructure
  • Requires comprehensive connection rule coverage

When to use: Production security posture for critical systems where only known, approved communications should occur.

Prerequisites:

  • Complete inventory of all required machine-to-machine communications
  • Connection rules defined for all legitimate traffic flows
  • Validated in Allow by Default mode to ensure no disruption
  • Change management approval for zero-trust enforcement

Metrics to monitor:

  • Blocked connection attempts (should be minimal after initial stabilization)
  • Policy violation trends
  • Coverage of allowed traffic (ensure all legitimate flows are permitted)
  • Time to create new rules for approved communications

Best practices:

  • Maintain a rollback plan to revert to Allow by Default if needed
  • Monitor closely for the first 48-72 hours after transition
  • Have on-call support available during transition window
  • Document the approval process for new connection rules

Rule Enforcement Precedence​

Understanding how rules are evaluated is critical for effective policy management:

Evaluation Order​

  1. Baseline Mode - The Gatekeeper's enforcement mode (Observe-Only, Allow by Default, or Block by Default) determines the starting point
  2. Protocol Enforcement Rules - Global port and protocol-based rules applied across all machines
  3. Machine-to-Machine Connection Rules - Specific rules between individual machines

Important Rule Behavior​

Protocol enforcement rules ALWAYS override machine-to-machine connection rules.

Example: If a protocol enforcement rule blocks TCP port 502 globally, a connection rule allowing TCP 502 between two specific machines will be overridden. The traffic will be blocked.

Best practice: Use protocol enforcement rules for broad security policies (e.g., blocking dangerous protocols) and machine-to-machine connection rules for specific communications between known machines.

Policy Types​

Corsha provides three types of policies for controlling access:

  • Connection Rules - Control which machines can communicate
  • Protocol Enforcement Rules - Control which protocols are allowed (overrides connection rules)
  • Scheduled Access Policies - Provide time-based temporary access

See Managing Policies for detailed guidance on policy types, precedence, and configuration.