Een penetratietest beantwoordt de vraag die in de scope staat, en niets anders. Staat er in de scope "test onze webapplicatie", dan krijgt u een rapport over wat de testers in de beschikbare tijd het interessantst vonden. Dat is niet noodzakelijk wat u wilde weten.
De oplossing is voorbereiding. Bepaal de vraag, de regels, de toegang, de omgang met data en de definitie van "klaar" voordat u offertes opvraagt.
Begin bij de vraag, niet bij het doelwit
Een lijst met IP-adressen en URL's is een lijst met doelwitten, geen doelstelling. De doelstelling is de beslissing die de test moet ondersteunen. NIST SP 800-115 stelt dat technische securitytests meerdere doelen dienen, zoals het vinden van kwetsbaarheden in een systeem of netwerk en het verifiëren van naleving van een beleid of andere eisen. Dat zijn verschillende opdrachten en ze vragen om verschillende tests.
Formuleer de doelstelling als een zin die een niet-technische opdrachtgever kan lezen. Enkele voorbeelden:
- Kan een ingelogde klant in het nieuwe portaal de facturen van een andere klant inzien?
- Kan een aanvaller zonder account bij de beheerinterface van het reserveringssysteem komen?
- Voldoet de applicatie aan de eisen voor toegangsbeheer die de securityvragenlijst van onze klant aanhaalt?
Elk van deze vragen impliceert een andere scope, andere accounts en een ander rapport. Lukt het u niet om het in één zin te zeggen, dan bent u nog niet klaar om in te kopen. Een kort afstemmingsgesprek met de testers of met een adviseur, zoals ons adviesteam, is de moeite waard voordat u offertes opvraagt.
Kies een referentie voor "getest"
"Volledig getest" zegt niets zolang u niet benoemt waartegen is getest. Voor webapplicaties bieden twee OWASP-projecten een gedeelde woordenschat.
De OWASP Application Security Verification Standard (ASVS) is een basis voor het testen van technische securitymaatregelen in webapplicaties, en geeft ontwikkelaars een lijst met eisen voor veilige ontwikkeling. De projectpagina noemt 5.0.0 als nieuwste stabiele versie. Elke eis heeft een genummerde identifier en het project adviseert die samen met de versie te vermelden, bijvoorbeeld v5.0.0-1.2.5. De versie is belangrijk omdat identifiers tussen releases kunnen veranderen.
De OWASP Web Security Testing Guide beschrijft hoe u test. Op de pagina staat v4.2 als huidige release, terwijl 5.0 nog in ontwikkeling is. Leg de versie die u verwacht vast in het contract, anders gaat elke partij uit van een andere.
Geef vervolgens aan welke onderdelen van de ASVS binnen de scope vallen, per hoofdstuk en sectie zoals ze in de gekozen versie staan. De identifier v5.0.0-1.2.5 verwijst bijvoorbeeld naar de 5e eis in de sectie "Injection Prevention" van het hoofdstuk "Encoding and Sanitization". Kies de secties die bij uw doelstelling passen en vraag om bevindingen die zijn gekoppeld aan de identifiers van de eisen. Dat maakt hertests en de opvolging door ontwikkelaars een stuk eenvoudiger.
Rules of engagement
De rules of engagement zijn de schriftelijke grenzen aan wat de testers mogen doen. Dit zijn onze aanbevelingen en geen voorschriften uit de bronnen, maar elk scopedocument hoort deze punten vast te leggen:
| Onderdeel | Te bepalen |
|---|---|
| Omgeving | Productie, staging of beide. Staging is veiliger, maar alleen nuttig als de configuratie overeenkomt met productie. |
| Testperiode | Data en tijden, en of buiten kantooruren getest mag worden. |
| Bronadressen | De IP-adressen die de testers gebruiken, zodat uw monitoringteam ze kan onderscheiden van een echte aanvaller. |
| Uitgesloten technieken | Denial of service, social engineering en fysieke toegang worden vaak uitgesloten. Leg het in beide gevallen vast. |
| Stopcondities | Wat de testers laat pauzeren: een storing, toegang tot onverwachte persoonsgegevens, een kritieke bevinding. |
| Contactpersonen | Twee genoemde personen per partij, met telefoonnummers die ook 's nachts werken. |
Bepaal vooraf of uw SOC op de hoogte wordt gesteld van de test. Als u het hen vertelt, test u het proces. Houdt u het stil, dan test u de detectie. Beide zijn geldig, maar maak de keuze bewust.
Testaccounts en omgang met data
Zorg voor accounts, want een tester zonder login kan niet onderzoeken wat erachter zit. Geef één account per rol die de applicatie kent, plus twee accounts in dezelfde rol die bij verschillende klanten of tenants horen. Zonder dat paar kan niemand controleren of de ene gebruiker bij de gegevens van een ander kan.
Maak de accounts vooraf aan, test of ze kunnen inloggen en leg uit hoe multifactorauthenticatie wordt afgehandeld.
Leg de omgang met data vast in het contract:
- Gebruik in staging waar mogelijk synthetische data. Valt productie binnen de scope, geef dan aan welke echte records de testers mogen inzien en welke niet.
- Beschrijf waar bewijsmateriaal zoals screenshots, requestlogs en geëxtraheerde data wordt opgeslagen, wie er toegang toe heeft en hoe lang de testers het bewaren.
- Eis dat het rapport zelf versleuteld wordt verstuurd. Het is een lijst van uw zwakke plekken.
- Stel een regel op voor gevoelige vondsten: stuiten testers op persoonsgegevens, dan stoppen ze, noteren ze de vindplaats zonder de inhoud te kopiëren en bellen ze uw contactpersoon.
Succescriteria en rapportage
"Geen kritieke bevindingen" is geen succescriterium. Het beloont een oppervlakkige test. Definieer "klaar" als dekking plus kwaliteit van de uitvoer: de afgesproken eisen zijn onderzocht en elke bevinding bevat genoeg detail om te reproduceren en te verhelpen.
NIST beschrijft zijn richtlijn als hulp bij het analyseren van bevindingen en het ontwikkelen van mitigatiestrategieën, naast het uitvoeren van de tests. Vraag om hetzelfde. Elke bevinding hoort te bevatten: reproductiestappen, het getroffen component, een ernstclassificatie met een benoemde methode zodat u die zelf kunt narekenen, en een concrete oplossing. Neem een hertest van opgeloste bevindingen op in de offerte en spreek af wie het rapport accepteert en wanneer.
Koopt u in bij een aanbieder zoals onze penetratietestdienst, neem deze punten dan op in de statement of work en niet alleen in het kick-offgesprek.
Waar te beginnen
- Schrijf de doelstelling op als één zin en laat de business owner ermee instemmen.
- Maak een lijst van de applicaties, omgevingen en rollen binnen de scope en benoem expliciet wat erbuiten valt.
- Kies de referentie: de ASVS-hoofdstukken en -secties binnen de scope en een versie van de Web Security Testing Guide, alles met versienummers.
- Vul de tabel met rules of engagement in, inclusief contactpersonen, testperiode en bronadressen.
- Maak testaccounts aan en verifieer ze, inclusief twee accounts in dezelfde rol voor verschillende tenants, en stel de regels voor de omgang met data vast.
- Leg de succescriteria vast in het contract: formaat van bevindingen, ernstmethode, koppeling aan identifiers van eisen en een hertest.
