SeNet's Gus Fritschie on Security in Daily Fantasy Sports

SeNet’s CTO, Gus Fritschie, was recently asked to provide his thoughts on cybersecurity as it relates to Daily Fantasy Sports.  The full article can be viewed here, but the portion with his comments is below:


Possible security breaches


Legal Sports Report: What are the potential security threats to daily fantasy sports sites, and what could security breaches result in?


Gus Fritschie: I believe there are two primary types of security issues to be concerned about.


First, are those types of security issues in the application software (i.e. code vulnerabilities such as SQL injection), operating system (missing patches), and/or IT infrastructure that could allow a system or organization to be exploited by an attacker.


Once an attacker has access, it depends on his motivation on the next step. Is it to install ransomware? An attempt to capture user credit card data or PII? Or, is it to remain persistent on the network and attempt to access information that could be used to impact the integrity of the games.


The second issue I see, and related to my previous statement, are vulnerabilities that would allow a user to obtain information or circumvent security controls that could affect the gameplay.


For example, if there was an application vulnerability that allowed a user to change their lineup after a contest started that could have a major impact. Likewise, and taking a story from previous security issues in online poker, if a rogue developer added code that allowed certain users to see other players’ lineups prior to a contest that impacts the integrity of the gaming operations.


As for the threat sources, I don’t believe it is much different from other sectors.


You will always have those attackers that are looking for a system with a known vulnerability that they have an exploit for. It does not matter if you are FanDuel or Marriott; if you have that vulnerability you are going to be exploited. The threats I am more concerned about are those targeting the sites for a specific reason, most often to gain an advantage and disrupt gaming operations.


Why little talk of security for DFS?


LSR: Why do you think security isn’t discussed as much as other regulations?


GF: I wouldn’t say that security is not discussed as much. If you look in the gaming regulations for states where iGaming is regulated, you will find security standards and requirements.


Now, often the majority of these are focused on player protection, such as requiring the ability for multi-factor authentication, or the ability to set gaming limits on amount deposited or stakes played. However, there are also standards for what the operator needs to have on the backend (i.e., auditing, IT, security staff).


New Jersey, [like] other states, also has a requirement for annual independent security testing.  This way there is a third party that assesses the security of the sites and provides a report to regulators.


What states should be doing


LSR: What tests and security monitoring should states require?


GF: I think that, prior to being allowed to operate, sites should have to meet a set of required security controls.


A standard could be created specific to iGaming, but my recommendation would be to borrow from other established security benchmarks, such as NIST, CIS, and ISO.


After that initial certification, the site should have to undergo annual security testing similar to what New Jersey mandates. This should include evaluation of technical, operational and management security controls.


We currently provide this annual testing service to some of the operators in New Jersey. Currently the focus is on technical controls — testing the gaming applications, servers and databases. However, I think that could be expanded and enhanced in order to provide an even greater level of assurance on the integrity of the games.


One area that is extremely important, but often not performed, is a security audit of the code. There was recently a case in the lottery sector where the RNG had a logic bomb programmed into the code that allowed winning numbers to be determined. This may have been prevented if annual independent security code reviews were required and performed correctly.


Differences for small and big DFS sites


LSR: Is lacking baseline security requirements an even bigger deal for a small DFS site that might not be able to put the same resources into security?


GF: Sure, this is always going to be an issue for smaller organizations with less staff and trained security personnel. [That’s] not to say that large organizations are not at risk. I have seen plenty of small companies that have a higher security posture than huge organizations.


It all comes down to their philosophy and buy-in and support from upper management. But this is another reason for compliance and regulations, as it will force sites to do something.


However, we must remember that regulations are not the silver bullet. Sometimes they have the opposite effect, as organizations will do the minimum to show compliance and turn the process into a paperwork exercise. The important concept I like to stress is that compliance does not equal security, but if you are secure you will be compliant.