[Oisf-users] [Emerging-Sigs] More "Unknown type of Driveby Sigs"

[Nathan]

On 11/27/11 11:31, Martin Holste wrote:
> I agree:  You would need to make the flowbits set by source or
> destination with a fairly high count, and in the end, I think you'd
> still end up with a lot of garbage JPG/GIF/PDF/etc having flowbits set
> that would be sent along with the exploit kit alert when the noalert
> would be toggled, so I think the practical value would be far less
> than the theoretical value, especially in NAT'ed environments.

Respectfully, we also have to be weary of the setting of flowbits superfluously
for latter advantageous situations due to performance degradation.  We also must
stay away from flowbit-only checks as these are severely performance degrading.
 I don't mean to say this authoritatively, I am speaking more to an empirical side.

I'm not insinuating that Kevin has suggested the above, rather I'm just saying
that flowbits aren't a cure-all.  Why set a flowbit for a PDF download only to
later check it's content or etc as being malicious.  Why not combine these two
operations into something that can result in a high-confidence event, as permitted?

Joel, something of high value and SIEM-like has been taking an action and/or
generating a separate alert (that could invoke a high-confidence action) on:

(( multiple events ( src ip || dst ip )) || ( singular event ( multiple src ip
|| multiple dst ip )))

that has fired X number of alerts in Y seconds, where 5 events by 300 seconds
tends to be valuable.  This has been extremely valuable in enforcing a
high-confidence act like a firewall block while not being tied to a singular
event.  Caveat is a bad rule can enact undesired change so some type
exclusions/class exclusions and QA is necessary.

I cobbled the above together in Perl and it's been a highly useful tool,
inclusion into Snort or Suricata could deem valuable depending on use case.

Thanks,
Nathan