IBM QRadar - Traffic Analyse (2) - Tuning

Dit werkt goed maar is niet foutloos

–  Over het algemeen kunnen false positives ontstaan doordat een set van events die behoort bij een bepaald device type op een dusdanig wijze in elkaar is gezet dat ze genoeg overeenkomsten vertoont met een ander log source type in de TA config file. Beide DSM’s kunnen een gelijkwaardige matching krijgen, maar er kan er maar één winnen.

–  De TA engine kan dan al simpelweg falen in het überhaupt detecteren van een log source. Vaak gebeurd dit omdat events binnenkomen in QRadar vanuit de beoogde logsource die de DSM niet kan parsen. Dit kunnen “bagger” events zijn maar het kunnen ook normale events zijn waarvan de DSM niet weet hoe deze verwerkt moeten worden. In beide gevallen, als een bepaalde DSM een aantal events kan parsen van een ongeïdentificeerde source of als het niet een hoog genoeg succes percentage heeft, kan de TA engine het opgeven omdat de resulaten onbepaald zijn.

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.