CISSP Domæne 4 handler om at koble klassisk netværksteori til de sikkerhedsbeslutninger, som CISSP-kandidater møder i moderne miljøer.
CISSP Domæne 4 handler om kommunikation og netværkssikkerhed: hvordan data beskyttes i transit, hvordan netværk designes og segmenteres, hvordan trafik overvåges, og hvordan organisationer vælger de rette kontroller til kablede, trådløse, cloud- og fjernadgangsmiljøer.
Opdateret for 2026: Denne gennemgang er skrevet med udgangspunkt i den aktuelle CISSP Common Body of Knowledge og eksamensrammen fra ISC2, men den gengiver ikke rigtige eksamensspørgsmål. Formålet er at forklare domænets principper på en måde, der både hjælper til eksamensforberedelse og til praktisk sikkerhedsarbejde i danske og europæiske organisationer.
Den oprindelige debat om netværkssikkerhed blev ofte drevet af væksten i datamængder og cyberangreb. Ældre kilder beskriver blandt andet forventninger om 175 zettabyte data og generelle cybersikkerhedsstatistikker, men Domæne 4 bør ikke forstås gennem løse tal alene. Det afgørende er, at organisationers forretningsprocesser, identiteter, applikationer og cloudmiljøer nu er afhængige af netværksforbindelser, der skal kunne beskyttes, måles og afbrydes kontrolleret ved mistanke om kompromittering.
Hvad CISSP Domæne 4 dækker
Domæne 4 tester forståelsen af sikre netværksarkitekturer, kommunikationskanaler, netværkskomponenter, protokoller, trådløs sikkerhed, fjernadgang og metoder til detektion og forebyggelse. Kandidaten forventes at kunne forklare, hvorfor en kontrol hører hjemme et bestemt sted i arkitekturen, og hvilke begrænsninger den har.
Det betyder, at Domæne 4 sjældent kun handler om at huske definitioner. En eksamensnær opgave kan eksempelvis beskrive et site-to-site-scenarie, et fjernadministrationsbehov eller en mistanke om dataeksfiltrering og derefter spørge efter den mest passende kontrol. Den rette løsning afhænger ofte af OSI-lag, tillidsgrænser, risiko, driftskrav og om organisationen har brug for fortrolighed, integritet, tilgængelighed eller ikke-afvisning.
CISSP er bredere end en teknisk netværkseksamen, men netværksbegreberne skal sidde fast. Kandidater, der ønsker et struktureret forløb, kan bruge CISSP-certificeringsforberedelse som supplement til egen læsning, labs og gennemgang af ISC2's officielle domænebeskrivelser.
Netværksdesign som sikkerhedskontrol
Et sikkert netværk starter ikke med en firewallregel, men med en arkitektur, der gør normal trafik forståelig og unormal trafik synlig. Segmentering, routing, navngivning, asset-inventar, identitet og logning skal hænge sammen, ellers bliver kontrollerne svære at håndhæve og endnu sværere at efterforske.
Zero Trust og SASE har gjort denne pointe tydeligere. Segmentering er ikke længere kun en perimeterøvelse mellem “internt” og “eksternt”; den bør også afspejle brugeridentitet, enhedstilstand, applikationsfølsomhed og udgående adgang. En flad VPC eller VNet i cloud kan give angribere gode muligheder for lateral bevægelse, selv når de indgående regler ser stramme ud.
En praktisk faldgrube er mikrosegmentering uden opdaterede inventarlister. Hvis ingen ved, hvilke systemer der taler sammen, ender projektet ofte i for brede undtagelser eller driftsstop. En anden fejl er uklar ejerskab af egress-politikker: netværksteamet kan eje firewallen, applikationsteamet kan kende trafikken, og sikkerhedsteamet kan få alarmerne, men ingen har mandat til at afvise ukendt udgående trafik.
Protokoller: TLS, IPsec og SSH i det rigtige scenarie
En typisk misforståelse i Domæne 4 er at behandle krypterede protokoller som udskiftelige. TLS, IPsec og SSH kan alle beskytte kommunikation, men de løser forskellige problemer og opererer på forskellige abstraktionsniveauer. Det er ofte netop forskellen, der afgør det rigtige svar i en eksamenscase.
TLS bruges typisk til at beskytte applikationskommunikation, for eksempel webtrafik, API-kald eller service-til-service-kommunikation. IPsec passer bedre, når hele netværksforbindelser eller host-to-host-forbindelser skal sikres på netværkslaget, særligt ved site-to-site VPN eller specifikke transport-/tunneltilstande. SSH er primært relevant til sikker administration, kommandolinjeadgang og visse former for tunneling, men bør ikke bruges som generel erstatning for en designet netværkskontrol.
| Scenarie | Typisk valg | Hvorfor det passer |
|---|
| Webapplikation eller API mellem klient og server | TLS | Beskytter applikationssessionen og understøtter certifikatbaseret servervalidering. |
| Site-to-site-forbindelse mellem to netværk | IPsec | Beskytter trafik på netværkslaget og kan anvende tunneltilstand mellem gateways. |
| Sikker administration af en Linux-server eller netværksenhed | SSH | Giver krypteret fjernadministration og stærk autentificering, når nøgler og adgangspolitik håndteres korrekt. |
SSL bør kun nævnes som historisk kontekst eller som noget, der skal udfases; moderne design bør anvende TLS i understøttede versioner og med korrekt certifikathåndtering. IPsec kræver også præcision: AH giver integritets- og autenticitetsfunktioner, mens ESP kan give fortrolighed, integritet og autentificering afhængigt af konfigurationen. I praksis er ESP det centrale valg i mange sikre VPN-designs.
Kryptering, inspektion og EU-hensyn
Kryptering beskytter data i transit, men den ændrer også sikkerhedsteamets synlighed. TLS 1.3, krypterede DNS-varianter og udviklingen omkring krypteret klienthello kan gøre klassisk indholdsinspektion vanskeligere. Derfor må Domæne 4 forstås sammen med logkilder, metadata, endepunktstelemetri og applikationskontrol.
I EU er krypteret trafikinspektion ikke kun et teknisk spørgsmål. TLS-proxy, certifikatinspektion og fingerprinting som JA3 kan være relevante i bestemte miljøer, men GDPR, proportionalitet, medarbejderprivatliv og dataminimering skal indgå i vurderingen. Datatilsynet, CFCS, ENISA og NIST-rammeværk som SP 800-53 og SP 800-207 kan bruges som referencepunkter, men den konkrete beslutning bør dokumenteres i organisationens risikovurdering og politikker.
Det betyder ikke, at organisationer skal undlade inspektion. Det betyder, at de skal vælge den rigtige grad af synlighed. For eksempel kan en virksomhed dekryptere trafik til kendte højrisikokategorier, undtage sundheds- eller bankrelateret privat trafik og samtidig bruge DNS-logning, proxylogs, egress-alarmer og endepunktsdetektion til at opdage afvigelser uden at åbne al kommunikation.
IDS, IPS, port-spejling og trafikovervågning
IDS og IPS er centrale begreber i Domæne 4, men forskellen er vigtig. Et IDS observerer og alarmerer, mens et IPS kan blokere eller ændre trafikflowet. Det gør IPS mere aktivt, men også mere følsomt over for falske positiver, som kan påvirke drift.
Port-spejling, SPAN-porte og TAPs bruges til at give analyseværktøjer adgang til trafik uden nødvendigvis at placere dem inline. En almindelig fejl er at forveksle promiskuøs tilstand med port-spejling. Promiskuøs tilstand er en indstilling på et netværksinterface, der accepterer flere rammer til analyse; port-spejling er en switchfunktion, der kopierer trafik fra udvalgte porte eller VLANs til en overvågningsport.
Overvågning bliver mest værdifuld, når den knyttes til en driftbar reaktionsmodel. Ved mistanke om DDoS, MITM eller dataeksfiltrering bør teamet have playbooks for packet capture, egress-anomalier og “contain without kill”, hvor forbindelser begrænses uden straks at ødelægge beviser eller afbryde kritiske forretningsprocesser.
Egress-kontrol og dataeksfiltrering
Egress-overvågning er analysen af trafik, der forlader miljøet. Den bliver ofte undervurderet, fordi mange sikkerhedsprogrammer historisk har fokuseret på indgående trusler. Moderne kompromitteringer handler imidlertid ofte om udgående kommando-og-kontrol, ukendt cloudlagring, tunneler eller stille eksfiltrering over legitime protokoller.
En god egress-model starter med forventet adfærd. Hvilke workloads må tale med internettet, hvilke må kun tale med private endpoints, og hvilke destinationer er forretningskritiske? I cloud bør security groups, NSG'er, private endpoints og routingtabeller gennemgås sammen, fordi en tilladt udgående regel kan ophæve værdien af pæn intern segmentering.
Det praktiske mål er ikke at blokere alt. Det er at gøre ukendt udgående trafik synlig, få ejerskab på undtagelser og teste alarmerne. En mini-lab kan være at oprette en test-workload, begrænse dens udgående adgang til en tilladelsesliste og derefter verificere, at forsøg på ukendte destinationer udløser logning og en reaktionsopgave.
Trådløs sikkerhed og fjernadgang
Trådløse netværk ændrer trusselsmodellen, fordi signalet ikke respekterer vægge og kabler. Domæne 4 lægger derfor vægt på sikre standarder, stærk autentificering og korrekt segmentering af gæste-, medarbejder- og administrationsnetværk. WEP og forældede WPA-konfigurationer bør kun betragtes som eksempler på svage eller udfasede løsninger.
I moderne miljøer bør WPA3, 802.1X, certifikatbaseret autentificering og netværksadgangskontrol vurderes efter risiko og brugerbehov. Et gæstenetværk bør ikke blot have en anden adgangskode; det bør være logisk adskilt, have begrænset adgang og være overvåget som en separat zone.
Fjernadgang kræver samme disciplin. VPN, ZTNA-løsninger og administrative bastion hosts kan alle være relevante, men valget bør afhænge af applikationstype, identitetskontrol, enhedstillid og logning. SSH direkte fra internettet til produktionssystemer er sjældent et godt design, selv om selve protokollen er sikker, fordi eksponeringen og adgangsstyringen ofte bliver problemet.
Cloud og virtualisering i Domæne 4
Cloud gør netværk mere softwaredefineret, men ikke mindre netværksafhængigt. Security groups, NSG'er, route tables, private endpoints, load balancers og virtuelle firewalls udgør stadig sikkerhedsgrænser, der skal designes og testes. En fejlkonfigureret regel kan flyttes hurtigt gennem infrastrukturkode, hvilket gør ændringskontrol og review afgørende.
Virtualisering tilføjer også øst-vest-trafik, som ikke altid passerer traditionelle perimeterkontroller. Workloads på samme host, samme subnet eller samme cluster kan kommunikere på måder, der kræver mikrosegmentering, hostbaseret firewalling og telemetri fra platformen. Her mødes Domæne 4 med arkitekturprincipper fra andre CISSP-domæner, særligt sikkerhedsarkitektur og risikostyring.
En praktisk test er at spørge, hvordan en kompromitteret workload opdages, begrænses og genskabes. Hvis svaret kun er “firewallen stopper det”, mangler designet sandsynligvis synlighed i interne flows, identitetsbaseret adgang og egress-kontrol.
Mini-labs der gør teorien konkret
Domæne 4 bliver lettere at forstå, når begreberne afprøves kontrolleret. Labs bør ikke være store for at være nyttige; de skal blot forbinde observationer med de beslutninger, eksamen og drift kræver. Wireshark, en lokal testserver, en skybaseret testkonto eller et lille virtuelt labmiljø kan være nok.
- Optag en TLS-session i Wireshark og identificer handshake, certifikatoplysninger og krypteret applikationsdata.
- Sammenlign en SSH-administrationssession med almindelig webtrafik og noter forskellen i formål og protokolvalg.
- Konfigurer en simpel tilladelsesliste for udgående trafik i et testmiljø og bekræft, at afviste destinationer logges.
- Spejl trafik til et analyseværktøj og dokumentér forskellen mellem SPAN-konfiguration og promiskuøs interface-tilstand.
Efter hver lab bør kandidaten skrive en kort forklaring: hvilken risiko kontrolleres, hvilket OSI-lag er relevant, og hvilke logs ville være nødvendige under en hændelse? Den øvelse træner den form for begrundet valg, som Domæne 4 ofte kræver.
Eksamenstænkning uden at lære udenad
CISSP-spørgsmål belønner typisk det mest risikobaserede og passende svar, ikke nødvendigvis den mest teknisk avancerede løsning. Hvis et spørgsmål handler om ledelse, politik eller ansvar, er et dybt teknisk værktøj ikke altid korrekt. Hvis spørgsmålet handler om konkret trafikbeskyttelse, er OSI-lag og protokolformål derimod ofte afgørende.
Et generisk prøveeksempel kan være: En organisation skal sikre al trafik mellem to datacentre over et ikke-betroet netværk uden at ændre applikationerne. Det mest sandsynlige valg er IPsec i tunneltilstand, fordi kravet ligger på netværksforbindelsen mellem miljøer, ikke på en enkelt webapplikation. Hvis scenariet i stedet beskrev en offentlig webapplikation, ville TLS være det mere oplagte svar.
Et andet eksempel: Et SOC-team ser store udgående datamængder fra en server til en ukendt destination. Den første modne reaktion er ikke nødvendigvis at slukke serveren. I mange miljøer bør teamet begrænse udgående adgang, bevare beviser, starte packet capture efter playbook og eskalere efter hændelsesklassifikation.
Hvor Domæne 4 passer ind i sikkerhedsarbejdet
Kommunikation og netværkssikkerhed er et praktisk domæne, fordi næsten alle sikkerhedshændelser efterlader spor i forbindelser, flows, DNS, identitet eller udgående trafik. Den stærke CISSP-kandidat kan derfor forklare både principperne og konsekvenserne: hvorfor segmentering reducerer lateral bevægelse, hvorfor TLS ikke løser alle tillidsproblemer, og hvorfor egress-kontrol ofte afslører hændelser, som perimeteren overser.
Readynez kan indgå som en neutral del af en bredere forberedelsesplan, men den vigtigste læring kommer af at kombinere CISSP-læsemateriale med scenarier, små labs og refleksion over egne netværksdesigns. Den mest effektive næste handling er at vælge tre Domæne 4-emner, for eksempel IPsec/TLS/SSH, egress-kontrol og IDS/IPS, og forklare dem med både eksamenslogik og en konkret driftscase.
