Problems with the time of my logs Google Chronicle SIEM

[erik314]

I have problems with my logs since they are ingesting in the SIEM with a schedule that is not appropriate, these logs have the correct schedule. I have verified this because it is ingesting in another SIEM and it sends them to me correctly, in Google Chronicle when modifying the location to UTC-6 does not match the information in my records, could you help me modify this or give suggestions on what to do?

[JeremyLand]

Since you are seeing a whole hour offset being applied it sounds like a timezone mapping issue.  Investigate the rawlog timestamp and the metadata.event_timestamp.

Is the rawlog in UTC or include a timezone offset? If not you may need to reconfigure the source or your ingest pipeline.

If the offset is included in the rawlog but not being parsed correctly, and you are using a default parser, open a case with GCP support and they'll work with the parser development team to get a fix implemented.

If you are using a custom parser (or feel adventurous and want to investigate how the default parser works) you'll want to use statedump() to investigate how the time is being extracted and potentially add or modify the date{} function that is setting your event time.  https://cloud.google.com/chronicle/docs/reference/parser-syntax#date_function

General troubleshooting guidance for other time related issues>

First things to check for most time related issues are the timestamp from the rawlog and 2 timestamps on the parsed event.

From the rawlog find the timestamp, take note of whether it includes a timezone or offset identifier.

metadata.ingestion_timestamp - This will indicate the time your log was ingested into the SIEM, If there is a large gap between the rawlog and ingestion timestamps it likely indicates an issue with your ingest pipeline and you should investigate how the logs are being generated at the source and all the steps they take before being picked up by a forwarder, the ingest api, or feeds.

metadata.event_timestamp - This indicates the time the parser extracted from the rawlog.  A large gap between the rawlog and the event timestamp generally indicate either a misconfigured timezone on the log source, or that the parser isn't interpreting the timestamp from your log properly.

[Surendrasumith]

I have noticed for few log sources that configured which correct time zone but even though some events showing almost 1.30 mints defence. I mean deference b/w event time stamp and ingested time stamp.So what we can do for this case ? Do we need to raise chronicle ticket to fix it if any pipeline issue or can you have any suggestions?