Culture Clash: When Security Comes Knocking
Game Developers are used to putting in Herculean efforts to ship products for market driven ship windows. A little bit too late, or in the wrong competitive window, or past Christmas, can destroy any hope that years of effort will turn into a commercial hit. “It just has to work once” has been an often heard refrain from engineers as they try to get the last ship-blocking bugs fixed without breaking anything new. And while proper engineering practices are used (or at least theoretically used) early in development, by the end, any hack that gets the game ready for ship is usually good enough.
Security professionals, by comparison, are far more concerned with the ability of an attacker to compromise the integrity of the end-users machine, and far less concerned with schedules or features. It is even fair to make the case that security professionals tend to be outright “feature hostile”, as anything that increases usability, or adds impressive new capabilities, especially when done in a networked fashion, adds to the attack surface that they must defend. And because security suffers from the “defender’s dilemma” (the attacker only needs to find one weakness, the defender must be strong everywhere), security auditors are extremely uncomfortable with late-development “hacks” that can fix feature bugs at the risk of adding security vulnerabilities.
This is a discussion of what happens when those two worlds meet, especially when they meet late in the development cycle, drawn from both sides of the divide.
Intended Audience: The intended audience is made up of producers, software engineers, and test leads in the game development community. No understanding of security issues is necessary for understanding the session.
Prerequisites: Familiarity with the traditional product development cycle in the game industry is advised, but not necessary. No understanding of security issues is necessary.
Format: Lecture
Date/Time: Friday, 2:00 PM
Room: Senate
