This message was deleted.

Being able to roll-up repeated alert is def a good idea, and I believe is actiually a feature request in the queue.

Alert: The Orts in namespace MORSELS were FUBARed; this alert repeated nn times over the last tt minutes

Hey @quaint-candle-18606, I am not the OP but, I would also like to have related events grouped inside NeuVector. The first event could create an alert with a link to the grouped collection of events. Following events, should generate an alert only once in a while (say after 30 minutes ongoing activity in that collection). That goes beyond what you mention with roll-ups. The idea is, that related events happen because someone needs to access pods, do some special maintenance which are not "normal", like entering the container or copying files for analysis, etc. Or, maybe a simple solution, having a way to set 'downtime' for maintenance windows to disable all alerts and possible also all enforcing. @clever-analyst-3023 as a workaround, I disable actions (alerts) in the cluster when false positives are expected to happen.

are we talking about a.

Notifications… Security Events

or b.

Policy… Response Rules

?

I don't know about the OP, but I was talking about "Policy->Response Rules" which trigger messages to Slack in my case

gotcha

The security events log, is interesting to look at, but I would be confused if things are not ordered by timestamp.

totally agree. best-practice is to feed security events to a siem like datadog, splunk, etc.

Yes, we do not have that (yet) 😉

in the short term. if you know you’re going to be triggering a lot of response rules, proactively disable that rule.

I am only setting up response rules for security events. After a few weeks of fine tuning, it is quiet. But when I go and start a pod with 'psql' to do some database work, it fires like mad 😉 In other words, it works as expected. This doesn't happen often, so we just live with the construction work noise from time to time. A bigger company might have problems with this approach but for small shops it is not a big deal.

i’d say in a scenario like that, you’d be doing that construction work in a dev/test cluster where there are no response rules. obv, “”best practice” and all. 😉

So no siem so far, security is in the hands of the same person doing the actual work (me).

this has testing on prod vibes. 😆

Yes, that would be a nice feature to have (with a specified ending time, so it's not forgotten). It should have a big red warning sign on the Dashboard - SOME SERVICES ARE IN MAINTENANCE MODE, or something like that.

and then log THAT “Alert: Peter set the following groups to maintenance mode for 30 minutes”

Yes, perfekt idea. The idea of NV is not to make work harder, but have the application run safer when nobody is looking.

bingo

I wouldn't want to set the whole NV to maintenance (normally), but a namespace or a single POD would be sufficient

i would still give you the line: Do this work in a test environment. Send the tested stuff to a prod environment. 🫡

At the moment, when I do not forget about it, I could do this with the 'discover' mode, but I rather would like to have a temporary Maintenance/ignore mode.

right. You don’t want it learning Bad Things™

Well, also not want to audit and then remove all the tempoary rules.

i can tell you that many folks will tell you to stop asking to solve a problem you shouldn’t be creating in the first place. 😄

If we had no security problems, we wouldn't need NV... 🙂

the real problem is humans. 😄

Yes, and complexity. Tell it your favorite AI.

that may be even worse. 🙃

That's fine with me. If the cat is triggering your alarm, you can as well turn it off. If you cannot turn it of, you may have to kill the cat 😞

and I’d also add an argument in favor of this: any group in that “maintenance” mode is in the same state it was before neuvector was ever installed. If giving people this option, even if its OMG not best practice, makes it easier for them to adopt neuvector then so be it.

Yes, agreed. Change needs time. And priority might be elsewere anyway.

bingo

Good doctor 😉

he really was

Actually, we were not testing in prod, but troubleshoot some issue with the database (remove some stale entries after an upgrade). We did it on the test system - in prod we will do the same, but then we will know exactly what to change. NV is new for us and we have to learn how to do it properly without triggering alarms. Anyway, NV will help us 99% of the time to catch bad things happening (but so far nothing happend, which is pleasantly boring ), and annoy us 1% of the time with false alarms.🙉

and squelching that 1% down is def a worthy goal 🤜 🤛