Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Stale security event / Windows firewall reporting

Brass Contributor

Wondering if anyone has a solution they are happy with for monitoring stale security events and Windows firewall logs.  Not heartbeats or latest general response, but the specific event/log collections to assure active collection from both sources.  Could do something like "If a recent heartbeat received in the last "x" time, but no security or firewall events collected (separately) within "y" time, then report the computer."  Not sure how best to address normal computer downtime when monitoring PCs.  If a PC has been off all weekend, then would likely trigger a false alarm Monday morning due to the log ingestion delay.  Could extend "y" to be longer than the normal PC downtime scenarios, but wondered if anyone already had a more elegant solution in place?  Thx!

1 Reply
best response confirmed by glenmcleroy (Brass Contributor)
Solution

Hi @glenmcleroy , it is a very common issue with monitoring systems, not just security. End point inactivity tends to be variable. I think that the way to tackle that is to start from the response process. i.e. what will you do if you don't get events from an endpoint for a day? Probably nothing.

 

Therefore, I would suggest setting up a fix time period after which you start getting "worried" and check things. A week? Two weeks? A rule that fires if events have not been observed for that period would be a good solution. You can have a playbook triggered that asks the user if things are OK and closes the incident automatically if he confirms.

 

Lastly, you will probably need a white list that will prevent triggering on known unresponsive computers. We will publish a blog on how to do that shortly. 

1 best response

Accepted Solutions
best response confirmed by glenmcleroy (Brass Contributor)
Solution

Hi @glenmcleroy , it is a very common issue with monitoring systems, not just security. End point inactivity tends to be variable. I think that the way to tackle that is to start from the response process. i.e. what will you do if you don't get events from an endpoint for a day? Probably nothing.

 

Therefore, I would suggest setting up a fix time period after which you start getting "worried" and check things. A week? Two weeks? A rule that fires if events have not been observed for that period would be a good solution. You can have a playbook triggered that asks the user if things are OK and closes the incident automatically if he confirms.

 

Lastly, you will probably need a white list that will prevent triggering on known unresponsive computers. We will publish a blog on how to do that shortly. 

View solution in original post