61D-14.0211. Server Based Gaming Systems (SBGS) and Server Supported Gaming Systems (SSGS)

(1) Prior to sale or delivery of a SBGS or SSGS for play in this state, the division must receive written certification by a licensed independent testing laboratory that all criteria for operation contained in Chapter 551, F.S., and Chapter 61D-14, F.A.C., are met. The testing laboratory that certifies the system shall perform an initial onsite test to confirm the install of the system to ensure proper configuration of all security applications.

(2) Each component of a SBGS or SSGS must function as indicated by the communication protocol implemented. All protocols must use communication techniques that have proper error detection and/or recovery mechanisms which are designed to prevent tampering. Encryption with secure seeds or algorithms is required.

(3) For a SBGS, the client must be rendered unplayable if communication from the server or system is lost. In the event of lost communication, the SBGS must provide a means for patrons to cash out credits indicated on the server based client terminal at the time communication was lost.

(4) In the event the SBGS or SSGS is utilized in conjunction with another approved progressive network, all communications must pass through at least one approved application-level firewall and must not have a facility that allows for an alternate network path. If an alternate network path exists for redundancy purposes, it too must pass through at least one application-level firewall.

(5) Except as provided in this section, the SBGS or SSGS shall not allow for remote access. A slot machine licensee shall provide in its system of internal controls a method of providing limited remote access to the SBGS or SSGS for a slot machine business occupational licensee pursuant to subparagraph 551.107(2)(a)3., F.S. Limited remote access, where permitted, shall authenticate all computer systems based on the authorized settings of the SBGS or SSGS, or firewall application that establishes a connection with the SBGS or SSGS, and:

(a) Prohibit unauthorized remote user administration functionality;

(b) Prohibit unauthorized access to any database other than information retrieval using existing functions;

(c) Prohibit unauthorized access to the operating system;

(d) The SBGS or SSGS must maintain an activity log either automatically or have the ability to manually enter the logs depicting all remote access information, which includes:

1. Log on name,

2. Time and date the connection was made,

3. Duration of connection; and,

4. Activity while logged in, including the specific areas accessed and changes that were made.

(e) Meets all other requirements for remote access as provided for under Chapter 61D-14, F.A.C.

(6) A SBGS or SSGS may be a collection of servers for load balancing, redundancy or functionality reasons. The system as a whole, which may be a collection of such servers, must meet the full requirements of Chapter 61D-14, F.A.C., but not necessarily each individual server.

(7) For a SBGS, the game server shall generate and transmit to the client terminals control, configuration and information data, depending upon the actual implementation. For a SSGS, the game server will not participate in the game determination process, but it’s primary functions will be that of downloading control programs and other software resources, or providing command and control instruction that may change the configuration of the software already loaded on the client terminal, on an intermittent basis.

(8) The servers shall be housed in a secure computer room or secure locked cabinet located at a Florida licensed slot facility and shall have dedicated cameras that offer unobstructed views and meet all camera requirements as specified in Rule 61D-14.054, F.A.C. All servers shall have sufficient physical and/or logical intrusion protection against unauthorized access. The system shall require manufacturer and division authority providing joint but not separate access.

(9) The SBGS or SSGS interface element setup and/or configuration menu(s) must not be available unless using an authorized access method that is secure. There shall be no means available for an operator to conduct programming on the server in any configuration. However, it shall be acceptable for licensed network administrators to perform authorized network infrastructure maintenance, provided that all requirements are met as detailed under Rule 61D-14.074, F.A.C.  All SBGS or SSGS servers and client devices shall have:

(a) Industry-standard virus protection; and,

(b) Copy protection to prevent unauthorized proliferation or modification of software, for servers or clients, provided that:

1. The method of copy protection is fully documented and provided to the licensed independent testing laboratory, who will verify that the protection works as described; and,

2. Any device(s) involved in enforcing the copy protection can be individually verified by the division.

(10) The SBGS or SSGS shall be designed to protect the integrity of pertinent data in the event of a failure. Audit logs, system databases, and any other pertinent data must be stored using a protection method determined as reasonable by the division. If hard disk drives are used as storage media, data integrity must be assured in the event of a disk failure. The protection method employed must also provide open support for backups and restoration. Backup scheme implementation must occur at least once every twenty-four (24) hours. In the event of a catastrophic failure when the SBGS or SSGS cannot be restarted in any other way, it shall be permitted, with prior written approval of the division, to reload the database from the last viable backup point and fully recover the contents of that backup. The SBGS or SSGS must implement self-monitoring of all critical interface elements, including but not limited to central hosts, network devices, firewalls, and links to third parties, and shall have the ability to effectively notify the system administrator of the condition, provided the condition is not catastrophic. The SBGS or SSGS shall be able to perform this operation with a frequency of at least once in every twenty-four (24) hour period.

(11) Each component of the SBGS or SSGS must have a method to be verified via a division approved third-party verification procedure. The third-party verification process shall not include any process or security software provided by the operating system or manufacturer. The SBGS or SSGS must be capable of verifying that all control programs contained on the server or system portion are authentic copies of approved components both automatically at least once every twenty-four (24) hours and on demand if requested. The method of validation must provide at least 128 bits of resolution or must be a bit-for-bit comparison and must prevent the execution of any control program component if the component is determined to be invalid. If an error(s) is detected, the system must provide a visual notification of the invalid program. A program component of the verification mechanism must reside on and securely load from non-alterable media. A report shall be available at the request of the division which details the outcome of each automated execution of the validation mechanism and shall identify any invalid program components.

(12) Program devices that only use read-only memory, such as smart cards, may be used provided they are able to be verified by the following methodology:

(a) A challenge is sent by the peer device, such as a hashing seed, to which the device must respond with a checksum of its entire program space using the challenge value; and,

(b) The challenge mechanism and means of loading the software into the device is verified by the licensed independent testing laboratory.

(13) The SBGS or SSGS shall provide the ability to conduct an independent integrity check of all applicable controlled components residing on the system. The third-party verification process shall be approved by the division, and shall not include any process or security software provided by the operating system manufacturer.

(14) The SBGS or SSGS shall provide the ability to authenticate all applicable controlled components for which a copy resides on the system on demand and once every twenty-four (24) hours and:

(a) The SBGS or SSGS shall authenticate all critical files including, but not limited to, executables, data, operating system files and other files, which may affect the game outcome or operation, and for which a copy resides on the system.

(b) The SBGS or SSGS shall employ a third-party industry-standard secure hashing algorithm. If embedded, the manufacturer must be able to demonstrate the algorithm of choice to both the licensed independent testing laboratory and the division.

(c) A report shall be available at the request of the division that details the verification results for each controlled component verification.

(d) In the event of failed authentication, the SBGS or SSGS shall deactivate the controlled component in a manner in which the download, install, and configuration of the controlled component to a connected client terminal is not possible. The SBGS or SSGS shall also provide a mechanism to provide notification of the authentication failure to the division.

(15) The server that supports a SBGS or SSGS must be able to provide the following information display:

(a) A complete play history for the most recent game played and at least nine (9) games prior to the most recent game for each client station connected to the server based game. The display must indicate the game outcome, intermediate play steps, credits available, bets placed, credits or coins paid, and credits cashed out. The capability to initiate game recall must be available at the client, for recall information specifically associated with the particular client station initiating the game recall. The capacity to initiate game recall for any and all clients that make up the SBGS must be available from the system or server portion of the SBGS. The requirement to display game recall applies to all game programs currently installed on the server portion of the server based game.

(b) A complete transaction history for transactions with a cashless wagering system to include the most recent and the previous thirty-four (34) transactions prior to the most recent transaction for each client station that incremented any of the cashless in-or out meters. The capability to initiate transaction history must be available at the client terminal for the transaction history specifically associated with the particular client terminal initiating the history information request.

(16) The SSGS download data library shall only be written to using a secure methodology by which the licensed manufacturer and/or Florida licensed slot machine operator will be able to access the download data library, provided that this access does not permit adding new download data files; or the download data library shall only be written to using a method that is acceptable by the licensed independent testing laboratory and the division.  Any changes that are made to the download data library, including the addition, changing or deletion of game programs, must be stored in an un-alterable audit log, which shall be available at the request of the division, and shall include, at a minimum:

(a) Time and date of the access and/or event;

(b) Log-in name; and,

(c) Download data files added, changed, or deleted.

(17) Any record of activity between the server and the client that involves the downloading of program logic, the adjustment of client settings and/or configurations, or the activation of previously downloaded program logic, must be stored in an unalterable audit log, which shall be available at the request of the division, and shall include:

(a) The client terminal(s) which the game program was downloaded to and, if applicable, the program it replaced; and,

(b) The client terminal(s) which the game program was activated on and the program it replaced; and,

(c) Changes to the client terminal configuration settings and/or configurations and what the changes were.

(18) The client terminal and/or the SSGS server must have a method to monitor and report to the facility based monitoring system (FBMS) all external door access during a foreground program download and/or activation process. Prior to execution of updated software, the client terminal must be in an idle state for four (4) minutes and the software successfully authenticated, as provided for under Chapter 61D-14, F.A.C. Prior to any software being added or removed from a gaming device or client station comprising a part of a system supported game, that would result in the loss or change of mandatory accounting meter information; a complete set of meter information must be successfully communicated to a slot accounting system. It must be possible for the division to perform an analysis of the game, which may include viewing the game data at the SBGS or SSGS server and/or being able to place the game data back onto another client terminal for further examination.

(19) Client terminal control programs that offer multiple paytables and/or denominations that can be configured via the SBGS or SSGS server will not require additional approval by the division to change the paytable selected, provided:

(a) All paytables that are available are certified by a licensed independent testing laboratory as meeting the requirements contained in Chapter 551, F.S., and Chapter 61D-14, F.A.C.;

(b) Received the prior approval of the division;

(c) The client terminal and/or SBGS server maintains the amounts bet and amounts won meters within critical memory for each of the paytables that are available;

(d) The client terminal maintains the master accounting meters in currency amounts;

(e) The game is in an idle state when the update occurs; and,

(f) The change will not cause any inaccurate crediting or payment.

(20) The process of clearing memory on the client terminals via the SBGS or SSGS must utilize a secure method that meets all requirements as provided for under Rule 61D-14.044, F.A.C. In the event the SBGS has the ability to download random values to the client terminal, the random number generator shall function in accordance with at least a 99% confidence level and meet all other requirements as outlined in Chapter 61D-14, F.A.C.

(21) The SBGS or SSGS client terminal(s) may receive game play information from the game server, in the case of a SBGS, or make its own determination in the case of a SSGS, and then display the information to the player. All SBGS or SSGS client terminals must conform to the requirements established by Chapter 551, F.S., and Chapter 61D-14, F.A.C.

Rulemaking Authority 551.103(1), (2) 551.122 FS. Law Implemented 551.103(1)(c), (d), (e), (h), (i), (2) FS. History–New 5-30-17.