Document toolboxDocument toolbox

4.3.3. Aanvullende informatie over de maatregelen (beheer gebeurtenissen)

4.3.3.1. Beheer van gebeurtenissen als maatregel

4.3.3.1.1. Preventie, detectie en reactie

Het proces beheer van gebeurtenissen of event management laat toe om gebeurtenissen of events te detecteren en indien nodig de gepaste actie uit te voeren. Omdat gebeurtenissen zo vroeg in de operationele cyclus worden gecapteerd, kunnen ze uitval of verstoring vermijden. Event management is dus het proactieve proces dat aan incident beheer voorafgaat.

Beheer van gebeurtenissen is een preventieve maatregel.

4.3.3.1.2. Wat zijn gebeurtenissen?

Een gebeurtenis of event is een willekeurige meetbare of waarneembare verandering of voorkomen die betekenis heeft voor het beheren van de ICT-infrastructuur of voor het leveren van een ICT-dienst, en voor het evalueren van de impact die een afwijking op de dienst zou kunnen hebben. Al wat materiële impact heeft op de zakelijke activiteiten komt in aanmerking, bvb:

  • Omgevingsfactoren zoals wijziging in temperatuur, vochtigheidsgraad, vermogen;

  • Intrusies;

  • Foutenboodschappen;

  • Boodschappen over het functioneren van een toepassing of systeem.

Het is voor een organisatie belangrijk om gebeurtenissen op te sporen en te analyseren en om passende actie te ondernemen. Voor het opsporen van gebeurtenissen moet de organisatie over geschikte methodes en monitoring beheerssystemen beschikken. Tevens moet die organisatie nauwkeurig hebben vastgelegd wanneer, uitgaande van een bepaalde basistoestand van haar infrastructuur, een waargenomen feit een gebeurtenis is volgens bovenstaande definitie.

4.3.3.1.3. Het verschil met incidenten

Wat is nu het verschil tussen een gebeurtenis of event en een incident?
Incidenten zijn ongeplande onderbrekingen of significante verminderingen in de kwaliteit van een ICT-dienstverlening. Zodra een incident zich voordoet, is er iets mis (voor meer informatie zie 4.5. Minimale maatregelen - Incidentbeheer )

Gebeurtenissen of events zijn wijzigingen in de status van de dienstverlening of configuratie-items.

Alle incidenten zijn dus gebeurtenissen, want een onderbreking of vermindering van de kwaliteit van een dienstverlening is een verandering in de status van die dienstverlening. Maar niet alle gebeurtenissen zijn incidenten, zoals bvb een verhoogd gebruik van een dienst (zolang binnen de eventueel gedefinieerde drempelwaarde), een gebruiker die inlogt, een geautomatiseerde back-up, …

4.3.3.1.4. Wat is beheer van gebeurtenissen?

Dit proces houdt zich bezig met de verwerking van gebeurtenissen aangegeven door het bron proces (het zakelijk proces, de toepassing, het systeem dat men wenst op te volgen), begrijpen wat ze betekenen en waar nodig de gepaste actie ondernemen, het is tevens de basis voor operationele monitoring en controle. Het proces beheer van gebeurtenissen registreert en interpreteert de wijziging van de status van een systeem of dienst in een vroeg stadium, wat toelaat om in te grijpen vooraleer de gevolgen voor de zakelijke processen significant worden. Elk systeem, proces of toepassing heeft de mogelijkheid om een triade aan gebeurtenissen te genereren. Het is dan ook niet mogelijk om alle gebeurtenissen te willen detecteren, opvolgen en beheren. Het is belangrijk om van meet af aan de juiste gebeurtenissen op te nemen in het beheersproces. Van bij het begin – de design fase van het bron proces – moet bekeken worden welke gebeurtenissen de moeite waard zijn om op te volgen. Het begint dus met de identificatie van de gebeurtenissen die moeten worden opgevolgd: gaat het om reguliere operationele activiteit, is het ongewoon maar niet exceptioneel, of gaat het om een uitzondering? Deze gebeurtenissen moeten ontwikkeld en getest worden, de nodige tooling om deze gebeurtenissen te genereren, moet worden voorzien. Deze noodzakelijke eerste stap moet ondernomen worden in het bron proces en vormt de input van het proces beheer van gebeurtenissen. Voor een veilige, stabiele en betrouwbare ICT-dienstverlening is het voor een ICT-organisatie belangrijk dat zij weet wat de 'normale' status is van haar ICT-infrastructuur en van haar ICT-diensten en dat zij vroegtijdig op de hoogte wordt gebracht van (dreigende) afwijkingen hiervan. Waargenomen  gebeurtenissen kunnen een aanwijzing voor een dergelijke afwijking zijn. Ze worden meestal door een bewakings- of monitoringsysteem geregistreerd. Een gebeurtenis kan een normale situatie aangeven of een ongebruikelijke maar niet uitzonderlijke situatie, maar ook een ongebruikelijke handeling met potentieel gevaar. Afhankelijk van de zwaarte van de gebeurtenis moet (indien mogelijk geautomatiseerd) gepaste actie worden ondernomen. Gebeurtenissen op het bron proces zijn een noodzakelijke input voor het proces beheer van gebeurtenissen; het bron proces moet dan ook volgende activiteiten voorzien (zie paragraaf 4.3.3. Aanvullende informatie over de maatregelen (beheer gebeurtenissen) | 4.3.3.2. De bouwstenen van beheer van gebeurtenissen ).

  • Detectie van gebeurtenissen;

  • De typering vastleggen: informationele gebeurtenis, waarschuwing of uitzondering;

  • Prioritering: toekennen van een prioriteit op basis van vooraf gedefinieerde regels (zoals bvb de criticiteit van het bron proces);

  • Review activiteiten door het bronproces: werd er correct gereageerd.

Beheer van gebeurtenissen zelf omvat volgende activiteiten:

  • Registratie van de gebeurtenis in het event management systeem;

  • Filtering: bepalen of de gebeurtenis gecommuniceerd of genegeerd wordt (in dit laatste geval blijft enkel de log over);

  • Correlatie: op basis van een vooraf gedefinieerde regels;

  • Selectie van de response: enkel logging van de gebeurtenis, of automatische response, waarschuwing en menselijke tussenkomst.

4.3.3.1.5. Input voor het proces ‘beheer van gebeurtenissen’

Zowat alle informatie die verwerkt wordt in het proces ‘beheer van gebeurtenissen’ is afkomstig uit systeem- en toepassingslogs. Bij de verwerking van die logs door het proces worden één of meer stappen uitgevoerd:

  • Collectie: verzamelen van de loginformatie uit de systemen/toepassingen. Hierbij wordt een ‘push’ of ‘pull’ techniek gehanteerd. Bij ‘pull’ worden de logs op regelmatige tijdsstippen opgehaald waardoor het real-time gehalte daalt.

  • Normalisatie: in deze stap wordt logs die verschillende formaten kunnen hebben (Windows Event log, Cysco log, syslog, …) omgezet naar een uniform formaat.

  • Correlatie: hier worden verbanden gezocht tussen log informatie, ook al zijn deze op verschillende tijdsstippen en door verschillende systemen of toepassingen aangemaakt.

  • Verrijking: sommige ‘event management’ systemen laten toe om extra informatie aan de logs te koppelen, bvb gekende kwetsbaarheden of de functie van een systeem/toepassing

Logging kan elektronisch, maar ook manueel gebeuren (voor meer informatie zie 5.2. Minimale maatregelen - logging en monitoring (SIEM) ). Manuele waarnemingen van gebeurtenissen die erkend worden als een incident, worden verder elektronisch verwerkt in het incident beheerproces (voor meer informatie zie pagina 4.5. Minimale maatregelen - Incidentbeheer .

4.3.3.1.6. Succesfactoren voor een goed beheer van gebeurtenissen

Een organisatie moet de kritische succesfactoren definiëren die passend zijn voor haar omgeving en elke kritische succesfactor moet opgevolgd worden door één of meerdere kritische prestatieindicatoren (zie hoofdstuk: ‘Meten is weten: prestatie-indicatoren (KPI’s)’). Succesfactoren voor beheer van gebeurtenissen omvatten:

  • Identificatie van de statuswijzigingen die significant zijn voor een goed beheer van systemen, toepassingen en dienstverlening – het is cruciaal dat deze bij het bron proces correct worden gedefinieerd;

  • Enkel een subset van gebeurtenissen vereist manuele interventie, maar het is wel belangrijk dat de juiste triggers gedefinieerd worden zodat – waar en wanneer nodig – deze interventie mogelijk is;

  • Een correctie identificatie van ‘normale situatie’ en de middelen om te vergelijken ten opzichte van deze situatie.

4.3.3.1.7. Event management vs. monitoring

Hoe verschilt beheer van gebeurtenissen van monitoring? Beide processen zijn erg nauw verwant maar er zijn toch verschillen. Beheer van gebeurtenissen legt de focus op het verwerken van betekenisvolle meldingen over de status van de ICT-infrastructuur en dienstverlening. Monitoring is nodig om deze meldingen te detecteren en door te geven, maar monitoring werkt breder: monitoring zal bvb de status van een systeem controleren, ook als deze activiteit geen meldingen genereert. Beheer van gebeurtenissen verwerkt gebeurtenissen gegenereerd door monitoring, terwijl monitoring ook parameters bewaakt en opvolgt die geen gebeurtenissen genereren. Het proces voor beheer van gebeurtenissen treedt enkel op wanneer een gebeurtenis zich voordoet, terwijl monitoring een continu proces is, dat werkzaam is zelfs als er geen gebeurtenis optreedt. Monitoring is dan ook een verlengde van beheer van gebeurtenissen. 

4.3.3.2. De bouwstenen van beheer van gebeurtenissen

4.3.3.2.1. Detectie van een gebeurtenis

Gebeurtenissen komen 24x7 voor. Belangrijk voor een goed beheer van gebeurtenissen is de identificatie van die gebeurtenissen die significant zijn voor de dienstverlening en het opzetten van een systeem om deze te detecteren.

Detectie van gebeurtenissen vloeit voort uit systeem- en management tools. Vaak wordt SNMP als protocol hiervoor gebruikt, maar sommige gespecialiseerde management tools gebruiken een eigen,  in-huis ontwikkeld protocol. Een gebeurtenis is gelinkt aan een configuratie-item, deze configuratie-items zijn zodanig opgezet dat ze een vooraf gedefinieerde set gebeurtenissen genereren. Zoals eerder vermeld, gebeurt dit best in de design fase van het bron proces.
Zodra een gebeurtenis door het bron proces is aangemaakt, moet dit geregistreerd worden in het proces voor beheer van gebeurtenissen. De meeste configuratie-items communiceren gebeurtenissen op volgende wijze:

  • Naar aanleiding van ondervraging door een beheerstool die bepaalde informatie van het systeem in kwestie opvraagt. Dit wordt polling genoemd.

  • Het systeem kan ook gebeurtenissen genereren wanneer bepaalde vooraf ingestelde voorwaarden zijn vervuld.

Het is een goede praktijk om de gebeurtenissen altijd te loggen in het proces voor beheer van gebeurtenissen: een record van de gebeurtenis wordt aangemaakt samen met de bijhorende acties door het beheerssysteem of door de individuele toepassing, proces of hardware dat de gebeurtenis getriggerd heeft.

Triggers voor gebeurtenissen

Gebeurtenissen kunnen ontstaan vanuit eender welk type verandering of voorkomen. Het is zaak de juiste veranderingen of voorkomen te definiëren, d.w.z. die significant zijn en/of enige actie vereisen. Voorbeelden van triggers zijn:

  • Bepaalde waarden van performantie;

  • Een uitzondering op een geautomatiseerde procedure of proces, bvb een routine is niet of niet tijdig uitgevoerd;

  • Een uitzondering op een zakelijk proces dat gemonitord wordt;

  • Vervolledigen van een geautomatiseerde taak of job;

  • Een status wijziging van een systeem of record in een database;

  • Toegang tot een toepassing of database door een gebruiker of een geautomatiseerde procedure of proces;

  • Een situatie waarbij een gedefinieerde drempelwaarde is bereikt of overschreden.

Input voor het beheer van gebeurtenissen

Het bron proces levert meldingen van:

  • Operationele en servicelevel vereisten;

  • Alarmen, alerts en drempelwaarden voor het herkennen van gebeurtenissen;

  • ‘Event correlatie’ tabellen, codes en geautomatiseerde antwoorden;

  • Operationele procedures.

Daarnaast zijn er ook gebeurtenissen die de beschikbaarheid en integriteit van gebeurtenissen van het bron proces garandeert:

  • Levert het bron proces nog steeds gebeurtenissen?

  • Zijn deze gebeurtenissen betrouwbaar (= zijn ze inderdaad van het bron proces afkomstig)?

4.3.3.2.2. Typering van een gebeurtenis

Een gebeurtenis wordt ingedeeld in één van volgende categorieën:

  • Informationele gebeurtenis: de gebeurtenis vereist geen onmiddellijke actie en is geen uitzondering. Ze worden bijgehouden in een logbestand gedurende een welbepaalde periode. Dit type gebeurtenis wordt gebruikt om de status van een systeem, toepassing of ICT-dienst te verifiëren of om statistische informatie te verzamelen, of om beter inzicht te verwerven voor besluitvorming.

  • Waarschuwing (warning/ alert): deze gebeurtenis wordt gegenereerd zodra een systeem, toepassing of ICT-dienst een vooraf bepaalde drempelwaarde nadert (threshold). Waarschuwingen worden gebruikt om de aandacht te vestigen op een potentieel naderend probleem zodat er kan worden ingegrepen vooraleer een uitzondering optreedt.

  • Uitzondering (exception/ error): dit houdt een gedegradeerde ICT-dienstverlening in, wat wil zeggen dat een systeem, toepassing of ICT-dienst onder het niveau van de normale parameters of indicatoren functioneert. Er zijn gevolgen voor de zakelijke processen, bvb door een verminderde performantie, verlies van functionaliteit of uitval van een ICT-dienst of systeem/ toepassing.

4.3.3.2.3. Filteren van gebeurtenissen

Dit houdt in dat een gebeurtenis kan worden gecommuniceerd of genegeerd. Indien de gebeurtenis genegeerd wordt, moet zij in ieder geval gelogd worden, maar er wordt geen verdere actie aan gegeven. Filtering is een essentieel onderdeel van beheer van gebeurtenissen om redundante en onnodige informatie te vermijden.
Filtering is nodig:

  • De hoeveelheid informatie gegenereerd door de systemen, toepassingen en ICT-diensten mag niet onderschat worden. Alle informatie over gebeurtenissen ongefilterd doorlaten zou het proces overbelasten.

  • Vaak wordt dezelfde informatie onder vorm van verschillende gebeurtenissen gegenereerd. Deze redundante gebeurtenissen herkennen en herleiden tot één stuk informatie kan de efficiëntie en beheersbaarheid alleen maar verhogen.

  • De impact op bandbreedte en netwerk capaciteit kan door filtering onder controle gehouden worden.

4.3.3.2.4. Correlatie van gebeurtenissen

Correlatie wordt meestal uitgevoerd door een correlation engine die vaak deel uitmaakt van een event management tool. Correlatie houdt in dat gebeurtenissen worden vergeleken volgens een vooraf gedefinieerde reeks criteria en regels in een bepaalde volgorde, ook business rules genoemd. Aan de hand van correlatie wordt de impact van de gebeurtenis op de zakelijke processen ingeschat.

Voorbeelden van correlatie zijn:

Aantal gelijkaardige gebeurtenissen (bvb verschillende inlogpogingen van een gebruiker);

  • Aantal configuratie-items die dezelfde gebeurtenis genereren;

  • Nagaan of een bepaalde actie is gekoppeld aan de code of data waarover de gebeurtenis bericht;

  • Of het om een uitzondering gaat;

  • Vergelijking met een minimum of maximumwaarde (is een bepaalde grens overschreden?);

  • Of bijkomende informatie nodig zijn om de gebeurtenis verder te analyseren, eventueel door het ophalen van informatie uit een ander systeem.

Aan de hand van vooraf gedefinieerde regels kan de correlation engine ook een prioriteit toekennen aan de gebeurtenis.

4.3.3.2.5. Reactie op een gebeurtenis

Er zijn verschillende mogelijkheden om te reageren op gebeurtenissen, in algemene termen kan gesteld worden:

  • Automatische response: hierbij wordt een actie getriggerd op de gebeurtenis zonder menselijke tussenkomst.

  • Menselijke interactie: deze gebeurtenissen moeten worden geëscaleerd naar de juiste personen zodat actie kan worden ondernomen.

  • Aanmaken van een incident record: een gebeurtenis van categorie uitzondering moet verder opgenomen worden in het proces incident beheer. Ook een waarschuwing kan verder afgehandeld worden in het proces incident beheer.

4.3.3.2.6. Review van een actie

Ingeval een gebeurtenis aanleiding geeft tot een interactie, dan zou het resultaat ervan best geverifieerd worden door het bron proces. Dit kan eventueel automatisch gebeuren, bvb door het uitvoeren van een script om te kijken of het systeem of de toepassing correct werkt.
Waar de gebeurtenis aanleiding geeft tot een incident of wijziging houdt de review een verificatie van de juiste overdracht naar het incident- of wijzigingsproces in. 

Gebeurtenissen worden niet altijd afgesloten:

  • Gebeurtenissen die een incident of wijziging genereren, moeten formeel afgesloten worden. Afsluiten van een gebeurtenis moet steeds gevolgd worden door een review van de genomen acties.

  • Gebeurtenissen van het type ‘informationele gebeurtenis’ worden gelogd en eventueel als input voor andere processen gebruikt en hoeven niet formeel afgesloten te worden

4.3.3.2.7. Het proces  

 

Related pages