Startup uden sikkerhedsfunktion: det første krav fra en kunde

I en startup med en håndfuld udviklere og en stifter, der også er sælger, er der måske ingen med sikkerhed i titlen. Når den første kunde beder om en pentestrapport, lander opgaven derfor hos den, der har tid, og det er sjældent en god fordeling. Hvordan I kommer igennem det, hviler på, at én person får ansvaret, og at testen afgrænses til det, kunden faktisk bruger.

Det korte svar er: udpeg en ejer, beskriv ærligt over for kunden, hvad I har, og bestil en afgrænset test af produktet, når den version, kunden skal bruge, er på plads. I behøver ikke opbygge en sikkerhedsorganisation for at svare kunden. Men I skal kunne vise, at nogen har overblikket.

Hvem tager opgaven?

I en lille virksomhed falder kundekravet let mellem to stole. Stifteren ejer kunden, udviklerne ejer koden, og ingen ejer spørgsmålet om test. Resultatet kan blive, at sælgeren svarer på sikkerhedsspørgsmål ud fra hukommelsen, mens udviklerne ikke ved, hvad der er lovet.

Udpeg én person, der er ansvarlig for kundekravet fra start til slut: forstå kravet, vælge tester, koordinere med udviklerne, få rapporten og udlevere den. Det er typisk den tekniske stifter eller den mest erfarne udvikler. Personen behøver ikke være sikkerhedsekspert, men skal have mandat til at prioritere tid til rettelser. → Hvem i softwarehuset ejer kundekravet om test?

Hvad I kan svare kunden nu

Kunden ved formentlig godt, at en startup ikke har samme apparat som en stor leverandør. Det, kunden har brug for, er en ærlig beskrivelse og en plan. Fortæl, hvordan produktet er bygget med hensyn til sikkerhed: login, adskillelse af kundedata, hvordan data opbevares, hvem der har adgang til produktionen, og hvordan I håndterer opdateringer. Sig, at der ikke er gennemført en uafhængig test endnu, hvis det er tilfældet, og hvornår den er planlagt.

Et tænkt eksempel: En startup med fem medarbejdere har udviklet et værktøj til kontraktstyring. Den første større kunde sender et skema på flere sider. Den tekniske stifter svarer på de spørgsmål, der kan besvares præcist, markerer resten som under udarbejdelse og giver kunden en dato for den første eksterne test. Kunden accepterer at starte en pilot med testdata og vente med rigtige kontrakter, til rapporten er modtaget. → Et ærligt svar uden test

Hvad der skal testes først

Med begrænset tid og budget skal testen dække det, kunden er mest optaget af. For et SaaS-produkt er det især adgangen: kan en bruger kun se sine egne data, kan en kunde kun se sin egen organisations data, og kan en almindelig bruger ikke nå administrative funktioner? Dertil API’et, hvis kunden skal integrere, og den del af produktet, der håndterer filer eller følsomme oplysninger.

Lad være med at udvide testen til alt, I har, for at få en flot rapport. Kontornettet, interne værktøjer og udviklernes bærbare er relevante for jeres egen sikkerhed, men det er ikke nødvendigvis det, kunden spørger om. En smal test af det rigtige giver kunden mere end en bred test af alt. → Hvad skal med i en penetrationstest af et SaaS-produkt? · → Produktet eller hele virksomheden

Forbered produktet, inden testeren starter

En første test kan godt finde noget, og i en startup er der ikke en sikkerhedsafdeling til at tage imod det. Brug et par uger før testen på det, I selv kan se: standardadgangskoder, testbrugere, der er glemt i produktionen, administrative funktioner uden ekstra beskyttelse, og afhængigheder, der ikke er opdateret længe. Det er ikke en erstatning for testen, men det betyder, at testeren bruger tiden på det, I ikke selv kunne finde.

Sørg også for, at testeren har det nødvendige: testkonti med de relevante roller, mindst to adskilte testkunder, så adskillelsen kan afprøves, og en kontaktperson, der kan svare hurtigt under testen. I en startup kan det være samme person som ejeren af kundekravet. → Testlejere: én eller flere kunder i produktet under testen?

Tid til rettelser

Planlæg tid til rettelser efter testen, før I lover kunden en rapport. Den tid skal tages fra udvikling af nye funktioner, og det er en reel prioritering i et lille team. Tal om det på forhånd, så det ikke bliver en konflikt, når rapporten kommer. Hvis et alvorligt fund kræver en større ændring, er det bedre at fortælle kunden det og give en ny dato end at sende en rapport med et uløst kritisk fund. → Få udviklere, mange kundekrav: sådan planlægger I testen

Fra første krav til fast praksis

Den første test er en anledning til at etablere nogle få faste rutiner, der gør næste kundekrav lettere. Gem svarene på kundens skema, så de kan genbruges og opdateres. Notér, hvem der har fået rapporten. Læg den næste test ind i planen, så den ikke afhænger af, at en kunde spørger. Det kræver ikke en sikkerhedsfunktion, men det kræver, at én person holder styr på det.

Overvej også, hvordan rapporten skal deles. En startup har måske ingen fast praksis for fortrolige dokumenter, og den første rapport ender let som vedhæftet fil i flere indbakker. Beslut, hvem der må udlevere den, i hvilken form, og om kunden skal skrive under på fortrolighed først. Når de næste kunder senere spørger til sikkerheden, er det også en fordel, at der findes en ordnet mappe med test, svar og udleveringer i stedet for en række spredte mails. → Læseadgang eller vedhæftet fil

Det skal I lade være med

Lade sælgeren svare alene · Sikkerhedssvar skal komme fra den, der kender produktet.
Love mere, end produktet kan · Kunden opdager det i testen eller i hverdagen.
Teste alt på én gang · En smal test af produktet er det, kunden har brug for.
Bestille uden tid til rettelser · En rapport med åbne kritiske fund hjælper ikke salget.
Glemme at gemme svarene · Næste kunde stiller mange af de samme spørgsmål.

Hvad kan og ikke kan konkluderes

En første afgrænset test kan give kunden dokumentation for, at produktets vigtigste dele er afprøvet af en uafhængig part. Den kan ikke dokumentere, at I har en sikkerhedsorganisation, og den kan ikke erstatte en ærlig beskrivelse af, hvordan I arbejder. Kunden vurderer begge dele.