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 - Handleiding Tuning 7.2.5. (Deel 1)

Inleiding tot het tunen van QRadar

Met deze handleiding kunnen systeembeheerders een IBM QRadar 7.2.5. omgeving tonen.

De systeembeheerder heeft hiervoor admin-rechten nodig op de netwerkcomponenten en firewalls binnen het te monitoren netwerk.

Daarnaast dient de systeembeheerder voldoende kennis te hebben van het bedrijfsnetwerk en van netwerktechnologieën.

Voor meer technische informatie over IBM QRadar verwijzen wij u naar de andere artikelen op dit Nederlandstalige blog: http://qradar-securityintelligence.blogspot.com

Fasen

Tuning van QRadar vindt plaats in twee fasen.

·      Fase I:  Deployment

·      Fase II: Tuning

Beide fasen bestaan uit 7 stappen.

Fase I: Deployment

1. Netwerk hierarchy inrichten

Met de netwerkhierarchy kunt u aangeven of systemen Local of Remote zijn. Daarnaast kunt u met de netwerkhierarchy aangeven tot welke logische groep(en) hosts behoren. Dit kan buiten een fysieke indeling om ook bijvoorbeeld een indeling zijn in business units, afdelingen, processen of een geografische indeling. Het gaat om het groeperen van servers aan de hand van IP-adressen.

U kunt servers met overeenkomstig gedrag groeperen. Servers met uniek gedrag kunt u het beste apart opnemen om het gedrag daarvan te kunnen zien.

Zorg dat u niet meer dan 15 servers in een groep plaats anders heeft u slecht zicht op de details.

Zorg dat u in ieder geval een groep creëert die alle servers omvat. Als u dan een nieuw netwerk toevoegt worden daar in iedere geval de regels op toegepast die default voor alle servers gelden.

U dient ervoor te zorgen dat alle interne IP-adressen gedefinieerd zijn in de netwerkhierarchy. Als dit niet gebeurd bestaat het risico dat er veel false positives gegenereerd worden, omdat QRadar de niet gedefinieerde adressen dan als extern beschouwt.

Om na te gaan of u alle hosts heeft opgenomen in de netwerkhierarchy kunt u nagaan of er remote-to-local verkeer bestaat binnen uw eigen range van IP-adressen of dat er remote-to-remote verkeer bestaat binnen uw eigen range van IP-adressen. 

Al het verkeer binnen uw eigen range van IP-adressen of vanaf uw eigen range van IP-adressen naar buiten toe moet namelijk Local-to-Local of Local-to-Remote zijn als al uw hosts zijn opgevoerd in de netwerkhierarchy.

U kunt dit nagaan door een zoekopdracht te definiëren in de network activity tab.

1. Ga naar Search.... -> New Search. 
2. Ga vervolgens naar Search Parameters. 
3. Kies in het drop down menu bij Parameter voor Flow Direction. 
4. Kies als operator Equals any of. 
5. Kies bij value voor: R->L en druk op +. 
6. Kies vervolgens bij value voor R->R en druk op +. 
7. Kies vervolgens Add Filter.
8. Kies vervolgens in het drop down menu bij Parameter voor Source IP [indexed]. 
9. Kies bij Operator Equals
10. Geef bij value uw address space op. Bijvoorbeeld. 150.200.50/24
11. Kies vervolgens op Add Filter
12. Kies daarna voor Filter

U krijgt dan een overzicht van alle interne IP-adressen die nog als remote beschouwd worden. Voor de IP-adressen die intern zijn maar nog als remote beschouwd worden dient u de hosts nog op te voeren in de netwerkhierarchy.

Richt de netwerkhierarchy in met voldoende detailniveau. Daarmee kunt u precies zien wat voor activiteiten, waar in het netwerk plaatsvinden. Overdreven gezegd: U kunt alle hosts wel als servers benoemen, maar daarmee verkrijgt u weinig inzicht in wat er gebeurd op uw netwerk. U kunt in de netwerkhierarchy hosts indelen naar locatie, functie, afdeling enzovoorts. Standaard wordt er in QRadar al een netwerkhierarchy indeling meegeleverd.

Beheerders dienen de volgende belangrijke objecten te definiëren in de Admin Tab onder de network hierarchy:

• DMZ: Het IP-adres vanaf de buitenkant, het internet

• VPN's: IP-adressen voor externe toegang

• Datacentra en server netwerken

• Netwerkmanagement en netwerkapparatuur

• Je moet voor iedere netwerkcomponent een waarde voor het gewicht toekennen tussen de 1 en 100. Een gewicht stelt QRadar in staat de severity van hetzelfde event op twee verschillende hosts te bepalen. Geef een hogere waarde voor het gewicht aan servers die cruciale informatie bevatten.

• Voorbeeld: De NS Reisplanner is voor een bedrijf misschien niet zo kritisch maar voor de NS zelf is dat weer heel anders

Veelal ziet u bij initiële installatie van QRadar, dus voor er tuning heeft plaatsgevonden, dat de gewichten van de applicaties nog niet bekend zijn en dat er dan eerst gekozen wordt om de gewichten van alle applicaties op 50 te stellen.

U kunt meer informatie over het definiëren van de netwerkhierarchy vinden in de QRadar SIEM Administration Guide in Hoofdstuk 6: Set up QRadar, Network Hierarchy en Defining your network hierarchy (blz. 57 - 61).

2.  

wordt vervolgd...

 

www.q-musketeers.com

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.