Security Compliance
Checkpoint Firewall Manager information not showing correctly on SEM
Checkpoint Firewall Manager information not showing correctly on SEM. The information appears on the Monitor > filters section as arriving with a new event every minute, however in the ndepth search, this does not appear to be the case. This article discusses the possible reason why.
First published date
Last published date
Overview
Checkpoint Firewall Manager information is not showing correctly in Security Event Manager (formerly Log & Event Manager).
The information appears on the Monitor > Filters section as arriving with a new event every minute. However, in the ndepth search this does not appear to be the case.
If Checkpoint Firewall Manager has been setup to gather logs from other firewalls in the environment and send the logs to SEM, this issue will occur. The Checkpoint Firewall Manager is sending information straight to SEM, but not in any particular order.
The following example scenario shows that there is a log entry sent by a checkpoint firewall to the checkpoint firewall manager, that has the following timeframe inside its log entry: 14:15 17th of March 2016 xxxxxxxxxx
- Other Checkpoint Firewalls > send logs to > Checkpoint Firewall Manager
- Checkpoint Firewall Manager > sends these logs to (in no particular order) (in this example, it sends the logs at 16:15 17th of March 2016) > SEM
- SEM > processes the logs themselves through it's configured connectors. > translates the information, and saves them to it's database. (In this example, it places the log entry accordingly with what timeframe is mentioned in the log itself, so on 17th of March 2016, 14:15)
- SEM > shows in the SEM console Monitor section, what time it has received the logs. (In this example, SEM received the logs at 16:15 17th of March 2016, so in the insertion time, this is the time that will be displayed)
Following this scenario, if you search in nDepth for the logs, in the timeframe 16:15 17th of March 2016, you will not see an event/log entry. This is because the log itself had a different timeframe. What you should be looking for in the nDepth search is: 14:15 17th of March 2016.