Internal Use

System and Communications Protection Policy

Dispel

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

This policy establishes Dispel’s requirements for protecting the confidentiality, integrity, and availability of information as it flows within and between systems, services, and networks. It sets expectations for boundary protection, secure network architecture, cryptographic protection of communications, and secure use of collaborative and name resolution services.

1.2 Scope

This policy applies to:

• All production and non-production environments that support Dispel services.
• All systems, applications, and network components operated by Dispel or on its behalf.
• All communications channels that carry company, customer, or sensitive information, including virtual private networks (VPNs), service-to-service traffic, and administrative access paths.
• All workforce members and contractors who design, operate, or administer Dispel networks and systems.

Cloud networking and infrastructure services provided by hyperscale cloud providers (e.g., AWS, Azure) are in scope for this policy where Dispel is responsible for configuration and use of those services; physical infrastructure aspects are governed by the Physical Security and Global Network Firewall policies.

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Dispel SHALL design and operate network and system architectures that enforce defense in depth, including clear security boundaries, segmented environments, and least-privilege access paths.

2.2 All communications carrying sensitive data (including authentication material, customer data, logs, and administrative traffic) SHALL be protected with modern cryptographic mechanisms in line with Dispel’s cryptography and key management requirements.

2.3 Boundary protection devices and configurations (e.g., firewalls, security groups, routing rules) SHALL default to deny and only permit explicitly authorized traffic flows.

2.4 Collaborative computing services and name resolution services used by Dispel SHALL be configured and monitored to prevent unauthorized access, eavesdropping, or tampering with communications.

3. REQUIREMENTS

3.1 Network Segmentation and Boundary Protection

• Dispel SHALL implement segmented network architectures (e.g., VPCs, subnets, security groups) that separate public-facing components from internal services and management planes.
• Traffic between segments MUST be controlled using deny-by-default rules, allowing only documented and justified flows.
• Administrative access paths (e.g., VPN, bastion hosts) MUST be authenticated, encrypted, and limited to authorized personnel.

3.2 Secure Communications

• All externally exposed application endpoints MUST use TLS for data in transit; only modern, secure cipher suites and protocol versions approved by the Security Officer MAY be used.
• Service-to-service traffic that traverses shared or untrusted networks MUST be encrypted (e.g., mTLS, VPN tunnels, encrypted messaging channels).
• Session timeouts and idle disconnects for administrative and user sessions MUST follow Dispel’s secure configuration standards.

3.3 Cryptographic Controls

• Cryptographic mechanisms used to protect data in transit MUST:
  • Use approved algorithms and key lengths as defined in cryptography standards maintained by the Security Officer.
  • Use keys generated, stored, rotated, and revoked in accordance with Dispel’s key management requirements.
• Wildcard or internally issued certificates MAY be used for internal system-to-system communications where risk and trust boundaries permit; public-facing endpoints MUST use certificates from trusted certificate authorities.

3.4 Collaborative Computing and Remote Access

• Collaborative tools (e.g., video conferencing, remote meeting software) used within Dispel MUST:
  • Be configured to require authentication for access.
  • Provide clear indicators when cameras and microphones are active.
• Remote access into production environments MUST occur only through controlled, logged and approved mechanisms (e.g., VPN plus bastion host, just-in-time access workflows).

3.5 DNS, Name Resolution, and Time Services

• Authoritative and recursive DNS services used by Dispel MUST be configured securely and, where supported, use DNSSEC or equivalent integrity mechanisms.
• Time synchronization across critical systems MUST be sourced from trusted time providers offered by cloud providers or other authoritative services, consistent with system-lifecycle and logging requirements.

4. ROLES AND RESPONSIBILITIES

• Chief Technology Officer (CTO) – Policy Owner; responsible for network and system security architecture decisions and ensuring implementation of this policy.
• Head of Operations / Development Operations Lead – Designs and maintains network topologies, firewall rules, and secure connectivity, and ensures changes are reviewed and tested.
• Security Officer – Defines cryptographic and remote access standards; monitors for adherence and coordinates response to system and communications-related incidents.
• Engineering Leads – Ensure services they own comply with this policy (e.g., enforcing TLS, secure DNS usage, robust session handling).
• All Engineers and Operators – Follow secure configuration guidance and change management procedures when modifying network or system communication paths.

5. PROCEDURES

5.1 Detailed procedures for implementing this policy (e.g., firewall change workflows, VPN configuration steps, certificate issuance processes) MAY be maintained as separate standard operating procedures owned by the Head of Operations and Security Officer.

5.2 FedRAMP-specific control narratives, including the full SC control family implementations for the Dispel Zero Trust Engine, SHALL be documented in the FedRAMP System Security Plan and supporting artifacts and referenced from this policy as needed.

6. MONITORING AND COMPLIANCE

• Compliance with this policy MAY be validated through:
  • Network architecture reviews and threat modeling.
  • Firewall and security group rule reviews.
  • TLS configuration scans and certificate inventory checks.
  • DNS and time service configuration reviews.
• Non-compliant configurations SHALL be tracked as issues and remediated in accordance with the risk management and change management processes.

7. EXCEPTIONS AND WAIVERS

• Temporary exceptions (e.g., short-term open access for incident handling or migration) MUST be:
  • Documented with a clear justification and scope.
  • Approved by the CTO or Security Officer.
  • Time-bound with a defined expiration date.
• Structural or long-term deviations from this policy MUST be evaluated via formal risk assessment and approved by senior management.

8. DEFINITIONS

• Boundary Protection – The process of monitoring and controlling communications at system interfaces using devices such as firewalls, gateways, and proxies.
• Defense-in-Depth – A security strategy that applies multiple layers of technical and procedural controls to protect systems and data.
• Collaborative Computing – Tools and services such as remote meetings, shared whiteboards, cameras, and microphones that support communication and collaboration.

9. REFERENCES

• Dispel Global Network Firewall Policy.
• Dispel Encryption and Key Management requirements.
• Dispel System Access Control and Change Management policies.
• FedRAMP Moderate/High baselines (SC family) as applicable to the Dispel Zero Trust Engine.

10. DOCUMENT HISTORY

11. APPROVAL SIGNATURES

APPENDICES

(Intentionally left blank at this time. Detailed SC control narratives, configuration examples, and code snippets are maintained in the FedRAMP SSP and internal runbooks.)