Test Role Definitions (OTG-IDENT-001) - Revision history

Tony Hsu HsiangChih: /* How to test */

2016-03-25T11:06:16Z

‎How to test

Jane O'Connor: Final edit

2014-05-14T14:25:22Z

Final edit

Andrew Muller at 16:40, 21 November 2013

2013-11-21T16:40:27Z

Andrew Muller at 13:25, 5 November 2013

2013-11-05T13:25:03Z

Andrew Muller at 13:48, 4 November 2013

2013-11-04T13:48:57Z

Andrew Muller at 14:30, 28 July 2013

2013-07-28T14:30:59Z

Andrew Muller: Created page with "== Summary == It is common amongst modern enterprises to define system roles to manage users and authorization to system resources. == Test objectives == Validate the syst..."

2013-07-28T14:19:29Z

Created page with "== Summary == It is common amongst modern enterprises to define system roles to manage users and authorization to system resources. == Test objectives == Validate the syst..."

New page

== Summary ==

It is common amongst modern enterprises to define system roles to manage users and authorization to system resources.

== Test objectives ==

Validate the system roles defined within the application sufficiently define and separate each system and business role

== How to test ==

=== Example ===

== Tools ==

== References ==

[http://csrc.nist.gov/groups/SNS/rbac/standards.html Role engineering and RBAC standards]

== Remediation ==

@@ Line 18: / Line 18: @@
-=== Example ===
+=== Example 1===
 {| class="wikitable"
@@ Line 32: / Line 32: @@
 |}
 A real world example of role definitions can be found in the WordPress roles documentation [http://codex.wordpress.org/Roles_and_Capabilities]. WordPress has six default roles ranging from Super Admin to a Subscriber.
 == Tools ==

@@ Line 3: / Line 3: @@
 == Summary ==
-It is common amongst modern enterprises to define system roles to manage users and authorization to system resources. In most system implementations it is expected that at least two roles exist: administrator and regular user. The first representing a role that permits access to privileged and sensitive functionality and information, the second representing a role that permits access to regular business functionality and information. Well developed roles should align with business processes which are supported by the application. It is important to remember that cold, hard authorisation isn't the only way in which to manage access to system objects. In more trusted environments where confidentiality is not critical, softer controls such as application workflow and audit logging can support data integrity requirements while not restricting user access to functionality or creating complex role structures that are difficult to manage. Its important to consider the Goldilocks principle when role engineering, in that defining too few, broad roles (thereby exposing access to functionality users don't require) is as bad as too many, tightly tailored roles (thereby restricting access to functionality users do require).
+It is common in modern enterprises to define system roles to manage users and authorization to system resources. In most system implementations it is expected that at least two roles exist, administrators and regular users. The first representing a role that permits access to privileged and sensitive functionality and information, the second representing a role that permits access to regular business functionality and information. Well developed roles should align with business processes which are supported by the application.
 == Test objectives ==
 Validate the system roles defined within the application sufficiently define and separate each system and business role to manage appropriate access to system functionality and information.
 == How to test ==
-Either with or without the help of the system developers/configurators, develop an role vs. permission matrix. The matrix should enumerate all the roles that can be provisioned and explore the permissions that are allowed to be applied to which objects including any constraints. If a matrix is provided with the application it should be validated by the tester, if it doesn't exist, the tester should generate it and determine whether the matrix satisfies the desired access policy for the application.
+Either with or without the help of the system developers or administrators, develop an role versus permission matrix. The matrix should enumerate all the roles that can be provisioned and explore the permissions that are allowed to be applied to the objects including any constraints. If a matrix is provided with the application it should be validated by the tester, if it doesn't exist, the tester should generate it and determine whether the matrix satisfies the desired access policy for the application.
 === Example ===
@@ Line 27: / Line 32: @@
 |}
-A real world example of role definitions can be found in the Wordpress roles documentation [http://codex.wordpress.org/Roles_and_Capabilities]. Wordpress has six default roles ranging from Super Admin to a Subscriber.
+A real world example of role definitions can be found in the WordPress roles documentation [http://codex.wordpress.org/Roles_and_Capabilities]. WordPress has six default roles ranging from Super Admin to a Subscriber.
 == Tools ==
-While the most thorough and accurate approach to completing this test is to conduct it manually, spidering tools [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsSpider] are also useful. Logon with each role in turn and spider the application (don't forget to exclude the logout link from the spidering).
+While the most thorough and accurate approach to completing this test is to conduct it manually, spidering tools [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsSpider] are also useful. Log on with each role in turn and spider the application (don't forget to exclude the logout link from the spidering).
 == References ==
@@ Line 38: / Line 45: @@
 [http://csrc.nist.gov/groups/SNS/rbac/standards.html Role engineering and RBAC standards]
 == Remediation ==
-Role Engineering
+Remediation of the issues can take the following forms:
-Separation of Duties
+*Role Engineering

← Older revision		Revision as of 16:40, 21 November 2013
Line 1:		Line 1:
		+	{{Template:OWASP Testing Guide v4}}
		+
	== Summary ==		== Summary ==

@@ Line 24: / Line 24: @@
 | Customer || Read || Customer record || Only own record
 |}
 == Tools ==