Omfangsafsnittet: det første, kundens sikkerhedsfolk læser

Når en kunde modtager jeres pentestrapport, kan sikkerhedsfolkene springe resuméet over og går direkte til omfanget. Svaret på, om rapporten kan bruges, afhænger nemlig mindre af antallet af fund end af, om testen dækkede det, kunden faktisk køber og bruger.

Et godt omfangsafsnit fortæller modtageren tre ting uden omveje: hvad der blev testet, hvad der bevidst blev holdt udenfor, og hvilket udgangspunkt testeren havde. Er de tre ting tydelige, kan kunden selv koble rapporten til sin egen brug af produktet. Er de uklare, kommer spørgsmålene i stedet, og salget venter.

Hvorfor kunden starter her

Kundens sikkerhedsansvarlige skal vurdere en risiko, der angår kundens egne data og brugere. En rapport om et andet modul, et andet miljø eller en anden udgangsposition hjælper ikke den vurdering, uanset hvor få fund den indeholder. Derfor er omfanget det filter, resten af rapporten læses igennem.

Det britiske NCSC beskriver, at afgrænsningen af en test bør munde ud i et dokument, der angiver de tekniske grænser for testen og de typer af test, der forventes. For jer som sælger er det samme dokument grundlaget for det, kunden får at se. Hvad der er aftalt før testen, bestemmer, hvad I kan vise bagefter. → Omfanget af en test af SaaS-produktet

Det, modtageren skal kunne aflæse

Et omfangsafsnit, der er skrevet til en ekstern læser, bør som minimum gøre disse punkter tydelige:

Produkt og komponenter · webapplikation, API, administrationsmodul og andet, der indgik, med de navne kunderne kender fra jeres materiale.
Miljø · produktion, et staging-miljø eller en separat testinstallation, og hvor tæt den ligner det, kunderne bruger.
Udgangspunkt · uden login, med almindelige brugerkonti, med administratorroller, og om adskillelsen mellem kunder var en del af opgaven.
Undtagelser · funktioner, integrationer eller dele af infrastrukturen, der ikke var med, og gerne kort hvorfor.
Testperiode og version · så resultatet kan placeres i tid. → Version og testdatoer

Brug kundens sprog, ikke kun interne kodenavne. En kunde, der køber “Rapportering” og “Medarbejderportal”, skal kunne finde netop de ord i afsnittet eller i en kort oversigt over, hvad de dækker.

Undtagelserne er en del af svaret

Det kan være fristende at gemme undtagelserne i en bisætning. Det er en dårlig ide. Kundens sikkerhedsfolk leder efter dem, og når de finder dem selv, virker det, som om I har prøvet at skjule noget.

Skriv hellere undtagelserne tydeligt og begrund dem: en integration, der ejes af en tredjepart, et modul, der udfases, eller en del, der blev testet separat. En begrundet undtagelse er et oplysningspunkt. En uforklaret undtagelse er et spørgsmål, som kunden vil have svar på, før aftalen kan gå videre. Rammer undtagelsen netop det modul, kunden køber, er der et reelt hul. → Rapporten dækker ikke det modul, kunden køber

Sådan får I et læsbart omfang i rapporten

Omfangsafsnittet skrives af testeren, men I kan påvirke det ved bestillingen. Fortæl testeren, at rapporten skal bruges over for kunder, og bed om, at omfanget beskrives, så en udenforstående kan forstå det. Bed også om, at kundernes navne på modulerne bruges eller oversættes.

Tekniske lister over adresser og systemnavne hører typisk hjemme i et bilag. Selve omfangsafsnittet kan holde sig til produktets dele, miljøet og udgangspunktet. Så kan en kundeversion af rapporten bevare et forståeligt omfang, selvom de tekniske detaljer fjernes. → Bestil testen, så rapporten kan bruges over for kunder · → Kundeversionen af rapporten

Når kunden har spørgsmål til omfanget

Selv et klart afsnit giver spørgsmål. Kunden vil måske vide, om en bestemt integration var med, om adskillelsen blev afprøvet med flere end to kunder, eller om administratorrollen hos kunden svarer til den, testeren brugte. Den slags spørgsmål er et godt tegn. De betyder, at kunden læser rapporten for at bruge den.

Hav svarene klar, før rapporten sendes ud. Det kræver, at nogen hos jer kender opgavebeskrivelsen og kan forklare forskellen på det, der stod i bestillingen, og det, testeren nåede. Var der ændringer i omfanget undervejs, fx fordi en del af produktet ikke var klar, skal det også kunne forklares. NCSC nævner, at komponenter uden for omfanget, som dukker op under testen, kan føre til en ændring af omfanget eller blive noteret som en begrænsning. Den slags noter læser kunden også.

Svar ikke på vegne af testeren om ting, der ikke står i rapporten. Hvis kunden spørger, om noget blev afprøvet, og svaret ikke fremgår, så sig det, og spørg testeren, før I lover noget. Et forkert ja om omfanget er svært at trække tilbage, når kunden senere ser den fulde rapport eller næste års test. → Opfølgende spørgsmål fra kundens sikkerhedsteam

Et tænkt eksempel

Et softwarehus sælger en platform til bookning af lokaler med tre moduler: selve bookningen, et API til kundernes egne systemer og et betalingsmodul, der bygger på en ekstern betalingsudbyder. Testen omfattede bookningen og API’et, med konti i to roller og to testkunder for at afprøve adskillelsen. Betalingssiden hos udbyderen var udenfor, fordi den drives af udbyderen.

Omfangsafsnittet nævner de tre moduler ved navn, siger hvilke to der var med, og forklarer i én sætning, hvorfor betalingssiden ikke var. Når en kunde, der kun bruger bookningen, læser afsnittet, kan spørgsmålet besvares med det samme. En kunde, der lægger vægt på betalingen, ved til gengæld, hvad der skal spørges om. Begge dele sparer tid i salget.

Det skal I lade være med

Beskrive omfanget bredere end det var · Kundens sikkerhedsfolk sammenligner med fundene og opdager uoverensstemmelsen.
Bruge interne kodenavne alene · Kunden kan ikke koble dem til det, der står i kontrakten.
Gemme undtagelser i et bilag · Det, der var udenfor, skal stå dér, hvor omfanget beskrives.
Udelade miljøet · En test i et staging-miljø skal ikke kunne læses som en test i produktionen.
Lade udgangspunktet være uklart · Med eller uden login giver to meget forskellige resultater.
Rette i testerens omfangsafsnit · Ønsker I en anden formulering, så bed testeren om den.

Hvad kan og ikke kan konkluderes

Et klart omfangsafsnit viser kunden, hvad testen sagde noget om. Det fortæller intet om de dele, der ikke var med, og det gør ikke en smal test bredere. Det kan heller ikke garantere, at kunden accepterer omfanget. Afsnittet gør det muligt for kunden at træffe den vurdering på et oplyst grundlag, og det er dets opgave.