De behoefte aan managed security services groeit al jaren en blijft volgens voorspelling groeien. De nieuwe meldplicht datalekken zal een extra stimulans hieraan geven om logging en periodieke controles te borgen. Wie voor het eerst een uitbestedingstraject gaat starten, moet weten dat er valkuilen zijn die met goede voorbereiding prima te ontwijken zijn. Het leek mij daarom aardig enkele ervaringen uit de praktijk langs deze weg te delen.
1) Rolverdeling
Allereerst is van cruciaal belang om na te denken over de rolverdeling. Er blijft namelijk altijd een verantwoordelijkheid bij de organisatie zelf liggen. Misschien een open deur voor mensen die ervaring hebben met dit soort trajecten. Maar in de praktijk zien we vaak genoeg dat verwacht of beloofd wordt dat het neerzetten van een blackbox die op afstand gemonitord wordt alles oplost. Nou nee. Informatiebeveiliging is per definitie maatwerk. Omdat het risicogedreven werkt en risico’s afhankelijk zijn van organisatie-specifieke variabelen.
En dus zul jeinput moeten leveren over wat jouw digitale kroonjuwelen zijn. En moet een externe analist bij het behandelen van een incident toegang hebben tot een contactpersoon die kan meedenken over de ernst van de situatie. Als je dit niet doet, kun je nog steeds een service afnemen, maar is de kans groot dat ernstigheid verkeerd wordt ingeschat en je te veel of te weinig wordt gealarmeerd.
2) Cloud, On-Premise of Hybride
In welke mate data buiten het bedrijfsnetwerk mag worden geplaatst, is bepalend voor de vraag of een vanuit de cloud geleverde security service geschikt is. In diverse bedrijfstakken is dat een absolute no-go en moet de security service dus met ‘on-premise’-apparatuur worden uitgevoerd. Ofwel apparatuur die ook binnen het bedrijfsnetwerk geplaatst wordt.
Hybride betekent hier een tussenvorm. Waarin bijvoorbeeld het gros van de apparatuur on-premise draait, maar deze gekoppeld wordt met een cloud omgeving voor threat intelligence. Dan blijft heel belangrijk te begrijpen welke soorten informatie het netwerk uitvloeien en of dit gewenst is (denk vooral aan persoonsgegevens).
3) Service Windows
Natuurlijk wil je dat je netwerk 24×7 beschermd is. Maar wil je ook dat de volledige service 24×7 werkt? Dit zijn twee verschillende dingen namelijk. Het tweede betekent dat je zelf ook klaar moet staan om opvolging te geven aan de werkzaamheden en incidenten. En natuurlijk is er een aanzienlijk kostenplaatje gemoeid met de stap naar 24×7, het zijn tenslotte meer dan 4x zoveel uren per week dan 8×5 (business hours).
De kans is groot dat hier een genuanceerd verhaal geldt: sommige delen van het werk moeten 24×7 doordraaien, terwijl andere delen alleen tijdens business hours uitgevoerd hoeven worden. Definieer dit in de opdracht en in de uiteindelijke service level agreement (sla) om duidelijkheid te scheppen en discussies te vermijden.
4) Key Performance Indicators
In een managed service worden vaak enorm veel taken uitgevoerd. Het beschrijven van die taken kan wenselijk zijn, alhoewel het ook een onnodig tijdrovende exercitie kan zijn. Maar hoe dan ook is er waarschijnlijk maar een aantal taken die écht van belang zijn en op basis waarvan je kunt beoordelen of het goed gaat met de dienst. Ofwel: key performance indicators (kpi’s).
Veelgebruikte kpi’s zijn:
- Reactie-, en/of oplostijden, vaak afhankelijk van drie tot vijf niveaus van ernstigheid
- Beschikbaarheid (of onbeschikbaarheid), vaak uitgedrukt in een percentage van de tijd
- Up-to-date systemen: de vraag of gebruikte systemen in de service up-to-date zijn en zelf niet kwetsbaar zijn voor misbruik
- Logging compliance, de mate waarin logs ook echt opgeslagen en beschikbaar zijn ten behoeve van interne audits
5) High Availability
Moet de service altijd koste wat het kost doordraaien? Wat gebeurt er als het er een uur uit ligt? Heel belangrijk om hier goed over na te denken. De primaire reactie zal tenslotte zijn: Ja! Natuurlijk moet die service doordraaien. Maar ook dit heeft wel consequenties. Bijvoorbeeld: wat als je een stroomstoring hebt? Wat als je een DDoS-aanval krijgt, of iemand met een graafmachine je internetlijn doorhakt? Natuurlijk allemaal scenario’s die uitgezonderd kunnen worden, maar dus wel waard om bij stil te staan.
Daarnaast is een service natuurlijk ook afhankelijk van security componenten, die bij een eis van high availability ook zo moeten worden ingericht met de nodige kosten tot gevolg. Het kan dus puur om kostenoverweging wenselijk of zelfs nodig zijn om enige water bij de wijn te doen ten aanzien van die primaire ‘Ja’-reactie.
6) Taal en Cultuur
Het blijkt in de praktijk regelmatig dat organisaties slechte ervaringen hebben met multinationale it-service providers, puur vanwege problemen met taal en cultuur. En juist met een security service kan dit pijnlijk en problematisch ineffectief uitpakken.
Bij het reageren op security incidenten is namelijk snelheid geboden. En er zal moeten worden afgestemd en gecommuniceerd over handelwijzen en maatregelen waarin de kleinste misverstanden grote gevolgen kunnen hebben. Of het is gewoon irritant om midden in de nacht iemand niet te kunnen verstaan.
In het selecteren van je it-service provider kun je hier natuurlijk al rekening mee houden. Maar ook in een uiteindelijke overeenkomst kun je eisen stellen aan de communicatie.
7) ISO of soortgelijke certificering
Hoe zit het eigenlijk met de informatiebeveiliging van de service provider zelf? Het makkelijkste is om een certificering te eisen zoals ISO27001, maar we weten ook dat een certificering niet alles zegt. Daarom nemen partijen in managed service contracten vaak een ‘right to audit’ op. Ofwel het recht om zelf proefondervindelijk te toetsen of de service goed en veilig wordt uitgevoerd.
8) Exit Plan
Natuurlijk moet je ook voorbereid zijn op een eventueel verschil in inzicht met jouw service provider. Of een andere reden waarom je van de dienst af wilt. Maar wat gebeurt er dan met de onderliggende security architectuur? Kun je die zelf beheren of overdragen aan weer een andere service provider? Blijven eventuele software of hardware licenties op jouw naam? Hoe zit het met intellectueel eigendom van en ondersteuning op speciaal voor jou ontwikkelde koppelingen, scripts, enzovoorts?
Om te vermijden dat je, in een situatie dat je wilt stoppen, op dat moment nog dit soort afspraken moet maken, kun je dat dus maar beter bij aanvang al afspreken. Het kan namelijk wel eens zijn dat de verstandhouding op dat moment een redelijke discussie in de weg staat.
Tot slot
Ik kan nog wel verder gaan, maar laat het even bij deze punten. Het zijn de zaken die mij als belangrijk zijn bijgebleven voor afnemers om mee te nemen in het formuleren van een outsourcing opdracht. Deze inzichten komen voort uit praktische ervaring die ik heb opgedaan in mijn werk voor DearBytes. We hebben inmiddels outsourcing trajecten doorlopen met allerlei soorten organisaties, qua omvang, branche en volwassenheid. Er zijn gerust nog allerlei zaken aan toe te voegen, maar het lijkt mij zo een redelijk bruikbaar setje handvatten.
