Een pentest voor livegang test een nieuwe applicatie voordat er echte klanten en echte gegevens in zitten. Dat is het goedkoopste moment dat er is: een fout die je dan vindt, kost een aanpassing. Dezelfde fout na livegang kost een aanpassing, een migratie, mogelijk een melding en zeker een gesprek met klanten dat je liever niet voert.
Kort samengevat
- Vóór livegang kost een fout een aanpassing; erna kost hij een migratie, een melding en vertrouwen.
- Een pentest voor livegang richt zich op logica, autorisatie, gegevenstoegang en de koppelingen naar buiten.
- Plan twee tot drie weken tussen test en livegang: testen, repareren, hertesten.
- Voor softwareleveranciers is het rapport bij oplevering een verkoopargument.
In scopegesprekken met organisaties die zelf software bouwen of laten bouwen, komt steeds dezelfde situatie voor: er staat een nieuwe applicatie op het punt om live te gaan, die gevoelige gegevens gaat verwerken, en de vraag is of daar nog even iemand naar moet kijken. Het antwoord is ja, en het argument is niet alleen beveiliging.
Waarom is testen vóór livegang zoveel goedkoper?
Omdat de kosten van een fout na livegang niet in de fout zitten, maar in alles eromheen:
- Vóór livegang: de ontwikkelaar past de code aan, de tester controleert het, klaar.
- Na livegang: de fout wordt gevonden door een klant, een aanvaller of bij toeval. Er zitten al gegevens in die mogelijk zijn ingezien. Er moet worden vastgesteld wat er is gebeurd, er moet mogelijk gemeld worden, klanten moeten geïnformeerd, en de aanpassing moet in productie zonder de dienst te onderbreken.
Dezelfde regel code, een factor tien of meer in kosten. En dat is nog zonder de reputatieschade van een nieuwe dienst die in zijn eerste maand een incident heeft.
Wat test een pentest voor livegang?
Anders dan bij een bestaande applicatie is er nog geen geschiedenis van incidenten of klachten om op te sturen. De tester kijkt daarom naar de categorieën waar nieuwe applicaties vrijwel altijd fouten in hebben:
- Autorisatie. Kan een gebruiker gegevens van een andere gebruiker zien door een nummer in de URL aan te passen? Kan een gewone gebruiker een beheerfunctie aanroepen? Dit is de meest voorkomende en meest schadelijke fout in nieuwe applicaties.
- Logica. Kan een stap in een proces worden overgeslagen? Kan een bedrag of een status worden aangepast die alleen het systeem zou mogen zetten?
- Gegevenstoegang. Hoe is de database bereikbaar, met welke rechten draait de applicatie, en wat gebeurt er als de inlog wordt omzeild: staat dan alles open, of alleen wat bij dat account hoort?
- Koppelingen. Welke API’s biedt de applicatie aan, welke externe diensten gebruikt ze, en zijn die allemaal beveiligd, of alleen de schermen die een mens ziet?
- Componenten. Welke externe bibliotheken zitten erin, in welke versie, en zijn daar al bekende problemen mee gepubliceerd?
Bij twee applicaties met dezelfde architectuur volstaat het testen van één als representatief voor beide. Dat scheelt de helft van de kosten zonder de helft van de zekerheid te verliezen.
Hoe plan je het zonder de livegang te bedreigen?
De meest gemaakte fout is een pentest voor livegang plannen in de laatste week. Dan is er geen tijd om iets met de uitkomst te doen, en wordt de test een formaliteit. Reken op drie stappen en drie weken:
- Week één: de test. Op een omgeving die lijkt op productie, met de functionaliteit compleet.
- Week twee: repareren. De ontwikkelaar werkt de bevindingen af, in volgorde van ernst.
- Week drie: de hertest. De tester controleert of de kritieke en hoge bevindingen echt dicht zijn.
Komen er kritieke bevindingen uit die niet in een week te repareren zijn, dan schuift de livegang. Dat voelt als een tegenslag; het is precies de uitkomst waarvoor je testte.
Voor wie software levert: het rapport is een verkoopargument
Organisaties die software leveren aan andere organisaties, merken het al: klanten sturen beveiligingsvragenlijsten, vragen om bewijs van onafhankelijk testen, en wegen dat mee in de keuze. Een pentest voor livegang levert dat bewijs op het moment dat je het het hardst nodig hebt: bij de oplevering, als het vertrouwen nog verdiend moet worden. Het is een van de weinige beveiligingsuitgaven die zich direct commercieel terugbetaalt.
Staat er bij jou een applicatie op het punt om live te gaan? In een scopegesprek bepalen we wat een pentest voor livegang in jouw geval moet omvatten en hoe hij in je planning past.
BOEM voert pentesten uit met EHGI, het bedrijf achter de EHGN-community van 2.500+ ethische hackers, waaronder specialisten van Politie, Defensie en DIVD. Welke tester bij jouw omgeving past, bepalen we in het scopegesprek.
Veelgestelde vragen
Wat is een pentest voor livegang?
Een test van een nieuwe applicatie of een grote nieuwe versie voordat die in productie gaat en voordat er echte gebruikers en echte gegevens in zitten. Fouten die dan worden gevonden, kosten een aanpassing; dezelfde fouten na livegang kosten veel meer.
Wanneer plan je een pentest voor livegang?
Zodra de functionaliteit compleet is en de omgeving lijkt op productie, maar vóór de datum waarop klanten erin gaan. Reken op twee tot drie weken tussen test en livegang: één voor de test, één voor reparaties, één voor de hertest.
Wat als er kritieke bevindingen uit komen vlak voor livegang?
Dan heb je precies gekregen waarvoor je testte. Een kritieke fout die één week uitstel kost, is oneindig veel goedkoper dan dezelfde fout die na livegang een datalek wordt. Plan de test dus ruim genoeg vooraf om uitstel op te kunnen vangen.
Levert een pentest voor livegang ook commercieel iets op?
Ja. Klanten en opdrachtgevers vragen steeds vaker om bewijs dat software onafhankelijk is getest. Een rapport bij oplevering is een verkoopargument en verkort de beveiligingsvragenlijst die grote klanten toch al sturen.
