topic Re: QRadar API 19.0 and Incoming Mapper problem in Cortex XSOAR Discussions

QRadar API 19.0 and Incoming Mapper problem

renaissancefreak — Wed, 23 Aug 2023 16:17:48 GMT

Dear all,

I am trying to deploy MT XSOAR on a customer and they are using QRadar 7.3.5 with API 19.0. I have noticed that some incidents do not get the same mapping, yet they use Qradar Generic Incoming Mapper and all incidents are set as QRadar generic.

For instance, Type A incident gets incidents.label.start_time mapped as incidents.starttime but type B incident does not have this mapping. Both incident types are coming from the same QRadar Instance. Is there any suggestion that you can provide?

Also one more thing. I want to check the Incoming Mapper options but whenever I try to pull incidents from QRadar on Incoming Mapper config page, I only get to see 1-2 incidents. Is there a way to fix this? I already applied the server config to increase limit to 100 by adding mapping.max.pulled.samples 100 config.

Kindly advise.

Re: QRadar API 19.0 and Incoming Mapper problem

RahulVijaydev — Wed, 23 Aug 2023 19:07:51 GMT

Hello,

If you are able to visualize the raw JSON data for both types that you are referring to, do you find the field absent from one of the types, or is it placed under a separate field in both types?

The number of samples you can retrieve will depend on how many alerts were available in the lookback period configured in the integration. The numbers can vary with time.

Re: QRadar API 19.0 and Incoming Mapper problem

renaissancefreak — Wed, 23 Aug 2023 21:57:06 GMT

Hello,

Both Incident A and B has the same incident.labels.starttime label and context.

Incident A has the same label mapped as incident.starttime. Incident B does not have the same context key. They are both mapped as QRadar Generic type and they both use the same Incoming Mapper option and same QRadar instance.

I hope I was able to explain the situation better.

Re: QRadar API 19.0 and Incoming Mapper problem

RahulVijaydev — Wed, 06 Sep 2023 20:05:04 GMT

That makes sense. If the field did not map to one of the incident types, is it possible that that key does not exist for that particular alert, or stored in a different location that the mapper does not read? Happy to jump on a call and take a look, but I would start by doing the following,

* Add the server configuration - ingestion.samples.save-mapped and value would be true. This ensures that the raw data from the alert is captured in the incident for us to review.

* Ingest a few QRadar alerts. After adding the above config, you should see the ${incident.rawJSON} field populate for every incident you ingest(not limited to one type)

* REMOVE the server config after a few QRadar samples have been collected. If not removed, it can have serious implications for storage and performance

* Review alert samples to see if data exists in just a subset of the types

Re: QRadar API 19.0 and Incoming Mapper problem

renaissancefreak — Thu, 07 Sep 2023 17:00:58 GMT

Hello,

I already solved my both problems. I guess first one was something momentary because it did not occur again.

I found the ingestion server config parameter from KBs and applied. Thanks for your help again.