De tre blir ofte presentert som nivåer av det samme, som om Red Team var en bedre penetrasjonstest og bug bounty en billigere. Det er de ikke. Hver av dem svarer på et eget spørsmål, og feil valg gir et presist svar på et spørsmål du ikke stilte.
Tre spørsmål
En penetrasjonstest spør: Hvilke sårbarheter har dette systemet? Et innleid team undersøker et avtalt omfang i en avtalt periode og rapporterer alt det fant, sammen med hva det dekket. Verdien ligger i dekningen: Du vet hva som ble testet, og hvordan.
Bug bounty spør: Hva kan folk utenfra finne som vi har oversett? Uavhengige sikkerhetsforskere ser på det som interesserer dem, så lenge de vil, og får betalt for gyldige funn. Verdien ligger i mangfoldet og utholdenheten. Ingen lover dekning.
En Red Team-operasjon spør: Ville vi merket et angrep, og kunne vi stanset det? Et team forfølger et konkret mål slik en virkelig angriper ville gjort, uten at forsvarerne dine vet om det. Verdien ligger i det den viser om deteksjon og respons. Å finne mange sårbarheter er ikke poenget; det holder å nå målet gjennom én.
Side om side
| Kriterium | Penetrasjonstest | Bug bounty | Red Team |
|---|---|---|---|
| Spørsmål | Hva er sårbart? | Hva har vi oversett? | Ville vi merket det? |
| Omfang | Avtalt, fast | Publisert, åpent | Definert av målene |
| Varighet | Dager til uker | Kontinuerlig | Uker til måneder |
| Hvem som vet om det | Alle | Alle | En liten kontrollgruppe |
| Dekning | Dokumentert | Ikke garantert | Ikke formålet |
| Betaling | For arbeidet | For gyldige funn | For arbeidet |
| Resultat | Rapport med alle funn | En strøm av rapporter | Beskrivelse av angrepet og hull i deteksjonen |
Den vanlige rekkefølgen
De fleste virksomheter bør ta disse stegene i rekkefølge, fordi hvert av dem er bortkastet uten det som kommer før.
- Penetrasjonstest. Finn og utbedre det en systematisk undersøkelse finner. Det er også dette revisorer og kunder ber om.
- Retningslinjer for sårbarhetsrapportering. Publiser en kanal for rapporter utenfra. Det koster lite, og det er grunnlaget for alt som følger.
- Privat bug bounty. Inviter en begrenset gruppe sikkerhetsforskere til et omfang som allerede er testet. Da betales belønningene for det som er vanskelig å finne.
- Offentlig bug bounty. Åpne programmet når svartidene og utbedringstidene holder i det private programmet.
- Red Team. Test deteksjon og respons når de grunnleggende sårbarhetene er borte og det finnes et team hvis arbeid kan testes.
Å begynne fra slutten er dyrt. Offentlig bug bounty på en utestet applikasjon betaler høye belønninger for funn som en test til fast pris ville levert de første dagene. En Red Team-operasjon mot en virksomhet uten overvåking beviser på en uke det som var kjent på forhånd.
Når rekkefølgen endres
- En myndighet foreskriver testen. Trusselbasert penetrasjonstesting etter DORA er en Red Team-øvelse med en fastsatt struktur. Hvis du er omfattet, er spørsmålet ikke om, men hvordan.
- Produktet får nye versjoner hver uke. En årlig test beskriver et system som ikke lenger finnes. Kontinuerlig testing erstatter det enkeltstående oppdraget.
- Systemet holder midler direkte. For smartkontrakter kommer revisjonen før utrullingen, og bug bounty med betydelige belønninger starter samme dag som utrullingen.
Hva du bør spørre en leverandør om
- Hva skal dekkes, helt konkret, og hvordan kan jeg se at det ble dekket?
- Hvem skal gjøre arbeidet, og hvem går gjennom rapporten?
- Hva skjer når en kritisk sårbarhet blir funnet den andre dagen?
- Er en retest inkludert, og frem til når?
- Hva trenger dere fra oss for å starte?
En leverandør som ikke kan svare på det første spørsmålet, selger tid, ikke trygghet.
Kort oppsummert
Velg penetrasjonstest når du trenger å vite tilstanden til et system. Velg bug bounty når du kjenner den og vil finne ut hva du har oversett. Velg Red Team når du vil teste menneskene og prosessene som skal oppdage et angrep. Hvis du ikke er sikker på hvilket spørsmål som er ditt, beskriv situasjonen, så sier vi hvilket vi ville startet med, og hvorfor.