Threat Modeling in the
Gaming Industry
Robert Wood
Technical Manager | Cigital
@robertwood50 | [email protected]
Agenda
•
Threat modeling overview
•
Unique risks in the gaming industry
•
Building our hypothetical threat model
•
Assets and controls
•
Identifying the threat actors
•
Gaming industry design challenges
•
Concluding remarks
Threat Modeling Overview
•
Depiction of a system’s attack surface and how a set
of threats will target system assets
•
Outlines a system’s component interaction, attack
surface, trust boundaries, and asset flows
•
Used to:
•
Identify the many ways in which threat agents can
and will target assets
•
Identify design flaws (~50% of vulnerabilities)
Threat Modeling Syntax
•
Asset
•
Control
•
Threat agent
•
Trust zone
•
Attack vector
•
Attack surface
Assets and Controls
Asset: Information or system functionality that needs
to be protected.
Control: A security control that is in place to protect a
(set) of assets
Threat Agent
•
“Someone or something that
could cause trouble, harm, etc.”
- Merriam Webster
•
Translating to the agent that
actually carries out the attack
•
A threat agent uses an attack
vector to compromise an asset
handled by/stored in some
system component
Quantifying Threats
•
Capabilities
•
Skill level
•
Resources and tools
•
Level of access to components within a certain
trust zone
Threat Modeling Process
•
Define the scope of analysis and outline business context
•
Diagram the system structure (not the network topology)
•
Identify assets and controls
•
Identify the threats and consider their capabilities/motivations
•
Overlay the threat structure to the system structure
•
Enumerate doomsday scenarios and other canonical attack vectors based on
system components/design patterns
•
Document misuse and abuse cases
•
Analyze and enumerate additional attack vectors
•
Analyze and interpret the results
Considering Business Risks
•
Account and asset hijacking/theft
•
Cheating, automation, botting, etc.
•
Denial of service
•
Fraud in a virtual economy
•
Piracy of game titles and game content
Breaking Away From Super
Secure Design
•
Not everything needs to be (or will be) 100%
secure
•
Some assets are worth investing in strong security
controls
•
Some will be subject to monitoring and controlling
for pre-defined time periods (e.g., cheating and
licensing)
Prevent
Control/Monitor
Allow
User Privacy Breaches
Cheating
Attacks on Payment
Information
Piracy/DRM Bypass
Denial of Service
Botting
Account Hijacking
Fraud
Modeling the System
•
The threat model builds from an initially created
system model
•
Information is collected through a series of
interviews and analyzing documentation
•
Diagram should visualize how control flows between
system components
•
Capture the app-layer communication protocols that
connect components, including proprietary ones
Trust Boundaries
•
Boundaries are derived from the system’s
deployment model
•
There are machine boundaries that indicate a
specific server, endpoint, database, etc.
•
There are also network boundaries/zones (e.g.,
datacenter vs Internet-facing systems)
Assets
•
Sample assets:
•
Game content and patches
•
Player account information (PII)
•
Payment/billing information (PAN)
•
Player assets (inventory, points, virtual currency, etc)
•
Fraud and cheat detection data
•
Customer service representative account
Controls
•
Sample controls:
•
Encrypted protocols
•
Anti-tamper security on the game client
•
Security event monitoring
•
VPN tunnels
•
Cheat/fraud analysis
•
IP address white-listing
Threat Agents
•
•
Gaming industry canonical threats
•
External, Internet attacker
•
External, malicious user/player
•
External, LAN-based attacker
•
Internal, Game system administrator
Start here but consider your specific game genre,
platform, revenue model, and other system specifics
Using The Model
•
•
Start with a threat agent and follow the flow-of-control
paths to the targeted asset
•
Question: are there any paths through which a threat
agent can reach an asset without passing through a
control?
•
Question: what must be done to circumvent a control?
You should still note controls that may be ineffective in
the diagram, but they should be described as a
potential vulnerability if they are easily bypassed
When to Threat Model?
The Little Things Matter
•
Different game genres may have different threats,
assets, and controls
•
Different revenue models will also affect the threat
model
•
For example a freemium model game vs a
subscription based MMORPG game will be
attacked differently and for different reasons
Let’s Illustrate
Batman Arkham Games
vs
DC Universe Online
Gaming Platforms
•
Game consoles
•
Mobile devices
•
PC’s (Windows, Linux, Mac)
•
Web browsers
•
Cloud hosted PC’s
•
Virtual reality devices
Modeling all the Things
•
A threat model can focus on many things, some interesting points
in the gaming space may include:
•
The game client
•
The game platform (consoles, cloud-hosted PC’s, etc)
•
Proprietary protocols or authN/authZ schemes
•
Server-side components
•
Distributed worlds
•
Payment systems, password storage schemes, account signup
flows, oh my…
Re-Usable Components
•
Software engineering pulls components that are reliable and
proven (libraries, frameworks, etc)
•
For the gaming industry we can do the same thing from a
development perspective, but also from a security review
perspective
•
Threat modeling patterns on:
•
Payment processing
•
Password management
•
Client hardening
Trusted on Busted
•
One of the biggest challenges to date with
securing games has been the client application
running in an untrusted, hostile environment
•
What kind of risks does your game present to
your users?
•
What kind of risks do your users present to your
game?
Program Considerations
•
Defense in depth is clutch
•
Integrate security touch points throughout the SDLC to
catch different classes of vulnerabilities as early as possible
•
Use threat modeling to drive other security activities like
static analysis, penetration testing, secure design, etc.
•
Consider the value of the asset you’re trying to protect and
whether a single or layered control approach will work the
best
•
Not everything needs to be 100% secure from attackers
Robert Wood
[email protected]
@robertwood50