About Junari

< Back to Article List

IS-11 Cryptographic Controls Policy

Last updated: 25 September 2023 at 16:43:21 UTC by Junari Assistant

Cryptographic Controls Policy[1] [2] [3] [4] 

 

 

 

Document Ref No

IS-11

Version No

V1

Last review date

16/10/2021

Approved by

Dom Tyler

Next review

16/10/2022

 

 

 

 

 

 

 

 

Contents

1.      Purpose, scope and users                                                                                                               3

2.      Cryptographic Requirements                                                                                                        3

2.1.       Encryption Strength                                                                                                               3

2.2.       Compromised Keys                                                                                                                    3

2.3.       Digital Signatures                                                                                                                    3

3.      Key Management                                                                                                                                3

3.1.       Key Generation                                                                                                                          4

3.2.       Key Distribution                                                                                                                         4

3.3.       Key Storage and Protection                                                                                                 4

4.      Document management                                                                                                                     4

5.      Version History                                                                                                                                  4

 


1.    Purpose, scope and users

This document defines standards for the implementation and use of encryption technologies within Accellier. All IT and Development staff are subject to this policy.

The Information Classification Policy should be referred to for guidance on which types of information should be encrypted.

Cryptographic controls provide an enhanced level of protection for Accelliers electronic information in the event of theft, loss or interception by rendering information unreadable by unauthorised individuals.

 

2.    Cryptographic Requirements

Encryption usage is risk based and should consider the sensitivity of information as per the Information Classification Policy.

2.1.         Encryption Strength

Encryption strength should be AES-256-bit or equivalent, where possible.

Cryptographic hash ciphers must be strong: SHA256, SHA512 or equivalent, and weak cryptographic hash ciphers must be disabled.

Whenever a password or passphrase is used as an encryption key (“Key”), it must follow the Password Policy which defines strong password/passphrases.

2.2.         Compromised Keys

Keys that are compromised (e.g. lost or stolen) must be reported immediately in accordance with the Incident Management Process. The Key must be revoked or destroyed and a new key generated. Key re-assignments require re-encryption of the data.

2.3.         Digital Signatures

Digital signatures should be supported by certificates issued by a trusted third-party Certificate Authority (CA). If the signatures are intended for legal signing, then they must be supported by third-party CA certificates.

 

3.    Key Management

For encryption to be effective, encryption Keys must be protected against unauthorised disclosure, misuse, alteration, or loss. In order to reduce the risk of loss or exposure of Keys, it is recommended that all Key management processes be performed with automated software. A Key management plan must also be in place that covers the following process areas.

3.1.         Key Generation

Secure creation of keys (symmetric encryption) or key pairs (asymmetric encryption).

       Keys must be created using cryptographically strong algorithms

3.2.         Key Distribution

Secure distribution of keys using manual transport methods (e.g. file transfer, key loaders), automated methods (e.g. Key transport and/or Key agreement protocols), or a combination thereof.

Keys must be encrypted when transmitted over communication lines.

The exchange of keys must employ encryption using an algorithm that is at least as strong as the one that is used to encrypt the data protected by the keys, and access must be strictly limited to those who have a need-to-know.

3.3.         Key Storage and Protection

All cryptographic keys are protected against modification, loss and destruction. Keys and their associated software products must be securely maintained for the life of the archived data that was encrypted with that product.

       Keys must be protected using the same or superior level of security as the information that they are protecting, and access must be strictly limited to those who have a need-to-know.

       In public-private key encryption, private keys need protection against unauthorised disclosure.

       Keys must not be stored on the same storage media as the encrypted data.

       Equipment used to generate, store and archive keys must be physically protected.

 

4.    Document management

This policy shall be available to all Accellier Employees and any Third Parties where required. The policy must be reviewed and, if necessary, updated at least once a year. Notice of significant revisions shall be provided to Accellier Employees via email.

 

5.    Version History

Summary of Change

Date of Change

Author

Version No

First Draft

16/10/2021

Dom Tyler

1

 

 

 

 

 

 

 

 

 

 

 


Is this document covering laptops only which are encrypted using Win10 Pro? Google Drive has some encryption options that we can look at (all HR/Personnel information is stored in my Google Drive account.

This is encryption in general so will apply to laptops, Google Drive and anywhere that personal data is held. I've made a suggested amendment to section 2.1, this will help if some of open source platforms being used aren't compatible with AES-256 encryption.

 

In practice, if some data isn't encrypted then is should be logged as a risk and then the business can make a decision whether to mitigate the risk or accept the risk.

No open source applications come with database/module/field encryption as standard.

I can amend the scope of the document so it doesn't include open source applications, but seeing as that's where the client data resides it's more of a risk than laptops and Google Drive. Or I can leave it in and the organisation document the risk and either decide to manage the risk where possible or accept the risk on the applications that encryption isn't possible