Skip to content

Latest commit

 

History

History
executable file
·
65 lines (39 loc) · 3.73 KB

readme.md

File metadata and controls

executable file
·
65 lines (39 loc) · 3.73 KB

Cryptographic Control Policy

Purpose

The purpose of this policy is to provide guidance on the selection and use of cryptographic algorithms.

Scope

This policy applies to all Infinity Works Consulting employees and contractors.

Policy

Algorithm Requirements

  • Ciphers in use must meet or exceed the set defined as "AES-compatible" or "partially AES-compatible" according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
  • Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
  • Signature Algorithms
Algorithm Key Length (min) Additional Comment
ECDSA P-256 Cisco Legal recommends RFC6090 compliance to avoid patent infringement.
RSA 2048 Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required.
LDWM SHA256 Refer to LDWM Hash-based Signatures Draft

Hash Function Requirements

In general, Infinity Works Consulting adheres to the NIST Policy on Hash Functions.

Key Agreement and Authentication

  • Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
  • End points must be authenticated prior to the exchange or derivation of session keys.
  • Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.
  • Servers and applications using SSL or TLS should have the certificates signed by a known, trusted provider where possible. (Self-signed certificates may be required in some limited cases, e.g. database server authentication).

Key Generation

  • Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
  • Key generation should be carried out using up-to-date software designed for the purpose, e.g. an up-to-date version of openssl.
    • Random numbers generated by the random number generators in most programming languages are not suitable for use in cryptographic applications and should not be used to generate keys.

Policy Compliance

Compliance Measurement

The ISMS Committee will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

Exceptions

Any exception to the policy must be approved by the ISMS Committee in advance.

Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Related Standards, Policies and Processes

  • National Institute of Standards and Technology (NIST) publication FIPS 140-2
  • NIST Policy on Hash Functions

Definitions and Terms

The following definition and terms can be found in the SANS Glossary located at: https://www.sans.org/security-resources/glossary-of-terms/

back