Sensors generate events with an ID unique to them. Sensors forward the events to both Managers in an MDR deployment to provide high availability and no loss of events. These events can come in any order from multiple Sensors connected to the individual Managers and hence, the association of UUID assigned at the Manager level to the individual events are potentially different between Managers. So, you cannot rely on UUID as a unique identifier to associate with events across Managers in an MDR configuration.
Since the Sensors send the events to both the Managers, events are duplicated across the Managers. When a Manager is temporarily down, and comes back up, the events that were not received during the downtime are not re-sent by the Sensors. There is an MDR mechanism to synchronize the missing events with the peer Manager. This synchronizes the missing events from the last 24 hours to a maximum of 10,000 events between the Managers. So, the only ID that is unique across both managers is the one generated by the Sensor itself. The Sensor-generated IDs are in monotonically increasing order. This imposes effort on the part of the SIEM products to de-duplicate events between Managers.
There is a new column added in iv_alert table for Sensor-generated ids. It is called SensorAlertUUID.
The current suggestions are:
- Access the database using the UUID to look for newer events.
- Look for events on a per Sensor basis with the SensorAlertUUID.
- For the most part, it is sufficient to consume events from one of the Manager’s database tables.
- If there is a jump in sensorAlertUUID for a Sensor, do one of the following:
- Peer Manager can provide the missing events based on sensorAlertUUID.
- Wait for the automatic event synchronization that occurs between the peer Managers for the missing data.
- In case the peer Manager cannot come up with the misssing SensorAlertUUID, it is likely the case that due to a restart of the Sensor, the Sensor will skip on the current sequence of SensorAlertUUID and start from a new base which is monotonically higher than the previous event received.
- If there are no new events in the current Manager’s database table, the Manager may be down. Check the peer Manager for new events. If any, switch to the peer Manager’s table and continue reading the table.
- The UUID is still valid for accessing the variable data part stored in iv_alerts_data table for events from iv_alert table.
- NTBA alerts are not synched to the peer Manager; they only exist in the Manager that has been configured in the NTBA device.
There are new columns added for operating system and user information. These columns will have values only for certain events.
- sourceUserId – user ID in the host that belongs to the sourceIpaddr
- destinationUserId – user ID in the host that belongs to the targetIpAddr
- sourceOSId – Operating system ID in the host that belongs to the sourceIpaddr
- destinationOSId – Operating system ID in the host that belongs to the targetIpAddr