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 - Protocollen (14) JDBC Setup/Testen

–  JDBC maakt een on-disk ‘session tracking’ file voor aanwezige informatie van het laatste event dat zij bekeken heeft om resets te vermijden als het Event Correlation Service (ECS) herstart. Net zoals de meeste andere ‘actieve’ QRadar protocollen die outbound communicatie maken om event gegevens van een extern systeem op te halen.

–  Bij JDBC wordt de tracking informatie opgeslagen in simple name=value property files. Die staan in /store/ec/jdbc/ met een file per JDBC log source

–  De files hebben een naam met daarin de sensorprotocolconfig id waarde voor de log source. Deze kan opgehaald worden uit de postgres database door gebruik te maken van het volgende commando:

•Psql –U qradar –c “select id from sensorprotocolconfig where configname = ‘<Log Source Name>’;”

–  Deze file kan worden gebruikt om vast te stellen wanneer de JDBC provider voor het laatst de remote database heeft gepoold en kan je ook vertellen wat de comparable kolom is en wat de laatst waargenomen waarde was.

–  Je kunt het JDBC protocol forceren om de oude gegevens opnieuw in te lezen door in te breken in deze file – dat is handig voor test en demonstratie doeleinden. Schakel de log source uit, pas de file aan door‘comparable’ naar een oudere timestamp/counter/id/etc aan te passen, schakel daarna de log source weer in. Wanneer de JDBC provider opstart leest het die file om te bepalen wanneer het met pollen moet beginnen en dus kijkt het terug in de tijd en haalt dan de oudere gegevens op.