You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an analyst, I may use SOC to find a log of interest and then choose the Correlate option to find other related logs. Currently, this uses the user's default time range in Hunt. For example, suppose I'm looking at an alert that occurred in the last 24 hours and choose the Correlate option. I'm then taken to Hunt and if my default time range is 7 days, it's quite likely that other non-related logs will display since given a large enough time range there will be other connections that have the same network tuple. If the Correlate option could specify a time range then that could help avoid those non-related logs. Consider a time range around the timestamp of the original log that accounts for some possible drift in timestamps. At minimum, the time range should be one hour before the original timestamp to one hour after the original timestamp. It's possible that users are sending logs from external devices that are not using UTC so we might want more than that two hour range but the maximum would be 24 hours before the original timestamp to 24 hours after the original timestamp.
The text was updated successfully, but these errors were encountered:
As an analyst, I may use SOC to find a log of interest and then choose the Correlate option to find other related logs. Currently, this uses the user's default time range in Hunt. For example, suppose I'm looking at an alert that occurred in the last 24 hours and choose the Correlate option. I'm then taken to Hunt and if my default time range is 7 days, it's quite likely that other non-related logs will display since given a large enough time range there will be other connections that have the same network tuple. If the Correlate option could specify a time range then that could help avoid those non-related logs. Consider a time range around the timestamp of the original log that accounts for some possible drift in timestamps. At minimum, the time range should be one hour before the original timestamp to one hour after the original timestamp. It's possible that users are sending logs from external devices that are not using UTC so we might want more than that two hour range but the maximum would be 24 hours before the original timestamp to 24 hours after the original timestamp.
The text was updated successfully, but these errors were encountered: