Part C: Raffle Backend System

Last Updated

Backend System Servers with Raffle Applications

The objective of the requirements in this section is to ensure technical integrity is embedded in ERS design, audit, security, monitoring and accounting capability that enable Charities to conduct and manage Raffles while maintaining the public interest.

4.1 Design

4.1.1 ERS components critical to the outcome of Raffles must reside in Canada.

4.1.2 Mechanisms must be in place to ensure the reliability, integrity, and availability of the ERS.

4.1.3 The ERS components must have synchronized time when providing the following, at a minimum:

  1. Time stamp for Ticket sales and Draws;
  2. Time stamp for Significant Events; and
  3. Referent time for logging and reporting.

4.1.4 The ERS must validate inputs before being processed to prevent risks to Raffle integrity or security.
Guidance:  This requirement is intended to ensure that inappropriate inputs do not compromise integrity or security of Raffles. For example, player inputs at Online POS must be validated to prevent malicious data injection, or Charity Raffle administration fields must be validated to be meaningful, e.g. numbers not accepted for letters.

4.1.5 ERS must be designed and tested to operate with integrity under anticipated load (total volume of sales and picks of Raffle Ticket transactions per minute) and communication bottlenecks in production environment.

4.1.6 The ERS must be designed for immunity against security attacks, such as security in depth (that is, multiple layers of security, so that if one layer is bypassed, the attack still has to get through the next layer, and so on).

4.1.7 Sensitive data must be secured and protected from unauthorized access or use at all times using industry good practices.

4.1.8 ERS components must not have access to nor be accessible from the internet beyond what is required by the ERS to support the Raffle solution.

4.2 Recovery

4.2.1 The ERS must be recoverable so that there is no impact on the integrity of the Raffle or the ability to audit the Raffle.

4.3 Access Control

4.3.1 The ERS must restrict users’ access based on business needs to the following, at a minimum:

  1. Access privileges must be granted, modified, and revoked based on employment status and job requirements, and all activities associated with these actions are logged; and
  2. All ERS accounts must be uniquely assigned to an individual.

4.3.2 Any changes to user access privileges must be logged, along with the user performing the change and time of the change. The following changes to user access privileges must be logged, at a minimum:

  1. Account creation;
  2. Account removal;
  3. Disabling/suspension of an account;
  4. Password change;
  5. Change in role; and
  6. Change in permissions.

4.3.3 A secure authenticator that meets industry good practices, e.g. strong password must be used to identify a user and his or her account to ensure that only authorized individuals are permitted to access their ERS account.

4.3.4 The ERS must automatically lock out accounts should identification and authorization requirements not be met after a defined number of attempts.

4.3.5 Logical access to the ERS must be fully auditable and all related events must be logged.

4.3.6 The ERS must prevent unauthorized access to sensitive database files/tables containing sensitive, confidential, or personally identifiable information, including stored procedures and passwords, and prevent their unauthorized alteration.

4.4 Secure Configuration

4.4.1 Only authorized personnel, Raffle Administrator/Manager may be permitted to configure the Raffle Game and Ticket information.

4.4.2 The ERS must not allow Raffle configuration changes that would adversely affect the security or integrity of the Raffle or any gaming-related information once the sale of Raffle Tickets has commenced.

4.4.3 ERS, data, activity logs and all other related components must be protected from threats, vulnerabilities, attacks, or breaches to ensure the integrity and security of the ERS, as follows, at a minimum:

  1. All ERS components and connections between the ERS and any other system, whether internal or external third party, must be hardened in accordance with industry and technology good practices prior to going live and prior to any changes; and
  2. The ERS must be protected against malware.

4.4.4 Functions performed by the Raffle Administrator/Manager at the Backend System must be technically restricted and not be possible to perform from POS.

4.4.5 The Backend System must have the ability to monitor and manage all RSUs and functions performed by Raffle sellers at the RSU, as follows, at a minimum:

  1. RSU must have a unique identifier to allow for its monitoring and tracking;
  2. RSUs must be authorized at the Backend System before being connected to it; 
  3. Only authorized sellers can sell Tickets for a Raffle Draw after login to assigned RSUs;
  4. Sellers can be enabled and disabled on-demand at the Backend System;
  5. RSUs can be enabled or disabled on-demand at the Backend System; and
  6. By default, all RSUs are disabled for sale of Tickets, except when assigned and enabled for sale of Tickets for a Raffle Draw.

4.5 Monitoring and Incident Response

4.5.1 Security activities must be logged in an auditable manner and monitored, as follows, at a minimum:

  1. Attempts to attack, breach or access ERS components in an unauthorized manner;
  2. Intrusion attempts must be actively detected and where possible prevented from causing disruption or outage of the ERS; and
  3. There must be adequate logging to capture and monitor any attempts to attack, breach or access in an unauthorized manner any components of the ERS.

4.6 Data Governance

4.6.1 Appropriate, accurate and complete records of Ticket transactions and Raffle event information must be kept for the purposes of audits and other regulatory purposes. 

4.6.2 The Backend Systems must record and store complete data from Tickets and financial transactions (e.g. cash floats & collections), Draw accounting data for all valid and Voided Tickets and player data, including at a minimum:

  1. Name of Charity conducting Raffle event;
  2. The Draw ID, date and time;
  3. Date and time of Ticket issuance;
  4. Ticket price(s);
  5. List of Prize(s), as applicable;
  6. Value of Prize seeds, if any;
  7. Winning Raffle Number(s) and Prize value(s);
  8. Where the Raffle event is being held in more than one jurisdiction, the jurisdiction of the winning Raffle Number(s) and Prize value(s);
  9. Financial information sufficient to reconcile Ticket sales, including payment method and price points of sold Tickets;
  10. Where the Raffle event is being held in more than one jurisdiction, sufficient information to reconcile Ticket sales, including payment method and price points of sold Tickets, for each jurisdiction separately;
  11. Player information, including name, address, age and contact information for Online sales;
  12. Individual Ticket information per section 2.3.1;
  13. Ticket status;
  14. Ticket transactions history, including Voided and Cancelled Tickets;
  15. Type of transaction or other method of differentiating ticket types;
  16. POS; and
  17. RSU seller ID.

4.6.3 Adjustments and corrections to Critical Game Data are permitted by authorized individuals, provided the following information is recorded in unalterable logs:

  1. ID of authorized user who performed the change;
  2. Date and time of change;
  3. Type of data changed; and
  4. The value of adjusted data before and after change.

4.7 Logging and Reporting

4.7.1 The ERS must provide at a minimum the following information for audit trail in on-demand generated reports with settable time periods and specific activities for each Raffle event:

  1. Raffle Transactions - Information on all Ticket transactions and Draw accounting handled by the ERS, including: All valid, Cancelled and Voided Tickets with Raffle Numbers and Validation Numbers, Ticket price, transaction POS identifier, time of transaction, Prize seed(s), total sales, cash floats & collections, winning Raffle Number(s), and Prize(s) distributed;
  2. Raffle Transactions – Where Raffle events occur in multiple jurisdictions, information on all Ticket transactions and Draw accounting handled by the ERS, including: The jurisdiction where the transaction occurred, and the jurisdiction where the winning Raffle Number(s) were purchased, and the Prize(s) distributed per jurisdiction;
  3. Security Events – any information on access and attempted authentication including: Component(s) accessed, username, success or failure of authentication, time, any changes made;
  4. Error Logs – All critical errors, e.g. failed software authentication and communication errors; and
  5. Significant Events Log - At minimum the last 100 events with the appropriate time stamp.

Randomness of Raffle Draws

The objective of this section is to ensure the outcome of Raffles is random.

5.1 Random Number Generators (RNG)

The following requirements apply to RNG randomness and its implementation.

5.1.1 The outputs provided by RNG must pass applicable statistical tests of Randomness to demonstrate:

  1. Statistical independence;
  2. Uniform distribution over their range for intended Raffle Game; and
  3. Unpredictability.

5.1.2 The range of random numbers used for statistical tests must correspond to the complete set of possible Raffle Game outcomes, as provided to the player, and to include both high and low end of Raffle sales.  The 99% confidence interval is applicable for Game specific statistical tests, including but not limited to frequency test, runs test and serial correlation test.

5.1.3 Valid RNG output must be used for Raffle Game outcome without alteration or secondary decision by the ERS.
Guidance:  The RNG output includes all necessary scaling performed such that the output is usable by the Raffle Game.

5.1.4 Where the Draw process of winning Raffle Numbers is interrupted, the original selection must be preserved until full ERS recovery.

5.1.5 The ERS must use secure communication protocols to protect RNG and random selection process.

5.1.6 Pools of Raffle Numbers must be stored securely.

5.2 Physical Randomizers

5.2.1 Physical randomizers that use the laws of physics to determine winning Raffle Ticket, must ensure Raffle Game integrity and Randomness of Raffle Draws (e.g. shuffling of Tickets).
Note: The Randomness and implementation of physical randomizers will be assessed on a case-by-case basis.

Integrity of Critical Software and Critical Game Data

The objective of the requirements in this section is to ensure technical integrity of the Critical Software and Critical Game Data during Raffle operations and that only approved software is installed.

6.1 Authentication of Critical Software

6.1.1 A mechanism that meets industry good practices must be built into the ERS to verify the integrity of the Critical Software in production in order to ensure approved software is being used with no unauthorized changes and Raffles operate as intended.

6.1.2 At a minimum, ERS must be successfully authenticated:

  1. Immediately prior to the start of a Raffle event;
  2. Before Raffle Draw for jackpot Prizes; and
  3. On demand.

6.1.3 If the self-authentication fails, the software that fails authentication must enter an error condition, safely stop operation, and notify the Charity.

6.1.4 The results of each authentication must be recorded in an unalterable report.  This report must include a pass/fail condition with details on which software did not pass the authentication.

6.2 Remote Authentication of Raffle Sales Unit (RSU) Critical Software

6.2.1 Backend System must initiate independent verification on any client device or RSU Critical Software upon initial establishment of a connection with the system. When a threshold of unsuccessful verification attempts is reached, such client device or RSU must be disabled.

6.3 Critical Game Data Integrity

6.3.1 The ERS must accurately maintain the integrity of Critical Game Data to ensure the Raffle Game operates as expected and is auditable.

6.3.2 The ERS must employ methods to detect corruption and unauthorized alteration to its Critical Game Data to prevent integrity issues from occurring.

6.3.3 Detection of corrupted or unauthorized alteration of Critical Game Data that cannot be recovered must cause Raffle sales to be halted immediately and must cause the POS to enter into an error condition, and not resume Raffle sales until the condition has been addressed.

6.3.4 The integrity of RSU Critical Game Data must be maintained by methodology that enables failure detection, backup, and recovery of Critical Game Data.

6.3.5 It must be possible to extract RSU Critical Game Data through Restricted Technical Procedures without contaminating the data in the original storage media.