Ansvarsfraskrivelse: Originalen til denne side er skrevet på hollandsk. Denne side er automatisk blevet oversat til andre sprog ved hjælp af DeepL. Dette kan resultere i forskelle i nuancer, tone og betydning. Hvis du er i tvivl, skal du altid konsultere den hollandske version først. På grund af de høje omkostninger ved oversættelser kan denne side være bagud i forhold til den hollandske version med hensyn til indhold. Vi betragter den hollandske version af denne side som førende.
Internet Cleanup Foundation har et adfærdskodeks, der fastlægger de grundlæggende principper for, hvilke målinger der offentliggøres og ikke offentliggøres.
Denne side uddyber dette med praktiske eksempler.
Offentlige målinger med et offentligt formål
I princippet måler Basic Security sikkerhed på det grundlæggende niveau. Dette kan frit offentliggøres uden at øge risikoen for misbrug ud over, hvad den allerede er. Overvej at måle, hvor almindelige sikkerhedsforanstaltninger mangler.
Basisbeveiliging.nl’s database indeholder mere end 10 millioner unikke målinger. Alle målinger i databasen kan til enhver tid offentliggøres i deres helhed eller lækkes uden at skabe nye risici, som en angriber kan udnytte.
En organisation med en passende sikkerhedspolitik vil altid være grøn på grundlæggende sikkerhed: Målingerne i sig selv er ikke nye eller chokerende, men den manglende anvendelse kan nogle gange være det.
Målingerne af den grundlæggende sikkerhed ligger inden for området etisk hacking og sikkerhedstestning. Der er stærke ligheder med de første trin i professionel sikkerhedstestning, som f.eks. kortlægning af angrebsfladen. Det dækker domæner, porte og software. Det er offentlig information, som er nem at indsamle i stor skala. Der er mange virksomheder, der gør dette og tilbyder det til meget lave omkostninger eller endda offentligt og gratis.
Basic Security offentliggør aldrig alvorlige eller kritiske sårbarheder. Det overlader vi til andre organisationer, f.eks. professionelle sikkerhedstestfirmaer som Secura, Zerocopter eller frivillige organisationer som DIVD.
Resultater, der kan offentliggøres
Internet Cleanup Foundation offentliggør information om sårbarheder og manglende sikkerhedsforanstaltninger. Det sker med det formål at få disse sårbarheder rettet. Baseret på adfærdskodekset afgøres det, om en sårbarhed kan offentliggøres. Det er her, offentlighedens interesse, proportionalitet og subsidiaritet overvejes.
Sårbarheder, der kan offentliggøres, er offentligt tilgængelige for alle på det grundlæggende sikkerhedswebsted. Dette kan også tilgås automatisk.
Sårbarheder, der kan offentliggøres, vurderes efter risiko. Dette er en anderledes risikovurdering, som er almindelig i sikkerhedsverdenen, fordi spektret af målinger er anderledes. Spektret for grundlæggende sikkerhed har fire karakterer, der er skaleret efter, hvad der potentielt kan gå galt. Dette er i modsætning til sædvanlige sikkerhedstests, som sætter de samme resultater i forhold til ting, der virkelig går galt lige nu. Hvor Basic Security vurderer noget som “højt”, vil det i en professionel sikkerhedstest blive vurderet som “info”, “lavt” eller i særlige tilfælde som “middel”, afhængigt af formålet med testen.
Graderingen af grundlæggende sikkerhed skifter over tid for langsomt at hæve barren for grundlæggende sikkerhed. Hvor en måling er orange i år, kan den være rød næste år for at henlede opmærksomheden på den. For eksempel er anvendelsen af security.txt ikke obligatorisk før midten af 2023, så på det tidspunkt vil ikke alle organisationer anvende denne standard. Men i midten af 2024 ville det være uacceptabelt, da de ville have haft et år til at anvende den. Der står mere om dette i målepolitikken.
Det er de fire gradueringer, vi anvender:
Rød: Dette repræsenterer en højrisiko-sårbarhed. Her handler det om en ufuldkommenhed, der skal rettes. Overvej f.eks. svag kryptering. Lækage af versionsinformation (læs: fortæller en angriber, hvad der skal udføres) og lignende.
Orange: Dette vedrører ofte institutioner og administrative mangler. Også nye målinger, som i sidste ende burde være røde, men som er skaleret som orange til introduktion: for at gøre målingen synlig og handlingsorienteret i de ansvarlige organisationer.
Grøn (lav): En måling, der involverer en afvigelse på sikkerheden, som har meget lille indflydelse (endnu), fordi der er få mennesker, der kan opleve dette problem, og i så fald er de ofte allerede udsat for en lang række mere alvorlige problemer. Dette niveau bruges også til målinger, der kan medføre juridiske forpligtelser i fremtiden, men som ikke er særlig almindelige i dag.
Grøn (ok): En korrekt måling: Sikkerheden er garanteret på dette tidspunkt.
Resultaterne forsynes altid med dokumentation, referencer og om muligt et link til en second opinion, hvor der kan udføres en ny test. Disse findes også i målepolitikken. Dette giver mulighed for at kende relevansen af et nyt fund og øjeblikkelig verifikation af, at sårbarheden er blevet rettet.
Eksempler på sårbarheder, der kan offentliggøres, er: manglende kryptering, manglende DNSSEC, manglende security.txt, tjenestens fysiske placering, anvendelse af RPKI, offentlige versionsoplysninger.
Alle oplysninger på webstederne, herunder alle målinger, er underlagt vores ansvarsfraskrivelse. Det er derfor altid for egen regning og risiko at handle på baggrund af disse resultater. Vi gør vores bedste for altid at offentliggøre korrekte og opdaterede mål, læs mere om dette i målepolitikken.
Hvordan offentliggøres nye målinger?
Før en ny måling bliver offentliggjort, bliver den først annonceret til paraplyorganisationerne, så de kan reagere på den. På det tidspunkt er selve måleresultaterne ofte endnu ikke indsigtsfulde. Mindst en måned senere bliver målingen synlig og offentlig.
Dette vil blive efterfulgt af en prøveperiode, hvor målingen højst vil blive vurderet som orange. I løbet af denne prøveperiode kan alle reagere på målingen, og målingen kan blive strammet. Denne periode varer normalt en måned eller to. Efter denne periode skaleres målingen igen og sættes muligvis til rød.
Eksempel på en sårbarhed, der kan offentliggøres
En organisation har brug for en hjemmeside. Hjemmesiden leveres af et udviklingsbureau. Udviklingsbureauet bruger standardsoftware og fokuserer primært på funktionalitet og information.
Hjemmesiden er ved at gå i luften, men der er endnu ikke taget hånd om sikkerheden. For eksempel er webstedet endnu ikke tilgængeligt via en krypteret forbindelse (1: https), der er ingen garantier for, at domænenavnet tilhører webstedets ip-adresse (2: DNSSEC), og der er et offentligt administrationspanel (3: loginpanel), der viser, at det drejer sig om softwareversion 7.0.2 (4: versionsoplysninger).
Denne sag giver en angriber alle mulige håndtag, som let kan undgås. En angriber behøver kun en lille eller ingen indsats for at finde dem og har længe og i vid udstrækning automatiseret denne viden for at gøre så meget skade som muligt på denne måde.
I dette casestudie kan en angriber udnytte sårbarheder på følgende måder: De kan læse med på internettrafikken på det samme netværk, f.eks. et Wi-Fi-hotspot, fordi https mangler (1: https), på det samme netværk kan angriberen omdirigere trafikken til en falsk side (2: dnssec), man kan forsøge at logge ind på administrationssiden hvor som helst i verden (3: login-panel) og søge efter og anvende offentligt kendte sårbarheder hvor som helst i verden (4: versionsoplysninger).
Angriberne har allerede disse oplysninger, så det er vigtigt, at de mennesker, der skal forsvare sig, også har dem. I alle disse angreb er der basis for åbenhed og god professionalisme.
Når kendte sikkerhedsrammer og standarder følges kompetent, er alle disse sårbarheder ikke til stede. Tænk på ISO27002, NEN7510, Baseline Information Security Government og lignende. Bemærk, at sådanne rammer ikke er praktiske og lader alle måle og måle løsninger selv. Som følge heraf vil en nybegynder i samme situation skrive en anden plan med hensyn til indhold end en professionel. I grundlæggende sikkerhed sætter vi en vis barre, som er relevant i alle tilfælde. Nogle finder denne overligger for høj, andre finder den for lav. Under alle omstændigheder er det grundlaget.
Sårbarheder, der ikke kan offentliggøres
Grundlæggende sikkerhed fokuserer på grundlæggende sikkerhedskrav.
Fondens frivillige finder også nogle gange alvorlige sårbarheder. Det er et biprodukt og ikke fondens mål. Her er, hvordan vi håndterer det. Aktive søgninger efter alvorlige sårbarheder foretages af den venligtsindede organisation DIVD. Så base security søger aldrig aktivt efter alvorlige sårbarheder.
Hvis vi ved et uheld finder en alvorlig sårbarhed, kan du se nedenfor, hvordan vi håndterer den.
Når der er mistanke om en alvorlig sårbarhed, overvejes det fra sag til sag, hvilken tilgang der giver den største sikkerhed på kortest mulig tid. Der er en række muligheder, der overvejes:
- Hvis det er en ny sårbarhed, som endnu ikke er kendt (ikke en CVE), er der en række muligheder. Det afhænger af, hvor sårbarheden er blevet identificeret, og hvor alvorlig den er. Følgende veje overvejes:
- Overlad det til Dutch Institute for Vulnerability Disclosure. De har infrastrukturen til at identificere ofre for denne sårbarhed og advare om lækagen. Denne handling er vores foretrukne mulighed.
- Når skaberen af softwaren har en ordentlig Coordinated Vulnerability Disclosure-proces, sendes denne sårbarhed også direkte til skaberen. Dette sker kun, når det kan gøres i fortrolighed.
- Grundreglerne omkring Coordinated Vulnerability Disclosure anvendes til at underrette den sårbare part.
- Når det drejer sig om en kendt sårbarhed, følges grundreglerne omkring Coordinated Vulnerability Disclosure. Det undersøges, om organisationen har en sådan proces på plads.
- Hvis der ikke findes en CVD-proces, kontaktes den sikkerhedsparaplyorganisation, som virksomheden tilhører. Det er f.eks. Informationssikkerhedstjenesten for kommuner eller det nationale cybersikkerhedscenter for den nationale regering.
- Det overvejes at sende rapporten videre via Security Hotline.
- Kommunikation omkring den alvorlige sårbarhed vil blive behandlet i henhold til CVD’s grundregler. Da det ikke er vores mål at finde og offentliggøre nye sårbarheder, vil kommunikationen om nye sårbarheder, hvis den overhovedet finder sted, sandsynligvis ske gennem den part, som den blev rapporteret til, Security Hotline, DIVD eller en lignende organisation.
Eksempler på sårbarheder, der ikke kan offentliggøres, er: SQL-injektion, cross-site scripting, brug af svage passwords, lækkede passwords, fjernudførelse af kode, bufferoverløb og CVE’er.
Eksempel på scenarie med alvorlig sårbarhed
Dette eksempel er baseret på et virkeligt scenarie og en kendt sårbarhed: Deaktivering af et modul, der gjorde filer med adgangskoder direkte læsbare på forsiden af et websted (deaktivering af PHP). Dette er en konfigurationsfejl.
En frivillig gennemsøger information på basicsecurity.co.uk. Den frivillige ser et websted: “oud.belangrijkeoganisation.nl”, som derfor kan have en svag sikkerhed. Den frivillige bliver interesseret og besøger siden.
Når man besøger siden, ser det ud til, at der er noget galt med konfigurationen: man kan se sidens kildekode i stedet for en smuk hjemmeside. Denne kildekode indeholder en databaseadgangskode og links til følsomme filer.
Den frivillige ved, at det ikke er hensigten, og rådfører sig med andre frivillige om, hvad der er klogt at gøre. Dette handler om en individuel og kendt sårbarhed, og CVD’s regler følges.
Den frivillige kontakter den sikkerhedsorganisation, der hører til hjemmesiden. Der udveksles oplysninger om sårbarheden, og organisationen følger de interne processer i forbindelse med CVD og løsning af sårbarheder.
Organisationen løste sårbarheden inden for en overskuelig tid. Nogle gange vælger organisationen at belønne journalisten med en godbid eller en plads i hall of fame.