Posted by Brenton Kohler on March 9, 2015
Everyone wants to believe that the code developed within a trusted software supply chain is legitimate. The unfortunate reality is that malicious coders have subtle ways to secretly embed code that exposes your business to risk. Malicious code can be challenging to recognize and can remain undetected within applications long before it causes damage.
Unless you learn to recognize the red flags.
Malicious code, also called malcode, is any code added to, changed within, or removed from an application that is designed to subvert the application’s intended function. It can include:
Unlike “malware” such as viruses and worms, malcode is not developed as external software to penetrate your systems. Rather, malcode is suspicious bits of code that appear like normal code sitting inside your own applications. It lays in wait until a specific event or action triggers the code.
When executed, malcode can pilfer data, download and install software, siphon money from accounts, log keystrokes, and permit outsiders to control computers remotely, among many other misdeeds.
Malcode can evade common application testing strategies because it blends in with normal functionality and can remain dormant for long periods of time – even years.
While it’s hard to accept, the sources for implanting and launching malcode can come from within your software supply chain. Culprits could be external development partners (offshore or onshore) or even disgruntled current or former employees that have access to code, administration or control management. They may be hiding illegal activity or simply have a grudge to bear.
It can be difficult to know who to trust to scan for malcode and fix any problems you find. For example, if an internal developer is the culprit, they know the infected application inside and out, have the inside track on how your security team looks for software vulnerabilities, and are skilled at hiding the traffic that malcode can generate. If you send a malcode report to your development team, you may tip off the perpetrator who inserted the malicious code, and they will learn to evade your detection techniques.
Make sure you track and record all sources of code in a central repository so you can trace back the work of any developer. This is essential to be able find the culprit in the event the code is malicious and it’s all just good practice.
Create a proactive plan to scan for malicious code regularly and determine in advance who will respond to any issues you find. Include binaries, design documentation, and source code in your analysis to build a story around what suspicious code may be doing and at what point in the supply chain it was inserted.
Implement some passive monitoring strategies. Institute a set of logging or firewall rules to determine whether there is backdoor access to data by comparing the system state before and after any malcode is executed. You can also actively modify firewall rules to prevent external access and data loss.
You can attach a malicious code detection process into your existing static analysis program so you can identify malicious code before it goes live. In fact, this is the ideal scenario as the two programs will pair with each other but they must be kept separate.
Rely only on a small, trusted team to scan for malicious code and collect data to identify the source of any issues you find. This operation should be as secretive as possible to prevent malicious developers from hiding themselves further.
When checking for malcode, make sure you know these common red flags: