Handleiding TU Delft Benchmark
tegen Abuse
Voor een deel van de providers heeft TU Delft een abuse benchmark opgesteld. Op deze pagina wordt het doel en het model achter de benchmark besproken.
Doel
Zo goed als alle online dienstenleveranciers hebben met abuse te maken. Zo ook in de hostingmarkt. Daar neemt dat bijvoorbeeld de vorm aan van gehackte servers, phishing sites, malicious re-directs, command-and-control servers, spamservers, exploit kits, et cetera.
Wanneer je als hostingbedrijf probeert abuse te bestrijden, hoe weet je dan of je effectief bent? Als je tien incidenten hebt in een jaar, zeg gehackte servers of spammende klanten, is dat veel? Weinig? Hoeveel incidenten hebben andere aanbieders in de hostingmarkt eigenlijk? Hoe kun je die aantallen vergelijken tussen bedrijven van verschillende grootte en met verschillende typen diensten? Zonder een antwoord op deze vragen, is het moeilijk om te weten of je goed bezig bent.
De afgelopen jaren heeft een team aan de TU Delft gewerkt aan een abuse benchmark voor de hostingsector. De meeste recente versie delen we nu met de sector. Dat wil niet zeggen dat de benchmark perfect is en zonder beperkingen. Er zit nog steeds onzekerheid en ruis in. Wat we wel weten is dat de benchmark waardevolle informatie bevat die nuttig is voor elk hostingbedrijf dat wil leren hoe je nog beter abuse kunt bestrijden. We hebben hem uitvoerig getest en het blijkt dat de benchmark in hoge mate kan voorspellen hoeveel incidenten gaan optreden in een hostingnetwerk. De benchmark is niet bedoeld voor ‘naming and shaming’, maar om elk individueel bedrijf inzicht te geven in waar ze staan in vergelijking met andere aanbieders.
Model
- We definiëren een hostingprovider als de entiteit die volgens WHOIS data verantwoordelijk is voor de IP ranges met hostingdiensten. We nemen dus niet Autonomous Systems (AS) als uitgangspunt. In een eerdere studie ontdekten we dat er gemiddeld zeven providers per AS actief zijn. In deze eerste versie van de benchmark hebben we alleen de providers meegenomen die lid zijn van NBIP, ISPConnect of DHPA en voor wie we de WHOIS informatie konden achterhalen. Dat zijn 129 providers.
- Vervolgens nemen we een aantal abuse feeds [2]. Per feed tellen we het aantal incidenten dat is gezien bij elke provider in de periode januari-augustus 2018.
- Grote providers hebben meer incidenten dan kleine, omdat ze meer klanten en meer infrastructuur hebben. Dat betekent natuurlijk niet dat de minder veilig zijn. Ook het type diensten maakt verschil. Daarom verzamelen we enkele kenmerken van de providers, zoals hoeveel IP-adressen ze adverteren, hoeveel domeinen ze hosten en hoeveel shared hosting ze hebben.
- De abuse en provider data stoppen we in een statistisch model. Het model kijkt naar het aantal incidenten, rekening houdend met de grootte van de provider en een beetje met het type diensten in het netwerk. Het voert te ver om precies uit te leggen hoe het model werkt, maar het is in de basis hetzelfde als een IQ-test of een CITO-toets. Zo’n model schat in hoe goed iemand is in wiskunde als deze persoon een bepaalde puntenverdeling heeft over de verschillende vragen van de wiskunde-toets. In het model van de benchmark is elke feed als het ware een toetsvraag waarop de provider een aantal punten scoort. Vervolgens schat het model in welke onderliggende vaardigheid het beste die puntenverdeling verklaart ten opzichte van de andere ‘leerlingen’. Ook geeft het model een onzekerheidsmarge rond die score. Sommige scores zijn vrij robuust, andere hebben een grote marge.
- De benchmark is een cijfer dat uitdrukt waar de provider zich bevindt in de totale groep van 129 providers volgens het model. We drukken dat cijfer uit als percentiel. Een provider met score 20, bevindt zich dus in het 20e percentiel. Dat betekent dat 20% van alle providers meer abuse hebben dan deze provider en dat 80% van alle providers juist minder abuse hebben, rekening houdend met omvang en type diensten. Een score van 20 is dus een slechte score in termen van abusebestrijding. Je hoort dan bij de slechtste 20% van de markt. We hanteren de volgende eenvoudige aanduidingen om deze resultaten te communiceren: een score tussen 1-20 is slecht, tussen 20-80 is gemiddeld en tussen 80-100 is goed.
- Tenslotte hebben we naast de abuse benchmark ook nog een vulnerability benchmark berekend. Die volgt dezelfde stappen, maar dan met vulnerability data in plaats van abuse data [3]. Ook deze benchmark wordt uitgedrukt met de omschrijvingen slecht (1-20), gemiddeld (20-80) en goed (80-100). Het kan dus zo zijn dat een provider goed presteert in termen van abuse en slecht in termen van vulnerabilities.
De abuse en vulnerability data die in de benchmark is gebruikt, beslaat januari tot en met augustus 2018. Deze data is slecht in beperkte mate beschikbaar in de AbuseIO-omgeving van abuseplatform.nl. Deze omgeving bevat nog niet alle feeds en ook alleen de meest recente data. Het is de bedoeling dat bij de volgende iteraties van de benchmark de data gelijk gaat lopen met het platform. Oftewel, dat de benchmark gebaseerd is op de incidenten en vulnerabilities die de provider zelf kan zien in zijn of haar AbuseIO-account op abuseplatform.nl.
Meer informatie
Mocht u vragen hebben over de benchmark of de onderliggende data, dan kunt u contact opnemen met Carlos Gañán van de TU Delft:
C.HernandezGanan@tudelft.nl
+31 15 27 82216
Referenties
[1] Publicatie met een wetenschappelijke beschrijving van de benchmark
Arman Noroozian, Michael Ciere, Maciej Korczynski, Samaneh Tajalizadehkhoob & Michel van Eeten (2017), Inferring Security Performance of Providers from Noisy and Heterogenous Abuse Datasets, Workshop on the Economics of Information Security (WEIS2017), La Jolla, CA.
http://weis2017.econinfosec.org/wp-content/uploads/sites/3/2017/05/WEIS_2017_paper_60.pdf
[2] Lijst van gebruikte abuse feeds
- Spamhaus DBL (split into C&C, phishing, malware, spam)
- Shadowserver Compromised website report
- Shadowserver Command and control report
- APWG
- Phishtank
- Google Safe Browsing
[3] Lijst van gebruikte vulnerability feeds
- Shadowserver Drone Report
- Shadowserver CHARGEN report
- Shadowserver Open Memcached server report
- Shadowserver Open Resolvers Report
- Shadowserver SSL Freak Vulnerable Report
- Shadowserver SSL Poodle Report