De stap van werkplek-MSP naar security-MSP begint niet bij detectie. Hij begint bij standaardisatie.
Stel: een MSP heeft een nieuw werkplektraject afgerond. Alle medewerkers van de eindklant zijn voorzien van een moderne werkplek. De evaluatie is positief, het traject scoort een tien. En dan komen er detecties uit. Detecties die kunnen impacteren op klantdata. Op identiteiten. Data die naar de verkeerde kant gestuurd wordt. Alarmbellen die niemand in de organisatie kan opvolgen, omdat de structuur daarvoor ontbreekt.
Dit scenario is geen uitzondering. Het is wat er gebeurt in MSP-organisaties die hebben geïnvesteerd in detectie zonder de fundering te leggen waarop detectie kan werken. En die fundering is geen extra tool. Het is standaardisatie.
MDR voor MSP: te lang overgeslagen?
Het NIST cybersecurity framework kent vijf pilaren waarop een veilige dienstverlening rust:
– Identify: weten wat je hebt, wat de risico’s zijn, wat beschermd moet worden
– Protect: preventieve maatregelen om die risico’s te beperken
– Detect: herkennen dat er iets misgaat, idealiter zo vroeg mogelijk
– Respond: adequaat reageren op wat is gedetecteerd
– Recover: herstellen van impact en leren voor de volgende keer
De afgelopen jaren hebben veel MSP’s vooral op Identify en Protect gefocust. Antivirus uitrollen, firewalls inrichten, identiteiten beheren, werkplekken beveiligen. Allemaal noodzakelijk. Maar Detect en Respond, samen wat we kennen als MDR (Managed Detection and Response), zijn structureel ondergesneeuwd gebleven.
Met het tempo waarin security incidenten in de krant verschijnen, vrijwel dagelijks of wekelijks, is dat geen houdbare positie meer. Eindklanten zien het. Compliance frameworks vragen het. En andere MSP’s bouwen nu wel die capabilities op, terwijl jij nog niet bent begonnen.
Detectie zonder opvolging is geen security dienstverlening
Het meest hardnekkige misverstand in MDR is dat detectie de moeilijkste stap is. Dat is niet zo. De moeilijkste stap is opvolging. Detectie zonder structurele opvolging is in de praktijk een log van dingen die zijn misgegaan, terwijl de impact al binnen is.
Wat er gebeurt zonder opvolging laat zich raden. Klantdata wordt verstuurd naar plekken waar het niet hoort te komen. Identiteiten worden gestolen voordat iemand de melding heeft gelezen. Configuraties die scheef staan, blijven scheef staan. En patronen in detecties worden niet herkend, dus worden ze ook niet opgelost.
Hier komt het tweede element bij dat veel MSP’s onderschatten: detecties zijn niet alleen waarschuwingen. Ze zijn ook leermateriaal. Adequate opvolging maakt het mogelijk om vanuit detecties de basis configuratie te verbeteren. Baseline management wordt strakker. Bepaalde security configuraties die eerder niet waren meegenomen, krijgen alsnog een plek in de standaardisatie.
Hoe relevanter je blijft bij de eindklant, hoe groter de kans dat die eindklant bij jou blijft. Een goedkopere alternatieve aanbieder heeft de kennis niet die jij hebt opgebouwd door consequent op te volgen.
Waarom standaardisatie de eerste stap is, niet de laatste
Detectie en respons werken alleen als de basis op orde is. En de basis is standaardisatie van klantomgevingen. Zonder standaardisatie weet een MSP niet hoe de configuratie eruit moet zien om uiteindelijk detect en respond capabilities goed te kunnen leveren.
Concreet: zonder de juiste technische telemetrie data komt er onvoldoende informatie binnen om security incidenten te herkennen. In het ergste geval worden incidenten gemist omdat de standaardisatie ontbreekt op de plek waar de detectie had moeten plaatsvinden. Het probleem zit niet in de tool. Het probleem zit in de configuratie van de tenant waarop de tool draait.
De winst van een gestandaardiseerde basis
Wanneer alle technologieën correct geconfigureerd zijn vanuit één gedeelde standaard, gebeuren er twee dingen tegelijk. Aan de ene kant komen er meer true positives binnen, dus echte security acties op echte dreigingen, omdat de detectie binnenkomt vanuit de juiste data. Aan de andere kant zijn er aanzienlijk minder false positives, dus minder ruis die tijd, geld en mensen kost aan meldingen die uiteindelijk niets blijken.
Voor MSP’s is dit een directe efficiëntiewinst. Tijd die niet aan false positives wordt besteed, kan worden ingezet om de dienstverlening verder te verbeteren of meer klanten op niveau te bedienen. Dat is geen toekomstmuziek, dat is wat een gestandaardiseerd platform vandaag al levert.
Slim omgaan met data: niet alles hoort in je SIEM
Een terugkerende vraag in MDR-trajecten: moet alle data in het SIEM-platform geïntegreerd worden? Het antwoord is genuanceerder dan veel MSP’s denken.
Een SIEM-oplossing verzamelt data uit applicaties, netwerk, tenants en audit logs, en voert daar analyses op uit. Maar tegenwoordig hoeft niet alle data daar terecht te komen. Neem netwerk traffic logs als voorbeeld. Het volume aan rauwe data van netwerkinfrastructuur is enorm. Dat allemaal in een SIEM stoppen kost gigabytes, terabytes aan opslag en analyse-capaciteit. Daar wordt cybersecurity onnodig duur.
De Defender-stack heeft al native ingebouwd dat netwerk traffic data wordt verwerkt op het platform zelf. Een netwerk firewall is bovendien beter geschikt om on-the-spot ongewenst verkeer te blokkeren dan een SIEM die achteraf analyseert.
Wat dat betekent voor de architectuur
De juiste vraag is niet hoeveel data je verzamelt, maar hoe je data zo neerzet dat hij actionable wordt. Voor veel MSP’s komt dat neer op een gerichte combinatie. Sentinel als SIEM voor de zaken waar correlatie en analyse op meerdere bronnen waarde toevoegen. Defender voor wat al native wordt afgehandeld op platform niveau. En een baseline configuratie die zorgt dat beide dezelfde uitgangspunten hanteren bij elke klant.
Op het moment dat je een melding in je SIEM hebt staan, weet je het. Maar als de configuratie van de tenant niet aansluit, kun je er nog steeds niet effectief actie op ondernemen. De keuze tussen wel of niet in het SIEM is daarmee secundair aan de vraag of de basis gestandaardiseerd genoeg is om de detectie überhaupt waardevol te maken.
Security is geen losse propositie meer
Een laatste valkuil voor MSP’s: security wordt nog te vaak behandeld als losse module. Een aparte SKU naast werkplekbeheer. Een opt-in voor klanten die het zelf willen. Dat is een positionering die niet langer houdbaar is.
Security hoort als verlenging van de bestaande dienstverlening, niet als extra bovenop. Wat een eindklant vandaag nodig heeft om over een paar jaar nog veilig te kunnen werken, is een geintegreerd geheel: moderne werkplek, identity en access management, application management én een MDR-laag eronder. Dat is wat in een security-first markt het verschil maakt.
MSP’s die security niet inbedden in hun propositie zetten daarmee de achterdeur open. Op het moment dat een eindklant gaat nadenken over zijn cyberweerbaarheid en bij jou geen antwoord vindt, komt iemand anders dat gesprek voeren. Niet alleen voor security. Voor het hele palet, want bij die andere partij is het wel een geintegreerde dienstverlening.
Van reactief naar structureel
De rode draad onder al deze onderwerpen is dezelfde beweging: van reactieve dienstverlening naar structurele dienstverlening. Bij reactieve dienstverlening is een MSP per definitie niet voorspelbaar. Er gebeurt iets, er wordt gereageerd. Soms goed, soms te laat, soms juist te activistisch.
Structurele dienstverlening rondom security betekent vooraf gemaakte afspraken over wat er gebeurt, wanneer, en in welke volgorde. SLA’s die worden nageleefd. Processen die ook doorlopen wanneer er druk staat op de organisatie. Want bij een security incident telt elk uur. Eén incident dat te laat wordt behandeld, kan voor een eindklant directe impact hebben.
De balans die je samen met de klant moet vinden
Tegelijk geldt het omgekeerde. Een te actieve dienstverlening, waarbij accounts onnodig worden dichtgezet of werkplekken te vaak worden geïsoleerd, levert een ander gesprek op. Een eindklant die zijn business niet kan draaien omdat zijn IT-partner overdreven streng heeft ingegrepen op een false positive, krijgt vragen die niet eenvoudig te beantwoorden zijn.
De juiste balans is alleen te vinden als de structuur vooraf met de klant is afgestemd. Welke acties horen bij welk type incident? Wie wordt wanneer geïnformeerd? Wat is acceptabele impact? Dat soort afspraken kun je niet improviseren tijdens een incident.
Aantoonbaar veiligheid is het nieuwe normaal
Een paar jaar geleden zei een groot elektronicabedrijf in een interview dat ze niet te hacken waren. Drie keer raden wat daarna is gebeurd. Het is een voorbeeld dat blijft hangen, niet om Sony specifiek, maar om de mentaliteit. De gedachte dat het bij ons wel goed zit, is op zichzelf het grootste risico.
Compliance frameworks zoals NIS2 vragen niet om een gevoel van veiligheid. Ze vragen om aantoonbare veiligheid en controle. Aantoonbaar maken is alleen mogelijk vanuit een gestandaardiseerde basis met continue monitoring. Niet incidenteel checken, maar structureel inzicht in elke tenant, elke configuratie, elke afwijking.
Voor MSP’s is dat geen extra last. Het is een commerciële kans. Een eindklant die door zijn auditor wordt gevraagd hoe hij zijn security borgt, kan zelf niet altijd het antwoord geven. Een MSP die dat antwoord wel onderbouwd kan leveren, vanuit baselines, monitoring en aantoonbare opvolging, wordt op dat moment geen leverancier meer. Hij wordt een strategische security partner.
Wat dit betekent voor MSP’s die nu de keuze maken
De volgorde is belangrijk. Voor MSP’s die hun MDR-propositie willen opbouwen, is dit de logische opbouw:
– Begin met standaardisatie. Zonder gedeelde baseline over alle klant tenants is geen werkende detect en respond mogelijk.
– Configureer voor relevante telemetrie. Zorg dat de juiste data binnenkomt op de juiste plek. Niet alles in je SIEM, wel de juiste signalen actionable.
– Bouw structurele opvolging. Detecties zonder proces zijn waarschuwingen die niemand leest. Maak afspraken vooraf met de klant.
– Gebruik detecties om de baseline te verbeteren. Elke goede opvolging levert input voor strakkere standaardisatie. Dat is de feedback loop die de dienstverlening sterker maakt.
– Maak het aantoonbaar. Niet alleen voor compliance, ook voor commerciële positionering bij nieuwe en bestaande klanten.
Dit is geen project van zes weken. Het is de manier waarop een MSP zijn dienstverlening de komende jaren opbouwt en uitbouwt. De feedback loop tussen Identify, Protect, Detect, Respond en Recover loopt steeds vaker, met steeds meer data, met steeds betere configuraties. En de eindklant merkt het verschil.
De relatie tussen MSP en eindklant is een vertrouwensrelatie
Een eindklant verwacht dat zijn IT-partner de juiste dingen doet, ook als hij zelf niet alle technische details overziet. Net zoals iemand die zijn auto naar de garage brengt erop vertrouwt dat de juiste handelingen worden uitgevoerd op zijn voertuig. Dat vertrouwen wordt verdiend door consistentie, voorspelbaarheid en een dienstverlening die niet alleen op het ene goede moment werkt, maar elke dag.
MSP’s die de stap naar structurele MDR maken op basis van een gestandaardiseerde fundering, bouwen die vertrouwensrelatie sterker. Niet als beheerder van losse onderdelen, maar als strategische partner die onderbouwd kan laten zien waar risico’s zitten en hoe die worden beheerst.
SuperVision biedt MSP’s het platform om Microsoft 365 omgevingen gestandaardiseerd, gecontroleerd en aantoonbaar veilig te beheren. Met Baseline Management als fundament onder elke werkende MDR-dienstverlening, en continu inzicht in afwijkingen voordat ze problemen worden. Voor MSP’s die hun security propositie niet willen bouwen op losse tools, maar op een gestandaardiseerde basis die meegroeit met elke klant.
