Administrative Interface - Revision history

Jmanico: Redirected page to Category:Access Control

2016-02-26T22:29:24Z

Redirected page to Category:Access Control

KirstenS: /* How to protect yourself */

2009-03-04T13:45:06Z

‎How to protect yourself

KirstenS: /* Best practices */

2009-03-04T13:19:21Z

‎Best practices

KirstenS: /* Best practices */

2009-03-04T13:18:47Z

‎Best practices

KirstenS: /* Objective */

2008-08-20T21:17:16Z

‎Objective

KirstenS at 17:27, 20 August 2008

2008-08-20T17:27:32Z

Jeff Williams at 10:50, 25 May 2006

2006-05-25T10:50:31Z

Weilin Zhong at 18:56, 22 May 2006

2006-05-22T18:56:11Z

Weilin Zhong at 17:00, 22 May 2006

2006-05-22T17:00:06Z

Weilin Zhong at 18:34, 18 May 2006

2006-05-18T18:34:16Z

New page

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

← Older revision		Revision as of 22:29, 26 February 2016
Line 1:		Line 1:
−	~~[[Guide Table of Contents\|Development Guide Table of Contents]]__TOC__~~	+	#REDIRECT [[Category:Access Control]]
−
−	~~==Objective ==~~
−
−	~~To ensure that:~~
−
−	* Administrator level functions are appropriately segregated from user activity
−
−	* Users cannot access or utilize administrator functionality
−
−	* Provide necessary audit and traceability of administrative functionality
−
−	~~==Environments Affected ==~~
−
−	~~All.~~
−
−	~~==Relevant COBIT Topics ==~~
−
−	~~PO4~~
−
−	* 4.08 Data and System ownership – requires separate operational and security administration
−
−	* 4.10 Segregation of duties
−
−	~~==Best practices ==~~
−
−	Administrative interfaces is one of the few controls within the Development Guide which is legally mandated – Sarbanes Oxley requires administrative functions to be segregated from normal functionality as it is a key fraud control. For organizations that have no need to comply with US law, ISO 17799 also strongly suggests that there is segregation of duties. It is obviously up to the designers to take into account the risk of not complying with SOX or ISO 17799.
−
−	* When designing applications, map out administrative functionality and ensure that appropriate access controls and auditing are in place.
−
−	* Consider processes – sometimes all that is required is to understand how users may be prevented from using a feature by simple lack of access.
−
−	* Help desk access is always a middle ground – they need access to assist customers, but they are not administrators.
−
−	* Carefully design help desk / moderator / customer support functionality around limited administration capability and segregated application or access.
−
−	This is not to say that administrators logging on as users to the primary application are not allowed, but when they do, they should be normal users. An example is a system administrator of a major e-commerce site who also buys or sells using the site.
−
−	~~==Administrators are not users ==~~
−
−	~~Administrators must be segregated from normal users.~~
−
−	~~===How to identify if you are vulnerable ===~~
−
−	* Log on to the application as an administrator.
−
−	* Can the administrator perform normal transactions or see the normal application?
−
−	* Can users perform administrative tasks or actions if they know the URL of the administration action?
−
−	* Does the administrative interface use the same database or middleware access (for example, database accounts or trusted internal paths?)
−
−	* In a high value system, can users access the system containing the administrative interface?
−
−	~~If yes to any question, the system is potentially vulnerable.~~
−
−	~~===How to protect yourself ===~~
−
−	* All systems should have separate applications for administrator and user access.
−
−	* High value systems should separate these systems to separate hosts, which may not be accessible to the wider Internet without access to management networks, such as via the use of a strongly authenticated VPN or from trusted network operations center.
−
−	~~==Authentication for high value systems ==~~
−
−	Administrative interfaces by their nature are dangerous to the health of the overall system. Administrative features may include direct SQL queries, loading or backing up the database, directly querying the state of a trusted third party’s system.
−
−	~~===How to identify if you are vulnerable ===~~
−
−	~~If a high value system does not use strong authentication and encrypted channels to log on to the interface, the system may be vulnerable from eavesdropping, man in the middle, and replay attacks.~~
−
−	~~===How to protect yourself ===~~
−
−	~~For high value systems:~~
−
−	* Use a separate hardened management network for administrative access.
−
−	* Use strong authentication to log on, and re-authenticate major or dangerous transactions to prevent administrative phishing and session riding attacks.
−
−	* Use encryption (such as SSL encrypted web pages) to protect the confidentiality and integrity of the session.
−
−	~~==Further Reading ==~~
−
−	* Perfect example of why the admin and users should be separate:
−
−	~~<u>http://www.securityfocus.com/bid/10861/discuss</u>~~
−
−
−	~~[[Guide Table of Contents\|Development Guide Table of Contents]]~~
−	~~[[Category:OWASP_Guide_Project]]~~
−	~~[[Category:Deployment]]~~
−	[[Category:Access Control]]

@@ Line 73: / Line 73: @@
 For high value systems:
-* Use a separate hardened management network for administrative access
+* Use a separate hardened management network for administrative access.
 * Use strong authentication to log on, and re-authenticate major or dangerous transactions to prevent administrative phishing and session riding attacks.
 * Use encryption (such as SSL encrypted web pages) to protect the confidentiality and integrity of the session.
 ==Further Reading ==

@@ Line 29: / Line 29: @@
 * When designing applications, map out administrative functionality and ensure that appropriate access controls and auditing are in place.
-* Consider processes – sometimes all that is required is to understand how users may be prevented from using a feature by simple lack of access
+* Consider processes – sometimes all that is required is to understand how users may be prevented from using a feature by simple lack of access.
 * Help desk access is always a middle ground – they need access to assist customers, but they are not administrators.
-* Carefully design help desk / moderator  / customer support functionality around limited administration capability and segregated application or access
+* Carefully design help desk / moderator  / customer support functionality around limited administration capability and segregated application or access.
 This is not to say that administrators logging on as users to the primary application are not allowed, but when they do, they should be normal users. An example is a system administrator of a major e-commerce site who also buys or sells using the site.

@@ Line 25: / Line 25: @@
 ==Best practices ==
-Administrative interfaces is one of the  few controls within the Guide which is legally mandated – Sarbanes Oxley requires administrative functions to be segregated from normal functionality as it is a key fraud control. For organizations that have no need to comply with US law, ISO 17799 also strongly suggests that there is segregation of duties. It is obviously up to the designers to take into account the risk of not complying with SOX or ISO 17799.
+Administrative interfaces is one of the  few controls within the Development Guide which is legally mandated – Sarbanes Oxley requires administrative functions to be segregated from normal functionality as it is a key fraud control. For organizations that have no need to comply with US law, ISO 17799 also strongly suggests that there is segregation of duties. It is obviously up to the designers to take into account the risk of not complying with SOX or ISO 17799.
 * When designing applications, map out administrative functionality and ensure that appropriate access controls and auditing are in place.
@@ Line 35: / Line 35: @@
 * Carefully design help desk / moderator  / customer support functionality around limited administration capability and segregated application or access
 This is not to say that administrators logging on as users to the primary application are not allowed, but when they do, they should be normal users. An example is a system administrator of a major e-commerce site who also buys or sells using the site.
 ==Administrators are not users ==

@@ Line 3: / Line 3: @@
 ==Objective ==
-To ensure that
+To ensure that:
-* administrator level functions are appropriately segregated from user activity
+* Administrator level functions are appropriately segregated from user activity
 * Users cannot access or utilize administrator functionality

@@ Line 1: / Line 1: @@
-[[Guide Table of Contents]]__TOC__
+[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__
 ==Objective ==
@@ Line 86: / Line 86: @@
-[[Guide Table of Contents]]
+[[Guide Table of Contents|Development Guide Table of Contents]]
 [[Category:OWASP_Guide_Project]]
 [[Category:Deployment]]
 [[Category:Access Control]]

← Older revision		Revision as of 18:56, 22 May 2006
Line 88:		Line 88:
	[[Guide Table of Contents]]		[[Guide Table of Contents]]
	[[Category:OWASP_Guide_Project]]		[[Category:OWASP_Guide_Project]]
		+	[[Category:Threat]]
		+	[[Category:Deployment]]
		+	[[Category:Access Control]]

← Older revision		Revision as of 17:00, 22 May 2006
Line 1:		Line 1:
		+	[[Guide Table of Contents]]__TOC__
		+
		+	==Objective ==
		+
		+	To ensure that
		+
		+	* administrator level functions are appropriately segregated from user activity
		+
		+	* Users cannot access or utilize administrator functionality
		+
		+	* Provide necessary audit and traceability of administrative functionality
		+
		+	==Environments Affected ==
		+
		+	All.
		+
		+	==Relevant COBIT Topics ==
		+
		+	PO4
		+
		+	* 4.08 Data and System ownership – requires separate operational and security administration
		+
		+	* 4.10 Segregation of duties
		+
		+	==Best practices ==
		+
		+	Administrative interfaces is one of the few controls within the Guide which is legally mandated – Sarbanes Oxley requires administrative functions to be segregated from normal functionality as it is a key fraud control. For organizations that have no need to comply with US law, ISO 17799 also strongly suggests that there is segregation of duties. It is obviously up to the designers to take into account the risk of not complying with SOX or ISO 17799.
		+
		+	* When designing applications, map out administrative functionality and ensure that appropriate access controls and auditing are in place.
		+
		+	* Consider processes – sometimes all that is required is to understand how users may be prevented from using a feature by simple lack of access
		+
		+	* Help desk access is always a middle ground – they need access to assist customers, but they are not administrators.
		+
		+	* Carefully design help desk / moderator / customer support functionality around limited administration capability and segregated application or access
		+
		+	This is not to say that administrators logging on as users to the primary application are not allowed, but when they do, they should be normal users. An example is a system administrator of a major e-commerce site who also buys or sells using the site.
		+
		+	==Administrators are not users ==
		+
		+	Administrators must be segregated from normal users.
		+
		+	===How to identify if you are vulnerable ===
		+
		+	* Log on to the application as an administrator.
		+
		+	* Can the administrator perform normal transactions or see the normal application?
		+
		+	* Can users perform administrative tasks or actions if they know the URL of the administration action?
		+
		+	* Does the administrative interface use the same database or middleware access (for example, database accounts or trusted internal paths?)
		+
		+	* In a high value system, can users access the system containing the administrative interface?
		+
		+	If yes to any question, the system is potentially vulnerable.
		+
		+	===How to protect yourself ===
		+
		+	* All systems should have separate applications for administrator and user access.
		+
		+	* High value systems should separate these systems to separate hosts, which may not be accessible to the wider Internet without access to management networks, such as via the use of a strongly authenticated VPN or from trusted network operations center.
		+
		+	==Authentication for high value systems ==
		+
		+	Administrative interfaces by their nature are dangerous to the health of the overall system. Administrative features may include direct SQL queries, loading or backing up the database, directly querying the state of a trusted third party’s system.
		+
		+	===How to identify if you are vulnerable ===
		+
		+	If a high value system does not use strong authentication and encrypted channels to log on to the interface, the system may be vulnerable from eavesdropping, man in the middle, and replay attacks.
		+
		+	===How to protect yourself ===
		+
		+	For high value systems:
		+
		+	* Use a separate hardened management network for administrative access
		+
		+	* Use strong authentication to log on, and re-authenticate major or dangerous transactions to prevent administrative phishing and session riding attacks.
		+
		+	* Use encryption (such as SSL encrypted web pages) to protect the confidentiality and integrity of the session.
		+
		+	==Further Reading ==
		+
		+	* Perfect example of why the admin and users should be separate:
		+
		+	<u>http://www.securityfocus.com/bid/10861/discuss</u>


	[[Guide Table of Contents]]		[[Guide Table of Contents]]
	[[Category:OWASP_Guide_Project]]		[[Category:OWASP_Guide_Project]]