There is no shortage of content covering the topic of preventing source code leaks, but what happens after a leak has already happened? How does an organization recover in those first chaotic, panicked days following a major breach?
Let’s take at what typically goes into a comprehensive response in the days follow a source code leak.
It Happens to the Best of Us
There are plenty of horror stories to read about. In 2013, Adobe suffered a leak in which source code for multiple products went public. In 2018, Snapchat saw their proprietary code appear in a public GitHub repository. The same year, a portion of source code from Apple’s operating system was discovered to be an inside job. Proving that even cybersecurity giants aren’t safe, Symantec had their antivirus source code stolen by “The Lords of Dharmaraja” in 2012.
And just last month, Valve saw source code for their CS:GO and Team Fortress 2 games released to the wild, leaving them with a large customer base in need of assurance.
More recently, Mercedes-Benz became the latest high-profile victim to a source code leak. Daimler AG, the German company behind Mercedes-Benz, stored source code pertaining to onboard logic units (OLUs) on their own Git web portal, but failed to properly lock down access. The result? 580 repositories of proprietary code became publicly accessible to anyone willing to create an account on Daimler’s portal. With no account confirmation mechanism in place, anyone could simply create an account using a fake corporate email.
So what can we learn about how these companies weathered the storm?
Plug the Leak
The first step is to “plug” the leak before any additional damage can take place. However, this means that we have to find the leak first. This is no small task, as the cause of the leak may not be immediately evident.
The cause isn’t always a technical glitch or mistake. In some cases, something more nefarious is at play. Some leaks are due to social engineering (cleverly deceiving an employee to share information), carelessness (an employee storing their work on personal devices), or worse, a disgruntled former employee stealing source code on their way out the door. Until they are found, they may not necessarily stop.
Therefore, an effective response begins with identifying the source of the leak. Be warned that this can be timely and costly. The organization must perform some lightning-fast detective work to determine if the cause was technological (a breached database, server operating system, or firewall) or simply a “people” problem – a fault in behavior (negligence or maliciousness).
Having a comprehensive change management system in place is critical to allow security teams quick insight into recent code changes. This will help them assess who last touched the source code in question. Open-source software often has the edge on this front, given that there are systems in place to audit recent changes and identify and reject unauthorized ones.
Plugging the leak immediately follows, which may involve hurriedly patching or hardening compromised systems or working with third parties to ensure illegally published code is removed. For example, GitHub is a very popular platform for publishing stolen code, so plugging a leak often involves issuing a Digital Millennium Copyright Act (DMCA) request that the code be taken down immediately.
Special consideration should be taken in the event that any especially sensitive data – authorization credentials, tokens, keys, and the like – that may have been included in the leaked source code is accounted for. All such data should be immediately invalidated and replaced before attackers can do even more damage.
Break the News – First
Managing the PR fallout immediately following a leak is arguably more difficult than any technical challenges posed by the event. The organization’s very reputation is at stake, and the measure of response given to the public largely decides how much of that reputation remains intact after the dust settles.
Customers should ideally learn of the leak directly from the vendor; hearing about it first from the media merely adds salt to the wound. With no time to waste, a sound response includes contacting all customers to fully inform them of how leaked code may potentially impact them.
For example, if the leaked code pertains to a live service, it may be necessary to take the service down until exploits resulting from the leak are addressed. In some cases, this means a prolonged outage and a very humble request for customers’ patience. Similarly, in a particularly severe situation, customers may be required to suspend use of a product, or at least the specific version of the product affected, either temporarily or even permanently. A software recall may accompany this.
A remediation process should be established for more severe scenarios and made easily available to affected customers during such a crisis. While this type of response may hit the bottom line for the quarter, it will stand to save and restore customer loyalty and confidence in service of long-term goals.
Another reason customers must be aware of the event is so that they have the time and opportunity to take their own response measures. It should, of course, go without saying that any such communication carry with it an authentic assurance that the organization is committed to the safety of their customers and their data.
Lastly, care must be taken to ensure that the organization can anticipate and prepare to respond to any data protection regulations that may have been violated due to the breach.
Change the Locks
The very moment source code is leaked, hackers will begin poking and prodding every nook and cranny for vulnerabilities from which they can create new exploits. The blueprints of a building reveal every possible point of entry once in the hands of an attacker, including those that perhaps even the creators themselves didn’t anticipate.
This puts the development team into an almost impossible bind: they must rush to detect any possible zero-day exploits before hackers have the opportunity to develop them. That makes for a very rapidly ticking clock while devs are thrown into a Minority Report-like role of trying to stop attacks before the possibility of attack even exists.
In other words, the new goal is to immediately update the software so that new exploits are already obsolete.
Prediction always brings with it a margin of error. It’s always possible that an attacker with enough time, patience, and determination, can conjure exploits from the most obscure and complex corners of source code beyond the imagination most developers would even imagine in. The creative nature of code becomes a double-edged sword in this case.
The rush to patch zero-day exploits brings with it new risks: Any fast-tracked patch naturally threatens to introduce new defects and vulnerabilities that would have otherwise been caught and addressed during a normal development cycle, were the solution not devised in a race against the clock.
Implement A Multi-Layered Security Approach
Perhaps one of the most important preventative measures to have in place from the beginning is a multi-layered security approach.
For example, when a portion of Apple’s IOS source code was leaked on GitHub by a former employee, Apple explained in a statement that “the security of our products doesn’t depend on the secrecy of our source code.”
A multi-layered security approach can mean that exploits found in one leaked layer of source code poses little (if any risk) because additional security measures in other layers are in place to catch the attack. In other words, one leak does not bring down an entire well-built wall.
Secure Source Code
Prevention, of course, is always the best defense. Source code storage, whether via internal repositories or external hosts such as GitHub, should be locked down tight with strict, tightly-tuned restrictions in place for who can access the repository and code within
This is where Cycode comes in. Breaking ground as the world’s first source code control, detection, and response solution, Cycode ensures that source code repositories are not simply protected, but closely monitored with mechanisms in place to provide a swift response the very moment an attack is attempted.
And Life (More Securely) Goes On
Weathering a source code leak is a nightmare scenario for most software creators, but it doesn’t have to spell a software solution’s doom.
Prepare for the worst before it happens and have multiple layers of security ready to kick in the moment any code leaks into the public eye. Have a plan on how to engage affected customers, address any PR or legal fallout, and re-secure software, ideally before any attacks can have a chance to begin.
With the right measures in place, there can indeed be life after the leak.
