Hoe een security sprint werkt

De meeste beveiligingstesten worden verkocht als een gebeurtenis: een scan draait, een rapport landt, een vinkje wordt gezet. Wij draaien het als een loop, omdat het rapport het minst waardevolle deel is. Zo verloopt een SealSec-security-sprint echt, en waarom hij de vorm heeft die hij heeft.

1. Inventariseren

Voordat we iets aanvallen, brengen we in kaart wat er bestaat. Niet alleen de belangrijkste webapp, maar de API, de mobiele clients, de cloudaccounts, de identity provider, de vergeten staging-machine met een publiek IP. Aanvallers respecteren je architectuurdiagram niet; ze vinden juist het ding dat je vergat. Dus de eerste taak is ervoor zorgen dat de scope overeenkomt met de werkelijkheid, en de doelwitten met hoge waarde expliciet te benoemen, meestal tenant-isolatie en authenticatie.

2. Testen

Dit is handwerk, geleid door een methode zoals de OWASP Web Security Testing Guide maar gedreven door oordeel. Scanners zijn goed in het bekende en het mechanische; ze zijn nutteloos bij de interessante bugs, de autorisatiecontrole die op een endpoint ontbreekt, het object-ID dat vertrouwd wordt zonder eigenaarschap te verifieren, de workflow die in de verkeerde volgorde kan worden uitgevoerd. We besteden onze tijd waar een echte aanvaller dat zou doen: ingelogd, als de ene tenant, proberend een andere te bereiken.

3. Triage

Een ruwe lijst met bevindingen is niet nuttig. We rangschikken op impact in de echte wereld op jouw specifieke product, niet op scanner-ernst. Een "medium" die de data van een andere klant blootlegt, gaat boven een "high" die fysieke toegang vereist tot een machine die niemand kan bereiken. Elke bevinding komt met genoeg reproductiedetail zodat je engineers het kunnen oplossen zonder een tweede vergadering.

4. Verifieren

Dit is het deel dat de meeste tests overslaan. Wanneer je iets hebt opgelost, hertesten we het. Een bevinding is gesloten wanneer iemand heeft bevestigd dat de fix werkt, niet wanneer een ticket naar "klaar" gaat. Dit is ook waar regressies worden opgevangen, en zoals ons regreSSHion-advies betoogt: een fix die niet getest wordt, is een fix die stilletjes ongedaan kan worden gemaakt.

Waarom een loop, geen lijn

De vier stappen voeden elkaar. Wat we leren tijdens het testen scherpt de volgende inventarisatie aan. Wat we verifieren wordt een regressietest. Het doel is geen certificaat om aan inkoop te tonen, al beantwoordt een recente test veel van een beveiligingsvragenlijst. Het doel is dat je product meetbaar moeilijker aan te vallen wordt, en dat blijft.

Als dat het soort testen is dat je wilt, is een kennismakingsgesprek waar we beginnen: we scopen het samen voordat iemand een toetsenbord aanraakt.