Ir. Pieter
Nierop, Q-Musketeers
Technische
Documentatie Q-Radar® Master Class
Utrecht, 20
Maart 1017
QID-Reeks
(3)
Relatie tussen QID’s, Building Blocks
en Rules
Gebeurtenissen in uw netwerk komen bij Q-Radar binnen op
een Event Collector of Flow Collector. Deze gebeurtenissen worden allereerst
geschikt gemaakt voor Q-Radar en daarbij omgevormd tot zogenaamde Q-Radar
events.
Tijdens het proces van het creëren van Q-Radar geschikte
events wordt onder andere de inhoud van de binnenkomende berichten geanalyseerd
en keurig in kolommen geplaatst. Dit wordt met regex (regular expressions)
gedaan. Zo komen source ip en destination ip van een bericht van een firewall
keurig in ieders hun eigen kolom. Dit proces vindt plaats in de zogenaamde
event pipeline. In de event pipeline vinden nog veel meer processen plaats maar
dat valt buiten de scope van dit artikel.
Naast het in kolommen plaatsen van de onderdelen van het
bericht dient u per gebeurtenis ook nog aan te geven wat voor soort bericht het
betreft. Bij een firewall kan dit bijvoorbeeld een “firewalll deny” betreffen
of een “firewall permit”.
Een “firewall deny” of een “firewall permit” kan gekoppeld
worden aan een QID (Q-Radar Identifier). QID’s zijn voor Q-Radar bekende gebeurtenissen
die herkent kunnen worden. Wil Q-Radar een binnenkomend bericht herkennen, dan
dient het binnenkomende bericht moet zeg maar op z’n plaats te vallen. Daar
zijn QID’s voor.
Binnen Q-Radar zijn rules gebouwd die in de gaten houden
of bepaalde gebeurtenissen, QID’s, optreden. Op basis van de rules kunnen
acties in gang gezet worden waaronder bijvoorbeeld het versturen van een syslog
bericht, of het creëren van een offense (incident), of het genereren van een
nieuwe gebeurtenis (event).
Stel u wil geïnformeerd worden als er meer dan 50 keer per
minuut een “firewall deny” optreedt op een specifieke firewall. Binnen Q-Radar
bestaat er dan al een rule die “excessive firewall denies” in de gaten houdt
voor u. U moet alleen nog maar aan Q-Radar vertellen dat de gebeurtenis die van
uw firewall afkomstig is een “firewall deny” betreft (dus dat een specifiek QID
opgetreden is). Dit wordt gedaan bij het mappen van events naar QID’s.
Building blocks zijn nagenoeg hetzelfde als rules, met het
verschil dat ze geen rule response hebben. Ze voeren zeg maar in-memory
tussenevaluaties uit voor een of meerdere rules. Ook in building blocks kan in
de gaten gehouden worden of bepaalde QID’s al dan niet optreden.
Het is voor een Q-Radar specialist natuurlijk interessant
om te weten in welke rules en building blocks bepaalde QID’s gebruikt worden.
Indien je een event naar een bepaalde QID mapt wil je natuurlijk weten welke
rules en buildingblokken dan zaken voor je in de gaten gaan houden. Of als je
een bepaalde mapping wegneemt wil je natuurlijk weten welke rules niet meer
functioneren of anders functioneren.
Deze gegevens zijn te vinden in de Vanila database. Dit is
een database die de ontwikkelaar van Q-Radar in de VS en Canada gebruiken. De
database wordt wel eens publiekelijk door IBM gedeeld op Masterclasses. De
database wordt continue bijgewerkt omdat er continue nieuwe netwerk componenten
en hosts op de markt komen en dergelijke systemen ook gewijzigd worden. Dat
noodzaakt IBM om voortdurend de QID-Map aan te passen bij iedere release en
tijdens DSM updates. In de Vanila database is het mogelijk om alle relaties te
vinden tussen High Level QID’s, Low Level QID’s, Rules en Building Blocks.
Copyright 2017 © Pieter Nierop
www.q-musketeers.com
® Q-Radar is a trademark owned by IBM
Geen opmerkingen:
Een reactie posten