Protecting source code

Earlier this year, EA (Electronic Arts), reported a cyberattack and the theft of some 780GB of source code for games such as FIFA 21 and the proprietary Frostbite game engine used for many other high-profile games such as Battlefield. The threat actors responsible for the EA data breach put the stolen data up for sale on an underground hacking forum for $28 million, promising potential buyers that they would have the "full capability of exploiting on all EA services".

Unfortunately for the hackers, on this occasion they failed to find any buyers or extort money from EA directly, so simply dumped their haul on an underground forum. In a statement, EA said there was no evidence to suggest that any player's privacy was at risk and that it was working with law enforcement officials as part of an ongoing criminal investigation.

But EA is not the only gaming victim and more unfortunately will follow. Hackers recently stole CD Projekt Red's source code for Cyberpunk 2077 and The Witcher 3 and in July of 2020, Nintendo source code for games including Super Mario Kart and an unreleased Zelda game was released into the wild. As well as short-term financial motivation being able to see the inner workings of a game or engine could help hackers craft cheats or cracks. The reputational repercussions of this amongst gamers, investors, and third parties could result in long-term damage to trust and revenues.

Advice for Protecting Source Code

Source code is a big deal in software companies, whether it's for popular computer games or business applications. It's the core of their intellectual property and losing control over it puts their businesses and customers at risk. In the recent SolarWinds attack, hackers managed to insert malicious code into the company's Orion software used by thousands of organizations and governments around the world for network and infrastructure monitoring. The malicious code was inadvertently distributed by SolarWinds to its customers as an update or patch.

In an interview with the Motherboard news website, a representative for the criminal group behind the EA attack said they purchased stolen authentication cookies for an EA internal Slack channel from a dark web marketplace called Genesis, for $10. They then used the cookies to imitate an EA worker and access the company's Slack channel before tricking an IT support worker into granting them access to the company's internal code repositories.

Israeli cybersecurity firm Cyberpion says that it had approached EA late last year to inform them of vulnerabilities that left multiple domains and other assets free for the taking.

One of the problems is that software development at scale is a complex process that involves multiple sites, teams, and tools. The mainstay tools for software developers have Integrated Development Environments (IDEs) such as NetBeans, which help them to write code that is correctly designed and formatted. Popular collaboration tools, like GitHub, also help development teams to work together, collaborate, re-use useful code segments, and manage the whole process.

Often the code itself is held on cloud servers, but the actual coding process, like most things, happens at the user's endpoint machine, which may increasingly be at home.

This distributed and collaborative environment presents a considerable attack surface to protect from multiple attack vectors such as phishing and social engineering, compromised user accounts, or drive-by website downloads. Then there are infrastructure vulnerabilities such as unpatched servers, or insecure FTP servers. And not forgetting the disgruntled or financially motivated employee who may steal code directly.

Time to focus on the data

Traditionally, we have tried to protect data or source code in this case with multiple layers of security to stop hackers or rogue insiders from getting access to it. But the relentless flow of headlines around successful cyberattacks from EA to SolarWinds proves that this is not working. So, if we cannot keep the cybercriminals out nor trust the people around us, we must rethink the traditional 'castle and moat' methods of protection and adopt a data-centric approach, where security is built into data itself, including valuable source code.

Technologies such as full disk encryption will protect data when it is at rest on a dormant hard disk or USB stick, which is great if a software developer loses a laptop but is of absolutely no use in protecting data against unauthorized access or theft from a running development system. Data, therefore, needs to be protected not only at rest, but also in transit, when copied and in use, on-site or in the cloud.

The problem is that this level of encryption has been considered complex and costly and detrimental to performance and productivity, so only used to encrypt only the 'most important' or 'sensitive' data. But deciding what is important and sensitive and discovering where it is stored is no easy task.

In a recent Ponemon report, 67% of respondents say discovering where sensitive data resides in the organization is the number one challenge in planning and executing a data encryption strategy. The report also found that 31% cited classifying which data to encrypt as difficult.

Weighing the balance too much towards automation results in sensitive information being misclassified. And giving the user too much choice also results in wrongly categorized data. After all, people tend to do what's easiest and not necessarily what is the most secure.

But with advances in technology and fast processing speeds, seamless data encryption can now be used to protect all data, structured and unstructured. This way, classification for data security purposes becomes irrelevant and stolen information remains protected and useless to cybercriminals.

In the case of EA or CD Projekt, the hackers would have been left disappointed when they realized that the data they had stolen was already encrypted and useless to them. No data, no ransom.