...
Bij het onderzoek naar mogelijke incidenten wordt veelvuldig gebruik gemaakt van de controle op logging uit systemen, netwerkapparatuur en programma’s. Los van de detectie, wordt logging ook achteraf gebruikt bij het reconstrueren van een incident of om te ontdekken welke systemen nog meer geraakt waren. Logs moeten bewaard worden volgens vaste regels en kennen per soort logging een bewaartermijn waarvan afgeweken kan worden (verlenging) als er een vermoeden is van een incident. Als logging op de juiste wijze bewaard en behandeld wordt, kan logging ook dienen als bewijsmateriaal voor de wet. Dan moet wel de integriteit van de logging goed ingericht zijn.
4.5.
...
3.2. Succesfactoren voor een goed incident beheer
Om tot een efficiënt en effectief incident beheer te komen, zijn volgende parameters belangrijk. Zij kunnen meegenomen worden als prestatie-indicatoren of KPI’s (zie hoofdstuk: ‘Prestatie-indicatoren (KPI’s)’) om het succes of falen van het proces te meten en bij te sturen waar nodig:
Tijdigheid: een incident moet tijdig opgemerkt en aangepakt worden.
Voorbeeld KPI: doorlooptijd vanaf aanname van een incident tot afsluiten van een incident, hoeveelheid afgehandelde incidenten per periode (bvb week, maand) t.o.v. het totaal aantal incidenten.Volledigheid: elk incident dat zich voordoet moet juist en volledig gedocumenteerd worden.
Voorbeeld KPI: aantal niet geregistreerde incidenten, aantal onvolledig geregistreerde incidenten.Beschikbaarheidhelpdesk/service desk: ondersteuning moet beschikbaar zijn voor gebruikers.
Voorbeeld KPI: openingstijden helpdesk/service desk, wachttijden.Juistheid: een incident moet correct verholpen worden en de betrokkenen moeten correct geïnformeerd worden. Voorbeeld KPI: % de eerste maal correct verholpen incidenten, % van de verstoringen, waarbij de klant juist is geïnformeerd.
Deskundigheid: er moet voldoende opgeleid personeel aanwezig zijn om incidenten vlot, correct en juist aan te pakken. Voorbeeld KPI: % functioneel geëscaleerde incidenten ten opzichte van het totaal aantal incidenten %, % hiërarchisch geëscaleerde incidenten ten opzichte van het totaal aantal incidenten %.
Klantvriendelijkheid: dit is vooral belangrijk naar de ondersteuning van gebruikers. Voorbeeld KPI: aantal klachten over het functioneren van de helpdesk/service desk.
4.5.
...
3.3. De bouwstenen van incident beheer
4.5.
...
3.3.1. Registratie en categorisatie van het incident
Deze activiteit omvat de melding door een eindgebruiker aan de helpdesk of service desk, maar kan ook het gevolg zijn van detectie van incidenten door de ICT-beveiliging, doordat bij de controle van de logging iets naar boven komt of detectie door systeem/toepassingsmonitoring. In dit laatste scenario wordt de melding aangereikt vanuit het proces voor beheer van gebeurtenissen (‘event management’).
...
De categorisatie van een incident is belangrijk om de documentatie, opvolging en toewijzing te vergemakkelijken en om trends vast te stellen die bvb bij probleem beheer, beheer van providers enz. kunnen worden gebruikt
4.5.
...
3.3.2. Prioriteit bepalen van een incident
Het toewijzen van een prioriteit aan een incident geeft weer hoe ernstig en dringend een incident is en bepaalt de verdere afhandeling ervan. De prioriteit van een incident wordt bepaald door twee factoren:
...
Oplossingtijd: tijd tussen aanmelden en oplossen of inperken van het incident. Het vaststellen van de prioriteit van een incident is geen statisch of eenmalig gegeven: het is mogelijk dat gedurende de levensloop van een incident de prioriteit wijzigt, bvb omdat meer informatie ter beschikking komt of omdat de gevolgen van een incident veranderen. Een op zich staand klein incident kan bovendien de voorbode zijn van een groter of complexer incident. Zo zal een incident gemeld door één gebruiker waarschijnlijk geen hoge prioriteit krijgen, maar dat verandert snel zodra meerdere gebruikers een gelijkaardige melding plegen.
Wanneer beroep gedaan wordt op externe dienstverlening, is een prioriteiten matrix vaak al vastgelegd door de dienstverlener. Het volstaat dan om eenvoudig bovenstaande matrix te mappen op de matrix van de dienstverlener.
4.5.
...
3.3.3. Behandelen van het incident
We beperken ons tot de bouwstenen nodig voor het afhandelen van informatie veiligheidsincidenten.
...
Een geplande wijziging: er kan geoordeeld worden dat een specifieke actie nodig is binnen een aanvaardbare termijn, deze wordt opgenomen via het proces wijzigingsbeheer;
Een niet-geplande wijziging: het betreft een verbetervoorstel waarvan de implementatie datum niet onmiddellijk kan worden opgesteld, deze wordt opgenomen via het proces beheer van releases
4.5.
...
3.3.4. Escalatie
Incidenten komen meestal op een min of meer centrale plaats terecht: vaak is dit een service desk, maar in organisaties waar deze functionaliteit ontbreekt, zijn er vaak één of meerdere personen aangeduid waar gebruikers terecht kunnen met hun ICT-problemen en/of is er een ICT-team dat zich buigt over door systemen gegenereerde waarschuwingen.
...
Voor functionele escalatie gelden criteria zoals kennis en ervaring. Er wordt vaak ook gesproken over eerstelijnssupport (service desk), tweedelijnssupport en (gespecialiseerde teams) en zelfs derdelijns support (leveranciers).
Gedurende het traject wordt het incident record voortdurend bijgewerkt door de medewerkers die aan het incident werken.
Wanneer er geen oplossing voor het incident voorhanden is, wordt het doorverwezen naar het proces probleem beheer (voor meer informatie zie 4.6. Minimale maatregelen - Probleembeheer )
4.5.
...
3.3.5. Documentatie van het incident
Het is belangrijk om elk incident en de ondernomen acties te documenteren en al deze informatie bij te houden. Hoe incidenten worden gedocumenteerd, hangt af van de grootte van de organisatie: voor grote organisaties, (ICT) providers en dienstenleveranciers met een professionele helpdesk/ servicedesk is een geautomatiseerde opvolgingstool onontbeerlijk. Voor kleine organisaties kan het volstaan om de incidenten te registreren in een eenvoudig logboek.
...
Merk op dat niet alleen incidenten in zo’n ticketing systeem worden geregistreerd, maar ook service aanvragen en aanvragen voor informatie. Het is ook belangrijk om de laatst bekende informatie van het incident goed bij te houden en te registreren: de prioriteit kan bvb in de loop van de afhandeling wijzigen, het incident kan toegewezen worden aan een andere supportgroep, de status van het incident wijzigt in de loop van de afhandeling enz. Deze nieuwe informatie moet toegevoegd worden aan het incident record zodat het record op elk moment de laatste bekende informatie over het incident bevat.
4.5.
...
3.3.6. Helpdesk/service desk
Een helpdesk is bedoeld om de klant of interne gebruiker van informatie en ondersteuning te voorzien met betrekking tot bedrijfsprocessen, producten en diensten. Het doel van een helpdesk is om een centrale bron van antwoorden te zijn, problemen op te lossen en bekende problemen te helpen oplossen. Helpdesk support kan langs verschillende kanalen aangeboden worden, waaronder fysieke locaties, gratis telefoonnummers, websites, instant messaging of e-mail. Een helpdesk kan deel uitmaken van een service desk.
De primaire rol van de helpdesk bestaat uit:
...
Het grote verschil tussen een service desk en een helpdesk, is dus dat de helpdesk een probleem meestal alleen registreert, oplost (aan de hand van gekende oplossing of work around) of doorstuurt naar een tweede lijn. Bij een service desk ligt de dienstverlening hoger. Op een service desk worden bijvoorbeeld ook autorisaties verleend en ICT-gerelateerde bestellingen aangenomen. Zowel helpdesk als service desk kunnen intern opgenomen worden of uitbesteed aan dienstenleverancier.
4.5.
...
3.3.7. Het incident team
Wanneer een incident van enige omvang de organisatie teistert, is vaak een team van specialisten nodig om het incident aan te pakken. Er moeten immer activiteiten vanuit verschillende invalshoeken opgestart worden om een antwoord te bieden op een aantal vragen zoals:
...
De grootte van de organisatie bepaalt of en hoeveel functies er nodig zijn. Kleinere organisaties hebben vaak de flexibiliteit om zich voor de aanpak van het incident snel tot het management te wenden. Dit is niet het geval voor grotere organisaties. Daar zal het incident team de meeste incidenten op een meer autonome wijze behandelen, zodat de bedrijfstop alleen in geval van een bijzonder ernstig incident wordt betrokken. Hoe groter de organisatie, hoe gedifferentieerder de samenstelling van het incident team moet zijn. In grotere organisaties kan er naast een incident team ook een crisisteam worden samengesteld uit vertegenwoordigers van het ondernemingsbestuur die bij ernstige incidenten de verantwoordelijkheid opnemen voor de strategische en bedrijfsbeslissingen en de communicatie hierover. Op deze manier kan de incident manager zich meer richten op de technische kwesties van het incident. Kleinere organisaties zullen ook vaker beroep doen op externe experts, bvb voor forensisch onderzoek of juridische ondersteuning
4.5.
...
3.3.8. Het proces
Alle bouwstenen samen maken deel uit van het proces voor het beheer van incidenten. Algemeen ziet dat er als volgt uit:
...