Security Operations in het CISSP Common Body of Knowledge is de operationele discipline waarmee organisaties systemen dagelijks zichtbaar, controleerbaar en herstelbaar houden. In de praktijk verbindt Domain 7 monitoring, incidentrespons, logging, patching, change control, fysieke beveiliging en continuïteit tot één samenhangend operationeel geheel.
Voor CISSP-kandidaten is dat belangrijk omdat dit domein minder gaat over losse tools en meer over bestuurbare processen. Een SOC dat veel meldingen ontvangt maar geen goede triage, escalatie of herstelprocedure heeft, voert geen volwassen security operations uit. Hetzelfde geldt voor een IT-team dat patches snel uitrolt zonder change window, rollback-plan of afstemming met de Change Advisory Board.
Wat CISSP Domain 7 eigenlijk toetst
CISSP Domain 7, Security Operations, richt zich op de vraag hoe beveiliging dagelijks wordt uitgevoerd nadat beleid, architectuur en controls zijn ontworpen. Het domein raakt onderwerpen als resource protection, logging en monitoring, incident management, disaster recovery, business continuity, investigations, patch management, change management en personnel safety.
De kern is operationele beheersing. Een organisatie moet weten welke assets bestaan, welke gebeurtenissen relevant zijn, wie bevoegd is om te handelen, hoe bewijs wordt beschermd en hoe systemen veilig terugkeren naar productie. In examenvragen verschijnt dit vaak als een scenario waarin meerdere goede antwoorden technisch mogelijk lijken, maar slechts één antwoord past bij governance, proportionaliteit en procesvolgorde.
Security operations moet daarom worden gelezen als de verbinding tussen steady-state operations en crisis-mode incident response. In steady-state draait het om monitoring, baselines, vulnerability management, patching, configuration control en hygiëne. In crisis-mode verschuift de aandacht naar triage, containment, forensische integriteit, communicatie en herstel. Volwassen teams kunnen tussen die twee standen schakelen zonder rollen, logging of autorisaties ter plekke te moeten uitvinden.
Hoe een SOC-dag Domain 7 zichtbaar maakt
Een gewone SOC-dag begint zelden met een dramatisch incident. Meestal begint die met dashboards, openstaande tickets, overdracht vanuit de vorige shift en meldingen die opnieuw moeten worden beoordeeld omdat nieuwe threat intelligence beschikbaar is. Analisten controleren of nachtelijke detecties echte afwijkingen laten zien, of er kwetsbare systemen zijn toegevoegd aan het assetregister en of geplande wijzigingen onverwachte logpatronen veroorzaken.
Daarna volgt triage. Een melding uit een SIEM krijgt pas betekenis wanneer zij wordt gekoppeld aan context: het betrokken asset, de gebruiker, recente wijzigingen, bekende kwetsbaarheden en normaal gedrag. Een mislukte login op een publiek systeem is iets anders dan een reeks aanmeldingen op een beheerdersaccount vlak na een phishingmelding. Domain 7 toetst precies dat beoordelingsvermogen: niet reageren op elk signaal alsof het een crisis is, maar ook geen patroon missen dat escalatie vraagt.
Escalatie hoort gestructureerd te verlopen. Een SOC-analist kan extra logbronnen raadplegen, een endpoint isoleren binnen vooraf goedgekeurde grenzen of een incident commander inschakelen wanneer de impact bedrijfsbreed kan worden. Aan het einde van een shift is de handover net zo belangrijk als de eerste detectie. Zonder duidelijke status, beslissingen, openstaande acties en bewijslocaties begint de volgende ploeg opnieuw, waardoor MTTD en MTTR kunstmatig oplopen.
Dit is ook waar automatisering zijn grens vindt. Realtime waarschuwingen, anomaliedetectie, incidentresponsprocedures en threat intelligence kunnen goed worden gecombineerd in SOAR-achtige workflows, maar automatische acties zijn vooral geschikt wanneer de gebeurtenis goed begrepen is, de impact beperkt is en rollback eenvoudig is. Menselijke triage blijft verstandiger wanneer bewijs veiliggesteld moet worden, productiecontinuïteit in gevaar is, de identiteit van een privileged user betrokken is of de melding mogelijk juridische gevolgen heeft.
Monitoring, SIEM en de kwaliteit van detecties
Monitoring is geen kwestie van zo veel mogelijk logs verzamelen. NIST SP 800-92 benadrukt het belang van logmanagement als proces: bepalen welke gebeurtenissen nodig zijn, hoe ze worden beschermd, hoe lang ze beschikbaar blijven en hoe ze bruikbaar worden gemaakt voor analyse. In een CISSP-context betekent dit dat logging zowel operationele detectie als onderzoek achteraf moet ondersteunen.
In de praktijk evolueren SIEM-use cases meestal in fasen. Een team begint vaak met brede detecties, zoals meerdere mislukte aanmeldingen, malware-alerts of afwijkende netwerkverbindingen. Na enkele weken blijkt welke regels te veel ruis veroorzaken, welke assets extra context nodig hebben en waar baselines ontbreken. Goede teams verfijnen detecties iteratief tot precision detections: minder meldingen, betere signalen en duidelijkere beslisregels.
Die verbetering wordt meetbaar via operationele KPI’s. Mean Time to Detect laat zien hoe snel een team een relevante gebeurtenis herkent. Mean Time to Respond of Mean Time to Recover laat zien hoe snel containment, herstel of normalisatie plaatsvindt. Alarmkwaliteit is minstens zo belangrijk: een dashboard met duizenden alerts kan slechter zijn dan een kleiner dashboard waarin prioriteit, eigenaar en verwachte actie duidelijk zijn.
Threat intelligence voegt waarde toe wanneer zij de detectie verbetert, niet wanneer zij alleen extra indicatoren toevoegt. Een IOC-lijst zonder assetcontext kan leiden tot ruis. Een intelligence-feed die wordt gekoppeld aan kritieke systemen, kwetsbaarheden en actuele aanvalstechnieken helpt juist om use cases te prioriteren en escalatiecriteria scherper te maken.
Incidentrespons zonder verwarring met BCP en disaster recovery
Incident response, business continuity planning en disaster recovery worden vaak samen genoemd, maar ze lossen verschillende problemen op. Incident response gaat over het identificeren, beheersen, onderzoeken en herstellen van een beveiligingsincident. Business continuity planning gaat over het behouden van essentiële bedrijfsfuncties tijdens verstoring. Disaster recovery richt zich op technisch herstel van systemen, data en infrastructuur na een grote uitval of calamiteit.
NIST SP 800-61 en ISO/IEC 27035 behandelen incidentrespons als een levenscyclus: voorbereiding, detectie, analyse, containment, eradication, recovery en verbetering. Voor Domain 7 is vooral relevant dat incidentrespons vooraf moet zijn ingericht. Rollen, communicatielijnen, bewijsbehandeling, juridische escalatie en technische bevoegdheden horen niet tijdens het incident te worden ontworpen.
Een beknopt runbook voor phishing of ransomware kan er als volgt uitzien:
- Triageer de melding en bepaal of er sprake is van verdachte inhoud, credential exposure, malware-uitvoering of laterale beweging.
- Beperk de impact door accounts, endpoints of mailitems te isoleren binnen vooraf goedgekeurde bevoegdheden.
- Verwijder de oorzaak door malware, persistence, kwaadaardige regels, gestolen tokens of misbruikte accounts aan te pakken.
- Herstel systemen en toegang op basis van gevalideerde back-ups, schone configuraties en gecontroleerde heractivering.
- Leg lessons learned vast en werk detectieregels, awarenessmateriaal, runbooks en KPI’s bij.
Een runbook is alleen waardevol wanneer het wordt onderhouden. Na elk relevant incident moet het team vastleggen welke stap te traag was, welke informatie ontbrak, welke goedkeuring vertraging veroorzaakte en welke detectie had kunnen helpen. Zo wordt incidentrespons onderdeel van continue verbetering in plaats van een document dat alleen tijdens audits wordt geopend.
Patching, change windows en rollback-plannen
Patchmanagement is een operationeel spanningsveld tussen snelheid en beschikbaarheid. Een kritieke kwetsbaarheid vraagt soms snelle actie, terwijl bedrijfskritische systemen onderhoudsvensters, testprocedures en rollback-plannen nodig hebben. CISSP Domain 7 kijkt daarom niet alleen naar de vraag of een patch wordt geïnstalleerd, maar naar de manier waarop risico, impact en controle worden afgewogen.
Een volwassen patchproces begint met assetinventarisatie en risicoprioritering. Internet-facing systemen, systemen met gevoelige data en componenten waarvoor actieve exploitatie bekend is, krijgen een andere behandeling dan interne systemen met beperkte blootstelling. Zonder actueel assetregister kan een team niet betrouwbaar bepalen waar een kwetsbaarheid bestaat en welke eigenaar moet handelen.
Change management is hierbij geen administratieve hindernis. Het Change Advisory Board-proces helpt om security-impact, afhankelijkheden, onderhoudsvensters, communicatie en rollback te coördineren. Een patch die een kwetsbaarheid sluit maar een productieketen onderbreekt, kan alsnog onacceptabel risico creëren. Omgekeerd kan een te trage wijzigingsprocedure ervoor zorgen dat bekende kwetsbaarheden onnodig lang open blijven.
Rollback verdient dezelfde aandacht als uitrol. Teams moeten weten welke versie wordt teruggezet, welke configuratie geldig was, welke data mogelijk geraakt is en welke monitoring na terugdraaiing nodig is. In Domain 7-termen is dit waar patching, configuration management, change control en recovery planning elkaar raken.
Logging, retentie en de EU-context
Logging is tegelijk een detectiemiddel, een onderzoeksbron en een governancevraagstuk. Voor security operations zijn logs nodig om te begrijpen wat er is gebeurd, wanneer het gebeurde, welke identiteit of service betrokken was en welke systemen geraakt zijn. Voor compliance en forensisch onderzoek is daarnaast belangrijk dat logs betrouwbaar, compleet en beschermd tegen manipulatie zijn.
In een Europese context maken de AVG en NIS2 dit onderwerp scherper. De AVG vraagt dat persoonsgegevens doelgericht, proportioneel en passend beschermd worden verwerkt. NIS2 legt voor veel organisaties meer nadruk op risicobeheer, incidentmelding en bestuurlijke verantwoordelijkheid. Dat betekent dat security operations niet alleen moet bepalen welke logs nuttig zijn, maar ook welke bewaartermijnen gerechtvaardigd zijn, wie toegang heeft en hoe meldpaden tijdig worden geactiveerd.
Retentie is daarbij iets anders dan compliance-archivering. SIEM-data wordt vaak geoptimaliseerd voor snelle zoekacties en correlatie, terwijl archivering gericht kan zijn op langere bewaring, integriteit en bewijswaarde. Voor forensisch gebruik zijn tijdsynchronisatie, toegangscontrole, hashing, write-once-opslag of andere immutability-maatregelen vaak belangrijker dan de hoeveelheid verzamelde data.
ENISA-publicaties over incident handling en Europese cybersecuritypraktijk sluiten aan bij dit operationele perspectief. De les voor Domain 7 is dat logging nooit losstaat van beleid. Een organisatie moet vooraf bepalen welke gebeurtenissen worden vastgelegd, waarom ze nodig zijn, hoe lang ze blijven bestaan en hoe zij gebruikt worden bij detectie, onderzoek en melding.
Fysieke beveiliging, toegangsbeheer en operationele discipline
Security operations beperkt zich niet tot digitale alerts. Domain 7 behandelt ook fysieke beveiliging, personeelsveiligheid, privileged access, media handling en bescherming van operationele omgevingen. Een onbeheerde serverruimte, zwakke bezoekersregistratie of slecht beheerde back-upmedia kan dezelfde impact hebben als een kwetsbare applicatie.
Toegangsbeheer hoort in operations voortdurend te worden gecontroleerd. Least privilege, need-to-know, scheiding van taken en periodieke review van privileged accounts zijn operationele controles, geen eenmalige ontwerpkeuzes. Vooral beheerdersaccounts verdienen extra logging en strengere goedkeuring, omdat misbruik van dergelijke accounts incidenten kan versnellen en onderzoek kan bemoeilijken.
De Cybersecurity Resource Reference Guide illustreert hoe breed operationele cybersecurity kan worden benaderd, van governance en bescherming tot respons en herstel. Voor CISSP-kandidaten is dat nuttig omdat Domain 7 vaak de brug vormt tussen technische handelingen en bestuurlijke verantwoordelijkheid.
Hoe kandidaten Domain 7 beter kunnen benaderen
Een veelgemaakte fout bij de voorbereiding op Domain 7 is het memoriseren van termen zonder het operationele verhaal erachter te begrijpen. Kandidaten kennen dan het verschil tussen incident response en disaster recovery in theorie, maar kiezen in scenario’s toch een herstelactie voordat containment of bewijsbehoud is geregeld. CISSP-vragen belonen meestal het antwoord dat risico beheerst binnen een proces, niet het antwoord dat technisch het snelst lijkt.
Een betere benadering is om elk onderwerp te koppelen aan een werkdag in operations. Monitoring vraagt om logbronnen, use cases en triage. Patching vraagt om assetdata, risico-inschatting, change approval en rollback. Incidentrespons vraagt om rollen, bewijs, containment, communicatie en lessons learned. Door die verbanden te leggen, wordt Domain 7 minder een lijst begrippen en meer een manier van denken.
Wie gestructureerde examenvoorbereiding zoekt, kan de CISSP-training van Readynez gebruiken als aanvulling op praktijkervaring en zelfstudie. Het belangrijkste blijft dat de kandidaat begrijpt waarom een operationele keuze verdedigbaar is, vooral wanneer snelheid, beschikbaarheid, bewijswaarde en compliance met elkaar botsen.
Security Operations als dagelijks vakmanschap
CISSP Domain 7 laat zien dat beveiliging pas betrouwbaar wordt wanneer zij dagelijks uitvoerbaar is. Detectieregels moeten worden afgestemd, logs moeten bruikbaar blijven, incidenten moeten volgens runbooks worden afgehandeld en wijzigingen moeten veilig door productieomgevingen bewegen. De waarde zit in herhaalbaarheid, meetbaarheid en duidelijke besluitvorming.
De praktische vervolgstap is om één operationeel proces te kiezen en dat proces langs Domain 7 te leggen. Een phishing-runbook, patchcyclus of logretentiebeleid kan vaak snel laten zien waar rollen ontbreken, waar automatisering te ver gaat of waar bewijswaarde onvoldoende is. Vanuit die verbetering groeit security operations van losse activiteit naar gecontroleerde uitvoering.
