Checkpoint firewall - automatic log collection - recommended method ?

Copper Contributor

Hi - is there a recommended/supported method to achieve automatic Checkpoint firewall log collection ?

 

On the Checkpoint side it seems there are 2 main log export mechanisms.

1. CPLOGTOSYSLOG tool.

2. Log Exporter - Check Point Log Export tool.

 

I am getting the impression that cplogtosyslog is the preferred supported method from Microsoft side. However from Checkpoint side Log Exporter tool is their preferred method going forward. Any guidance or advice on how to get this to work would be appreciated ?

 

Thanks...

5 Replies

Hi Max,

 

Thanks for reaching out.

Few comments on that:

  1. The general answer depends on the log format that each of these tools exports. While I'm not familiar with the format exported by "Log Exporter", MCAS do support formats exported from CPLOGTOSYSLOG.
  2. If possible, please share the format provided by the "Log Exporter", to see whether are also supported out of the box or by MCAS custom log parser.
  3. Can you elaborate some more on the meaning of "Checkpoint side Log Exporter tool is their preferred method going forward"?

 

Thanks,

Danny.

Hi @Danny Kadyshevitch just wondering how this might play out?

 

From what we can see this was raised some time ago as well?

https://techcommunity.microsoft.com/t5/Microsoft-Cloud-App-Security/Cloud-App-Security-lack-of-integ...

 

We can see that just using the Snapshot tool we can take a "Smart Tracker" formatted download from the Checkpoint Firewall and then upload it into MCAS and it has plenty of detail, and yet looking thru the  details here: https://docs.microsoft.com/en-us/cloud-app-security/set-up-cloud-discovery it appears that by using the AutoCollector method all we are going to see is Target and Origin IP Address only? How come there is such a disparity of the detail in the two different approaches?

 

It looks like we can get a Graduate to maually do this process as a daily task and then end up getting a decent amount of worthwhile data ingested into MCAS, but if we automate it then the level of detail falls off considerably - it could be that we've misunderstood this - but this doesn't seem to make sense? Is there possibly another way of semi-automating the upload of the Samrt Tracker logs into MCAS for ingestation? It would not be ideal as it would keep having to reference the specific snapshot....

Regards,
Dave C

Hi @David Caddick,

 

I recently worked with CP team, to learn about their new flow for exporting traffic data over syslog.

These will be reflected by new formats which will be supported by MCAS and that will include more details than the ones included in current supported formats.

 

This is something so be pushed during Q1CY20.

 

Thanks,

Danny.

Thanks @Danny Kadyshevitch, but as we are working with some Govt. Customers that are still on R80.10 and R80.20, etc... I'm not sure how relevant that might be to some of our Customers?

While we have a possible opportunity to create a Customer case study with MS cause this customer is running with Office ATP, Azure ATP, Defender ATP, AAD ID P2, Azure MFA, Azure Sentinel - and yet for MCAS it looks like there is very little rationale to go to the effort of adding the Automated Collector for a CheckPoint Firewall if all it's going to be able to do is add Target/Origin IP address...

 

Sorry, just telling it like it is, and it's a real shame... Is there no other way of getting the Tracker info ingested somehow?

Hi @David Caddick,

 

I think I was misunderstood -

The same data that is supported on the manual approach is also the one supported on the automated approach. If you're saying that it worked for you with the manual option, you should just go ahead and upload data automatically, there's no difference in that case in the data being extracted.

 

Yet, for my knowledge - "Smart Tracker" doesn't include traffic volumes such as upload and downloaded bytes, and that the delta is the username which is included in the "Smart Tracker" logs.

 

Hope it makes more sense now.

 

Thanks,

Danny.