Sikkerhedsdrift betyder at omsætte brede kontrolkrav til konkrete handlinger, når alarmerne vælter ind, ændringer skal godkendes, og sårbarheder konkurrerer om opmærksomheden.
CISSP Domain 7, Security Operations, handler om den daglige styring af sikkerhed: hændelsesrespons, logning, overvågning, ressourcebeskyttelse, change management, sårbarhedshåndtering, fysisk sikkerhed og driftskontroller. I praksis møder domænet hverdagen i et SOC, i IT-drift og i beredskabsarbejdet, hvor beslutninger skal træffes på ufuldstændige data og under tidspres.
Det gør Domain 7 særligt relevant for danske organisationer. Emnerne passer direkte ind i krav og forventninger omkring GDPR, NIS2, Datatilsynets vejledninger, ISO/IEC 27035, NIST SP 800-61r2 og NIST SP 800-53. Disse kilder bør ikke læses som identiske regelsæt, men som overlappende rammer for at skabe sporbarhed, ansvar, risikobaserede prioriteringer og dokumenterbare processer.
Hvor CISSP Domain 7 møder den operationelle virkelighed
På eksamensniveau kan Domain 7 beskrives som et sæt discipliner. I en organisation er det et samspil mellem mennesker, processer og tekniske kontroller. En alarm i et SIEM-system kan starte som et teknisk signal, men den bliver hurtigt et spørgsmål om ansvar, forretningskritikalitet, databeskyttelse, kommunikation og change control.
Det er også her, mange sikkerhedsprogrammer bliver svagere end dokumentationen antyder. Der kan være en incident response-plan, men ingen har øvet den mod realistiske scenarier. Der kan være logning, men ikke de rigtige identitets-, cloud- eller applikationslogs. Der kan være patch management, men ingen fælles prioritering mellem sikkerhed, applikationsejere og drift.
Domain 7 bør derfor læses som en driftsmodel, ikke som en samling isolerede emner. Hændelsesrespons afhænger af logning. Logning afhænger af aktivstyring. Aktivstyring afhænger af konfigurationsstyring. Change management påvirker både oppetid og sikkerhed. Den praktiske modenhed ligger i, om organisationen kan få disse områder til at fungere sammen, når noget går galt.
SOC-arbejdet: mindre støj, bedre detektion
Et SOC måles ofte på evnen til at opdage og reagere hurtigt, men hastighed alene er et fattigt mål, hvis alarmerne er upræcise. Alert fatigue opstår, når analytikere bruger for meget tid på hændelser, der mangler kontekst, har lav relevans eller gentager kendte mønstre uden at føre til handling. Løsningen er sjældent blot flere regler. Den ligger oftere i bedre detection engineering.
Detection engineering begynder med et brugsscenarie: hvilken adfærd skal opdages, hvorfor er den risikabel, hvilke datakilder er nødvendige, og hvad skal analytikeren gøre bagefter? En mistænkelig privilegeret loginaktivitet kræver eksempelvis andre logs og en anden runbook end en malware-alarm på en almindelig klient. Hvis use casen ikke beskriver triage, eskalering og afslutningskriterier, flyttes kompleksiteten bare fra regeludvikleren til SOC-analytikeren.
En praktisk anvendelse af Domain 7 er derfor at kortlægge domænets begreber til operationelle artefakter: use cases, SIEM-regler, SOAR-playbooks, runbooks, RACI-afklaringer og ITSM-tickets. Hændelseshåndtering bliver først effektiv, når en alarm både har teknisk logik og en tydelig beslutningsvej.
Runbooks og RACI: sådan undgås ticket ping-pong
En almindelig fejl i sikkerhedsdrift er at behandle eskalering som en e-mail eller en ticket uden klart ejerskab. SOC sender sagen til drift, drift sender den til applikationsteamet, og applikationsteamet efterspørger mere dokumentation. Resultatet er forsinket respons og uklare beslutninger, især ved sårbarheder, kompromitterede konti og mistænkelige ændringer.
En RACI-model hjælper, fordi den adskiller den, der udfører arbejdet, fra den, der ejer beslutningen. Ved en kompromitteret privilegeret konto kan SOC være ansvarlig for triage og bevisindsamling, IAM-teamet for spærring eller credential rotation, systemejeren for forretningsmæssig konsekvensvurdering, og incident manageren for koordinering. Legal, DPO eller compliance kan skulle konsulteres, hvis personoplysninger kan være berørt.
Runbooks bør ikke være lange dokumenter, som kun læses under revision. De bør være korte, handlingsorienterede og knyttet til konkrete scenarier. En god runbook forklarer, hvilke signaler der udløser processen, hvilke data der skal indsamles, hvem der skal kontaktes, hvornår sagen eskaleres, og hvornår den kan lukkes. Det giver både SOC og IT-drift et fælles sprog, når en hændelse bevæger sig fra analyse til handling.
Hændelsesrespons med dansk og europæisk kontekst
NIST SP 800-61r2 beskriver incident response som en livscyklus med forberedelse, detektion og analyse, inddæmning, fjernelse, genopretning og læring efter hændelsen. ISO/IEC 27035 arbejder tilsvarende med struktureret håndtering af informationssikkerhedshændelser. For en dansk organisation bør disse rammer kobles til interne politikker, GDPR-forpligtelser, NIS2-arbejde og kommunikationsveje til ledelse og relevante myndigheder.
GDPR gør logning og hændelsesrespons mere nuanceret. Logdata kan være nødvendige for sikkerhed, men de kan også indeholde personoplysninger. Det betyder, at SIEM-opsætninger bør afspejle principper om formålsbegrænsning, dataminimering, adgangsstyring og passende opbevaringsperioder. En organisation bør kunne forklare, hvorfor bestemte logs indsamles, hvor længe de opbevares, hvem der har adgang, og hvordan de bruges ved undersøgelse af hændelser.
Ved potentielle brud på persondatasikkerheden er notifikation ikke kun et teknisk spørgsmål. Der skal være en proces for at vurdere risikoen for registrerede personer, involvere DPO eller juridisk funktion og dokumentere beslutninger. Datatilsynet giver vejledning om håndtering og anmeldelse af brud på persondatasikkerheden, men den konkrete vurdering afhænger af hændelsens karakter. Denne artikel er ikke juridisk rådgivning; pointen er, at Domain 7-processer bør være designet, så de understøtter rettidig vurdering og dokumentation.
Logning, retention og kvalitet frem for volumen
Logning er en af de mest synlige dele af Domain 7, men også en af de mest misforståede. Mere logdata giver ikke automatisk bedre sikkerhed. Uden prioritering kan organisationen ende med højere omkostninger, mere støj og vanskelige privacy-spørgsmål uden væsentligt bedre detektion.
En moden logningsstrategi starter med de vigtigste risici og forretningsprocesser. Identitetslogs, privilegerede handlinger, administrative ændringer, netværksadgang, endpoint-events, cloud control plane-logs og kritiske applikationshændelser har ofte højere sikkerhedsværdi end store mængder lavkontekstdata. Det afgørende er, om loggen kan besvare et undersøgelsesspørgsmål: hvem gjorde hvad, hvornår, hvorfra, mod hvilket aktiv, og med hvilken effekt?
Opbevaringsperioder bør balancere detektionsbehov, efterforskningsbehov, kontraktkrav, regulatoriske krav og dataminimering. Nogle logs er nødvendige i længere tid for at opdage langsomme angreb eller understøtte forensics, mens andre bør forkortes eller aggregeres. Beslutningen bør dokumenteres, fordi den både påvirker sikkerhed, privacy og omkostninger.
Målinger der faktisk forbedrer sikkerhedsdrift
Metrics kan skabe bedre drift, men kun hvis de måler adfærd, der kan forbedres. Antallet af alarmer behandlet pr. dag siger lidt om kvaliteten af detektionerne. En organisation kan behandle mange alarmer og stadig overse de vigtigste angreb, hvis datakilderne er svage eller triage-processen er uklar.
MTTA, mean time to acknowledge, kan vise hvor hurtigt en alarm bliver set. MTTR, mean time to respond eller recover afhængigt af definition, kan vise hvor hurtigt organisationen handler eller genopretter. False positive-rate kan pege på behov for bedre regelkvalitet. Log coverage kan afsløre blinde vinkler, for eksempel manglende cloud trail-logs, utilstrækkelig endpoint-telemetri eller manglende integration fra SaaS-platforme.
Det vigtige er at koble målingerne til forbedringsarbejde. Hvis MTTA er høj uden for normal arbejdstid, kan problemet være bemanding, alarmeringsveje eller prioritering. Hvis MTTR er høj for kontokompromittering, kan årsagen være uklare IAM-handoffs. Hvis false positives er høje for en bestemt regel, bør use casen justeres, beriges med kontekst eller pensioneres. Metrics bør føre til ændringer i runbooks, datakilder og ansvar, ikke kun til rapportering.
Patch management og konfigurationsstyring som risikostyring
Patch management bliver ofte fremstillet som en lineær proces: find sårbarheden, test patchen og udrul den. I virkeligheden konkurrerer patches med oppetidskrav, afhængigheder, legacy-systemer og change windows. Domain 7 kræver derfor en risikobaseret tilgang, hvor sikkerhed og drift træffer prioriteringer på samme grundlag.
En enkel prioriteringsmodel kan tage udgangspunkt i fire spørgsmål: hvor forretningskritisk er aktivet, findes der tegn på aktiv udnyttelse eller høj trusselsrelevans, hvor eksponeret er systemet, og er der konkrete compliancekrav? Et interneteksponeret system med privilegeret adgang eller følsomme data bør normalt prioriteres højere end en intern lavkritisk komponent uden kendt udnyttelse. Samme model kan bruges til både patching, logging og change-processer, fordi den binder teknisk risiko til forretningsmæssig konsekvens.
Konfigurationsstyring spiller en lignende rolle. Baselines for servere, endpoints, cloud-konti, netværksenheder og identitetspolitikker gør det muligt at opdage uautoriserede ændringer og drift fra godkendte standarder. Når en hændelse undersøges, kan konfigurationshistorik være forskellen på en uklar mistanke og en dokumenteret ændring, der kan spores tilbage til en change request eller en kompromitteret konto.
Change management uden at bremse sikkerheden
Change management skal beskytte stabilitet, men processen må ikke blive så tung, at kritiske sikkerhedsændringer forsinkes unødigt. Det kræver forskellige spor for normale ændringer, standardændringer og nødændringer. En firewallændring, en IAM-politik, en endpoint-konfiguration og en kritisk patch har ikke samme risikoprofil, selv om de alle kan påvirke sikkerheden.
Den praktiske udfordring er at bevare sporbarhed uden at skabe bureaukrati. En nødændring bør stadig dokumenteres, risikovurderes og efterbehandles, men godkendelsesvejen kan være kortere, når truslen er aktiv. Efterfølgende review er vigtigt, fordi hastige ændringer kan indføre nye sårbarheder eller driftsproblemer.
Her er forbindelsen mellem Domain 7 og ITSM tydelig. Incident management fokuserer på at begrænse og løse en hændelse. Problem management undersøger den underliggende årsag. Change management styrer den varige ændring. Hvis disse processer ikke hænger sammen, lukker organisationen måske alarmen uden at fjerne årsagen.
Cloud og SaaS ændrer sikkerhedsoperationerne
Cloud-drift ændrer ikke Domain 7-principperne, men den ændrer datakilder, ansvar og tempo. Workloads kan være kortlivede, infrastruktur kan oprettes gennem kode, og identitet bliver ofte den vigtigste kontrolflade. En traditionel serverbaseret logningsstrategi fanger ikke nødvendigvis ændringer i cloud control plane, API-kald, service principals, adgangsnøgler eller cross-account aktivitet.
Shared responsibility betyder, at leverandøren sikrer dele af platformen, mens kunden stadig har ansvar for konfiguration, adgang, data, applikationer og overvågning inden for kundens kontrolområde. Mange hændelser i cloudmiljøer skyldes ikke svigt i den underliggende platform, men fejlkonfigurationer, for brede rettigheder, manglende logging eller svage processer for secrets og nøgler.
SaaS skaber en tilsvarende udfordring. Kritiske data ligger ofte i samarbejdsplatforme, CRM-systemer, HR-systemer og supportværktøjer, men logadgang, retention og eksportmuligheder varierer. Sikkerhedsdrift bør derfor stille krav til audit logs, administratorhandlinger, integrationer, datadeling og identitetskontroller, før en SaaS-tjeneste bliver forretningskritisk.
Ressourcebeskyttelse, privilegerede konti og fysisk sikkerhed
Domain 7 omfatter også kontroller, der let bliver undervurderet i tekniske sikkerhedsprogrammer. Ressourcebeskyttelse handler om at sikre, at aktiver, data, systemer og faciliteter behandles efter deres værdi og risiko. Det kræver klassifikation, ejerskab og procedurer for håndtering gennem hele livscyklussen.
Privilegerede konti kræver særlig opmærksomhed, fordi de ofte er målet for både interne misbrugsscenarier og eksterne angreb. Praktiske kontroller omfatter mindst privilegium, separate administrative konti, stærk autentifikation, just-in-time adgang, sessionslogning og regelmæssig review af rettigheder. Det vigtigste er, at privilegeret aktivitet kan forklares og spores.
Fysisk sikkerhed og personaleprocesser har stadig betydning, selv i cloudbaserede organisationer. Adgang til lokaler, udstyr, backupmedier, netværksporte og administrative arbejdsstationer kan påvirke den digitale sikkerhed direkte. Jobrotation, feriekrav og funktionsadskillelse kan også reducere risikoen for uopdagede fejl eller misbrug, hvis de anvendes med respekt for organisationens størrelse og arbejdsgange.
Fra CISSP-forberedelse til bedre drift
CISSP-kandidater bør læse Domain 7 med to perspektiver. Det ene er eksamensperspektivet, hvor begreber, ansvar og kontroltyper skal forstås præcist. Det andet er driftsmæssigt, hvor de samme begreber skal bruges til at analysere realistiske situationer: Hvem ejer handlingen? Hvilke logs er nødvendige? Hvilken risiko prioriteres først? Hvordan dokumenteres beslutningen?
Den kobling er også værdifuld for driftsteams, der ikke nødvendigvis arbejder mod certificering. Domain 7 kan bruges som et fælles referencepunkt mellem SOC, IT-drift, compliance, risikostyring og ledelse. Readynez kan indgå som struktureret CISSP-forberedelse for kandidater, der har brug for at forbinde domænekravene med praktiske sikkerhedsoperationer, men selve værdien ligger i, at organisationen kan omsætte begreberne til bedre beslutninger.
En nyttig øvelse er at tage en nylig hændelse eller næsten-hændelse og gennemgå den gennem Domain 7-briller. Var aktivet kendt? Var logningen tilstrækkelig? Fandtes der en runbook? Var RACI tydelig? Blev ændringen dokumenteret? Blev læringen omsat til en forbedring? Denne type review gør domænet konkret og afslører ofte svagheder, som ikke fremgår af politikkerne.
Et mere modent Domain 7-program
Et modent sikkerhedsoperationsprogram er kendetegnet ved sammenhæng. Logning understøtter detektion. Detektioner udløser runbooks. Runbooks skaber klare handoffs. Hændelser fører til problem- og change-processer. Metrics viser, hvor processen halter. Cloud- og SaaS-miljøer indgår i samme styringsmodel som traditionelle systemer, men med datakilder og ansvar tilpasset deres arkitektur.
Det mest effektive næste skridt er at vælge et område, hvor risikoen er høj og friktionen tydelig: kontokompromittering, patchprioritering, cloud logging eller incident handoffs. Når organisationen forbedrer én gennemgående arbejdsgang fra signal til handling, bliver CISSP Domain 7 mere end teori. Det bliver en praktisk model for sikker drift. Hvis målet også er certificering, kan Readynez bruges som en struktureret vej gennem stoffet, mens den daglige praksis giver den kontekst, der gør domænet lettere at forstå og anvende.
Se den oprindelige cybersikkerhedsreference, som den tidligere artikel henviste til, hvis der er behov for en bredere ressourceoversigt over sikkerhedsbegreber og operationelle kontroller. For a deeper dive, see Omfattende guide til CISSP-certificering: Løft din.
