Kort sagt: Pentest eller sårbarhedsscanning er ikke et enten-eller-spørgsmål, men et spørgsmål om rækkefølge. En sårbarhedsscanning finder automatiseret kendte sårbarheder og fejlkonfigurationer, hurtigt og billigt, men med falske alarmer og blinde pletter. En penetrationstest kontrollerer målrettet, hvad en angriber faktisk kunne opnå. Et bug bounty-program åbner kontrollen for eksterne forskere og kan først betale sig, når scanninger og pentests er blevet rutine. For de fleste SMV er rækkefølgen: scanne regelmæssigt, udbedre fund, lade teste målrettet, oprette en meldestilling for sårbarheder.
Hvorfor spørgsmålet stilles på ny efter PHP2Shell
Den, der efter PHP2Shell kontrollerer sit website med en online-scanner, kan få forvirrende resultater. En scanner melder måske en kritisk sårbarhed, selv om hostingudbyderen har bekræftet patchen. En anden melder intet, selv om serveren stadig bruger en gammel PHP-version, fordi versionsangivelsen er skjult.
Årsagen ligger i arbejdsmåden. Mange scannere udleder sårbarheden af den viste version. Distributioner indspiller dog backports uden at ændre versionsnummeret; ifølge rapporter viser f.eks. Ubuntu 24.04 efter opdateringen fortsat 8.3.6. Hvorfor det er sådan, forklarer Hvorfor php -v efter opdateringen viser det samme nummer. Det pålidelige bevis leverer pakkens changelog, se Kontrollér PHP-version og patchstatus korrekt.
Det er ikke et argument imod scannere, men et for at kende deres grænser og kombinere dem med andre metoder.
Pentest eller sårbarhedsscanning: de tre metoder sammenlignet
| Kriterium | Sårbarhedsscanning | Penetrationstest | Bug bounty |
|---|---|---|---|
| Hvem kontrollerer? | Automatiseret værktøj | Bestilte fagfolk | Eksterne forskere, ofte via en platform |
| Hvad findes? | Kendte sårbarheder, forældede versioner, fejlkonfigurationer | Udnytbare sårbarheder, logikfejl, sammenkædninger | Hvad forskere finder og melder, ofte noget usædvanligt |
| Dybde | Bred, men overfladisk | Dyb inden for den aftalte ramme | Varierende, afhængig af deltagerne |
| Falske alarmer | Hyppige | Sjældne, fund dokumenteres | Mange meldinger, som skal vurderes |
| Planlægbarhed | Høj, kan gentages vilkårligt | Høj, fast periode og omfang | Lav, meldinger kommer løbende |
| Forudsætninger i virksomheden | Nogen, der vurderer resultaterne | Afstemt omfang, testmiljø eller vedligeholdelsesvindue | Moden proces til vurdering, udbedring og belønning |
| Typisk anvendelse | Løbende, f.eks. månedligt eller efter ændringer | Før start, efter større ændringer, regelmæssigt | Supplerende ved modne, eksponerede applikationer |
Ingen af metoderne erstatter de andre. Scanningen viser meget på kort tid, pentesten viser, hvad der virkelig tæller, og bug bounty finder det, ingen havde tænkt på.
Ved scannere kan det desuden betale sig at se nærmere på scanningens art. En scanning udefra ser kun, hvad enhver besøgende ser, og må ofte gætte versioner ud fra serverens svar. En autentificeret scanning, hvor værktøjet med egne adgangsoplysninger aflæser de installerede pakker på serveren, giver klart mere pålidelige resultater, især ved PHP's faktiske pakkestatus. Den forudsætter dog, at I opsætter og beskytter en begrænset adgang dertil. Til afhængighederne i egne PHP-applikationer findes der igen egne kontrolværktøjer, f.eks. composer audit til pakker fra Composer.
Den fornuftige rækkefølge for SMV
- Oversigt og scanning: Først vide, hvilke websites og servere der findes, derefter scanne regelmæssigt. Overtag ikke fund ukontrolleret, men vurdér dem.
- Udbedre grundlaget: Fjern forældet software, manglende opdateringer og åbenlyse fejlkonfigurationer. At sætte en pentest på upatchede systemer spilder budget.
- Målrettet penetrationstest: For de vigtigste applikationer, f.eks. shop, kundeportal eller grænseflader, med klart aftalt omfang og eftertest.
- Kodekontrol ved egenudvikling: Den, der driver egne PHP-applikationer, supplerer testen med en gennemgang af kildekoden. Hvordan det forløber, beskriver Sikkerheds-code review til PHP-projekter.
- Meldestilling for sårbarheder: En politik for, hvordan eksterne kan melde sårbarheder, og en security.txt-fil efter RFC 9116 under
/.well-known/security.txtmed kontakt og udløbsdato. - Bug bounty, når grundlaget sidder: Først når meldinger vurderes pålideligt, og sårbarheder udbedres rettidigt.
For at det bliver et varigt forløb, er det værd at se på Sårbarhedshåndtering for mindre og mellemstore virksomheder.
Hvad ingen af metoderne kan
Ingen kontrolmetode beviser, at et system er sikkert. Den viser kun, hvad der på et tidspunkt blev fundet med bestemte metoder. En ren pentest-rapport fra foråret siger intet om en sårbarhed som PHP2Shell, der bliver kendt i oktober.
Lige så lidt besvarer scanning eller pentest spørgsmålet, om en server allerede er kompromitteret. Dertil kræves en sporsøgning på selve systemet: processer, filer, cronjobs, konti, forbindelser. Det er en egen opgave med egne metoder.
Lad kun systemer kontrollere, som I er berettiget til, og afklar ved hostede systemer udbyderens regler på forhånd. En penetrationstest kræver en skriftlig bestilling med omfang, periode og kontaktpersoner.
Hvornår I ikke har brug for en ekstern test
Til et enkelt virksomhedswebsite uden formularer med følsomme data, hos en hostingudbyder, der indspiller opdateringer pålideligt, er en regelmæssig scanning med kritisk vurdering af resultaterne ofte nok. En penetrationstest ville her som regel være uforholdsmæssig. Vigtigere er aktuel software, stærke adgange og backups.
En ekstern test kan betale sig ved shops, portaler, egenudvikling, grænseflader til interne systemer og overalt, hvor kunder eller standarder kræver et uafhængigt bevis.
Hvordan hjælper PHP SOS konkret?
- Vi opsætter regelmæssige scanninger og vurderer resultaterne, inklusive de falske alarmer på grund af backports.
- Vi hjælper med at udbedre grundlaget, før der investeres penge i en pentest.
- Sammen med specialiserede partnere gennemfører vi sikkerhedsaudits og penetrationstests med afstemt omfang og eftertest.
- Vi støtter opbygningen af en meldestilling for sårbarheder og en security.txt.
Konklusion
Scanning, pentest og bug bounty er trin, ikke konkurrenter. Den, der begynder med regelmæssige scanninger, udbedrer grundlaget og derefter lader teste målrettet, får mest sikkerhed for sit budget. Bug bounty er det frivillige ekstra for organisationer, hvor det obligatoriske allerede sidder.
Ofte stillede spørgsmål
Hvad er forskellen på pentest og sårbarhedsscanning?
En sårbarhedsscanning kontrollerer automatiseret, om kendte sårbarheder eller fejlkonfigurationer kan genkendes. En penetrationstest går videre: Fagfolk forsøger inden for en aftalt ramme faktisk at udnytte og sammenkæde sårbarheder og vurderer følgerne.
Finder en scanner ud af, om min server er patchet mod PHP2Shell?
Kun i begrænset omfang. Mange scannere aflæser den viste PHP-version. Indspiller distributionen en backport, forbliver nummeret ofte det samme, og scanneren melder en sårbarhed, som for længst er lukket. Omvendt kan et nyt nummer blive vist, mens gamle processer stadig kører.
Er et bug bounty-program noget for små virksomheder?
Som regel endnu ikke. Bug bounty forudsætter, at meldinger vurderes hurtigt, og sårbarheder udbedres rettidigt. En god begyndelse er en enkel politik for melding af sårbarheder med en security.txt-fil.
Må jeg selv kontrollere mit website med en scanner?
Jeres egne systemer som regel ja, hvis I er berettiget dertil. Ligger websitet hos en hostingudbyder, afklar på forhånd, om scanninger er tilladt eller skal varsles. Fremmede systemer kontrollerer I kun med skriftlig tilladelse fra driftsansvarlige.
Hvor ofte bør en pentest finde sted?
Der findes ingen fast regel. Almindeligt er en test før start af en ny applikation, efter større ændringer og med regelmæssige mellemrum, som jeres risiko og eventuelt krav fra kunder eller standarder bestemmer.