Produktejerens rolle i penetrationstesten

I mange softwarehuse falder pentesten mellem to stole: udviklerne ser den som en sikkerhedsopgave, og den sikkerhedsansvarlige ser den som en del af udviklingen. Produktejeren kan være den, der bedst kan samle trådene, fordi rollen allerede ejer det, testen handler om: hvad produktet skal kunne, hvem det er til, hvad der kommer i næste release, og hvad kunderne er blevet lovet.

Det betyder ikke, at produktejeren skal kunne vurdere sikkerhedsfund. Det betyder, at produktejeren træffer de beslutninger om omfang, timing og prioritering, som testen kræver, og at rollen står for, at testen ender som et svar, kunderne kan bruge.

Hvorfor netop produktejeren

En pentest af et softwareprodukt kræver beslutninger, der ligger i produktejerens felt. Hvilke dele af produktet skal med? Skal den nye funktion være klar, før testen begynder? Hvad flyttes i backloggen, når fundene kommer? Hvornår skal kunderne have en status? Det er ikke spørgsmål om teknik, men om produktets retning og løfter.

Den britiske NCSC anbefaler, at alle relevante risikoejere deltager, når en pentest afgrænses, og skriver, at vurderingen af fund og beslutningen om rettelser er jeres ansvar. I et softwarehus kan produktejeren være den, der ejer risikoen ved produktet i det daglige. Hvem der i sidste ende ejer selve kundekravet, er et ledelsesspørgsmål, som er beskrevet for sig. → Hvem ejer kundekravet?

Før testen: omfang og timing

Før testen er produktejerens vigtigste opgave at sikre, at testen dækker det, kunderne vil spørge til. Produktejeren ved, hvilke moduler de store kunder bruger, hvilke funktioner der er nye, og hvilke der er på vej ud. Den viden er afgørende for en afgrænsning, der passer til produktet. → Omfanget af testen

Produktejeren bestemmer også, hvornår testen passer ind i planen. Ligger testen, mens en stor ændring er halvt færdig, beskriver rapporten et produkt, der snart ser anderledes ud. Ligger den lige før en lancering, er der ikke tid til at rette. Rollen er den, der kan flytte det ene eller det andet. → Lanceringsdato og testvindue

Konkret kan produktejeren stå for:

Listen over det, der skal med · moduler, roller, integrationer og API’er, set fra kundernes brug.
Listen over det, der ikke skal med · og begrundelsen, så den kan forklares til kunderne.
Testvinduet · placeret, så det passer til releaseplanen og giver tid til rettelser.
Testkonti og testdata · at de afspejler de roller og den brug, kunderne har.

Under testen: beslutninger, der ikke kan vente

Under testen er det udviklernes kontaktpunkt, der svarer på tekniske spørgsmål. Men nogle situationer kræver en beslutning, og den ligger hos produktejeren. Melder testeren et alvorligt fund, skal nogen beslutte, om det skal rettes med det samme, om en funktion skal slås fra, og om kunderne skal have besked. → Udviklerne og testeren

Produktejeren bør også beslutte, om der må udrulles under testen. Planlagte releases kan være lovet kunder, og en pause kan koste. Omvendt kan en udrulning midt i testen gøre rapporten uklar. Det er en afvejning mellem releaseplanen og ønsket om en entydig rapport, og den hører hjemme hos den, der ejer begge dele.

Det samme gælder ændringer i omfanget undervejs. Opdager testeren en del af produktet, som ikke var med i afgrænsningen, men som ser ud til at være vigtig, skal nogen tage stilling til, om den skal med. Det kan forlænge testen eller flytte tid fra andre dele. Produktejeren er den, der kan vurdere, om delen betyder noget for kunderne, og som kan sørge for, at beslutningen bliver skrevet ned, så rapportens omfang stadig kan forklares.

Efter testen: prioritering og kundesvar

Når rapporten foreligger, har produktejeren tre opgaver. Den første er at få fundene ind i backloggen med en plads, der passer til deres alvor og til det, der er lovet kunderne. Den anden er at tage stilling til fund, der ikke rettes med det samme, og begrunde det. Den tredje er at sørge for, at de, der svarer kunderne, får en status, de kan bruge. → Fund i backloggen

Den sidste opgave kan blive glemt. Salg og kundeansvarlige sidder med spørgeskemaer, hvor der spørges til åbne fund og planlagte rettelser. Hvis de ikke ved, hvad produktejeren har besluttet, svarer de enten for vagt eller lover for meget. En kort, skriftlig status efter hver test og efter hver retest løser det. → Salgsteamet og sikkerheden

Produktejeren er ikke sikkerhedsekspert

Det er vigtigt at holde grænsen. Produktejeren skal ikke vurdere, om et fund er alvorligt, eller om en rettelse er tilstrækkelig. Det er testerens og udviklernes opgave, og i mange softwarehuse også den sikkerhedsansvarliges. Produktejeren skal tage beslutninger på grundlag af deres vurderinger og kende konsekvenserne for kunderne.

I et lille softwarehus kan produktejeren, den tekniske ansvarlige og direktøren være de samme to personer. Så er pointen ikke titlen, men at de beslutninger, der er beskrevet her, træffes af nogen, og at det er klart, hvem.

Et tænkt eksempel

Et softwarehus med et system til styring af ejendomsservice skal have sin årlige pentest. Produktejeren ved, at to store kunder er ved at tage et nyt modul til beboerkommunikation i brug, og at modulet først er færdigt om en måned. Produktejeren foreslår at flytte testen, så modulet kommer med, og lægger testvinduet tre uger før næste store release, så der er tid til rettelser. Efter testen sorterer produktejeren fundene sammen med udviklerne og sender en kort status til de kundeansvarlige, så de kan svare de to kunder præcist om modulet og om tidsplanen for rettelser. Ingen af beslutningerne krævede sikkerhedsviden, men de krævede viden om produktet og kunderne.

Det skal I lade være med

Overlade omfanget til testeren alene · testeren kender ikke kundernes brug.
Lade pentesten være ingens ansvar · så ender den, når en kunde rykker.
Gøre produktejeren til dommer over fund · alvoren vurderes af dem, der kan.
Glemme salgsteamet efter testen · de skal have en status, de kan bruge.
Planlægge testen uden for releaseplanen · så rammer den enten for tidligt eller for sent.

Hvad kan og ikke kan konkluderes

Når produktejeren ejer omfang, timing og prioritering, er der større chance for, at rapporten dækker det, kunderne spørger til, og at fundene bliver fulgt op. Det siger ikke noget om kvaliteten af testen eller af rettelserne. Det afgøres af testeren og udviklerne.