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
Thanks, James 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
