At vente, til kunden spørger

En del beslutninger i et ungt softwarehus kan godt vente, til en kunde beder om dem. Den første penetrationstest er en af de få, hvor det har en pris at vente, fordi hele forløbet fra bestilling til brugbar dokumentation så skal nås, mens en kunde venter på et svar. Det betyder ikke, at testen skal købes før tid. Det betyder, at en del af forberedelsen kan gøres nu, og at I bør kende de tegn, der siger, at det er tid til den første test.

Hvad der sker, når kravet kommer midt i et salg

Kravet kan komme sammen med et sikkerhedsspørgeskema, en leverandørpolitik eller et kontraktudkast, og det kan komme, når kunden har besluttet sig for jer og vil have aftalen på plads. Uden en rapport kan I kun svare, at testen er planlagt. Nogle kunder accepterer det med en dato. Andre sætter aftalen på pause, eller de vælger en leverandør, der kan vise dokumentationen med det samme. → Salget er gået i stå

Presset smitter af på testen. Når den skal nås til en bestemt dato, bliver omfanget let lagt efter det, der kan nås, og ikke efter det, kunderne har brug for. Tiden til rettelser bliver klemt, og rapporten kan ende med at vise åbne fund for den kunde, den var tænkt til. Og fordi testen er bestilt til én kunde, passer den måske ikke til den næste, som spørger et halvt år senere med andre moduler i aftalen.

Kæden, der skal nås

Den første test er ikke én opgave, men en kæde, hvor hvert led kræver tid hos jer:

Afklaring · hvad kunden kræver, og hvad testen skal dække.
Valg af tester · tilbud, sammenligning og aftale.
Forberedelse · testmiljø, testkunder, testkonti og beskrivelse af produktet.
Selve testen · med en kontaktperson, der kan svare undervejs.
Rettelser · tid fra udviklingen til de fund, der skal lukkes, før rapporten bruges.
Retest og dokumenter · efterprøvning og et resumé eller en erklæring, der kan udleveres.

Ingen af leddene er svære, men de kan ikke springes over. Hvor lang tid kæden tager, afhænger af produktet, testerens kalender og jeres egen kapacitet. Det, I kan styre, er, hvor mange af leddene der er gjort, når kunden spørger. Er afklaring, forberedelse og valg af tester på plads, er det kun selve testen, rettelserne og dokumenterne, der skal nås, mens kunden venter. → Aftalen venter på en pentestrapport

Det, I kan gøre, før nogen spørger

En stor del af forberedelsen kræver ingen test og kan laves i roligt tempo:

En kort beskrivelse af produktet · moduler, roller, integrationer og hosting, som en tester og en kunde kan forstå.
Et testmiljø · der ligner produktionen nok til, at en test giver mening.
En kontaktvej · en fast adresse for sikkerhedsspørgsmål og meldinger om sårbarheder.
Svar på de faste spørgsmål · om udvikling, adgange, adskillelse og håndtering af fejl.
En registrering af fund · så I kan svare på spørgsmål om rettelser med fakta.
En plan · for hvornår den første test skal ligge, og hvem der ejer den.

CISA beskriver i sit Secure by Design-initiativ, at sikkerhed bør bygges ind i designfasen, før produktet når markedet. Det er en opfordring om at tænke sikkerheden ind fra start, ikke et krav om en bestemt test. For et ungt softwarehus betyder det, at en del af det, kunderne spørger efter, kan være på plads længe før den første rapport. → Startup uden sikkerhedsfunktion

Tegn på, at det er tid til den første test

Der er ingen fast regel for, hvornår et SaaS-produkt skal testes første gang. Nogle tegn peger dog på, at det er tid til at sætte en dato:

Salget går mod større erhvervskunder · kunder med en sikkerhedsafdeling og en leverandørpolitik.
Produktet rummer følsomme data · fx personoplysninger, økonomi eller helbred.
Flere kunder deler løsningen · og adskillelsen mellem dem er afgørende.
Et API eller integrationer åbner produktet · for andre systemer.
Kunder i regulerede brancher er i spil · fx sundhed eller finans.

Jo flere af tegnene der passer på jer, jo mere taler for at lægge den første test nu, så rapporten er klar, før den første store aftale kræver den. Brug tegnene som grundlag for en beslutning i ledelsen, ikke som en fast regel. → Den første store kunde

At starte tidligt uden at bruge for meget

At starte tidligt betyder ikke at teste alt. Afgræns den første test til det, kunderne kommer til at spørge om: webapplikationen, login, roller, adskillelsen mellem kunder og det API, kunderne bruger. Kontornettet og interne værktøjer kan vente, til en kunde eller jeres egen risikovurdering kræver det. → Scope for et SaaS-produkt

Bestil testen, så rapporten kan bruges over for kunder fra starten. Det handler om at få omfang, version og datoer skrevet tydeligt og om at aftale en form, der kan udleveres, fx et resumé eller en kundeversion. Uden det kan det blive nødvendigt med en ny test eller en ny rapport, før den første kan vises til en kunde. → Bestil til kundebrug

Et tænkt eksempel

En startup med et værktøj til planlægning af vareleverancer har en pilot med en mellemstor grossist og forhandler med en landsdækkende kæde. Stifterne har endnu ikke fået en test. De skriver en produktbeskrivelse, sætter en sikkerhedsadresse op og lægger den første test et kvartal før kædens forventede beslutning, med tid til rettelser bagefter. Da kæden sender sit spørgeskema, kan de svare med en dato for testen og et resumé to uger senere.

Det skal I lade være med

Vente, til et kontraktudkast kræver rapporten · så skal hele kæden nås under pres.
Teste alt for at være på den sikre side · test det, kunderne bruger.
Love en rapport til en dato uden tid til rettelser · rapporten kan vise åbne fund.
Undlade forberedelsen, fordi testen ligger langt ude · beskrivelse, kontaktvej og svar kan laves nu.
Lægge testen efter testerens første ledige tid alene · læg den efter, hvornår rapporten skal bruges.

Hvad kan og ikke kan konkluderes

En tidlig plan og en forberedt organisation gør det muligt at svare en kunde med en dato og et grundlag i stedet for en undskyldning. Den kan ikke garantere, at en bestemt kunde accepterer en rapport, der endnu ikke findes, og den ændrer ikke, at testen viser forholdene på det tidspunkt, den blev udført.