Difference between revisions of "Internal software developer"

From OWASP
Jump to: navigation, search
(Related Attacks)
(filling in "risk factors" section)
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:Threat}}
 
{{Template:Threat}}
 +
<br>
 +
[[Category:OWASP ASDR Project]]
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
==Description==
 
==Description==
Line 5: Line 9:
 
Internal software developers are members of the software development team with access to change the software and some aspects of the software configuration. In many organizations, these developers will have the ability to modify any part of the software baseline. Some organizations have strict controls about what internal software developers are allowed to access in production, but others are more lax, allowing developers to make production changes.
 
Internal software developers are members of the software development team with access to change the software and some aspects of the software configuration. In many organizations, these developers will have the ability to modify any part of the software baseline. Some organizations have strict controls about what internal software developers are allowed to access in production, but others are more lax, allowing developers to make production changes.
  
A malicious developer is one of the most difficult threats to deal with, as it is extremely difficult to identify malicious code. A talented attacker will make attacks look exactly like an inadvertent error for plausible deniability. In addition, malicious code may be obfuscated to prevent easy detection. Some techniques include spreading an attack throughout a software baseline, using inheritance and class loading tricks to hide calles, and even formatting tricks.
+
A malicious developer is one of the most difficult threats to deal with, as it is extremely difficult to identify malicious code. A talented attacker will make attacks look exactly like an inadvertent error for plausible deniability. In addition, malicious code may be obfuscated to prevent easy detection. Some techniques include spreading an attack throughout a software baseline, using inheritance and class loading tricks to hide calls, and even formatting tricks.
  
==Examples ==
+
Because internal software developers may have more access to production systems and more knowledge of other internal systems, they are more dangerous than outsourced software developers. However, because their actions can be tracked more closely and their job is on the line, many organizations trust them more than external developers.
  
Java software developer
+
==Risk Factors==
SQL developer
+
Mainframe developer
+
  
==Related Attacks==
+
Internal software developers can become a threat when dissatisfied or angry with their employer. Developers commonly have a decent level of access to internal resources, knowledge of internal processes, and an implied trust with their employer, which can allow them opportunities to steal confidential information or plant malicious code.
 +
 
 +
==Examples==
 +
 
 +
* Java software developer
 +
* SQL developer
 +
* Mainframe developer
 +
 
 +
==Related [[Threat Agent|Threat Agents]]==
 +
 
 +
* [[Contractors]]
 +
 
 +
==Related [[Attacks]]==
  
 
* [[Logic/time bomb]]
 
* [[Logic/time bomb]]
Line 19: Line 33:
 
* [[Salami attack]]
 
* [[Salami attack]]
  
[[Category:Attack]]
+
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
[[Category:Intranet attacker]]

Latest revision as of 23:18, 9 December 2012

This is a threat agent. To view all threat agents, please go to Threat Agent Category page.

Last revision (mm/dd/yy): 12/9/2012

Description

Internal software developers are members of the software development team with access to change the software and some aspects of the software configuration. In many organizations, these developers will have the ability to modify any part of the software baseline. Some organizations have strict controls about what internal software developers are allowed to access in production, but others are more lax, allowing developers to make production changes.

A malicious developer is one of the most difficult threats to deal with, as it is extremely difficult to identify malicious code. A talented attacker will make attacks look exactly like an inadvertent error for plausible deniability. In addition, malicious code may be obfuscated to prevent easy detection. Some techniques include spreading an attack throughout a software baseline, using inheritance and class loading tricks to hide calls, and even formatting tricks.

Because internal software developers may have more access to production systems and more knowledge of other internal systems, they are more dangerous than outsourced software developers. However, because their actions can be tracked more closely and their job is on the line, many organizations trust them more than external developers.

Risk Factors

Internal software developers can become a threat when dissatisfied or angry with their employer. Developers commonly have a decent level of access to internal resources, knowledge of internal processes, and an implied trust with their employer, which can allow them opportunities to steal confidential information or plant malicious code.

Examples

  • Java software developer
  • SQL developer
  • Mainframe developer

Related Threat Agents

Related Attacks

Related Vulnerabilities