maandag 26 oktober 2015

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...




Geen opmerkingen:

Een reactie posten