Information Technology

Non-IT personnel are largely precluded from having unmonitored access to areas containing back-office gaming/entertainment servers and equipment.  The “periodic monitoring” requirement is determined primarily by what a reasonable person would deem appropriate, based on the type of system, the nature of the work being performed, and the level of risk associated with the system.

IT MICS #5 addresses gaming personnel, including the manufacturers of the gaming equipment, who are not IT personnel.  IT personnel must periodically and physically check on these individuals to ensure they are working on the appropriate systems in the appropriate locations.

MICS #7(a) through (d) apply to all levels of the system – meaning the application, database(s), and operating system(s) housing the gaming system.  The system of internal control must include all systems and whether they can be configured to comply with the requirements of the standard.  The system of internal control should be sufficiently specific to indicate to the reviewer the level at which each system is capable of, and currently configured to, comply with the requirements of the standard. 

During normal application program operations, data files are continually updated as a result of background operating system and application system functions.  As application programs normally operate, database tables are also updated continually to reflect new and changed data.

This standard requires that databases and operating systems be configured to monitor data files and database tables that belong to gaming systems to identify and log manual edits and modifications made by normal users and not by the programs or operating systems.

MICS #8 requires that operating systems, databases, networks and applications for gaming related systems be configured to log specific events.  MICS #12 requires that these logs are examined by IT personnel other than the system administrator.  This is specifically because MICS #8(d) requires that the use of administrative accounts be logged and that these logs be reviewed by someone who can understand the logs but is also independent of the system administration function.

The event logs must be reviewed for the following reasons:

1. Accountability – Log data can identify what accounts are associated with certain events.
2. Reconstruction – Log data can be reviewed chronologically to determine what occurred before, during, and after a specific event or set of events.
3. Intrusion Detection – Unusual or unauthorized events can be detected through the review of log data, assuming that the correct data is being logged and reviewed.
4. Problem Detection – In the same way that log data can be used to identify security events; it can be used to identify problems that need to be addressed.

The standard permits the use of digital tools that will “poll” event logs from multiple servers and report details of the specific event types required by MICS #8.  Additionally, an outside entity (knowledgeable of the log data and purpose of the review) may perform this review and report their findings to IT personnel.  The logs themselves, however, must be maintained by the licensee for the required period of time specified in IT MICS #11 (7 days for normal event logs and 30 days, for administrative access logs).

For the licensees with small IT departments where all IT employees are system administrators, or for the licensees with no IT department, the standard permits the review of the logs to be performed by an employee outside of the IT department using the system, provided that this employee is independent of the gaming department, and has sufficient training and knowledge to perform an adequate review.  The definition of IT personnel emphasizes that the term is not limited to employees within an IT department.

For the licensees/operators using an IT service provider for all or any information technology-related function, licensee/operator IT personnel (not the service provider’s personnel), independent of the system administration function, have the responsibility of reviewing the logs.

Generally, an employee should have only enough access to perform required job functions and nothing more.  In some instances, it may be appropriate for an employee being promoted within the same department to retain access from the previous position.  As such, access is not required to be disabled prior to assuming a new role within a department or area.

The MICS does, however, require that all previous access be removed from the user’s account before assuming a new role in a new department or property.

MICS #13 and #14 apply to user account provisioning on the application level only.  Application level user provisioning can be performed by a user access administrator, who is an individual responsible for assigning application functions matching the employee’s current job responsibilities (see definition of the user access administrator).  Therefore, management personnel, IT service provider’s personnel, or person(s) independent of the department using the system may perform user provisioning on the application level. 

MICS #10 requires certain information to be included on a single report, the User Access Listing.  Information relating to menu functions that a specific user or group can perform, as required by #10(c), may be contained on a separate report.  A list of all groups a user account is a member of [required by #10(h)] may also be contained in a separate report, provided that the user account is clearly identified, and the report can be easily cross-referenced with all other user account reports. 

The system of internal control should clearly identify any information that cannot currently be reported by the system on a set of user access listing reports. 

No.  The purpose of including this information in the user access listing is to readily identify these events to the person reviewing the report as the most recent dates on which this activity occurred for the listed user accounts.  Although the information is also reported in an event log or transaction report, it would be very difficult to sort through these logs/reports to find a specific event related to a specific user.  Additionally, it is very difficult to ensure that the event noted in the log is the most recent one for any specific user account.  These fields must be reported on the main user access listing report provided by any gaming system. 

MICS #15 requires that employees with multiple user accounts only be able to use one account at a time when a possible segregation of duties deficiency may be created.  Such a situation may exist in the slots department; a slot floorperson (employee performing a jackpot payout) may occasionally function as a supervisor (employee authorizing a jackpot payout). Two user accounts may be established for an employee performing two different roles.  To comply with this MICS, the employee’s account (as a slot floorperson) used to perform a jackpot payout is disabled when the employee is functioning as a supervisor to keep the supervisor from performing both functions (pay and authorize a jackpot payout).

As a reminder, when a race/sports writer occasionally functions as a supervisor, only one account can be established for this employee which complies with the requirements of Race and Sports MICS #49.  Additionally, as addressed in Race and Sports MICS #50 (and note), a writer and/or cashier is prohibited from accessing the administrative terminal or performing administrative functions.

The user access listing selected for review is to be one of the listings actually retained during each quarter (see MICS #35 for required retention of listing).  As a reminder of the requirement of MICS #35, user access listings for each gaming-related application (with the exception of pari-mutuel systems) are retained; as such, only gaming-related user access listings are to be reviewed. 

The user access listings review should be performed by the end of each quarter.

When the system is not capable of providing a user access listing indicating the date when the account was deactivated and/or the date of the last password change, the system is considered to be “grandfathered in” and compliance with MICS #18(c) and (d) is not required.  However, the written system of internal control is to delineate the reason for not performing the review.

The technical standards governing administrative access to servers housing system-based gaming (SBG) and system-supported gaming (SSG) systems only require that licensees ensure that at least two individuals are involved in such access.  The standard does not specifically identify any particular method. Using a split or dual password is one suggested method by which this may be accomplished.  The primary purpose of IT MICS #25 is to require that someone independent of the slot department review the controls on a daily basis to determine that at least two people were involved in every administrative login event. 

In most cases, these systems will log the login event for the administrative account and log specific usage of the administrative account.  The system log does not usually identify which individuals were involved in the login of the administrative account.  One possible method to determine who was involved would be to maintain a manual log for administrative logins.  The individuals involved must sign off on the log and record the reason(s) for the administrative login.  The reviewer can examine the manual log and cross reference it against the SBG or SSG event log to determine usage of the administrative account was appropriate and matches the manual log.  The individual reviewing the events should have sufficient competency to understand the contents of the SSG or SBG event logs.  The method(s) used by the licensee should be documented in the system of internal control.

Most systems do not require two users to supply their login names and passwords to gain administrative access to the system.  In this case, the administrative account password can be “split” by requiring that one person supply the first few characters of the password, and that a second person provide the remaining characters. 

The list required in MICS #32 should include any enabled generic, default, or system account.  Any disabled or deleted accounts should not be included on the list.  The systems that should be covered by this list include gaming applications along with their underlying databases and operating systems.  If the operating system and/or database system supports more than just a single gaming application, then the list should include all system, generic or default accounts enabled on that operating system or database, regardless of what system to which they pertain. 

The list required in MICS #33 should include all user accounts assigned to personnel of an IT service provider(s).  Any disabled or deleted accounts should not be included in the list.  The systems that should be covered by the list are gaming applications, along with their underlying databases and operating systems.

The list required by IT MICS #32 should be reviewed once every six months by IT management personnel of the licensee or an operator (not by the IT service provider’s personnel) and by the system administrator(s).  The list must be maintained in real time and updated as system moves, adds, or changes occur to reflect all currently enabled generic, system, and default accounts.  

IT MICS #39 applies when the source documents and reports required by Regulation or any section of the MICS are not maintained in their original physical forms but stored and maintained electronically for the duration of the required retention period, or when these source documents and reports are originally generated and stored electronically.  The examples of such source documents and reports include but are not limited to: jackpot and fill slips, cage inventory count sheets, cashier and teller turn-in slips, currency count documentation, daily audit checklists, evidence of the performance of the required procedures, daily/monthly system reports required to be generated from the gaming systems, user access listings generated per MICS requirement, back up for the NGC tax returns, etc.

This standard was implemented in response to numerous recent security breaches in which patrons' sensitive personal information was compromised.  The gaming industry traditionally collects a patron’s personally identifiable information in many areas (i.e., credit, player’s club, etc.)  It is extremely important to safeguard any personally sensitive information that patrons entrust to Nevada gaming operators.  Therefore, this requirement is limited to gaming systems approved by the Board’s Technology Division.  Gaming licensees are required to assess all the ways in which sensitive patron information is being collected, maintained, and transmitted.  Licensees are required to establish procedures to safeguard patrons’ sensitive information and the procedures are to be documented and maintained.

MICS #62 does not apply to the blank stock used for printing wagering instruments.  It applies to wagering instruments created and printed by the cashless wagering system.