Sikkerhedskrav i kravspecifikationen

En pentest kan finde svagheder, men den kan ikke sige, om produktet lever op til jeres egne krav, hvis kravene aldrig er skrevet ned. Svaret på, hvordan I får testen og kundernes krav til at hænge sammen med udviklingen, hviler på sikkerhedskrav i kravspecifikationen: krav, der er formuleret, så både udviklerne, testeren og kunden kan se, om de er opfyldt.

Det er ikke et spørgsmål om store dokumenter. Det er et spørgsmål om, at sikkerhed står i de samme krav og acceptkriterier, som alt andet i produktet bliver bygget efter.

Hvorfor krav og test hænger sammen

Uden skrevne krav måler testeren produktet op imod sin egen erfaring og almindelig god praksis. Det er nyttigt, men det gør det svært at sige, om et fund er et brud på noget, I havde besluttet, eller en ny erkendelse. Med skrevne krav kan testen også vise, om det, I har besluttet, faktisk virker. Det giver rapporten et ekstra lag, som kunderne kan bruge: den beskriver ikke kun, hvad testeren fandt, men også om produktet holder det, leverandøren har lovet.

NIST anbefaler i sit rammeværk for sikker softwareudvikling (SSDF), at sikkerhedskravene til softwareudvikling altid er kendt, så de kan tages i betragtning gennem hele udviklingen. Kravene kommer både indefra, fra egne politikker og forretningsmål, og udefra, fra love og regler. For et softwarehus er kunderne en af de vigtigste kilder udefra.

Hvor kravene kommer fra

Sikkerhedskrav til et SaaS-produkt kan komme fra fire steder:

Kundernes kontrakter og bilag · krav om adskillelse, logning, login og adgangskontrol, som I har forpligtet jer til. → Sikkerhedsbilaget til kundekontrakten
Kundernes leverandørpolitikker og skemaer · det, kunderne spørger om igen og igen, er et godt bud på det, de forventer.
Standarder og rammeværk · fælles krav, der allerede er formuleret, så I ikke skal opfinde dem selv.
Jeres egen trusselsmodel · de risici, I selv har fundet, og hvad I har besluttet at gøre ved dem.

Den sidste kilde er den, der gør kravene til jeres egne. Den viser, hvor produktet har sine særlige risici, og hvor kravene derfor skal være strengere. → Trusselsmodellering før testen

Krav fra kunderne er ikke altid til at forhandle. Men de er lettere at opfylde, når de allerede står i jeres egne krav, og lettere at sige nej til, når de ikke passer til produktet. → Forhandling af sikkerhedskrav

Et fælles sprog for krav

OWASP Application Security Verification Standard (ASVS) er en samling krav til sikkerhed i webapplikationer og tjenester. OWASP nævner selv, at den kan bruges som grundlag for at angive krav til verifikation af applikationssikkerhed i kontrakter, og at den giver udviklere en liste over krav til sikker udvikling.

Det gør den nyttig på to måder for et softwarehus. Kravene kan bruges direkte i specifikationen, og de giver et sprog, som kunder og testere allerede kender. Når en kunde henviser til ASVS i sit skema, kan I svare ud fra de krav, I selv har valgt. → OWASP ASVS

Krav, der kan efterprøves

Et sikkerhedskrav er kun nyttigt, hvis nogen kan se, om det er opfyldt. Sammenlign to formuleringer. “Produktet skal være sikkert” kan ingen teste. “En bruger må kun kunne se data fra egen kunde, også via API” kan både udvikles, testes og forklares.

Gode sikkerhedskrav har typisk disse kendetegn:

De er konkrete · de beskriver, hvad der skal ske, ikke en generel hensigt.
De passer til produktet · de handler om jeres roller, data og integrationer.
De har et acceptkriterium · det er klart, hvornår kravet er opfyldt.
De har en ejer · nogen svarer for, at kravet holdes ved lige, når produktet ændrer sig.

Kravene skal ikke beskrive, hvordan udviklerne løser dem. De beskriver resultatet, og løsningen er udviklingsteamets. Det gør også kravene mere holdbare, for de skal ikke skrives om, hver gang teknikken bag produktet skifter.

Kravene i hverdagen

Krav, der ligger i et separat dokument, bliver ikke altid læst. Krav, der står i de historier og opgaver, udviklerne arbejder med, bliver bygget. Det kan være så enkelt som et fast punkt i definitionen af færdig for nye funktioner, eller en kort liste af sikkerhedsspørgsmål, der skal besvares, før en funktion går i gang.

Når en ny funktion skal testes før lancering, er kravene det naturlige udgangspunkt for testen. Testeren kan få dem med i opgavebeskrivelsen og prøve, om de holder. → Penetrationstest af en ny funktion

Kravene skal også følge med, når fund i en pentest viser, at noget mangler. Et fund, der skyldes et manglende krav, bør føre til et nyt krav, ikke kun til en rettelse. Omvendt kan et krav, der aldrig giver anledning til fund eller spørgsmål, være skrevet for bredt eller for tidligt. Gennemgå derfor kravene en gang imellem, fx når I alligevel forbereder den årlige test, og fjern det, der ikke længere passer til produktet. → Fundene som læring

Et tænkt eksempel

Et softwarehus til ejendomsadministration får i samme kvartal tre skemaer fra kunder, der alle spørger, om administratorer skal bruge totrinsbekræftelse, og om adgang logges. Svarene ligger spredt i hovedet på tre udviklere.

Produktejeren skriver de to forhold ind som krav med acceptkriterier og lægger dem ind som faste punkter for nye funktioner. Ved næste pentest får testeren kravene og bekræfter, at de holder. Næste gang et skema spørger, kan svaret henvise til både kravet og testen. Udviklerne skal ikke længere spørges hver gang, og sælgeren ved, at det, der står i svaret, også står i specifikationen. Da en af kunderne senere vil have kravet skrevet ind i kontrakten, er det allerede en del af produktet og koster ingen ekstra forhandling.

Det skal I lade være med

Skrive krav, ingen kan teste · så kan hverken testeren eller kunden se, om de holder.
Kopiere en hel standard ind uden at vælge · ikke alle krav passer til jeres produkt.
Lægge kravene i et dokument, ingen åbner · de skal stå, hvor udviklerne arbejder.
Love kunden krav, I ikke har i jeres egen specifikation · så bliver løftet ikke bygget.
Beskrive løsningen i stedet for resultatet · det låser udviklerne unødigt.

Hvad kan og ikke kan konkluderes

Skrevne sikkerhedskrav gør det muligt at teste, om produktet gør det, I har besluttet, og at svare kunderne præcist. De kan ikke dække risici, ingen har tænkt på, og en test mod kravene alene finder ikke de svagheder, der ligger uden for dem.

Tjekliste til sikkerhedskravene

☐ Står sikkerhedskravene i samme specifikation som de øvrige krav?
☐ Er kundernes gentagne krav samlet og vurderet?
☐ Har hvert krav et acceptkriterium?
☐ Er det besluttet, hvilke dele af en standard I følger?
☐ Får testeren kravene med før testen?
☐ Fører fund til nye eller skarpere krav?

Kilder

OWASP Application Security Verification Standard: krav til sikkerhed i webapplikationer, også som grundlag for krav i kontrakter og som liste over krav til sikker udvikling.
NIST SP 800-218, Secure Software Development Framework: praksis PO.1 om at holde sikkerhedskravene til softwareudvikling kendt gennem hele udviklingen, fra både interne og eksterne kilder.

Senest gennemgået: oktober 2026.