Detect intrusions - Revision history

KirstenS at 12:28, 7 April 2009

2009-04-07T12:28:39Z

KirstenS: /* Related Controls */

2008-09-09T22:31:59Z

‎Related Controls

KirstenS: /* Related Vulnerabilities */

2008-09-09T22:31:02Z

‎Related Vulnerabilities

KirstenS at 18:41, 5 September 2008

2008-09-05T18:41:35Z

KirstenS: /* References */

2008-09-05T18:40:59Z

‎References

KirstenS: /* References */

2008-09-05T18:40:35Z

‎References

Cduffey346 at 00:20, 28 May 2008

2008-05-28T00:20:44Z

Jeff Williams at 12:27, 4 December 2006

2006-12-04T12:27:08Z

Sinonada: /* Categories */

2006-12-04T02:59:40Z

‎Categories

Sinonada: /* Categories */

2006-12-04T02:58:28Z

‎Categories

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

@@ Line 46: / Line 46: @@
 * [[Controls 1]]
+TBD
 ==References==

@@ Line 40: / Line 40: @@
 * [[Vulnerability 1]]
+TBD
 ==Related [[Controls]]==

← Older revision		Revision as of 18:41, 5 September 2008
Line 1:		Line 1:
	{{Template:Principle}}		{{Template:Principle}}
		+	<br>
		+	[[Category:OWASP ASDR Project]]
		+	[[ASDR Table of Contents]]__TOC__
		+

	==Description==		==Description==

@@ Line 45: / Line 45: @@
 ==References==
-* [[ESAPI_Secure_Coding_Guideline#Logging_and_Intrusion_Detection ESAPI Logging and Intrusion Detection]]
+* [[ESAPI_Secure_Coding_Guideline#Logging_and_Intrusion_Detection|ESAPI Logging and Intrusion Detection]]
 ==Categories==
 [[Category:Principle]]

@@ Line 1: / Line 1: @@
 {{Template:Principle}}
-Detecting intrusions is important because otherwise you give the attacker unlimited time to perfect an attack. If you detect intrusions perfectly, then an attacker will only get one attempt before he is detected and prevented from launching more attacks. Remember, if you receive a request that a legitimate user could not have generated - it is an attack and you should respond appropriately.
+==Description==
-Don't rely on other technologies to detect intrusions. Your code is the only component of the system that has enough information to truly detect attacks. Nothing else will know what parameters are valid, what actions the user is allowed to select, etc...  You must build this into your application.
+Detecting intrusions requires three elements:
-Logging is an important part of detecting intrusions, although there are many other pieces as well. You should log all security relevant information. Perhaps you can detect a problem by reviewing the logs that you couldn't detect at runtime. But you must log enough information. In particular, all use of security mechanisms should be logged, with enough information to help track down the offender.
+You should log all security relevant information. Perhaps you can detect a problem by reviewing the logs that you couldn't detect at runtime. But you must log enough information. In particular, all use of security mechanisms should be logged, with enough information to help track down the offender. Additionally, the logging functionality in the application should also provide a method of managing the logged information. If the security analyst is unable to parse through the event logs to determine which events are actionable, then logging events provide little to no value.
-If you do this, then someday when your application/site is down/hacked you can trace the culprit and check what went wrong. If the user uses an anonymizing proxy, having good logs will still help as "what happened" is logged and the exploit can be fixed more easily.
+Detecting intrusions is important because otherwise you give the attacker unlimited time to perfect an attack. If you detect intrusions perfectly, then an attacker will only get one attempt before he is detected and prevented from launching more attacks. Remember, if you receive a request that a legitimate user could not have generated - it is an attack and you should respond appropriately. Logging provides a forensic function for your application/site. If it is brought down or hacked, you can trace the culprit and check what went wrong. If the user uses an anonymizing proxy, having good logs will still help as "what happened" is logged and the exploit can be fixed more easily.
 ==Categories==
 [[Category:Principle]]

@@ Line 9: / Line 9: @@
 '''Log All user access (IP, Username, Time, web requests, etc.).'''
-If you do this, then someday when your application /site is down/hacked you can trace the culprit and check what went wrong.
+If you do this, then someday when your application/site is down/hacked you can trace the culprit and check what went wrong.
-You may ask , if the user uses an proxy , Though it will help. As "what happened" is logged and the exploit can be fixed more easily.
+You may ask, if the user uses a proxy, though it will help. As "what happened" is logged and the exploit can be fixed more easily.