You may want to try rebuilding the Receiver DB as mentioned below in point 4.
It seems you have already verified the time of the Windows devices. Have you verified the timestamp of the logs sent by the Windows devices like if it is a DNS log, we can open the dns.log file & verify the timestamp of the logs.
The presence of a single event from the past can skew the time delta for the particular data source in the Receiver DB.
Some times time delta issues occur due to old data being sent from the individual devices. Also we may need to verify the timestamp format set on the ESM.
Usually the timestamp format set on the ESM in the extreme right hand side.
You will be able to see the time zone & date format on the ESM, when you click the down arrow button next to the NGCP user>Select User Settings> Time zone & date format.
By default the timezone set on the SIEM devices are in UTC format. You can verify this on the CLI by using the 'date' command.
It would be best advisable to click on the 'Sync receiver clock' button in the ERC properties page so that the time of the ERC is in sync with the ESM.
Common issues for time delta include:
1) Incorrect time zone set in the respective Datasource properties page of the ERC as compared to the ERC & ESM.
If the datasource is located in London, we have to mention the time zone in the Datasource properties page on the ERC as GMT otherwise it will lead to time delta issues.
Thus, if the NGCP user in the ESM is configured to be in IST timezone, there will be a difference between 5 hours & 30 minutes for the events from the datasource in the ESM GUI which is expected.
2) Improper timezone & date format set on the Datasource.
On the SIEM, the time format will be in mm:dd:yyyy format, whereas on the actual device the time format may be dd:mm:yyyy there by creating a time delta due to the difference between mm:dd:yyyy & dd:mm:yyyy format.
A typical example would be 12/03/2020 & 03/12/2020.
SIEM would read the date as 3rd December 2020 due to the mm:dd:yyyy format whereas the actual event sent by the Datasource would be from March 12th, 2020.
3) Events from the future or past say 2189 or 1960 being sent by the Datasource.
We can check this by checking the packet tab of the Events from the respective Datasource on the ESM GUI & there by checking the timestamp when the packet was sent.
We can verify the first time & last time of the respective event from the Datasource in the ESM GUI.
We can also use the streaming viewer option on the ESM GUI to check the timestamp of the events that are being parsed for the respective datasource.
Also, If we check the event & packet table of the ERC DB for the particular IPSID we may be able to find if there are events from the future or past. Technical Support may be able to assist you with this.
4) Corrupt event & packet table in the ERC DB.
Sometimes the Event & Packet table of the Receiver database may be corrupt leading to time delta issues. A McAfee Technical Support engineer may be able to perform a forced rebuild of the last 2 partitions of the event & packet table of the Receiver DB after stopping the services on the ERC which may rectify the issue.
If the time delta is 2780000 minutes, we can calculate by converting it into days by dividing the value by 60 which converts the minutes into hours. We can further divide the value in hours by 24 thereby converting it into days. This value can be further be divided by 30 thereby converting it into months.If needed we can also divide further by 12 thereby converting the value in years.
In this case 2780000 minutes corresponds to 5 years and 3 month approximately. Thus we can check the events from the Datasource as per the point mentioned in item 2 above if there were events coming form the Datasource approximately 5 years in the past or in the future.
We do not show negative values for Time Delta anymore.
Prashanth B Pillai
McAfee Technical Support
Customer Success Group