Hi all,<br><br>Following on from what Jeremy raised regarding knowing what happened after an alert fired - given that we need to see the subsequent packets in a stream (after the triggering one(s)) to determine if an exploit was successful, in some situations couldn't that be automated by the IDS? Like extending the flowbits function of snort to not just detect an attempted exploit, but evaluate the victim response to determine if the attack was successful or not. Or perhaps at least confirming that it failed, and thus issuing a lower severity alert.<br>
<br>For example, a web attack is detected, the equivalent of a flowbit for 'web-attack' is set, and the ids checks for a 404 (or similar) response - if so, it suggests the attack was unsuccesful. If it sees a 200 OK server response, the alert has higher severity.<br>
<br>Or watching for succesful brute force attacks - easy for a signature to detect many attempts to login in a short space of time, perhaps detect many failed attempts in a short space of time - of more interest is many failed and then successful  -okay, perhaps this belongs in the realm of a correlation SIEM app, but a thought.<br>
<br>Mainly, I'm thinking why not offload some of the analyst work of investigating network traffic associated with an ids signature match onto the ids itself. At least as far as server response goes - most signatures are built to answer the question - 'is this traffic malicious or not?' Why not build them so they also try to answer - 'and was it successful or not?'<br>
<br>Cheers,<br>Christian<br><a href="mailto:discussion%40openinfosecfoundation.org?Subject=%5BDiscussion%5D%20Features%20suggestion&In-Reply-To=" title="[Discussion] Features suggestion">
       </a>