Hello once more, reader! It’s time for another blog, this time focusing on a brand new subject I’ve not touched before. Data Security.
It’s no secret that games collect data – all kinds of data. From analytics, to login details, to personal player information, to payment info. And of course, when this data is stored it needs to be protected in one way or another from those who would try to access it without the proper authorisation. In a worst case scenario, if your data is accessed illegally, money or identities could be stolen, and lives harmfully impacted, even ruined. So this is pretty important.
Now, each different type of data will require a different level of security, proportional to how devastating it would be if that data were made public or got into the wrong hands. If your analytics data for the average amount of time players spend browsing through the options menu gets out, it’s going to be far less terrible for everyone than if the credit card data for your users gets stolen. So you’re going to want to protect that second one a fair bit more, to say the least. But how much? And how?
For now, let’s look at a high priority piece of data, credit card information. There is a particular standard created by five rather large banks that defines a series of rules that require compliance if they are to allow you to use their services. This standard is known as the PCI DSS (Payment Card Industry Data Security Standard).
The PCI DSS is, admittedly, somewhat vague in its requirements, and dictates what seem like a fairly common sense set of rules. These include things like:
- Maintain a firewall
- Don’t use system default usernames and passwords (apparently that needed to be made explicit…)
- Protect stored cardholder data
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- And more!
Now, there’s a lot there that isn’t awfully specific, such as ‘Protect stored cardholder data’, which you’d take as a given for a cardholder data security policy. But that is because there’s a number of ways this can be done.
Firewalls can be created and allowed incoming traffic to the network on which this data is stored heavily restricted. Essentially, your data server should be set up to only allow connections from very specific, trusted connections. This means that if an outsider learns the address for you server, they can’t just connect straight to it and do as they please. They may be able to do so by first accessing one of your already authorised connections, so those also need to be suitably restricted and additionally monitored.
All connections in and out of your data server and just your network in general should be monitored and logged. If this is then reviewed regularly (or actively monitored by a program), chances are you’ll be able to notice when something is amiss. These logs could then potentially be used to trace back to your culprit, or to determine exactly what they’ve got their hands on.
Say the malicious hackers manage to get a hold on your data anyway, there’s still a protection you can apply to the data itself. Encryption. By using an algorithm to transmute your data into something that is effectively gibberish without the appropriate decryption tool, the hackers can’t actually get the information out of the data they possess.
There are various types of encryption though, and each has a different level of complexity, a different amount of time to encrypt/decrypt, different types of weaknesses, and a different amount of time to brute-force your way to the key, getting access anyway. And of course, more complex algorithms are likely going to take more time and money to develop. So these must be taken into account, relative to the sensitivity of your data.
For example, in 2011 a large portion of Sony’s user information from the Playstation Network was taken, and the passwords contained therein exposed. The passwords used a form of cryptographic hash function to obscure them, but that form of protection is comparatively easy to brute force.
To add a brief addendum to Sony’s mistakes in that particular debacle, they also took almost a week to actually notify the public that personal data may have been compromised. Whilst it is understandable to wait until you’re certain to confirm, it is critical that your consumers know of possible breaches as soon as possible so they can take the appropriate cautionary actions. This is especially true when dealing with sensitive data such as payment details, or personal information, as was the case with Sony.
Anyway, this is going on long enough. To close this out, I’m going to leave a basic policy outline for the encryption of data relative to game development. It’s by no means authoritative, and of course there’s plenty of other ways your data could be taken, but it’s a start. Keep in mind though, this does assume you have the time and resources for whatever you need.
Data Security Policy
User Payment Information
Advanced Encryption Standard (AES) based encryption. 256-bit keys, 14 cylces.
User Personal Information
AES based encryption. 192-bit keys, 12 cylces.
User Username & Password Information
This will vary to an extent based on what these give access to. Essentially, they should be encrypted to an equal level, otherwise it’s providing an easier way to access your more heavily encrypted data.
Analytics/Basic Player Profiles (No Personal Info)
Depending on the sensitivity of these, they may not need much encryption at all. If you’re tracking basic player interactions in your games, chances are there’s little risk of someone trying to steal them. But if it’s sales data or data that your specifically don’t want the public or a competitor to get their hands on, AES 128-bit encryption should do the job.
Say you have a server for tracking all of your game’s keys, if they’ve been used, and who they’ve been used by, and perhaps even for generating new keys. These keys are your product and your life blood. Use at least AES 192-bit.