Internal Use

Encryption Policy

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

This policy defines organizational requirements for the use of cryptographic controls and key management, in order to protect the confidentiality, integrity, authenticity, and nonrepudiation of information.

1.2 Scope

This policy applies to:

• All systems, equipment, facilities, and information within the scope of Dispel’s information security program.
• All employees, contractors, part‑time, and temporary workers, service providers, and third parties who work with cryptographic systems, algorithms, or keying material on behalf of Dispel.

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Management Commitment

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

• Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
• Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
• Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
• Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.2 Primary Policy Statement

Dispel SHALL protect information assets using approved cryptographic algorithms and keys, managed according to formal key management processes and aligned with industry best practices.

2.3 Secondary Policy Statements

At a minimum, Dispel SHALL:

• Use only approved cryptographic tools and algorithms to protect information at rest and in transit.
• Manage cryptographic keys so they are protected from loss, unauthorized use, and unauthorized disclosure throughout their lifecycle.
• Provide customers, upon request, with information about cryptographic protections relevant to their data, including:
  • Cryptographic tools used;
  • Any capabilities that allow customers to apply their own cryptographic solutions; and
  • Countries/regions where cryptographic tools are used to store or transfer customer data.
• Ensure that cryptographic practices comply with applicable laws and regulations, including import/export restrictions.

3. REQUIREMENTS

3.1 Cryptographic Controls

Objective: Standardize cryptographic protections across Dispel systems.

Mandatory Activities:

1. Systems SHALL use only approved cryptographic controls. At minimum, this includes:

   • Public Key Infrastructure (PKI) for authentication:
     • Algorithm: RSA‑4096
     • Key size: 4096‑bit keys
   • Data Encryption Keys (e.g., Amazon EBS volume encryption):
     • Tool: Amazon EBS
     • Algorithm: AES‑256‑XTS
     • Keys: Two 256‑bit volume keys (or equivalent strength)
   • Virtual Private Network (VPN) keys:
     • Tool: OpenVPN (or equivalent approved VPN)
     • Algorithm: AES‑256
     • Keying: 4096‑bit key for key exchange / authentication
   • Website TLS/SSL Certificates:
     • Hash/Signature algorithm: SHA‑256
     • Key size: at least 4096‑bit RSA (or equivalent elliptic curve strength)

2. Cryptographic configurations SHALL be:

   • Documented in system design and configuration records.
   • Reviewed periodically for alignment with current standards and regulatory expectations.

Required Outputs:

• A current list of approved cryptographic controls and their parameters (algorithm, mode, key size, use case).

Security Controls: SC‑12, SC‑13; ISO/IEC 27001 A.8.24, A.8.25.

Approval Required: CTO, Security Officer.

3.2 Key Management

Objective: Ensure cryptographic keys are generated, stored, used, rotated, and destroyed securely.

Mandatory Activities:

1. All key management SHALL be performed using an approved key management service that:

   • Automatically manages key generation.
   • Enforces access control and usage policies.
   • Provides secure storage and backup for the entirety of a key’s operational lifetime.
   • Supports key rotation, enabling, disabling, and scheduled deletion.

2. Keys SHALL be protected against loss, change, or destruction by:

   • Applying appropriate logical access control (role‑based access control, least privilege).
   • Backing up keys on a regular basis within the key management service.

3. Symmetric (secret) keys SHALL:

   • Be protected during distribution using a stronger algorithm and longer key length than the keys being distributed.
   • If already at the strongest algorithm and key length, be split into multiple components, each encrypted with a different key, and transmitted using different mechanisms or channels.
   • At rest, be protected by security measures at least as strong as those used during distribution.

4. Asymmetric (public/private) keys SHALL:

   • Be generated and stored in secure hardware or software environments as appropriate.
   • Have private keys restricted to the user or system identity to which they belong.
   • Be escrowed only where explicitly required (e.g., encryption certificates), in accordance with Dispel policy; identity/signature keys SHALL NOT be escrowed.

5. Hardware tokens and other key storage devices SHALL:

   • Be treated as sensitive company equipment, especially outside company offices.
   • Not be left connected to end‑user devices when not in use.
   • Not be stored or transported in the same container or bag as the associated computer when traveling.

6. PINs, passwords, and passphrases used to protect private keys or key stores SHALL:

   • Meet the complexity and length requirements defined in Dispel’s Password Policy.
   • Not be shared or reused across unrelated systems.

7. Loss, theft, or suspected compromise of any encryption key covered by this policy MUST:

   • Be reported immediately to the Security Officer and appropriate management.
   • Trigger key revocation and re‑issuance procedures as defined in supporting standards/runbooks.

Required Outputs:

• Documented key management procedures and system configurations.
• Records of key lifecycle events where required (creation, rotation, revocation, destruction).

Security Controls: SC‑12, SC‑13.

Approval Required: Security Officer.

4. ROLES AND RESPONSIBILITIES

4.1 Policy Owner (e.g., CTO or Delegate)

Responsibilities:

• Owns and maintains this Encryption Policy.
• Ensures the policy is reviewed and updated at least annually and after major changes to systems or regulations.

4.2 Security Officer

Responsibilities:

• Oversees implementation and enforcement of cryptographic controls and key management.
• Coordinates incident response related to key compromise or cryptographic failures.
• Ensures alignment with related policies (Password Policy, Data Protection Policy, etc.).

4.3 Engineering / Operations

Responsibilities:

• Implement cryptographic controls in systems and services according to this policy.
• Integrate key management service(s) into system architectures.
• Maintain documentation for cryptographic configurations.

4.4 All Personnel

Responsibilities:

• Use cryptographic tools and keys only as authorized.
• Protect hardware tokens, passwords, and PINs associated with cryptographic keys.
• Report any suspected loss, theft, or compromise of keys or cryptographic material immediately.

5. PROCEDURES

5.1 High‑Level Encryption and Key Management Procedure

Detailed operational runbooks MAY exist separately and are referenced by this high‑level procedure.

6. MONITORING AND COMPLIANCE

6.1 Compliance Monitoring

Compliance with this policy SHALL be monitored through:

• Configuration reviews of cryptographic settings on systems and services.
• Audits of key management operations and access logs.
• Security monitoring for anomalous use of cryptographic keys or failures of cryptographic protections.

6.2 Metrics and Reporting

6.3 Non‑Compliance Consequences

Violations of this policy may result in:

• Corrective and preventive actions.
• Disciplinary measures up to and including termination.
• Additional technical or procedural remediation to restore secure cryptographic protection.

7. EXCEPTIONS AND WAIVERS

7.1 Exception Process

Exceptions to this policy SHALL:

1. Be submitted in writing by the requesting party.
2. Include detailed justification and business impact.
3. Describe compensating controls or mitigation measures.
4. Define exception duration and remediation plan.

7.2 Exception Approval Authority

8. DEFINITIONS

Cryptographic Controls: Algorithms, protocols, and mechanisms used to protect data, such as encryption, digital signatures, and key agreement.

Key Management: Processes and tools for generating, storing, distributing, rotating, and destroying cryptographic keys in a secure manner.

Hardware Token: Physical device (e.g., smartcard, USB token) used to store cryptographic keys or perform cryptographic operations.

PKI (Public Key Infrastructure): A framework for managing public‑key encryption and digital certificates.

9. REFERENCES

9.1 Internal References

• Information Security Policy
• Password Policy
• Data Protection Policy
• Access Control Policy

9.2 External References

• ISO/IEC 27001 Annex A.8.24–A.8.25
• NIST SP 800‑57 (Key Management)
• NIST SP 800‑52 (TLS)
• SOC 2 Trust Services Criteria
• HIPAA Security Rule 45 CFR §164.312

10. DOCUMENT HISTORY

11. APPROVAL SIGNATURES

END OF POLICY

APPENDICES

Appendix A: Approved Cryptographic Controls (Summary)

• Summary of current approved cryptographic algorithms, tools, and key sizes (e.g., RSA‑4096, AES‑256‑XTS, AES‑256, SHA‑256), including where and how each is used.

Appendix B: Key Management Service Configuration

• Summary of key management service capabilities and configuration parameters, including access roles, rotation policies, backup/restore, and logging settings.