IBM QRadar - Traffic Analyse (3) - Tuning

Gelukkig kunnen we de TrafficAnalysis engine tunen

Op iedere event collector bevindt zich een TrafficAnalysisConfig.xml file in /opt/qradar/conf/

Iedere DSM die is aangemeld bij de TA engine heeft zijn eigen element.

De “order” eigenschap definieerde de voorrang/prioriteit van elke DSM – hoe lager het nummer hoe belangrijker de DSM is. Dus als de ene DSM de order 400 heeft en de andere heeft 500 en ze parsen beide 50 events succesvol vanaf een onbekende bron, dan zal degene met de order=400 automatisch aangemaakt worden.

–Dus als je de ene DSM meer prioriteit wilt geven dan de andere DSM verander dan de order. Een bekend voorbeeld hiervan is het verzetten van de AIXServer boven de LinuxServer, omdat hun events nagenoeg identiek zijn. Een klant met een hoop AIX machines zou veel false positives kunnen zien van automatisch aangemaakte LinuxServers log sources.

IBM QRadar - Traffic Analyse (4) - Tuning

De meeste DSM elementen hebben alleen een ‘class’ of ‘order’ attribuut. Maar ze kunnen ook een additionele set Threshold en Template waarden erven van de defaults in de header van de file. Deze kunnen veranderd worden per individuele DSM (indien gewenst kunnen de defaults ook gewijzigd worden).

–  De Templates bepalen alleen hoe autodetected log sources namen en beschrijvingen toegewezen krijgen.

–  De Thresholds zijn statische tuning parameters die het runtime gedrag bepalen van de TA engine

•  MinNumEvents bepaalt hoeveel succesvolle parses een DSM nodig heeft van een gegeven sourceAddress om autodetection te mogen uitvoeren en dit dan als juist te beschouwen.

•  MinSuccessRate definieert het percentage van parse pogingen van een gegeven sourceAddress dat succesvol moet zijn voor een DSM om autodetectie te mogen uitvoeren en dit dan als juist te beschouwen.