This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Intrusion Detection"
Line 5: | Line 5: | ||
Intrusion detection is an important countermeasure for most applications, especially client-server applications like web applications and web services. [[Logging]] is an important aspect of intrusion detection, but is best viewed as a way to record intrusion-related activity, not to determine what is an intrusion in the first place. The vast majority of applications do not detect attacks, but instead try their best to fulfill the attackers' requests. | Intrusion detection is an important countermeasure for most applications, especially client-server applications like web applications and web services. [[Logging]] is an important aspect of intrusion detection, but is best viewed as a way to record intrusion-related activity, not to determine what is an intrusion in the first place. The vast majority of applications do not detect attacks, but instead try their best to fulfill the attackers' requests. | ||
− | + | Lack of intrusion detection allows an attacker to attempt attacks until a successful one is identified. Intrusion detection allows the attack to be identified long before a successful attack is likely. It is not very difficult for a web application to identify some attack traffic. A simple rule-of-thumb is that if the traffic could not have reasonably been generated by a legitimate user of the application, it is almost certainly an attack. Once attacks are identified, then the application can respond appropriately. Typically, this means logging off the user, invalidating their account, and potentially recording information for the authorities. | |
There are three types of requests that an application might receive: | There are three types of requests that an application might receive: | ||
Line 13: | Line 13: | ||
The question for application developers is how to deal with these three categories. The safest rule is to assume that everything except legitimate traffic is an attack. However, this will probably create a lot of false alarms for users. So perhaps it is best to accept the requests that you are not sure about and log some extra information so that you can investigate it later. This is a policy decision that you should make during the requirements phase of the lifecycle. | The question for application developers is how to deal with these three categories. The safest rule is to assume that everything except legitimate traffic is an attack. However, this will probably create a lot of false alarms for users. So perhaps it is best to accept the requests that you are not sure about and log some extra information so that you can investigate it later. This is a policy decision that you should make during the requirements phase of the lifecycle. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Related Countermeasures== | ==Related Countermeasures== |
Revision as of 18:18, 23 April 2010
This is a control. To view all control, please see the Control Category page.
Description
Intrusion detection is an important countermeasure for most applications, especially client-server applications like web applications and web services. Logging is an important aspect of intrusion detection, but is best viewed as a way to record intrusion-related activity, not to determine what is an intrusion in the first place. The vast majority of applications do not detect attacks, but instead try their best to fulfill the attackers' requests.
Lack of intrusion detection allows an attacker to attempt attacks until a successful one is identified. Intrusion detection allows the attack to be identified long before a successful attack is likely. It is not very difficult for a web application to identify some attack traffic. A simple rule-of-thumb is that if the traffic could not have reasonably been generated by a legitimate user of the application, it is almost certainly an attack. Once attacks are identified, then the application can respond appropriately. Typically, this means logging off the user, invalidating their account, and potentially recording information for the authorities.
There are three types of requests that an application might receive:
- Almost certainly an attack
- Not sure whether it an attack or not
- Almost certainly legitimate input
The question for application developers is how to deal with these three categories. The safest rule is to assume that everything except legitimate traffic is an attack. However, this will probably create a lot of false alarms for users. So perhaps it is best to accept the requests that you are not sure about and log some extra information so that you can investigate it later. This is a policy decision that you should make during the requirements phase of the lifecycle.