I think there may be gaps in doing it with the profiler.  You can record stats 
and counts of different alert types, and maybe even alert ids, but you can't 
cross-correlate these IDs to the alert body.  At least not in the profiler.  I 
was thinking about emailing something that looks like a zeppelin report.  You 
would run it in a cron, export to PDF, and send that out as a summary.  It can 
be a simple list of alerts that match your rule, or it can have aggregations, 
graphics, metrics, KPI screens, etc.  That would be the feature that I would 
want to discuss and flesh out


13.12.2017, 14:26, "Simon Elliston Ball" <si...@simonellistonball.com>:
> We can already do that with profiles I would have thought. Create a profile 
> that only picks alerts and then base your emails only from the alert events 
> produced by that profile. Would that create the right batching mechanism (at 
> a cost of possible higher latency than you might get with a more specific 
> alert batcher?)
> Simon
>>  On 13 Dec 2017, at 21:23, James Sirota <jsir...@apache.org> wrote:
>>  I agree with Simon. If you email each alert individually you will be 
>> overwhelmed. I think a better idea would be to email alert summaries 
>> periodically, which is more manageable. This is probably a feature worthy of 
>> consideration for Metron.
>>  13.12.2017, 12:19, "Simon Elliston Ball" <si...@simonellistonball.com>:
>>>  Metron generates alerts onto a Kafka queue, which can be used to integrate 
>>> with Alert management tools, usually some sort of existing alert 
>>> aggregation tool.
>>>  An alternative approach common with this is to have a tool like Apache 
>>> NiFi attach to the Metron alert feed and send email.
>>>  The solution here would be to have Metron generate alerts (by adding the 
>>> is_alert: true flag in the enrichment process) and possibly other flags 
>>> like alert_email for example, and then have NiFi use ConsumeKafka and then 
>>> filter out the alert only messages in NiFi to use the PutEmail processor 
>>> (probably with a ControlRate before it too).
>>>  Something I would caution is that email is not a great way to manage or 
>>> send alerts at the volume likely to occur in network monitoring tools. A 
>>> spike in network traffic can lead to a very large number of emails, which 
>>> tends to then cause you bigger problems. As such we usually find people 
>>> want some sort of buffering or aggregation of alerts, hence the use of a an 
>>> alert management or ticketing solution in front.
>>>  Simon
>>>>   On 13 Dec 2017, at 19:06, Ahmed Shah <ahmeds...@cmail.carleton.ca> wrote:
>>>>   Hello,
>>>>   Just wondering if Metron has a feature to email alerts based on rules 
>>>> that a user defines.
>>>>   Example:
>>>>   Rule A: Email the user 1...@1.com whenever ip_src_addr=100.2.10.*
>>>>   Rule B: Email the user 1...@1.com whenever payload contains "critical"
>>>>   If not, does anyone have any recommendations on where to code these 
>>>> rules in the Metron stack that uses attributes from the GROK parser?
>>>>   -Ahmed
>>>>   _______________________________________________________________
>>>>   Ahmed Shah (PMP, M. Eng.)
>>>>   Cybersecurity Analyst & Developer
>>>>   GCR - Cybersecurity Operations Center
>>>>   Carleton University - cugcr.com<https://cugcr.com/tiki/lce/index.php>
>>  -------------------
>>  Thank you,
>>  James Sirota
>>  PMC- Apache Metron
>>  jsirota AT apache DOT org

Thank you,

James Sirota
PMC- Apache Metron
jsirota AT apache DOT org

Reply via email to