Ansvarsfraskrivelse: Originalen av denne siden er skrevet på nederlandsk. Denne siden er automatisk oversatt til andre språk ved hjelp av DeepL. Dette kan føre til forskjeller i nyanser, tonefall og betydning. Hvis du er i tvil, bør du alltid konsultere den nederlandske versjonen først. På grunn av de høye kostnadene ved oversettelser kan denne siden ligge etter den nederlandske versjonen når det gjelder innhold. Vi anser den nederlandske versjonen av denne siden som ledende.
Internet Cleanup Foundation har etiske retningslinjer som beskriver de grunnleggende prinsippene for hvilke målinger som skal og ikke skal publiseres.
På denne siden utforskes dette nærmere med praktiske eksempler.
Offentlige målinger med et offentlig formål
I prinsippet måler Basic Security sikkerhet på grunnleggende nivå. Dette kan publiseres fritt uten å øke risikoen for misbruk utover det den allerede er. Vurder å måle hvor vanlige sikkerhetstiltak mangler.
Basisbeveiliging.nls database inneholder mer enn 10 millioner unike målinger. Alle målingene i databasen kan publiseres i sin helhet når som helst, eller lekkes, uten at det skaper nye risikoer som en angriper kan utnytte.
En organisasjon med en adekvat sikkerhetspolicy vil alltid være grønn på grunnleggende sikkerhet: Målingene i seg selv er ikke noe nytt eller sjokkerende, men mangelen på anvendelse kan av og til være det.
Målingene av grunnleggende sikkerhet ligger innenfor området etisk hacking og sikkerhetstesting. Det er store likhetstrekk med de første trinnene i profesjonell sikkerhetstesting, for eksempel kartlegging av angrepsflaten. Dette omfatter domener, porter og programvare. Dette er offentlig informasjon som er lett å samle inn i stor skala. Det finnes mange selskaper som gjør dette og tilbyr det til svært lave kostnader eller til og med offentlig og gratis.
Basic Security publiserer aldri alvorlige eller kritiske sårbarheter. Dette overlater vi til andre organisasjoner, for eksempel profesjonelle sikkerhetstestingsselskaper som Secura, Zerocopter eller frivillige organisasjoner som DIVD.
Publiserbare funn
Internet Cleanup Foundation publiserer informasjon om sårbarheter og manglende sikkerhetstiltak. Dette gjøres med sikte på å få disse sårbarhetene rettet. Basert på de etiske retningslinjene avgjøres det om en sårbarhet kan publiseres. Her vurderes allmennhetens interesse, proporsjonalitet og subsidiaritet.
Publiserbare sårbarheter er offentlig tilgjengelig for alle på nettstedet for grunnleggende sikkerhet. Denne kan også nås automatisk.
Publiserbare sårbarheter er rangert etter risiko. Dette er en annen risikoklassifisering enn det som er vanlig i sikkerhetsverdenen, fordi målespekteret er annerledes. Spekteret for grunnleggende sikkerhet har fire grader som er skalert etter hva som potensielt kan gå galt. Dette står i kontrast til vanlige sikkerhetstester, som setter de samme funnene opp mot ting som virkelig går galt akkurat nå. Der Basic Security vurderer noe som «høyt», vil det i en profesjonell sikkerhetstest bli vurdert som «info», «lavt» eller i et spesialtilfelle som «middels», avhengig av formålet med testen.
Graderingen av grunnleggende sikkerhet endres over tid, slik at listen for grunnleggende sikkerhet sakte heves. Der et mål er oransje i år, kan det være rødt neste år for å rette mer oppmerksomhet mot det. For eksempel er det ikke obligatorisk å bruke security.txt før i midten av 2023, så rundt den tiden vil ikke alle organisasjoner bruke denne standarden. I midten av 2024 vil dette imidlertid være uakseptabelt, ettersom de da har hatt ett år på seg til å ta den i bruk. Det står mer om dette i retningslinjene for måling.
Dette er de fire graderingene vi bruker:
Rød: Dette representerer en sårbarhet med høy risiko. Her handler det om en mangel som må utbedres. Tenk for eksempel på svak kryptering. Lekkasje av versjonsinformasjon (les: forteller en angriper hva som skal kjøres) og lignende.
Oransje: Dette gjelder ofte institusjoner og administrative mangler. Også nye målinger som på sikt burde være røde, men som er skalert som oransje for innføring: for å gjøre målingen synlig og handlingsrettet hos de ansvarlige organisasjonene.
Grønn (lav): En måling som innebærer et avvik på sikkerheten som har svært liten innvirkning (ennå) fordi det er få mennesker som kan oppleve dette problemet, og som i så fall ofte allerede er utsatt for en lang rekke mer alvorlige problemer. Dette nivået brukes også for målinger som kan medføre juridiske forpliktelser i fremtiden, men som ikke er særlig vanlige i dag.
Grønn (ok): En korrekt måling: sikkerheten er ivaretatt på dette punktet.
Funnene dokumenteres alltid med referanser og, der det er mulig, en lenke til en second opinion som kan brukes til å utføre en ny test. Disse finnes også i målepolicyen. På denne måten får man kunnskap om relevansen av et nytt funn og umiddelbar bekreftelse på at sårbarheten er utbedret.
Eksempler på sårbarheter som kan publiseres, er: manglende kryptering, manglende DNSSEC, manglende security.txt, fysisk plassering av tjenesten, bruk av RPKI, offentlig versjonsinformasjon.
All informasjon på nettsidene, inkludert alle målinger, er underlagt vår ansvarsfraskrivelse. Det er derfor alltid på egen regning og risiko å handle på grunnlag av disse opplysningene. Vi gjør vårt beste for alltid å publisere korrekte og oppdaterte mål, les mer om dette i retningslinjene for måling.
Hvordan publiseres nye målinger
Før en ny måling publiseres, blir den først kunngjort for paraplyorganisasjonene, slik at organisasjonene kan ta stilling til den. På det tidspunktet er selve måleresultatene ofte ennå ikke så innsiktsfulle. Minst en måned senere blir målingen synlig og offentlig.
Deretter følger en prøveperiode der målingen maksimalt vil bli vurdert som oransje. I løpet av denne prøveperioden kan alle reagere på målingen, og målingen kan bli strammet inn. Denne perioden varer vanligvis en måned eller to. Etter denne perioden skaleres målingen på nytt og settes eventuelt til rød.
Eksempel på scenario for publiserbar sårbarhet
En organisasjon trenger et nettsted. Nettstedet leveres av et utviklingsbyrå. Utviklingsbyrået bruker standard programvare og fokuserer hovedsakelig på funksjonalitet og informasjon.
Nettstedet er i drift, men sikkerheten er ennå ikke ivaretatt. For eksempel er nettstedet ennå ikke tilgjengelig via en kryptert tilkobling (1: https), det er ingen garantier for om domenenavnet tilhører nettstedets ip-adresse (2: DNSSEC), og det er et offentlig administrasjonspanel (3: påloggingspanel) som viser at det dreier seg om programvareversjon 7.0.2 (4: versjonsinformasjon).
Denne saken gir en angriper alle slags håndtak som lett kan unngås. En angriper trenger liten eller ingen innsats for å finne dem, og har lenge og i stor grad automatisert denne kunnskapen for å gjøre så mye skade som mulig på denne måten.
I denne casestudien kan en angriper utnytte sårbarheter på følgende måter: De kan lese med i Internett-trafikken på samme nettverk, for eksempel en Wi-Fi-hotspot, fordi https mangler (1: https), på samme nettverk kan angriperen omdirigere trafikk til en falsk side (2: dnssec), man kan gjøre forsøk på å logge inn på administrasjonssiden hvor som helst i verden (3: innloggingspanel) og søke etter og bruke offentlig kjente sårbarheter hvor som helst i verden (4: versjonsinformasjon).
Angriperne har allerede denne informasjonen, så det er viktig at de som skal forsvare seg også har den. I alle disse angrepene ligger det en basis i åpenhet og god profesjonalitet.
Når kjente sikkerhetsrammeverk og standarder følges på en kompetent måte, er ikke alle disse sårbarhetene til stede. Tenk på ISO27002, NEN7510, Baseline Information Security Government og lignende. Merk at slike rammeverk ikke er praktiske og lar alle måle og måle løsninger selv. Som et resultat vil en nybegynner i samme situasjon skrive en annen plan med hensyn til innhold enn en profesjonell. I grunnleggende sikkerhet setter vi en viss målestokk som er relevant i alle tilfeller. Noen synes denne listen er for høy, andre synes den er for lav. Uansett er den grunnlaget.
Sårbarheter som ikke kan publiseres
Grunnleggende sikkerhet fokuserer på grunnleggende sikkerhetskrav.
Det hender også at stiftelsens frivillige finner alvorlige sårbarheter. Dette er et biprodukt og ikke et mål for stiftelsen. Her er hvordan vi håndterer dette. Aktive søk etter alvorlige sårbarheter gjøres av vår vennlige organisasjon DIVD. Base Security søker altså aldri aktivt etter alvorlige sårbarheter.
Hvis vi ved et uhell skulle finne en alvorlig sårbarhet, kan du se nedenfor hvordan vi håndterer den.
Når det er mistanke om alvorlig sårbarhet, vurderes det i hvert enkelt tilfelle hvilken tilnærming som gir størst sikkerhet på kortest mulig tid. Det er en rekke alternativer som vurderes:
- Hvis det er en ny sårbarhet som ennå ikke er kjent (ikke en CVE), finnes det en rekke alternativer. Det avhenger av hvor sårbarheten er identifisert og hvor alvorlig den er. Følgende veier er vurdert:
- Overlever til det nederlandske instituttet for sårbarhetsavsløring. De har infrastrukturen til å identifisere ofre for denne sårbarheten og advare om lekkasjen. Denne handlingen er vårt foretrukne alternativ.
- Når programvareskaperen har en skikkelig Coordinated Vulnerability Disclosure-prosess, blir denne sårbarheten også sendt direkte til skaperen. Dette skjer bare når det kan gjøres i fortrolighet.
- Grunnreglene rundt Coordinated Vulnerability Disclosure brukes for å varsle den utsatte parten.
- Når det gjelder en kjent sårbarhet, følges grunnreglene rundt Coordinated Vulnerability Disclosure. Det undersøkes om organisasjonen har en slik prosess på plass.
- Hvis det ikke finnes noen CVD-prosess, kontaktes sikkerhetsparaplyorganisasjonen som virksomheten tilhører. Dette kan for eksempel være Kommunenes informasjonssikkerhetstjeneste eller Nasjonalt cybersikkerhetssenter for staten.
- Det vurderes å videresende rapporten gjennom Security Hotline.
- Kommunikasjon rundt den alvorlige sårbarheten vil bli vurdert i henhold til CVDs grunnregler. Ettersom det ikke er vårt mål å finne og publisere nye sårbarheter, vil kommunikasjon om nye sårbarheter, hvis det i det hele tatt skjer, sannsynligvis skje gjennom den som har rapportert den, Security Hotline, DIVD eller en lignende organisasjon.
Eksempler på sårbarheter som ikke kan publiseres, er: SQL-injeksjon, skripting på tvers av nettsteder, bruk av svake passord, lekkede passord, ekstern kjøring av kode, bufferoverløp og CVE-er.
Eksempel på scenario for alvorlig sårbarhet
Dette eksemplet er basert på et sant scenario og en kjent sårbarhet: Deaktivering av en modul som gjorde filer som inneholdt passord direkte lesbare på forsiden av et nettsted (deaktivering av PHP). Dette er en konfigurasjonsfeil.
En frivillig surfer på informasjon på basicsecurity.no. Den frivillige ser et nettsted: «oud.belangrijkeoganisation.nl», som derfor kan ha svak sikkerhet. Den frivillige blir interessert og besøker nettstedet.
Når du besøker nettstedet, ser det ut til at noe er galt med konfigurasjonen: I stedet for et vakkert nettsted kan du se kildekoden til nettstedet. Kildekoden inneholder et databasepassord og lenker til sensitive filer.
Den frivillige vet at dette ikke er hensikten, og rådfører seg med andre frivillige om hva som er lurt å gjøre. Dette handler om en enkeltperson og kjent sårbarhet, og CVD-reglene følges.
Den frivillige tar kontakt med sikkerhetsorganisasjonen som tilhører nettstedet. Informasjon om sårbarheten utveksles, og organisasjonen følger de interne prosessene knyttet til CVD og løsning av sårbarheten.
Organisasjonen løste sårbarheten innen overskuelig tid. Noen ganger velger organisasjonen å belønne reporteren med en godbit eller en plass i hall of fame.