Architecture and Infrastructure

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

9.1 The gaming system architecture and all its related components shall demonstrate security in depth.

9.2 All gaming systems and devices shall validate inputs before inputs are processed.

9.3 The gaming system shall only display the minimum information about the gaming system to unauthorized users and during system malfunctions.
Guidance: The intent is to ensure that the gaming system does not display unnecessary information to unauthorized individuals that may be used to compromise the gaming system or privacy of information.

9.4 All remote access methods shall be appropriately secured and managed.

9.5 Use of wireless communication shall be secured and only used where appropriate.
Guidance: The intent is to ensure that wireless communication is not present in areas
where it could be potentially harmful (e.g. data centres).

9.6 All components shall be hardened as defined by industry and technology good practices prior to going live and as part of any changes.

Requirements – At a minimum:

  1. All default or standard configuration parameters shall be removed from all components where a security risk is presented.
  2. The appropriateness and effectiveness of steps taken to harden technology components shall be regularly assessed and, if appropriate, changes must be made to improve the hardening.

9.7 Access shall be appropriately restricted to ensure that the domain name server records are kept secure from malicious and unauthorized changes.

Data and Information Management

9.8 All private encryption keys shall be stored on secure and redundant media that are only accessible by authorized management personnel.

9.9 Encryption keys must be appropriately rotated at regular intervals.

9.10 The gaming system architecture shall limit the loss of data and session information.

System Account Management

9.11 The gaming system shall be able to change, block, deactivate or remove system accounts in a timely manner upon termination, change of role or responsibility, suspension or unauthorized usage of an account.

9.12 A secure authenticator that meets industry good practices shall be used to identify a user and his or her account to ensure that only authorized individuals are permitted to access their system account on the gaming system.

Requirements – At a minimum:

  1. The gaming system shall automatically lock out accounts should identification and authorization requirements not be met after a defined number of attempts.

9.13 The gaming system shall ensure that all access to the system is fully attributable to, and logged against, a unique user identification.

9.14 Only the minimum access rights shall be granted to each system account on the gaming system and access rights shall be clearly documented.

9.15 All temporary and guest accounts shall be disabled immediately after the purpose for which the account was established is no longer required.

9.16 System accounts and system access rights for the gaming system shall be regularly reviewed and updated.

9.17 A log of account owners shall be kept and regularly reviewed and updated.

9.18 A mechanism shall be in place to ensure that the assignment of administrator accounts is approved by the Operator’s management and that usage is monitored for appropriateness.

9.19 Inappropriate use of system accounts on the gaming system shall be logged, reviewed and responded to within a reasonable period of time.

9.20 Inappropriate use of administrator accounts shall be reported to the Registrar in a timely manner.

Software

Note: The following Standards apply to the following types of software: 1) Commercial off the shelf software, 2) Modified commercial off-the-shelf software, 3) Proprietary developed software, and 4) OLG specific developed software.

9.21 Software used for the gaming system shall be developed using industry good practices.

9.22 Software development methodologies used shall be clearly documented, regularly updated and stored in an accessible, secure and robust manner.

9.23 An appropriate system shall be in place to manage the software development and ongoing software management lifecycle.

9.24 All software development roles shall be segregated during and after release of code to a production environment.

9.25 The Operator shall establish an appropriate audit trail of authority and management review of code for software.

9.26 Controls shall be in place to ensure software is appropriately secured and access is appropriately restricted throughout development.

9.27 The Operator’s authorized management staff shall review and approve software documentation to ensure that it is appropriately and clearly documented.

9.28 Source code and compiled code shall be securely stored.
Guidance: Compiled code could be digitally signed or hashed (including each time there is a change) in a manner that allows for external verification.

9.29 The promotion or movement of code from testing through other environments to production shall be accompanied by the appropriate documentation and approvals.

9.30 All promotion of code from development to production shall only be performed by production support staff and not by development staff.

9.31 Appropriate testing environments shall be in place to allow for thorough testing of any code before it is put into production.

9.32 Access to production environments shall be restricted from development personnel.
Note: This does not preclude granting of temporary supervised access for conducting technical investigations that may only be performed on the production environment.

9.33 Development code shall not be present in the production environment.

9.34 A mechanism shall be built into the gaming system to verify the integrity of the software that is deployed to production, including before changes are implemented, as well as on an ongoing basis.

9.35 Appropriate release and configuration management systems shall be in place to support software development.

9.36 All code developed by a third party shall be tested to ensure it meets industry good practices and that it performs to meet its purpose prior to being added to the testing environment and prior to integration testing.

9.37 All code developed by a third party shall pass integration testing before it is added to production.

9.38 Mechanisms shall be in place to ensure that bugs are identified and addressed prior to, and during, production.

9.39 Quality assurance processes, including testing, shall take place during development and prior to the release of any code.

9.40 All components, where appropriate, shall be tested for the purposes for which they will be used.

Change Management

9.41 Post implementation reviews shall be performed to ensure that changes have been correctly implemented and the outcomes shall be reviewed and approved.

9.42 All change related documentation and information shall be captured, stored and managed in a secure and robust manner.

9.43 The implementation of software related updates, patches or upgrades shall be regularly monitored, documented, reviewed, tested and managed with appropriate management oversight and approval.

9.44 A mechanism shall be in place to regularly monitor, document, review, test and approve upgrades, patches or updates to all gaming-related hardware components as they become end of life, obsolete, shown to have weaknesses or vulnerabilities, are out-dated or have undergone other maintenance.

9.45 Appropriate release and configuration management processes with support systems shall be in place to support both software and hardware related changes.

9.46 Only dedicated and specific accounts may be used to make changes.