# Guide til synopsis i Netværks- og Kommunikationssikkerhed > For hver gang du skriver *"jeg gjorde"*, så spørg dig selv: > > **"Hvorfor gjorde jeg det, og hvilke sikkerhedsmæssige konsekvenser har det?"** > > Det er ofte i besvarelsen af dette spørgsmål, at den sikkerhedsfaglige analyse opstår. ## Formålet med en synopsis En synopsis er ikke en projektlog og heller ikke en installationsvejledning. Målet er ikke at dokumentere alle de trin, der blev udført under projektet. Målet er derimod at undersøge et sikkerhedsfagligt problem, begrunde de valg der træffes, analysere resultaterne og reflektere over løsningens styrker og svagheder. En god synopsis viser derfor ikke blot *hvad* der er gjort, men især *hvorfor* det er gjort, og hvilke konsekvenser det har for sikkerheden. Som tommelfingerregel bør en læser kunne forstå: - Hvilket problem der undersøges. - Hvilken teori der ligger bag løsningen. - Hvorfor løsningen er designet som den er. - Hvad testene viser. - Hvilke begrænsninger løsningen har. - Hvad der kan læres af projektet. --- # 1. Problemformulering **Omfang:** ca. ½ side Problemformuleringen er fundamentet for hele synopsen. Den skal beskrive det konkrete spørgsmål eller problem, som projektet søger at besvare. En god problemformulering er: - Konkret - Afgrænset - Undersøgbar - Relevant for netværks- og kommunikationssikkerhed ### Eksempler #### Mindre præcis > Hvordan virker WireGuard? #### Mere præcis > Hvordan kan WireGuard implementeres som sikker fjernadgang til et privat netværk, og hvilke sikkerhedsmæssige fordele og udfordringer medfører løsningen? ### Husk Problemformuleringen skal kunne besvares i konklusionen. Hvis du ikke kan forestille dig en klar konklusion, er problemformuleringen sandsynligvis for bred. --- # 2. Afgrænsning **Omfang:** ca. ¼ side Ingen projekter kan undersøge alt. Afgrænsningen beskriver derfor bevidst, hvad projektet ikke omfatter. Dette hjælper læseren med at forstå projektets fokus og begrænsninger. ### Eksempler - Opgaven fokuserer på WireGuard og sammenligner ikke med OpenVPN eller IPSec. - Opgaven undersøger detektion af brute-force-angreb, men ikke automatiseret respons. - Opgaven analyserer OAuth 2.0, men ikke OpenID Connect. En tydelig afgrænsning viser, at der er truffet bevidste valg. --- # 3. Teoretisk fundament **Omfang:** 1½–2 sider Teoriafsnittet skal introducere de begreber, modeller og teknologier, som anvendes senere i projektet. Teorien skal være relevant for problemformuleringen og må ikke udvikle sig til en generel lærebogsgennemgang. ## Formålet med teorien Teorien skal give læseren den nødvendige baggrundsviden til at forstå: - Designvalg - Implementering - Testresultater - Diskussion og refleksion ## Eksempler på relevant teori ### Honeypot-projekter - Honeypots - Brute-force-angreb - Threat Intelligence - MITRE ATT&CK - Prevent-Detect-React ### VPN-projekter - VPN-teknologi - Kryptering - Tunnelering - Segmentering - Adgangskontrol ### IDS/IPS-projekter - IDS og IPS - Signaturbaseret detektion - Adfærdsbaseret detektion - False positives og false negatives ### Autentificering og autorisation - OAuth - JWT - Identitetsstyring - Least Privilege ## Gode råd Forklar teorien med egne ord. Undgå lange definitioner uden sammenhæng til projektet. Spørg dig selv: > Kommer jeg til at bruge denne teori senere? Hvis svaret er nej, bør teorien sandsynligvis fjernes. --- # 4. Design og metode **Omfang:** 1–1½ side Dette afsnit beskriver den valgte løsning og forklarer de designmæssige overvejelser bag projektet. Mange projekter indeholder flere mulige teknologier og tilgange. Derfor er det vigtigt at forklare, hvorfor netop denne løsning blev valgt. ## Beskriv - Arkitektur - Komponenter - Netværksdesign - Datastrømme - Valgte teknologier ## Forklar - Hvorfor netop denne teknologi blev valgt - Hvilke alternativer der fandtes - Hvilke fordele og ulemper valget medfører ### Eksempel I stedet for: > Jeg valgte WireGuard. Forklar: > WireGuard blev valgt, fordi løsningen er lettere at konfigurere end OpenVPN, samtidig med at den anvender moderne kryptografiske algoritmer og et mindre kodegrundlag. ## Diagrammer Diagrammer og netværkstegninger kan ofte forklare komplekse sammenhænge langt mere effektivt end tekst. Brug dem gerne. --- # 5. Implementering **Omfang:** 1–1½ side Implementeringsafsnittet beskriver de vigtigste dele af den konkrete opsætning. Formålet er ikke at dokumentere alle klik og kommandoer. Fokus bør være på de elementer, der har sikkerhedsmæssig betydning. ## Beskriv eksempelvis - Segmentering - Firewallregler - VPN-konfiguration - IDS-regler - Honeypot-konfiguration - OAuth-flow ## Undgå Lange trin-for-trin guider. Læseren skal forstå løsningen – ikke nødvendigvis kunne genskabe den alene ud fra synopsen. --- # 6. Test og analyse **Omfang:** 1½–2 sider Dette er ofte synopsisens vigtigste afsnit. Her dokumenteres det, om løsningen virker som forventet. ## Test Beskriv: - Hvad der testes - Hvordan det testes - Hvilket resultat der forventes ### Eksempel #### Positiv test VPN-klienten kan tilgå webserveren i DMZ. #### Negativ test VPN-klienten kan ikke tilgå management-netværket. ## Analyse Analyse handler om at fortolke resultaterne. ### Beskriv ikke kun resultatet I stedet for: > Ping virkede. Forklar: > Testen viser, at routing og firewallregler fungerer som planlagt, og at klienten kun har adgang til de netværk, der er tilladt. ### Overvej - Hvad viser resultatet? - Hvorfor virker det? - Hvilke sikkerhedsmæssige konsekvenser har det? - Hvilke begrænsninger har testen? --- # 7. Diskussion og refleksion **Omfang:** ca. 1 side Her vurderes projektet kritisk. Dette afsnit handler om at demonstrere forståelse for, at ingen sikkerhedsløsning er perfekt. ## Mulige refleksioner ### Begrænsninger - Hvad blev ikke testet? - Hvilke antagelser bygger løsningen på? ### Risici - Hvad kan stadig gå galt? - Hvilke angreb er stadig mulige? ### Alternativer - Kunne en anden teknologi have været valgt? - Hvilke kompromiser er der foretaget? ### Realisme - Hvordan ville løsningen fungere i en virksomhed? - Hvilke udfordringer ville opstå i større skala? ## Gode emner - Least Privilege - Defense in Depth - Segmentering - Zero Trust - Threat Intelligence - Compliance - Brugeradfærd - Fejlkonfigurationer --- # 8. Konklusion **Omfang:** ca. ½ side Konklusionen skal besvare problemformuleringen direkte. Den skal samle projektets vigtigste resultater og vurderinger. ## En god konklusion - Besvarer problemformuleringen - Fremhæver de vigtigste resultater - Samler analysens centrale pointer ## Undgå At genfortælle hele projektet. Konklusionen skal være svaret på det spørgsmål, der blev stillet i starten. --- # Anbefalet fordeling af de 8 normalsider | Afsnit | Omfang | |---------|---------:| | Problemformulering | 0,5 side | | Afgrænsning | 0,25 side | | Teoretisk fundament | 1,5–2 sider | | Design og metode | 1–1,5 side | | Implementering | 1–1,5 side | | Test og analyse | 1,5–2 sider | | Diskussion og refleksion | 1 side | | Konklusion | 0,5 side | --- # Afsluttende råd En synopsis i Netværks- og Kommunikationssikkerhed bør ikke læses som en installationsvejledning. Den bør læses som en sikkerhedsfaglig undersøgelse. Fokusér derfor på: - Hvorfor løsningen er valgt. - Hvordan den understøtter sikkerheden. - Hvilke resultater der opnås. - Hvilke begrænsninger der findes. - Hvad der kan læres af projektet. Når læseren er færdig med synopsen, skal det være tydeligt, at du ikke blot kan implementere en løsning – men også forstå, analysere og vurdere den.