Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


The Devils in the Design

Are your software developers sabotaging your company's application code? How do you know?

ARLINGTON, Va. -- Computer Security Institute 2007 -- What if a software developer wants to put a security flaw in your enterprise's applications?

That was the foreboding question posed by Dawn Cappelli and Andrew Moore, two experts from CERT and the Software Engineering Institute at Carnegie Mellon University, in a session held at the CSI show here today. The answers had some security pros in attendance worried.

"This is a little scary," said one attendee, who asked to remain anonymous. "This could happen to us."

Most enterprises trust their developers, and they generally assume that security flaws found in enterprise software are the result of accidents, oversights, or sloppy coding. But enterprises should also be watching for that small, dangerous fraction of developers who create backdoors or other exploits that might let them steal or damage data later on, according to the CERT experts. (See Security's New School.)

CERT, which has been doing research on insider threats for several years in conjunction with the U.S. Secret Service, found one company that lost $691 million over a five-year period through modified source code introduced by an employee in applications development.

"You wonder, how could a company lose that much money over such a long period of time and not catch it," said Cappelli. "But he was in a position where he could not only reroute the funds, but he could also change the reports."

Companies should ask themselves whether their policies, tools, and processes might make them vulnerable to such insider attacks, Cappelli said. Given the right circumstances, a seemingly harmless developer could leave openings for theft, plant a logic bomb to destroy information, or wipe out backup data that is crucial to the company, she observed.

"In the research we've done with the Secret Service, we've seen more logic bombs and malicious code than we expected," Cappelli said. "Some of them aren't terribly destructive at first and some of them don't go off right away. We saw one developer put malicious code in software that didn't begin to operate until a year after he put it in."

Cappelli and Moore took attendees through a range of scenarios in which a developer might have the leeway to intentionally create security vulnerabilities. Shared passwords, insufficient separation of duties, and a lack of adequate access controls are among the environmental weaknesses that might tempt a greedy or disgruntled worker, they said.

For example, some IT organizations might allow the same individual who manages administrative passwords to also gain access to code, the experts said. A developer who has the ability to make changes in software and the means to cover his tracks might be extremely dangerous to the corporation, they said.

Some of these opportunities for malicious coding can be eliminated through more secure development tools and practices, Cappelli said. But it's also important to implement managerial processes that help limit developers' reach and detect warning signs that a programmer might be about to go bad, she said.

"In our work with the Secret Service, we've used psychologists to study the behavior of the individuals who committed these types of attacks," she said. "There are a lot of non-technology indicators that you need to watch for as well."

Most developers who commit sabotage do so because they are upset or angry with the company, Cappelli observed. Thieves, by contrast, may do a better job of hiding their behavior -- and their tracks.

"The people around them can often see it coming before something happens," Cappelli says. Companies should work to create a culture in which individuals feel a responsibility to report suspicious activity, especially among the development team, she says.

The insider threat continues to grow, mostly without notice in the industry, Cappelli says. When CERT and the Secret Service did their first study three years ago, 39 percent of enterprises reported having experienced an insider incident. Last year, that figure was up to 55 percent.

"In most cases, this sort of threat is handled internally," said Cappelli. "Of the enterprises we found that had experienced an insider attack, 74 percent of them never reported the incident to law enforcement."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

  • Secure Computing Corp. (Nasdaq: SCUR)
  • U.S. Computer Emergency Readiness Team (CERT)
  • Software Engineering Institute

    Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    COVID-19: Latest Security News & Commentary
    Dark Reading Staff 9/21/2020
    Hacking Yourself: Marie Moe and Pacemaker Security
    Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
    Startup Aims to Map and Track All the IT and Security Things
    Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
    Register for Dark Reading Newsletters
    White Papers
    Current Issue
    Special Report: Computing's New Normal
    This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
    Flash Poll
    How IT Security Organizations are Attacking the Cybersecurity Problem
    How IT Security Organizations are Attacking the Cybersecurity Problem
    The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    PUBLISHED: 2020-09-23
    An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. T...
    PUBLISHED: 2020-09-23
    An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. Howeve...
    PUBLISHED: 2020-09-23
    An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar...
    PUBLISHED: 2020-09-23
    An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory a...
    PUBLISHED: 2020-09-23
    An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains...