Ransomware. Het woord alleen al is genoeg om iedere sysadmin even stil te laten vallen. Want we weten allemaal dat het niet de vraag is óf er iets misgaat, maar wanneer. En als het dan misgaat, wil je niet uitzoeken waar je SCCM-omgeving staat terwijl de business al aan de lijn hangt. In deze post lopen we door de meest concrete stappen om je Configuration Manager-omgeving weerbaar te maken — en wat je doet als het toch te laat is.
Waarom SCCM een interessant doelwit is
SCCM is de ruggengraat van veel Windows-omgevingen. Dat is precies waarom het zo aantrekkelijk is voor aanvallers. Als je toegang hebt tot je site server, heb je in feite beheer over alle clients in je omgeving. Software deployen, scripts uitvoeren, configuraties pushen — dat is precies wat een aanvaller ook wil doen, maar dan met andere bedoelingen.
Het is geen theoretisch probleem. Aanvallen op beheersoftware en infrastructuur worden steeds vaker gemeld, ook in Nederland. De NOS berichtte al meerdere keren over grootschalige aanvallen waarbij IT-beheerinfrastructuur bewust als eerste doelwit werd gekozen — juist omdat het de sleutel is tot de rest van het netwerk. Dat is het moment waarop je blij bent dat je je SCCM-omgeving niet behandeld hebt als een bijzaak.
De kern van het probleem: veel organisaties beheren SCCM alsof het een interne tool is die vanzelf veilig is. Dat is het niet. Het is een krachtig platform, en dat vereist een bijpassende beveiligingshouding.
Je SCCM-hiërarchie hardenen — de basics die je echt moet doen
Oké, laten we praktisch worden. Want je kunt eindeloos praten over security-filosofie, maar uiteindelijk wil je een checklist die je kunt afvinken.
Begin met de meest voor de hand liggende dingen die verrassend vaak worden overgeslagen:
- Beperk wie Site Admin is. Serieus. Controleer je SMS Admins-groep. Je zult versteld staan hoeveel accounts daar in zitten die er niet meer in horen.
- Gebruik HTTPS-only communicatie. Enhanced HTTP is een prima tussenoplossing, maar PKI-based HTTPS is de gouden standaard. Geen excuses meer in moderne omgevingen.
- Isoleer je site server. De machine waarop je primaire site server draait, hoeft geen lid te zijn van allerlei extra AD-groepen. Houd het minimaal.
- Audit je boundaries en boundary groups. Verkeerd geconfigureerde boundaries kunnen ertoe leiden dat clients content ophalen van locaties die je niet verwacht.
- Disable ongebruikte site system roles. Heb je een Application Catalog Web Service Point dat al jaren niemand meer gebruikt? Weg ermee.
Dit zijn geen rocket science-maatregelen. Maar ze worden structureel vergeten in de dagelijkse drukte van deployments, updates en de eeuwige stroom van tickets.
Wat ook vaak over het hoofd wordt gezien: de service accounts die SCCM gebruikt. Check of die accounts niet meer rechten hebben dan strikt noodzakelijk. Een Network Access Account met Domain Admin-rechten is een ramp die wacht om te gebeuren — want wie heeft er nou niet een keer een service account geconfigureerd met te brede rechten “omdat het anders niet werkte”, en het daarna nooit meer aangepast?
Monitoring en detectie: weten wat er in je omgeving gebeurt
Hardening is één ding. Maar je wilt ook weten wanneer iemand met je SCCM-omgeving aan het rommelen is. En nee, af en toe in de console kijken telt niet.
Zorg allereerst dat je SCCM-logging centraal wordt verzameld. De log files op je site server — smsprov.log, smsdbmon.log, policypv.log — bevatten waardevolle informatie over wat er gebeurt. Als je een SIEM hebt, zorg dan dat deze logs daarin terechtkomen. Als je geen SIEM hebt… dat is een gesprek voor een andere dag, maar het is een gesprek dat je moet voeren.
Specifiek voor SCCM zijn er een aantal zaken die je wilt monitoren:
- Onverwachte wijzigingen in collections, zeker in de All Systems of All Workstations collections.
- Nieuwe deployments die buiten je change window vallen. Als er midden in de nacht een script deployment wordt aangemaakt zonder ticket, wil je dat weten.
- Wijzigingen in SMS Admins of security roles. Dit is een klassieke indicator of compromise.
- Bulk-queries via WMI of de SMS Provider. Aanvallers die je omgeving verkennen, doen dat vaak via queries die afwijken van normaal gebruik.
Veel van dit soort activiteiten laten sporen na in de Windows Event Log van je site server. Combineer dat met je SCCM-logs en je hebt al een redelijk beeld. Niet perfect, maar een stuk beter dan niets.
Als het misgaat: incident response met een SCCM-component
Stel: het is 03:00 uur. Je krijgt een melding. Ransomware. Je omgeving is geraakt. Wat nu?
Eerste stap: isoleer je site server zo snel mogelijk van het netwerk als je vermoedt dat die gecompromitteerd is. Ja, dat betekent dat je SCCM-beheer tijdelijk plat ligt. Dat is acceptabel. Wat niet acceptabel is, is dat een aanvaller je site server gebruikt om malware te deployen naar al je clients.
Tweede stap: ga niet zomaar dingen herstellen zonder forensisch beeld. Maak een snapshot van de getroffen systemen als dat nog kan. Log alles wat je doet. Je gaat dit later nodig hebben voor je incident rapport, voor je verzekering, en mogelijk voor toezichthouders.
Derde stap: herstel vanuit een bekende goede backup. Klinkt simpel, maar hier gaat het vaak mis — niet omdat er geen backup is, maar omdat die backup nooit is getest. De SCCM-database is groot en complex. Een restore van alleen de database is niet voldoende; je hebt ook de content library, de site server zelf, en je site system roles. Microsoft heeft hier documentatie over, maar de praktijk is weerbarstiger dan de theorie.
Een paar dingen die je herstelproces een stuk aangenamer maken als je ze van tevoren regelt:
- Documenteer je site configuratie. Boundaries, boundary groups, discovery methods, client settings — alles. Een screenshot per kwartaal is beter dan niets.
- Test je backup restore. Doe dit minstens één keer per jaar in een testomgeving. Je wilt niet de eerste keer dat je een SCCM-restore doet, dat doen terwijl de business staat te wachten.
- Houd een offline kopie bij van je installatiemedia en licenties. Als je site server plat is, wil je niet afhankelijk zijn van een share die ook plat is.
Preventie op de lange termijn: SCCM als onderdeel van je security posture
SCCM-beveiliging is geen project. Het is een doorlopend proces. En dat klinkt als een cliché, maar het is gewoon waar.
Wat dat concreet betekent: zorg dat security een vaste plek heeft in je SCCM-beheerproces. Dat begint bij change management — elke wijziging in je SCCM-omgeving moet gelogd en goedgekeurd worden. Niet omdat je collega’s niet te vertrouwen zijn, maar omdat je bij een incident wilt kunnen terugkijken wat er wanneer is veranderd.
Verder: houd je SCCM-omgeving up-to-date. Microsoft brengt regelmatig updates uit voor Configuration Manager, en die bevatten niet alleen nieuwe features maar ook security fixes. Een SCCM-omgeving die twee jaar achterloopt op updates is een risico. Plan je updates, test ze, en rol ze uit. Ja, ook als dat gedoe is.
Betrek ook je security-team bij je SCCM-beheer. Niet om ze de baas te laten spelen over je deployments, maar om samen te zorgen dat je monitoring, je alerting, en je incident response procedures aansluiten op de realiteit van je SCCM-omgeving. Een SOC-analist die niet weet wat een SCCM collection is, kan een alert over verdachte SCCM-activiteit niet goed beoordelen. Dat is een gap die je wilt dichten.
En tot slot: wees eerlijk over je risico’s. Als je SCCM-omgeving op dit moment niet voldoet aan de basics uit deze post, is dat geen reden voor schaamte. Het is een reden voor een prioriteitenlijst. Begin met de dingen die het meeste impact hebben bij het minste werk — de SMS Admins-groep auditen, HTTPS aanzetten, backups testen. Dat zijn uren werk, geen weken.
Conclusie
Beveiliging van je SCCM-omgeving is geen optionele extra. Het is onderdeel van je verantwoordelijkheid als beheerder van een platform dat in feite de sleutels heeft tot al je Windows-endpoints. Hardening, monitoring, incident response, en structureel onderhoud — het zijn geen losse activiteiten maar onderdelen van één geheel.
Je hoeft het niet perfect te doen. Maar je moet het wel serieus nemen. En als je nu denkt “wij zijn klein, dit treft ons niet” — dat is precies de gedachte die aanvallers graag horen. Pak die checklist erbij, begin bovenaan, en werk je erdoorheen. Je toekomstige zelf — die om 03:00 uur niet gebeld wordt — zal je dankbaar zijn.