IBM QRadar - Traffic Analyse (1) - Tuning

De TrafficAnalysis engine is hoe de autodetectie van QRadar werkt

Het idee hierachter is als volgt. De TA engine laadt alle DSMs die in staat zijn inkomend verkeer via syslog te ontvangen. Indien event het systeem binnenkomen met een sourceAddress dat niet overeenkomt met één van de geconfigureerde log sources, dan probeert de TA engine het event te parsen met de DSM’s die het heeft geladen. De engine houdt succes statistieken bij voor iedere sourceAddress/DSM combinatie en geleidelijk aan (als meer events van hetzelfde sourceAddress binnen komen)  bepaalt het dan welke DSM bij welke events thuis horen.

In het geval van bepaling aan de hand van verzamelde statistieken besluit de TA, indien een ondersteund log source type bestaat in de omgeving van de klant, dat het dan ook dat type is en het zal dan automatisch een log source creëren voor dat SourceAddress en dan beginnen met het daarvoor verzamelen van de events.

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.