Personal tools
You are here: Home Networks and Security News Managing the insider threat through code obfuscation
Document Actions

Managing the insider threat through code obfuscation

by Ryan Talabis last modified 2005-12-18 04:36 PM

Corporations spend billions building effective security protocols, but complacency and a desire for efficiency can soon lead to deviations from security protocols that workers gradually become accustomed to. The result is that small but potentially crippling holes develop in even the most effective systems, creating openings for attackers, including, potentially, insiders. Countering the insider threat requires a comprehensive, multi-tiered approach that includes physical controls, software access controls, and software protection obfuscation.

Insiders? How serious is that threat? The Ernst & Young 2004 Security Survey says, "We suspect that some respondents are influenced by either media or vendor dramatizations that escalate interest in viruses and worms instead of focusing their attention on the most lethal threat -- the insider."

When do good employees turn into threats? The May 2005 Insider Threat Study by the US Secret Service and CERT illustrates how circumstances may have affected a once-trusted database administrator. In this case, the database administrator had consistently high performance ratings, until the time she complained of harassment in the workplace. Subsequent reviews were poor, causing her to become frustrated and to find new employment. Once in the new position, she discovered that her prior employer had forwarded only negative performance reviews during the job application process. In spite, the former insider deleted key files on the employer's server, wreaking havoc with their system.

Financial gain and economic espionage are also, unfortunately, a reality of modern business. Workers, both currently and formerly employed, possess unique knowledge about security procedures. The failure to ensure that employees do not leave with information about internal applications presents a ripe target for former insiders who seek illicit economic gain or revenge.

Insiders bypass traditional security procedures

Insiders can often go around security measures to reach critical systems. In smaller departments, an inherent sense of trust can cause employees to give passwords or to grant access to critical systems when asked. In larger organizations, social engineering tricks allow hackers to bypass security measures. For example, a malicious administrator could call a corporate manager asking for his password because the company is "changing databases." The success of "phishing" scams demonstrates that even intelligent users are willing to give up their user information if they believe it is for technical administration purposes.

In information security, the corporation is at a major disadvantage: it must be secure everywhere, whereas an attacker must find only a single vulnerability. Because insiders see how a company's security protocols work in a variety of circumstances, it is easy for them to find one such flaw. If Mallory the disgruntled employee knows that an administrator leaves early every Friday, or that fewer employees are around on Christmas Eve, she could take advantage of the situation by convincing a coworker to override standard control processes. Perhaps a coworker will let her use a machine when the proper authority figures are not present to verify her intentions.

Unobfuscated code provides many with source-level information

Running systems aren't the only things at risk. Your company's source code contains vital data: information about databases, critical algorithms, and the workings of internal systems, for example. In a well-controlled environment, only developers should have access to this source code, while end users are given binaries to run.

Because of the nature of .Net and Java assemblies, however, distributing unobfuscated binaries is essentially equivalent to distributing source code. This is because in a matter of seconds free decompilers can easily recreate source code from an executable unless you take steps to prevent it.

To get an idea of the extent of information available in code, look at this table, which compares binaries that have been run through decompilers. On the left is code from a binary that was not obfuscated; on the right is an example of what a decompiler might generate when encountering strongly obfuscated code. (2005-12-15, Mark Fagerholm)


Powered by Plone Section 508 WCAG Valid CSS Usable in any browser IOSN

Copyright respective authors. Unless otherwise specified, content licensed under Creative Commons Attribution License.

Legal Disclaimer