Security by design
Også kendt som: indbygget sikkerhed
At tænke sikkerhed ind fra starten i systemer og processer i stedet for at tilføje den til sidst.
Kladde - dette opslag er endnu ikke gennemgået.
Formelt
Princippet om, at sikkerhedsbehov fastlægges og opfyldes i alle faser af at bygge et system eller en proces - fra den første idé over design og udvikling til drift - med sikre indstillinger som standard.
Forklaret enkelt
Som at planlægge ledningerne, før væggene sættes op - gør man det bagefter, må man rive vægge ned.
I praksis
Før en kommune får bygget en ny selvbetjeningsportal til borgerne, kræver projektgruppen MFA til medarbejdernes login og så få personoplysninger som muligt, og skriver begge dele ind i kontrakten med leverandøren.
Hvorfor det betyder noget
Det koster langt mere at rette en svaghed efter lancering end at undgå den på tegnebrættet, og nogle svagheder kan slet ikke rettes uden at starte forfra.
Sådan kommer du i gang
De typiske trin i rækkefølge. Tilpas dem til jeres organisation.
- Fastlæg sikkerhedskravene allerede på idéstadiet sammen med de funktionelle krav, ud fra de data og tjenester, systemet håndterer, og regler som NIS2, GDPR eller CRA.
- Tegn arkitekturen med dataflow og tillidsgrænser, og lav en trusselsmodel med en metode som STRIDE, før udviklingen begynder.
- Vælg designprincipper, der fjerner hele klasser af fejl, fx mindst mulige rettigheder, sikre fejltilstande, kontrol af hver adgang, enkle mekanismer og hukommelsessikre sprog, hvor det er muligt.
- Gør den sikre indstilling til standard - ingen standardadgangskoder, ubrugte tjenester slået fra, og MFA, logning og kryptering slået til uden ekstra pris eller besvær for brugeren.
- Skriv kravene ind i kontrakter og acceptkriterier, når I køber eller outsourcer udvikling, så leverandøren skal vise, hvordan hvert krav er opfyldt.
- Kontrollér design og kode undervejs med gennemgange og automatiske test, ikke kun med en penetrationstest til sidst.
- Lever vejledning i hærdning og en klar vej til at modtage og rette sårbarhedsrapporter, og gentag trusselsmodellen, hver gang designet ændres.
Typiske faldgruber
- At regne en penetrationstest før lancering for security by design, selv om arkitektoniske fejl, der findes på det tidspunkt, er dyre eller umulige at rette.
- At lade sikre indstillinger være tilvalg, som kunden selv skal slå til, i stedet for at gøre dem til standard.
- At skrive vage krav som "systemet skal være sikkert", som hverken kan testes eller holdes op mod en leverandør.
Gode vejledninger
- D-mærkets kriterier(åbner i en ny fane) · D-mærket
- Secure by Design(åbner i en ny fane) · CISA (på engelsk)
- Secure design principles(åbner i en ny fane) · NCSC UK (på engelsk)
- NIST SP 800-160 Vol. 1 Rev. 1 - Engineering Trustworthy Secure Systems(åbner i en ny fane) · NIST (på engelsk)
Teknisk uddybning
Security by design er princippet om, at sikkerhedskrav udledes, implementeres og verificeres gennem hele systemets udviklingslivscyklus frem for at blive sat på lige før udgivelse, og at systemer leveres i en sikker konfiguration som standard. Det parres ofte med den beslægtede idé secure by default: den leverede tilstand minimerer angrebsfladen (unødvendige tjenester slået fra, ingen standardadgangskoder, least-privilege som standard, kryptering slået til), så en bruger, der ikke ændrer noget, stadig er rimeligt beskyttet. Det økonomiske argument er veletableret: fejl er langt billigere at fjerne tidligt, og nogle arkitektoniske svagheder - en fejlagtig tillidsmodel, manglende adskillelse mellem lejere, en autentificeringsmodel, der ikke kan eftermonteres - kan ikke patches senere uden redesign, og derfor lægger disciplinen vægt på krav- og designfaserne, ikke kun på sikker kodning.
I ingeniørpraksis operationaliseres dette gennem en secure development lifecycle (Microsoft SDL, OWASP SAMM, BSIMM som modenhedsmålestok). Kerneaktiviteter omfatter trusselsmodellering under design (STRIDE til at opregne spoofing, tampering, repudiation, information disclosure, denial of service og elevation of privilege; attack trees; dataflowdiagrammer med tillidsgrænser), analyse af misbrugstilfælde ved siden af use cases og valg af gennemprøvede designprincipper, som Saltzer og Schroeder formulerede i 1975 - economy of mechanism, fail-safe defaults, complete mediation, open design, least privilege, separation of privilege, least common mechanism og psychological acceptability. Senere faser tilføjer standarder for sikker kodning, SAST og DAST i pipelinen, software composition analysis af afhængigheder og sikkerhedstest-gates før udgivelse. NIST SP 800-160 Vol. 1 (Engineering Trustworthy Secure Systems) leverer den systemtekniske indramning.
Begrebet har bevæget sig fra god praksis mod pligt. GDPR artikel 25 gør "databeskyttelse gennem design og gennem standardindstillinger" til et lovkrav ved behandling af personoplysninger, så privatlivsrelevante designbeslutninger skal minimere data og som standard vælge de mest beskyttende indstillinger. EU's Cyber Resilience Act stiller væsentlige cybersikkerhedskrav til produkter med digitale elementer, herunder secure-by-default-konfiguration og håndtering af sårbarheder, med forpligtelser, der indfases, og indberetningspligter, der gælder fra 11. september 2026. CISA's internationale "Secure by Design"-vejledning skubber yderligere ansvaret over på producenterne frem for slutbrugerne. NIS2 artikel 21 understøtter samme forventning for væsentlige og vigtige enheder.
En vedholdende misforståelse sætter lighedstegn mellem security by design og blot at køre en penetrationstest før lancering; test til sidst validerer, men kan ikke erstatte designbeslutninger, der allerede er indbygget, og en pentest, der finder en arkitektonisk fejl, finder den typisk for sent til at rette billigt. En anden er at opfatte "secure by default" som absolut - standardindstillinger sænker risikoen for det gennemsnitlige setup, men kan ikke foregribe ethvert miljø, så dokumenteret hærdningsvejledning er stadig vigtig. Security by design adskiller sig fra defence-in-depth (der lagdeler kontroller under drift) ved at handle om, hvordan systemet undfanges og bygges; de to supplerer hinanden, for godt design afgør, hvor de lag skal placeres.
Hvad du bør lære først
Alt det, dette bygger på - grundlaget først.
- CIA-triaden
- →Security by design
Relationer
- Forudsætter
- CIA-triaden
- Implementeres af
- DevSecOpsSikker udviklingslivscyklus (SDL)
- Forveksl ikke med
- Privacy by design
- Afbøder
- Sårbarhed
- Krævet af
- Cyberrobusthedsforordningen (CRA)
- Bruges sammen med
- Zero Trust
Kilder og videre læsning
Standarder og officielle tekster
- NIST SP 800-160 Vol. 1 Rev. 1 - Engineering Trustworthy Secure Systems · NIST
Kursusmateriale
- Cyber Security Fast Track - Ordliste
Hvor dataene kommer fra
Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.
Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON
Test dig selv
Indlæser…