De Internet Cleanup Foundation hanteert een code of conduct waarin de grondbeginselen staan over welke metingen wel en niet gepubliceerd worden.
Op deze pagina wordt dit verder uitgediept met praktische voorbeelden.
Openbare metingen met publiek een doel
In beginsel meet Basisbeveiliging veiligheid op het basisniveau. Dit kan vrij gepubliceerd worden zonder dat het risico op misbruik groter wordt dan deze al is. Denk aan het meten van waar gangbare beveiligingsmaatregelen ontbreken.
De database van Basisbeveiliging.nl bevat meer dan 10 miljoen unieke metingen. Alle metingen in de database kunnen op ieder moment volledig gepubliceerd worden, of uitlekken, zonder dat dit nieuwe risico’s oplevert waar een aanvaller gebruik van kan maken.
Een organisatie met een adequaat beveiligingsbeleid zal altijd groen staan op basisbeveiliging: de metingen zijn op zichzelf geen nieuws of schokkend, maar het gebrek aan toepassing kan dit soms wel zijn.
De metingen van basisbeveiliging zitten op het vlak van ethical hacking en beveiligingstesten. Er zijn sterke overeenkomsten met de eerste stappen van professionele security tests, zoals het aanvalsoppervlak in beeld brengen. Dat gaat over domeinen, poorten en software. Dit is publieke informatie die eenvoudig op grote schaal is te verzamelen. Er zijn vele bedrijven die dit doen en aanbieden tegen zeer lage kosten of zelfs openbaar en gratis.
Basisbeveiliging publiceert nooit ernstige of kritieke kwetsbaarheden. Dit laat ze over aan andere organisaties, zoals professionele security testbedrijven als Secura, Zerocopter of vrijwilligersorganisaties als de DIVD.
Publiceerbare bevindingen
De Internet Cleanup Foundation publiceert informatie rondom kwetsbaarheden en ontbrekende beveiligingsmaatregelen. Ze doet dit met het doel om deze kwetsbaarheden te laten oplossen. Op basis van de code of conduct wordt bepaald of een kwetsbaarheid gepubliceerd kan worden. Hier wordt gekeken naar het algemene belang, proportionaliteit en subsidiariteit.
Publiceerbare kwetsbaarheden zijn voor iedereen publiek inzichtelijk op de website van basisbeveiliging. Deze kan ook geautomatiseerd worden geraadpleegd.
Publiceerbare kwetsbaarheden worden beoordeeld op risico. Dit is een andere risicoclassificatie die gebruikelijk is in de securitywereld omdat het spectrum van metingen anders is. Het spectrum op basisbeveiliging heeft vier gradaties die worden geschaald op wat er potentieel mis kan gaan. Dit in tegenstelling tot gebruikelijke security tests, waarin dezelfde bevindingen worden afgezet tegen dingen die echt verkeerd gaan op dit moment. Waar Basisbeveiliging iets waardeert als “hoog” zal dit in een professionele security test als “info”, “laag” of in een bijzonder geval als “midden” worden neergezet afhankelijk van het doel van de test.
De gradaties op basisbeveiliging verschuiven over tijd, om zo de lat van basisveiligheid langzaam omhoog te tillen. Waar een meting dit jaar oranje is, kan deze volgend jaar op rood staan om hier zo meer aandacht op te vestigen. Zo is de toepassing van security.txt medio 2023 pas verplicht, dus rond die tijd zullen niet alle organisaties deze standaard toepassen. Echter zou dit medio 2024 onacceptabel zijn omdat men dan een jaar heeft gehad om het toe te passen. Hierover staat meer in het meetbeleid.
Dit zijn de vier gradaties die we toepassen:
Rood: dit staat voor een hoog risico kwetsbaarheid. Hier gaat het om een onvolkomenheid die moet worden opgelost. Denk bijvoorbeeld aan zwakke versleuteling. Het uitlekken van versie-informatie (lees: vertellen welke aanvaller een aanvaller moet uitvoeren) en dergelijke.
Oranje: dit gaat vaak over instellingen en administratieve onvolkomenheden. Ook worden nieuwe metingen die uiteindelijk rood horen te zijn, maar ter introductie worden ingeschaald als oranje: om zo de meting zichtbaar te maken en actionable te maken bij de verantwoordelijke organisaties.
Groen (laag): Een meting waarbij het gaat om een afwijking op veiligheid dat (nog) heel weinig impact heeft omdat er weinig mensen zijn die dit probleem kunnen ervaren, en in dat geval vaak al worden blootgesteld aan een breed scala ernstigere zaken. Dit niveau wordt ook gebruikt voor metingen die mogelijk in de toekomst wettelijke verplichtingen met zich meebrengen, maar vandaag niet heel gangbaar zijn.
Groen (ok): Een correcte meting: de veiligheid is gewaarborgd op dit punt.
Bevindingen worden altijd voorzien van documentatie, referenties en waar mogelijk een second opinion link waarop een hertest kan worden uitgevoerd. Deze staan ook in het meetbeleid. Hierdoor kan bij een nieuwe bevinding kennis worden opgedaan over de relevantie en direct controleren of de kwetsbaarheid is verholpen.
Voorbeelden van publiceerbare kwetsbaarheden zijn: ontbrekende versleuteling, ontbreken van DNSSEC, het ontbreken van security.txt, de fysieke locatie van dienstverlening, toepassing van RPKI, publieke versie-informatie.
Alle informatie op de websites, dus ook alle metingen, vallen onder onze disclaimer. Het handelen op basis van deze bevindingen is dus altijd voor eigen rekening en risico. We doen ons best om altijd correcte en up to date metingen te publiceren, lees hierover meer in het meetbeleid.
Hoe worden nieuwe metingen gepubliceerd
Voordat een nieuwe meting wordt gepubliceerd wordt deze eerst aangekondigd bij koepelorganisaties zodat organisaties hier maatregelen op kunnen nemen. De meetresultaten zelf zijn dan vaak nog niet inzichtelijk. Minimaal een maand later wordt de meting inzichtelijk en openbaar.
Hierna volgt een proefperiode waarop de meting ten hoogste als oranje wordt ingeschaald. In die proefperiode kan iedereen op de meting reageren en wordt de meting mogelijk nog aangescherpt. Deze periode duurt meestal een maand of twee. Na deze periode wordt de meting opnieuw ingeschaald en mogelijk op rood gezet.
Voorbeeldscenario publiceerbare kwetsbaarheid
Een organisatie heeft een website nodig. Deze website wordt opgeleverd door een ontwikkelbureau. Dit ontwikkelbureau maakt gebruik van standaard-software en richt zich voornamelijk op functionaliteit en informatie.
De website gaat live, maar er is nog niet gekeken naar de veiligheid. Zo is de site nog niet bereikbaar via een versleutelde verbinding (1: https), zijn er geen garanties of de domeinnaam wel bij het ip-adres van de site hoort (2: DNSSEC) en staat er een beheerpaneel publiek (3: login panel) waarop te zien dat het gaat over softwareversie 7.0.2 (4: versie informatie).
Deze casus geeft een aanvaller allerlei handvatten die makkelijk voorkomen kunnen worden. Een aanvaller hoeft niet of nauwelijks moeite te doen om deze te vinden, en heeft deze kennis lang en breed geautomatiseerd om op deze manier zoveel mogelijk schade te doen.
In deze casus kan een aanvaller op de volgende manieren misbruik maken van kwetsbaarheden: ze kunnen op hetzelfde netwerk zoals een wifi hotspot meelezen met het internetverkeer omdat https ontbreekt (1: https), op hetzelfde netwerk kan de aanvaller het verkeer omleiden naar een valse pagina (2: dnssec), men kan overal ter wereld pogingen doen om in te loggen op de beheerpagina (3: login panel) en overal ter wereld publiek bekende kwetsbaarheden zoeken en toepassen (4: versie informatie).
Aanvallers hebben deze informatie al, daarom is het belangrijk dat de mensen die moeten verdedigen ook hierover beschikken. Bij al deze aanvallen zit een basis in openbaarheid en goed vakmanschap.
Wanneer de bekende security-raamwerken en -normenkaders kundig worden opgevolgd zijn al deze kwetsbaarheden niet aanwezig. Denk aan ISO27002, NEN7510, Baseline Informatiebeveiliging Overheid en dergelijke. Let wel dat dergelijke frameworks niet praktisch zijn en iedereen zelf oplossingen laat meten en aanmeten. Hierdoor zal in dezelfde situatie een beginneling inhoudelijk een ander plan schrijven dan een professional. Bij basisbeveiliging leggen we een bepaalde lat dat in alle gevallen relevant is. Sommigen vinden deze lat te hoog, anderen vinden deze te laag. Het is in ieder geval de basis.
Niet publiceerbare kwetsbaarheden
Basisbeveiliging richt zich op basis-veiligheidseisen.
Vrijwilligers van de stichting vinden soms ook ernstige kwetsbaarheden. Dit is bijvangst en niet het doel van de stichting. Hier staat hoe we hiermee omgaan. Actief zoeken op ernstige kwetsbaarheden wordt gedaan door bevriende organisatie DIVD. Basisbeveiliging zoekt dus nooit actief naar ernstige kwetsbaarheden.
Mochten we per ongeluk toch een ernstige kwetsbaarheid vinden, staat hieronder hoe we hiermee omgaan.
Bij vermoeden van een ernstige kwetsbaarheid wordt hier per casus bekeken wat de aanpak is die de grootste veiligheid oplevert op de kortste termein. Er zijn een aantal opties die worden overwogen:
- Is het een nieuwe kwetsbaarheid die nog niet bekend is (geen CVE), dan zijn er een aantal opties. Het hangt af van waar de kwetsbaarheid is vastgesteld en wat de ernst is. De volgende paden worden overwogen:
- Overdragen aan de Dutch Institute for Vulnerability Disclosure. Zij hebben de infrastructuur om slachtoffers van deze kwetsbaarheid te identificeren en te waarschuwen voor het lek. Deze actie heeft onze voorkeur.
- Wanneer de maker van de software een goed Coordinated Vulnerability Disclosure proces heeft, wordt deze kwetsbaarheid ook direct aan de maker doorgestuurd. Dit gebeurd alleen wanneer dit in vertrouwen kan.
- De spelregels rondom Coordinated Vulnerability Disclosure worden toegepast om de kwetsbare partij in te lichten.
- Wanneer het gaat om een bekende kwetsbaarheid dan worden de spelregels gevolgd rondom Coordinated Vulnerability Disclosure. Er wordt gekeken of de organisatie een dergelijk proces heeft ingericht.
- Als er geen CVD proces is ingericht wordt contact opgenomen met de security-koepelorganisatie waar deze organisatie onder valt. Dit is bijvoorbeeld de Informatiebeveiligingsdienst voor Gemeenten of het Nationaal Cyber Security Centrum voor de landelijke overheid.
- Er wordt overwogen om de melding door te zetten via het Security Meldpunt.
- Communicatie rondom de ernstige kwetsbaarheid wordt overwogen volgens de spelregels van het CVD. Omdat het vinden en publiceren van nieuwe kwetsbaarheden niet ons doel is, zal de communicatie over nieuwe kwetsbaarheden, als dit al ooit voorkomt, waarschijnlijk lopen via de partij waaraan het gemeld is, het Security Meldpunt, de DIVD of een soortgelijke organisatie.
Voorbeelden van niet publiceerbare kwetsbaarheden zijn: SQL injectie, cross-site scripting, gebruik van zwakke wachtwoorden, uitgelekte wachtwoorden, remote code execution, buffer overflows en CVE‘s.
Voorbeeldscenario ernstige kwestbaarheid
Dit voorbeeld is gebaseerd op een waargebeurd scenario en een bekende kwetsbaarheid: het uitzetten van een module waardoor bestanden met wachtwoorden direct leesbaar waren op de voorpagina van een site (uitschakelen van PHP). Dit is een configuratiefout.
Een vrijwilliger is aan het grasduinen door informatie op basisbeveiliging.nl. De vrijwilliger ziet een site: “oud.belangrijkeoganisatie.nl”, met daarom misschien zwakke beveiliging. De vrijwilliger raakt geïnteresseerd en bezoekt de site.
Bij het bezoek van de site blijkt dat er iets mis is met de configuratie: de broncode van de site is te zien, in plaats van een mooie website. In deze broncode staat een wachtwoord van de database en links naar gevoelige bestanden.
De vrijwilliger weet dat dit niet de bedoeling is en overlegt met andere vrijwilligers wat verstandig is om te doen. Dit gaat over een individuele en bekende kwetsbaarheid, de regels van CVD worden gevolgd.
De vrijwilliger neemt contact op met de security-organisatie die hoort bij de website. Informatie over de kwetsbaarheid wordt uitgewisseld en de organisatie volgt de interne processen die horen bij CVD en het oplossen van kwetsbaarheden.
De organisatie heeft de kwetsbaarheid binnen afzienbare tijd opgelost. Soms kiest de organisatie ervoor om de melder te belonen met een goodie of vermelding in de hall of fame.