Separation of duties - Revision history

KirstenS at 22:19, 7 April 2009

2009-04-07T22:19:40Z

KirstenS: /* Related Vulnerabilities */

2009-02-09T01:56:03Z

‎Related Vulnerabilities

KirstenS: /* Description */

2008-09-05T19:12:07Z

‎Description

KirstenS at 19:11, 5 September 2008

2008-09-05T19:11:23Z

Jhoraz: /* Description */

2008-07-08T23:34:56Z

‎Description

Jhoraz: /* Description */

2008-07-08T23:33:06Z

‎Description

Cduffey346: Added Related Controls

2008-06-17T00:43:18Z

Added Related Controls

Cduffey346 at 00:24, 4 June 2008

2008-06-04T00:24:01Z

Jeff Williams at 15:04, 14 June 2006

2006-06-14T15:04:17Z

New page

{{Template:Principle}}

{{Template:Stub}}

==Overview==

A key fraud control is separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived.

Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.

For example, an administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.

[[Category:Principle]]

← Older revision		Revision as of 22:19, 7 April 2009
Line 5:		Line 5:
	<br>		<br>
	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]
−	~~[[ASDR Table of Contents]]__TOC__~~

@@ Line 25: / Line 25: @@
 * [[Log Forging]]
 * [[Least Privilege Violation]]
 ==Related [[Controls]]==

@@ Line 10: / Line 10: @@
 ==Description==
-The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevalent control in both the accounting and IT communities. The goal is to eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different from normal users. In general, administrators should not be users of the application.
+The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevalent control in both the accounting and IT communities. The goal is to eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles, fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different from normal users. In general, administrators should not be users of the application.
 ==Examples==

← Older revision		Revision as of 19:11, 5 September 2008
Line 2:		Line 2:

	{{Template:Stub}}		{{Template:Stub}}
		+
		+	<br>
		+	[[Category:OWASP ASDR Project]]
		+	[[ASDR Table of Contents]]__TOC__
		+

	==Description==		==Description==

@@ Line 5: / Line 5: @@
 ==Description==
-The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevalent control in both the accounting and IT communities. The goal is to eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.
+The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevalent control in both the accounting and IT communities. The goal is to eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different from normal users. In general, administrators should not be users of the application.
 ==Examples==

← Older revision		Revision as of 00:43, 17 June 2008
Line 26:		Line 26:
	==Related [[Controls]]==		==Related [[Controls]]==

−	* [[~~Controls 1~~]]	+	* [[Access control]]
		+	* [[Authorization]]

@@ Line 3: / Line 3: @@
 {{Template:Stub}}
-==Overview==
+==Description==
-A key fraud control is separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived.
+The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevelant control in both the accounting and IT communities. The goal is the eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.
-For example, an administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.
+==Examples==
 [[Category:Principle]]