Risk & IS
Sony gets hacked
In December 2010, a group of hackers going by the moniker of Fail0verflow announced at a security conference that they had successfully bypassed the encryption protocol on Sony’s Playstation 3 game console. In effect, they had developed a crack that would allow illegally pirated software to be run on the console—a situation Sony has long fought to prevent to ensure the continued support of 3rd party developers in creating software for their console. Sony later dedicated time and resources to fix the vulnerability and update their firmware.
The effort was wasted. Recently, in October 2012, another group of hackers released into the public domain a set of encryption keys that would allow anyone with enough technical aptitude to download a custom set of firmware and install it on their machine to bypass, forever more, Sony’s console security. The breaking of these keys—keys that were created and installed during the manufacturing process and that cannot be remotely updated—represent the end of a long history Sony has had assessing risk to their hardware. The response from Sony over the years to secure the Playstation 3 illustrates the difficulty of establishing a clear process for assessing and responding to risk. And, in the case of choosing to implement their encryption keys directly into the hardware, the difficulty of anticipating future risk during the analysis and design.
What could Sony have done differently to secure their system? What are the steps that a firm designing a complex information system can take to mitigate risk and to anticipate risk during the analysis stage of the SDLC? The following web pages discuss several aspects that can be useful when assessing risk during the analysis stage of a new system.