LeagueSpot Data Privacy White Paper

LeagueSpot is a competition engine built on a data platform. Our philosophy is that we don’t own the competition data in our database, rather our customers own their own data that we secure. This positions us as trusted guardians of our customers’ data, and to fulfill that obligation we have implemented solutions and procedures that exceed standard data security requirements.

This becomes even more important as our intended end users are competitive gamers of all ages, inclusive of a broad youth audience - given the growing number of regulations pertaining to securing especially youth data, it is imperative that we implement as many best practices as possible to safeguard our customers’ data.

Minimal Personal Identifiable Information (PII) footprint

The LeagueSpot platform collects minimal PII, limited to:

• First and last name
• Email
• Third party usernames (e.g., Discord)
• Gamer handle - how the user prefers to be referred to in game
• User avatar - this could potentially consist of an image containing a photo or likeness of the user
• Custom registration fields - pre-defined fields that capture custom data points for leagues in which this feature is enabled. This feature is disabled by default and therefore is not applicable to most customers

Even though we limit the PII data that we collect, we view even a single data record as being critical to secure. We take several measures to ensure data is presented to only users who have predetermined, explicit access.

Role-based access

The following is a matrix of the access that each LeagueSpot user has to PII data:

Technology stack

Application security starts with avoiding known vulnerabilities at the OS or framework level. Our applications are designed to regularly update and resolve security issues through our use of constantly updated PaaS resources and automatic framework updates on every deployment.

The LeagueSpot API runs as a .NET Core 6 application, hosted as an Azure App Service and backed by an Azure SQL database. We leverage Azure DevOps for source control and build/release automation. Due to how our build agents and PaaS resources are configured, we are always using the latest patch version of .NET Core 6 at both build time (via the SDK) and runtime as is supported by Azure.

Data security implementation details

In addition to securing our applications by only using the latest versions of OS and frameworks, LeagueSpot implements the following software and cloud best practices to secure systems, keys and data from unintended access.

Authentication tokens

The LeagueSpot API is secured by JSON web tokens that are generated from secret keys that prevent forgery. Tokens cannot be used between environments, and user tokens expire after 7 calendar days.

Administrator token expiration

User access tokens are set to expire in 7 calendar days. As our administrators have significantly elevated access to application operations, we only allow 3 hours before we expire our administrators’ access tokens.

End-to-end encryption

Our users’ data flows from and to our web application through our API and is stored in our SQL database. The entire route is secured via TLS encryption (commonly known as encryption “in transit”) and our SQL databases are configured to encrypt all data “at rest.”

Limited cloud resource access

All LeagueSpot Microsoft accounts that have access to Azure services are mandated to use Microsoft multi-factor authentication. Accounts are assigned to specific cloud resources in accordance with least privilege required to operate effectively, and access to our databases is maintained by a strict IP whitelist.

Securely protecting secrets

We leverage Azure Key Vault to securely store application secrets in environment-specific stores with the most restrictive access privileges. This avoids storing secrets within source control, configuration files (encrypted or otherwise) or in the App Service app settings interface. It also has the added benefit of not storing the secrets in clear text while still being available to our applications, meaning that a developer with access to our API’s cloud resource cannot read the secrets that are passed at runtime.

Regular key rotation

Our database passwords are over 30 characters long and consist of alphanumeric (including special) characters. While these are already highly secure, we take the additional step of rotating our passwords every three months for redundancy just in case a secure password were to be discovered. Our ability to leverage Key Vault as a central store makes this a straightforward process.

Environment isolation

We have three primary environments, and provide graduated degrees of access based on least privilege - our Development environment being the most open, Production being the most restricted. All resource access keys (e.g., database password) are different in each environment, so no key can be used to gain additional access beyond what the user or application requires in its own environment.

We promote more thorough application testing by regularly copying our Production database to lower environments. Our process uses irreversible PII obfuscation controls to ensure that PII data never leave the Production environment.

Application logs

While we do log API requests to our application logs, we specifically scrub PII from those log messages prior to sending. For example, this is the message content for a request to edit a user’s profile information:

{EditUserProfileCommand}

"[Id, 8ae553e9-7ec7-4ae2-9a22-08d73640dcbf], [FirstName, *****], [LastName, *****], [GamerHandle, *****], [GameHandles, *****]"

While not technically considered PII, passwords are also scrubbed from messages sent to our application logs.

Visibility controls on PII fields

Our API only allows certain roles (e.g., an organization Manager) to see sensitive PII fields such as a user’s email address, which follows the principle of least privilege based on the user’s role requirements. Additionally, we have the ability to make certain fields anonymous to ALL API consumers such as our web application. This is particularly useful when working with education records or children under the age of 13 in terms of COPPA compliance.

Strict limit on API key access

We use API keys to allow secondary application integrations such as our Discord bot that leverages our API. We can also provision keys that only work within specific leagues. Keys provide limited resource access based on the context to which we assign to them, much like our users’ access tokens only allow them to complete certain operations given their explicit access rights.

Specific regulatory considerations

LeagueSpot takes all federal and state regulations seriously. Below is a non-exhaustive list of regulations and how we have adjusted to them as examples. We are committed to continuing to monitor the regulatory process in order to remain within compliance.

COPPA

While our application has historically been excluded from COPPA requirements due to requiring that registering users confirm that they are 13 or older, we intend to open up some organizations to register users under 13, which means we will implement a few additional procedures to comply with regulations:

• We do not and will never sell our customers’ data.
• We disallow anyone under age of 13 to upload an avatar.
• Updated privacy policies that comply with COPPA requirements
• Requiring a parent/guardian to provide written signature on data collection terms
• Implementing parent/guardian accounts that can be associated with specific children

GDPR

LeagueSpot currently intends for its application to be used by customers within the US, but as our business grows we are aware of the need to expand to cover new users located in the EU. The good news is that we currently satisfy most GDPR requirements today, regardless of our exclusive US footprint.

• We currently request users to accept cookies prior to using them for behavior tracking purposes (e.g., Google Analytics).
• We currently limit the PII that we request minimally to deliver an excellent experience on our platform.
• We currently honor requests to remove or anonymize data for specific users.
• Updated privacy policies that comply with GDPR requirements
• Expanding the parent/guardian consent for children under 16

CCPA

Esports activity in the US is disproportionately based in California, and our view is that the CCPA is likely to be only the first of just such regulations across the country. We are dedicated to monitoring the regulatory process and complying with all US acts including and similar to the CCPA.

• We do not and will never sell our customers’ identifiable data.
• We currently honor requests for a user to review their own data, and to remove or anonymize data for specific users.
• Updated privacy policies that comply with CCPA requirements

CIPA

We strongly believe in the spirit of the regulation and therefore enact procedures to protect students from malicious content such as working with league hosts to monitor text and media content uploaded by users, and will enact bans on users who upload inappropriate content.

FERPA

We implement parent/guardian accounts that can be associated with specific children to review and request changes to their data. We also commit to provide data manually requested by parents/guardians in terms of their child(ren)’s data.

PPRA

We do not collect any of the PII items as enumerated by either the PPRA directly nor by the No Child Left Behind act - specifically Sec. 1061 which amends the PPRA. We do not use identifiable data for marketing or any other commercial purposes outside of the direct purposes of our platform. LeagueSpot honors requests for parents/guardians to review in detail and request changes to their child(ren)’s information.

SOPIPA

LeagueSpot does not engage in targeted marketing or advertising that leverages the PII of its users, including extended user metadata such as IP address or geolocation. We also do not sell any identifiable information of our users.

AB 1584

We understand that all records provided to our systems in accordance with programs specifically within Education are owned by that institution, which is consistent with our general philosophy that all of our customers own their provided and generated data.

• We do not sell identifiable information nor do we use it for targeted marketing or advertising purposes.
• Parents/guardians can create an account with the explicit purpose of viewing their child(ren)’s information and request edits.
• Our systems leverage a hierarchy of predefined roles that have explicit access to certain information, limiting data to only those legally authorized to access.

CSDPA

LeagueSpot is committed to compliance with the federal regulations FERPA, COPPA & PPRA and California regulations SOPIPA, AB 1584 as described in this document. Furthermore:

• We honor requests for partial and complete disposal of student data in accordance with CSDPA terms.
• LeagueSpot does not use any identifiable information for the purposes of marketing or advertising.
• We implement prevailing best practices and protocols with the intent of exceeding industry standards for data security.

Data breach

We go to great lengths to secure our clients’ data. In the unexpected event of a data breach, we will provide notification to and work with all of our clients to remediate and provide notice to affected users in accordance with prevailing federal and state regulations.

Remediation plan

1. Identify that PII has been acquired or is reasonably believed to have been acquired by an unauthorized party. Due to their constituency (e.g., where PII could be considered education records), each of our customers has different requirements on what would be specifically considered sensitive PII.
2. Temporarily take offline and rotate keys on affected resources. The actual response will depend on the known details and extent of a breach.
3. Thoroughly document the data that has been exposed by the breach.
4. Notify our customer leadership that a breach has occurred. Determine whether the unauthorized access would be considered sensitive PII and should trigger a public notification.
5. Notify law enforcement.
6. Patch application code and/or vulnerabilities that were responsible for the breach, if applicable.
7. Notify via email all users whose PII is known to or suspected of being exposed by the breach. This communication will be in cooperation with law enforcement and our customer leadership, and will be sent as expeditiously as is reasonably possible.

Subject: NOTICE OF DATA BREACH

Describe the pertinent details of the breach, including:

1. How it happened
2. What information was taken
3. How the unauthorized party has used the information (if known)
4. The actions we have taken to remedy the situation
5. The actions we are taking to protect individuals
6. How to reach the relevant contacts in our organization

If notice must be sent to more than 500 California residents, a copy of the notice will also be sent to the California Attorney General.

NOTE: The checklist discussed in this document is meant to be used as a general example illustrating some current industry best practices in data breach response and mitigation applicable to the education community. This list is not exhaustive and organizations are encouraged to tailor the checklist to reflect their individual needs and priorities. Further, note that educational agencies and institutions are responsible for ensuring that their breach response plan addresses all applicable federal, State, and local data breach notification and other legal requirements. Therefore, we advise that you always consult with your organization’s legal counsel to determine your organization’s full responsibilities regarding applicable privacy laws