Security & Compliance
< Back to Article ListIS-11 Cryptographic Controls Policy
Last updated: 24 October 2024 at 11:46:23 UTC by Russell Briggs
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 Recycly . 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 Recycly 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 Recycly 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 Recycly 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