Cryptographic Controls and Key Management Policy
1. Background and purpose:
In today’s digital world data must be protected from theft, alteration, and should be used only by authorised users. Hence having a comprehensive Cryptographic controls and key management policy is essential for Melbourne Racing Club, its subsidiaries, and related entities (“MRC”), to ensure they meet legal regulatory requirements and protect the confidentiality, authenticity and/or integrity of MRC information.
2. Scope
The cryptographic controls and key management policy covers all of MRC’s information systems including servers, endpoint devices, database, applications, networks, storage, and other information assets.
This policy applies to all employees of MRC, whether permanent, temporary, casual, part-time or on fixed-term contracts employees. This policy also applies to all partners and third parties who have access to MRC IT systems (collectively,” Users”).
3. Policy
MRC must use cryptographic controls for protection of sensitive and/or critical information systems against accidental or malicious destruction, damage, modification, or disclosure, and to maintain appropriate levels of confidentiality and availability of such information systems.
MRC must use and protect cryptographic keys through their entire lifecycle.
3.1. Roles and Responsibilities
3.1.1. IT Department should be responsible for:
- Approving the use of cryptographic services;
- Setting security standards for cryptographic algorithms and key length;
- Providing technical advice on the use of cryptography;
- Ensuring that all of MRC information systems have appropriate encryption tools implemented;
- All classified information at rest and/or in transit are adequately encrypted; and
- Ensuring the use of industry approved algorithms for encryption and/or digital signature.
3.1.2 Users should be responsible for:
- Ensuring that all sensitive information which is processed/stored and/or transferred are appropriately encrypted; and
- Reporting any deviation and/or non-compliance to the IT department.
3.2. Cryptographic Algorithms
Based on the purpose (confidentiality, integrity, or availability), MRC must select either the most stringent of the following methods or combinations of the three methods:
- Asymmetric/public key algorithms;
- Hashing algorithms; and
- Symmetric encryption algorithms.
3.3. Use of Encryption
- MRC should establish a procedure for identifying the security risks associated with critical and/or sensitive data and evaluate where those risks might effectively be reduced using encryption;
- Data not marked as sensitive or confidential should still be considered for encryption if it falls within the definitions of sensitive and/or critical data;
- For a file to be decrypted, a key must be communicated separately & ensured that the source of the key is trustworthy;
- MRC must use appropriate encryption controls to protect the confidentiality of information being transferred on portable media or across networks;
- Exchange of critical and/or sensitive data, whether transported manually or electronically (including an attachment to email), must specify security controls that reflect the sensitivity of the information involved and the risks to the data during its transfer;
- For Remote Network Access, following controls must be considered:
- o All VPN connections must be encrypted;
o Appropriate encryption controls must be utilised to secure remote access;
o Relevant Controls for encryption must be deployed to safeguard the confidentiality;and integrity of data passing over public networks.
3.4. Use of Certificates 3.4.1 Web Server Certificates
MRC must:
- Use digital certificates signed by an approved Certificate Authority (CA);
- Select a key size of 2048 bits or greater; and
- Select certificate expiration date of not more than three years for users accessing MRC’s classified Information.
3.4.2 Code Signing Certificates
MRC must:
- Protect access to these certificates with multifactor authentication; and
- Restrict access to the smallest group possible.
3.4.3 Self-Signed Certificates
MRC must:
- Not use them for any production purpose on a public network; and
- Not use them for the testing of users processing, storing, or transmitting MRC’s classified Information.
3.5. Key Management
MRC must establish procedures for managing cryptographic keys though their whole lifecycle including generating, storing, archiving, retrieving, distributing, retiring, and destroying keys.
3.5.1. Protecting Keys
- MRC must protect private encryption keys to prevent their unauthorised disclosure and subsequent fraudulent use;
- All private keys protecting MRC Information and IT systems must be classified. 3.5.2. Private Keys
MRC must:
- Physically and logically secure private keys;
- Not share the key with anyone other than those expressly authorised;
- Never store the key(s) on the same IT system; and
- Never reuse the key(s) to encrypt another set of unrelated or separate MRC Information.
Users handling private keys protecting MRC Information must maintain records of access, so the use of the keys is auditable.
3.5.3. Generating Strong Keys
MRC must:
- Select a key size using the minimum recommended by the encryption method;
- Generate keys on the IT system itself or, if transmission of a private key is required, distribute keys manually using a public key transport mechanism or using a previously distributed or agreed-upon key-encrypting-key (KEK); and Use a random key generation mechanism
3.5.4. Emergency Access to Keys
MRC must have auditable procedures in place to provide access to private keys in the event of an emergency and/or the passphrase holder being unavailable.
3.5.5. Changing Private Keys and Private Key Lifecycle
MRC must:
- Have a process to approve key changes, record dispositions and change keys when a user with access to a private key(s) separates or changes roles;
- Have a process to change keys as part of the response to an information security incident;
- Private keys protecting classified MRC Information should change at least once annually;
- Private keys must be revoked and/or deleted when they are no longer needed to perform a business function;
- Private keys must not be re-issued or reused.
3.5.6. Encryption Key Backup and Escrow
- MRC must backup the private key associated with any encryption at rest, of MRC Information;
- MRC must place in escrow the private key associated with any encryption of MRC Information using at least one CXO approved role (e.g., a IT Member who is trained to handle private keys) or in a CXO approved tool or process (e.g. key management software, a second key pair to provide access);
- MRC must test key recovery or business continuity/disaster recovery of keys annually.
3.5.7 Access to Keys
- Must be limited to need-to-know basis depending upon job responsibilities.
3.5.8. Compromised Keys
- MRC must change an encryption key immediately, if the key becomes compromised or is discovered by any unauthorised user or party.
4. Renew & Request Certificate Process
4.1. Certificate Management
Certificate Management is the activity of monitoring, facilitating, and executing every certificate process necessary for uninterrupted network operations. In other words, it is the process of purchasing, deploying, renewing, and replacing certificates on their respective endpoints (which could be an application, a server, a device, or any other network component).
A well-defined certificate management strategy is vital for MRC, since the increased visibility and control over their infrastructures will help MRC prevent application downtime and outages which are caused due to faulty, misconfigured, or expired certificates.
4.2. Renew Your Certificate
- A CSR (Certificate Signing Request) should be generated each time an old certificate is renewed. Though some web servers may allow the use the old CSR, generating a new one is recommended for incorporating new encryption methods and hashing algorithms into the new certificates;
- MRC can, however, use the same private key for new certificate as was used in the old one. In case the above method is adopted, using a dedicated software solution to manage certificates, the renewal process can be automated;
- A Certificate management software or Certificate Authority (CA) must send alerts reminding about renewal of certificates 90 days before it’s set to expire.
4.3. Certificate Request
Certificate Signing Request (CSR) is the message that’s sent to the CA to get a digital certificate created. A CSR is often generated on the same server on which the certificate is to be installed. Before creating a CSR, the applicant must first generate a public-private key pair. The public key is included in the CSR and is used by the CA to create the certificate while the private key (to be kept private again) is used to sign the information contained in the CSR. Apart from the public key, the CSR may have the following information on it:
A CSR is usually represented as a Base64 encoded PKCS (Public Key Cryptography Standard) #10.
5. Applicability of Other Policies
- Data Breach Response Plan;
- Risk Management Policy; and
- Information Security Policy.
6. Key Legislation, Acts & Standards
- ISO/IEC 27002:2013 standards – Information Technology Security Techniques – Code of practice for information security controls – https://www.iso.org/standard/54533.html;
- ISO/IEC 27001:2013 standards- Information Technology – Security Techniques – Information security management systems –Requirement – https://www.iso.org/standard/54534.html; and
- Australia Cyber Security Centre (ACSC) – Guidelines for Cryptography – March 2023 – https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-cryptography.
7. Enforcement
Violations may result in disciplinary action, which may include suspension, restriction of access, or more severe penalties up to and including termination of employment. Where illegal activities are suspected, MRC may report such activities to the applicable authorities. If any provision of this policy is found to be unenforceable or voided for any reason, such invalidation will not affect any remaining provisions, which will remain in force.
8. Review
This Policy is recommended to be reviewed biennially.[1]
9. Further assistance
For advice and assistance on policy matters please direct your enquiries to MRC’s IT Department via itsupport@mrc.net.au.
10. Glossary of terms/definitions:
Term
Definition
Algorithm
an algorithm is a finite sequence of well-defined, computerimplementable instructions, typically to solve a class of problems or to perform a computation
CA
Certificate Authority or Certification Authority (CA) is an entity that issues digital certificates.
Digital Signature
Digital signature is a form of electronic signature that has been encoded using public key or asymmetric cryptography
Digital certificate
Digital certificates are a proof of an endpoint’s authenticity, like a server or a user. Digital certificates provide the stamp of genuineness by binding the public key with the entity (server or client) that owns it, provided the entity possesses the corresponding private key
Encryption
The process of encoding data with an algorithm so that it is unintelligible and secure without the key. Used to protect data during transmission or while stored.
Escrow
Key escrow is an arrangement in which the keys needed to decrypt encrypted data are held in escrow so that, under certain circumstances, an authorised third party may gain access to those keys.
Information System
An automated system that creates or manages information about an organisation’s activities. Includes applications whose primary purpose is to facilitate transactions between an organisational unit and its customers, e.g. an e-commerce system, client relationship management system, purpose-built or customised database, finance or human resources systems.
Keys
Key is a string of characters used within an encryption algorithm for altering data so that it appears random. Like a physical key, it locks (encrypts) data so that only someone with the right key can unlock (decrypt) it.
Multifactor authentication
Multi-factor authentication is an electronic authentication method in which a computer user is granted access to a website or application only after successfully presenting two or more pieces of evidence to an authentication mechanism.
Sensitive Information
Sensitive Information is a subset of personal information. Because of its nature, it has higher restrictions on when it can and cannot be collected. There are nine different types of sensitive information under the Privacy and Data Protection Act 2014 i.e. Racial or ethnic origin, political opinions, membership of a political association, religious beliefs or affiliations, philosophical beliefs.
VPN
Virtual private network (VPN) extends a private network across a public network and enables users to send and receive data across shared or public networks
[1] Review date is recommended only. Should this Policy have not been reviewed or updated by its review date, this Policy shall still remain in force and does not expire.