Hvilke ændringer i produktet kræver en ny test?

Et produkt i løbende udvikling ændrer sig hele tiden, og spørgsmålet er ikke, om der er sket noget siden testen, men om det, der er sket, berører det, testen undersøgte. Kriteriet hviler på rapporten selv: hvis en ændring rører ved login, roller, adskillelsen mellem kunderne, de data, produktet håndterer, eller de veje, man kan nå produktet ad, er den seneste test ikke længere et dækkende svar på den del.

Det giver et praktisk værktøj til udviklingsteamet. I stedet for at diskutere størrelsen af hver release kan I stille de samme få spørgsmål til hver ændring og notere svaret. Så har I både en beslutning og dokumentationen for den, når en kunde spørger.

Ændringer, der bør vurderes hver gang

Nogle typer ændringer går direkte ind i det, kunderne læser i rapporten. De bør altid føre til en vurdering, og ofte til en afgrænset test:

Login og identitet · ny måde at logge ind på, totrinslogin, kobling til kundernes eget login eller ændret håndtering af sessioner. → Single sign-on mod kundernes egne login
Roller og rettigheder · nye roller, en ændret rollemodel eller nye administratorfunktioner.
Adskillelsen mellem kunder · ændringer i den måde, kundernes data holdes adskilt på, fx ved en ny database eller en fælles funktion på tværs af kunder.
Nye typer data · produktet begynder at håndtere personoplysninger af en ny art, betalinger eller oplysninger, kunderne betragter som fortrolige.
Nye veje ind · et nyt offentligt API, nye integrationer, webhooks eller en komponent, der kan indlejres på kundernes sider.
Ny platform · flytning til en anden hosting, en ny arkitektur eller udskiftning af en central komponent.

Det sidste punkt kan være så omfattende, at hele den tidligere rapport mister sin værdi. Så er det ikke en afgrænset test, men en ny, der er brug for. → Større omskrivning eller ny arkitektur

Ændringer, der sjældent kræver en ny test

Andre ændringer berører ikke det, testen byggede sine konklusioner på. Ændrede tekster og farver, nye rapporter, der viser data, brugeren i forvejen har adgang til, rettelser af fejl uden betydning for adgang og hastighedsforbedringer hører typisk hjemme her.

Grænsen er dog ikke skarp. En ny rapportfunktion kan samle data på tværs af kunder, og en fejlrettelse kan ændre, hvordan en rettighed kontrolleres. Det er derfor indholdet af ændringen, ikke dens størrelse, der skal vurderes. En lille ændring i adgangskontrollen kan veje tungere end et stort nyt modul til statistik.

Opdateringer af tredjepartskomponenter er en sag for sig. En rutinemæssig opdatering af et bibliotek hører til vedligeholdelsen og kræver sjældent en pentest. Udskiftes en komponent, der står for login, kryptering eller adgangskontrol, med en anden, er det derimod en ændring af selve fundamentet, og den bør vurderes efter de samme spørgsmål som jeres egen kode.

Spørgsmålene i udviklingsprocessen

Vurderingen virker kun, hvis den sker på et fast sted i processen. En mulighed er at lægge den som et punkt, en ændring skal igennem, før den planlægges eller godkendes. Spørgsmålene kan være enkle:

Ændrer det, hvem der kan logge ind, eller hvordan?
Ændrer det, hvad en rolle eller en kunde kan se og gøre?
Håndterer det nye typer data?
Åbner det en ny vej ind i produktet eller ud af det?
Flytter det produktet til en ny platform eller en ny central komponent?

Et ja til et af spørgsmålene betyder ikke automatisk en ny test, men det betyder, at nogen skal tage stilling. Det er typisk produktejeren sammen med den, der har ansvaret for sikkerheden. → Produktejerens rolle i penetrationstesten

Hvad standarderne siger

Nogle standarder bruger netop begrebet væsentlige ændringer. PCI DSS knytter kravet om penetrationstest til både et fast interval og til væsentlige ændringer i miljøer med betalingskortdata. Hvis jeres produkt håndterer kortdata, kan det være mere end en god idé. Selv hvor standarden ikke gælder, kan tankegangen bruges: testen følger ikke kun kalenderen, men også produktet. → Når produktet håndterer kortdata

Hubben penetrationtest.dk beskriver, hvordan en køber vurderer en større opdatering af et system, den har købt. Her er det den anden side: I er leverandøren, og det er jer, der kender ændringerne og skal tage stilling, før kunden spørger. Se penetrationtest.dk.

Dokumentér beslutningen

Skriv vurderingen ned for de ændringer, der fik et ja. En kort note er nok: hvad ændringen var, hvilke spørgsmål den ramte, og hvad der blev besluttet. Hvis der blev testet, henvises der til rapporten. Hvis der ikke blev, står begrundelsen der. Gem noterne samme sted som rapporterne, så de kan findes af dem, der svarer på kundernes spørgeskemaer.

Noterne bliver jeres bedste værktøj, når en kunde spørger, hvad der er sket siden rapporten. I kan vise, hvilke væsentlige ændringer der er kommet, og hvordan hver af dem er håndteret. → Meget er udgivet siden testen

Et tænkt eksempel: et softwarehus tilføjer en funktion, hvor kunderne kan dele dokumenter med eksterne via et link. Ændringen åbner en ny vej ud af produktet og berører adskillelsen. Den får en afgrænset test, før den slås til for alle. En samtidig ændring af designet på forsiden får et nej og en enkelt linje i noterne. → Penetrationstest af en ny funktion før lancering

Funktioner, der kun er slået til for nogle

Mange produkter ruller ændringer ud gradvist eller kun for udvalgte kunder. En ændring, der endnu kun er slået til for få, er stadig en ændring i produktet, og den skal vurderes, før den bliver bred. Det er også det bedste tidspunkt at teste den. → Funktioner, der kun er slået til for nogle kunder

Det skal I lade være med

Lade versionsnummeret afgøre det · en mindre version kan ændre login eller roller.
Vurdere ændringer efter størrelse · det er indholdet, der tæller.
Springe vurderingen over i travle perioder · det er netop dér, de væsentlige ændringer sniger sig igennem.
Teste uden at notere, hvorfor · uden noten kan I ikke forklare valget for kunden.
Glemme gradvise udrulninger · en funktion for få kunder er stadig en del af produktet.

Hvad kan og ikke kan konkluderes

Et fast sæt spørgsmål og en note for hver vurdering viser, at I tager stilling til ændringer systematisk. Det viser ikke, at alle vurderinger var rigtige, og det erstatter ikke den test, en væsentlig ændring kræver.

Tjekliste til ændringer

☐ Er spørgsmålene om login, roller, data, adgangsveje og platform en fast del af processen?
☐ Er det klart, hvem der tager stilling, når svaret er ja?
☐ Bliver beslutning og begrundelse noteret for hver væsentlig ændring?
☐ Er gradvise udrulninger med i vurderingen?
☐ Kan I vise kunden en oversigt over væsentlige ændringer siden seneste rapport?