Developers often have full access to the source code of critical systems to do their job. This same access can also be used to insert logic bombs, sabotage the system, or siphon money from an organization. We have seen numerous cases of developers and system administrators exploiting parts of the software development lifecycle to commit their crimes. In this entry, we examine some recent cases involving developers who became malicious insiders.

In our repository of over 440 incidents of malicious insider activity, including crimes of IT sabotage, theft of IP, and fraud, about 4% involved source code modifications. The case summaries below outline a few of the recent cases we've encountered.

• A network security specialist, after termination, read former colleagues' email messages and modified and deleted web page style sheets that were used for client account management.
• A securities trader for a bank, who was previously a computer specialist, inserted a logic bomb into a risk model program that he created to cause employees to make increasingly riskier financial deals. The logic bomb was discovered by a programmer who was trying to modify the program's source code. Repairing the damage cost the organization $50,000.
• A programmer deleted crucial instructional code from a criminal history database and inserted malicious code into a second critical database. If executed, this malicious code would have disabled the entire system. The organization spent $85,000 repairing the damage.
• A group of analysts manipulated a casino game's source code to pay regardless of the outcome of the game. They stole over $45,000 from the casino before getting caught.
• A programmer inserted malicious source code into a software distribution system that would propagate viruses on end users' computers. The organization spent $36,000 cleaning infected machines.
• A software administrator at a financial organization, who had full access to source code, modified the code to make changes to accounts and forward funds to his personal accounts. The insider stole over $90,000 from his employer before being confronted by management after a routine system audit.

All of these cases demonstrate poor configuration management (CM) by the victim organizations. A strong CM process may have prevented these modifications before they were deployed into production. Additionally, if the organizations had a process in place to review code change logs and verify changes before releasing code into production, these incidents may have been prevented. Finally, mandatory code reviews might also have been effective in detecting unauthorized changes to critical code bases. An earlier article published by the CERT Insider Threat Center, "Spotlight On: Programming Techniques Used as an Insider Attack Tool," examined the use of programming techniques as an insider threat tool in more detail.

Upcoming Presentations / Workshops

CERT Insider Threat Center staff regularly present at conferences and hold workshops. The following are some of our upcoming events:

• March 24 -- SEPG North America 2011 - "What The Good Guys And Bad Guys Have Taught Us About Our OSP In A Cyber Environment" (Randy Trzeciak)
• March 29-30 -- Insider Threat Workshop, Arlington, VA (Adam Cummings and Randy Trzeciak)