Skip to main content
Solved

Request Clarification: Palo Alto source integration

  • July 24, 2024
  • 9 replies
  • 139 views

Aravind3
Forum|alt.badge.img+8

Hello Everyone,

While integrating Palo Alto with Chronicle, I found a document from Palo Alto which states that the endpoint URL should be set as "https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate" or according to region. My question is, by doing this, how do we specify the Log type? How will Chronicle identify that this is intended for Palo Alto Prisma Access logs or any other log type?

Reference: https://docs.paloaltonetworks.com/strata-logging-service/administration/forward-logs/forward-logs-to-an-https-server

Thanks in advance.

Aravind Sreekumar

Best answer by Rene_Figueroa

Hi @Aravind3 the Palo Alto integration sets the log type. I think this integration sets the log type as ARCSIGHT_CEF and therefore the logs are parsed by our ARCSIGHT_CEF parser. If you want to double check the log source, you can follow up with Palo Alto directly. 

9 replies

Rene_Figueroa
Staff
Forum|alt.badge.img+10

Hi @Aravind3 the Palo Alto integration sets the log type. I think this integration sets the log type as ARCSIGHT_CEF and therefore the logs are parsed by our ARCSIGHT_CEF parser. If you want to double check the log source, you can follow up with Palo Alto directly. 


Aravind3
Forum|alt.badge.img+8
  • Author
  • Bronze 2
  • July 29, 2024

Hi @Aravind3 the Palo Alto integration sets the log type. I think this integration sets the log type as ARCSIGHT_CEF and therefore the logs are parsed by our ARCSIGHT_CEF parser. If you want to double check the log source, you can follow up with Palo Alto directly. 


Hi @Rene_Figueroa,
Thanks a bunch


Aravind3
Forum|alt.badge.img+8
  • Author
  • Bronze 2
  • September 17, 2024

Hi @Aravind3 the Palo Alto integration sets the log type. I think this integration sets the log type as ARCSIGHT_CEF and therefore the logs are parsed by our ARCSIGHT_CEF parser. If you want to double check the log source, you can follow up with Palo Alto directly. 


Hi @Rene_Figueroa ,
Is there an official google doc available for Proofpoint OnDemand integration?


Rene_Figueroa
Staff
Forum|alt.badge.img+10

Hi @Rene_Figueroa ,
Is there an official google doc available for Proofpoint OnDemand integration?


Hi @Aravind3 we have the following PoD info on our public docs:

https://cloud.google.com/chronicle/docs/reference/feed-management-api#proofpoint-on-demand


Aravind3
Forum|alt.badge.img+8
  • Author
  • Bronze 2
  • September 18, 2024

Forum|alt.badge.img
  • New Member
  • November 1, 2024

Using the same Palo Alto integration I get an error at the very last step. It complains that "region is required". Has anyone seen that error before?


ionutm
Staff
Forum|alt.badge.img+5
  • Staff
  • November 7, 2024

Using the same Palo Alto integration I get an error at the very last step. It complains that "region is required". Has anyone seen that error before?


We haven't seen this error on other instances. If this happens again please go through support so we can further investigate.


klay
  • New Member
  • July 28, 2025

Hi There,

 

Have you seen any bottleneck around the ingestion API?

It’s because I receive these notifications from time to time from Strata Logging Service:

 

________________________________

The HTTPS server with uri: https://xxxxx-malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate is not receiving logs due to the following error: "Read timed out".

________________________________

 

For us this is the preferred way to collect the PA logs: SaaS 2 SaaS, but it’s surprising to see low performance on the ingestion API, we’re not receiving the 100% of the logs through the HTTPS destination, PA points that the destination (ingestion api) is not able to cope with the load.

 

Regards,

 

Karl.


klay
  • New Member
  • July 28, 2025

Furthermore, for this specific case, we have no way to set the "namespace" and "labels" fields as of now. By any chance Is there a way to set them once received them in SecOps? Maybe during parsing time?