[Oisf-users] Alternatives to ET Pro?

[Brandon Lattin]

Absolutely. Let me chat with one of my guys and we'll work out an automated
method.

We can modify our testing frequency and window if it's helpful as well.

I'll get back to you within the week with something.

On Tue, Feb 9, 2016 at 12:49 PM, Will Metcalf <william.metcalf at gmail.com>
wrote:

> >We've been happy with ET for year, but we have noticed an increase in the
> number of rules we've had to disable due to unreasonably high percentages
> of CPU time. We do profile on a large sample set (~7Gbps for 10 minutes)
> daily.
>
> Would you be willing to share these stats off list?  I would love to take
> a stab at trying to optimize the worst offenders, additionally I don't
> think there is any super sensitive information in the rule perf stats.
>
> Regards,
>
> Will
>
> On Tue, Feb 9, 2016 at 10:56 AM, Brandon Lattin <latt0050 at umn.edu> wrote:
>
>> We've been happy with ET for year, but we have noticed an increase in the
>> number of rules we've had to disable due to unreasonably high percentages
>> of CPU time. We do profile on a large sample set (~7Gbps for 10 minutes)
>> daily. I have no doubt that you guys do your best testing, but we have a
>> large network with a lot of students and researchers doing some very weird
>> things. We get that it's as much an art as it is a science.
>>
>> As for the price whispers I'm hearing from legal, I guess we'll let the
>> lawyers figure it out.
>>
>> On Tue, Feb 9, 2016 at 10:41 AM, Will Metcalf <william.metcalf at gmail.com>
>> wrote:
>>
>>> I'm sorry that you feel our rule quality has declined. We test rules for
>>> perf/fp's before they go out each day on a live sensor network and with a
>>> collection of QA pcaps. That said the straight poop is every network is a
>>> snowflake and determining performance impact of a rule in a specific
>>> network without a feedback loop is impossible, it's an educated guess at
>>> best. As a PRO customer you are more than welcome to open a support ticket.
>>> With additional info about your environment we can help try to tune the
>>> rule with you. Alternatively you can simply disable it, or look at using
>>> Lua to detect a multi-byte encoded xor'd executable although I doubt this
>>> will be any cheaper perf wise. Additionally I would be weary of relying on
>>> suri rule perf stats outside of single threaded mode during short runs to
>>> sample rule perf. In my experience they tend to be unreliable even with the
>>> same rules/networks across runs. Victor can correct me if I'm wrong but
>>> afaik they are unreliable in these modes as they include lock wait time
>>> which should level out over long runs.  BTW we have no plans to raise
>>> prices that I'm aware of :).
>>>
>>> Regards,
>>>
>>> Will
>>>
>>> On Tue, Feb 9, 2016 at 9:36 AM, Brandon Lattin <latt0050 at umn.edu> wrote:
>>>
>>>> I'm sure some of you are aware that Proofpoint has acquired Emerging
>>>> Threats.
>>>>
>>>> We've seen a decline (perhaps anecdotal) in rule quality - to the tune
>>>> of a single new rule (2815810) taking 49% of total CPU time. Additionally,
>>>> it would appear they are planning on raising prices.
>>>>
>>>> I'm curious if anyone is using an alternative to the ET Pro set.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Brandon Lattin
>>>> Security Analyst
>>>> University of Minnesota - University Information Security
>>>> Office: 612-626-6672
>>>>
>>>> _______________________________________________
>>>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>>> Site: http://suricata-ids.org | Support:
>>>> http://suricata-ids.org/support/
>>>> List:
>>>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>> Suricata User Conference November 9-11 in Washington, DC:
>>>> http://oisfevents.net
>>>>
>>>
>>>
>>
>>
>> --
>> Brandon Lattin
>> Security Analyst
>> University of Minnesota - University Information Security
>> Office: 612-626-6672
>>
>
>


-- 
Brandon Lattin
Security Analyst
University of Minnesota - University Information Security
Office: 612-626-6672
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160209/3f85f850/attachment-0002.html>