Policy för publicering

Friskrivningsklausul: Originalet till denna sida är skrivet på nederländska. Denna sida har översatts automatiskt till andra språk med hjälp av DeepL. Detta kan resultera i skillnader i nyans, ton och betydelse. Om du är osäker ska du alltid först läsa den nederländska versionen. På grund av de höga kostnaderna för översättningar kan denna sida innehållsmässigt ligga efter den nederländska versionen. Vi betraktar den nederländska versionen av denna sida som ledande.

Internet Cleanup Foundation har en uppförandekod som anger de grundläggande principerna för vilka mätningar som publiceras och vilka som inte publiceras.

På denna sida förklaras detta närmare med praktiska exempel.

Offentliga mätningar med ett offentligt syfte

I princip mäter Basic Security säkerheten på den grundläggande nivån. Detta kan publiceras fritt utan att risken för missbruk ökar mer än vad den redan gör. Överväg att mäta där vanliga säkerhetsåtgärder saknas.

Basisbeveiliging.nl:s databas innehåller mer än 10 miljoner unika mätningar. Alla mätningar i databasen kan när som helst publiceras i sin helhet eller läcka ut, utan att det skapar nya risker som en angripare kan utnyttja.

En organisation med en adekvat säkerhetspolicy kommer alltid att vara grön när det gäller grundläggande säkerhet: mätningarna i sig är inte nyheter eller chockerande, men bristen på tillämpning kan ibland vara det.

Mätningarna av grundläggande säkerhet ligger inom området etisk hackning och säkerhetstestning. Det finns stora likheter med de första stegen i professionella säkerhetstester, t.ex. kartläggning av attackytan. Detta omfattar domäner, portar och programvara. Detta är offentlig information som är lätt att samla in i stor skala. Det finns många företag som gör detta och erbjuder det till mycket låg kostnad eller till och med offentligt och gratis.

Basic Security publicerar aldrig allvarliga eller kritiska sårbarheter. Det överlåter vi till andra organisationer, till exempel professionella säkerhetstestföretag som Secura, Zerocopter eller frivilliga organisationer som DIVD.

Publicerbara resultat

Internet Cleanup Foundation publicerar information om sårbarheter och bristande säkerhetsåtgärder. Detta görs i syfte att få dessa sårbarheter åtgärdade. Baserat på uppförandekoden avgörs det om en sårbarhet kan publiceras. Här beaktas allmänintresset, proportionaliteten och subsidiariteten.

Publicerbara sårbarheter är allmänt tillgängliga för alla på webbplatsen för grundläggande säkerhet. Detta kan också nås automatiskt.

Sårbarheter som kan offentliggöras riskklassificeras. Detta är en annan riskklassificering än den som är vanlig i säkerhetsvärlden eftersom spektrumet av mätningar är annorlunda. Spektrumet för grundläggande säkerhet har fyra grader som är skalade efter vad som potentiellt kan gå fel. Detta står i kontrast till vanliga säkerhetstester, där samma resultat ställs mot saker som verkligen går fel just nu. Där Basic Security värderar något som ”högt”, kommer det i ett professionellt säkerhetstest att anges som ”info”, ”lågt” eller i ett specialfall som ”medel” beroende på syftet med testet.

Graderingarna för grundläggande säkerhet ändras över tid för att långsamt höja ribban för grundläggande säkerhet. Om en mätning är orange i år kan den vara röd nästa år för att dra mer uppmärksamhet till den. Till exempel är tillämpningen av security.txt inte obligatorisk förrän i mitten av 2023, så vid den tiden kommer inte alla organisationer att tillämpa denna standard. I mitten av 2024 skulle detta dock vara oacceptabelt eftersom de då har haft ett år på sig att tillämpa den. Det finns mer om detta i mätpolicyn.

Det är dessa fyra grader vi tillämpar:

Röd: detta representerar en sårbarhet med hög risk. Här är det en ofullkomlighet som måste åtgärdas. Tänk till exempel på svag kryptering. Läckage av versionsinformation (läs: tala om för en angripare vad som ska köras) och liknande.

Orange: detta gäller ofta institutioner och administrativa brister. Även nya mätningar som i slutändan borde vara röda, men som är skalade som orange för introduktion: för att göra mätningen synlig och handlingsbar hos de ansvariga organisationerna.

Grön (låg): En mätning som innebär en avvikelse på säkerheten som har mycket liten påverkan (ännu) eftersom det är få människor som kan uppleva detta problem, och i så fall ofta redan är utsatta för en lång rad allvarligare problem. Denna nivå används också för mätningar som kan innebära juridiska skyldigheter i framtiden, men som inte är särskilt vanliga idag.

Grönt (ok): En korrekt mätning: säkerheten är garanterad vid denna punkt.

Resultaten åtföljs alltid av dokumentation, referenser och, om möjligt, en länk till en second opinion som kan användas för att utföra en ny mätning. Dessa finns också i mätpolicyn. Detta gör det möjligt att få kunskap om relevansen av ett nytt resultat och omedelbar verifiering av att sårbarheten har åtgärdats.

Exempel på publicerbara sårbarheter är: saknad kryptering, saknad DNSSEC, saknad security.txt, fysisk plats för tjänsten, tillämpning av RPKI, offentlig versionsinformation.

All information på webbplatserna, inklusive alla mätningar, omfattas av vår ansvarsfriskrivning. Att agera utifrån dessa resultat sker därför alltid på egen bekostnad och risk. Vi gör vårt bästa för att alltid publicera korrekta och uppdaterade mått, läs mer om detta i mätpolicyn.

Hur publiceras nya mätningar?

Innan en ny mätning publiceras meddelas den först till paraplyorganisationerna så att de kan vidta åtgärder utifrån den. Vid det laget är mätresultaten i sig ofta ännu inte insiktsfulla. Minst en månad senare blir mätningen synlig och offentlig.

Därefter följer en testperiod under vilken mätningen som mest kommer att bedömas som orange. Under denna provperiod kan alla reagera på mätningen och mätningen kan komma att skärpas. Denna period varar vanligtvis en månad eller två. Efter denna period skalas mätningen om och eventuellt sätts den till röd.

Exempel på scenario för publicerbar sårbarhet

En organisation behöver en webbplats. Den här webbplatsen levereras av en utvecklingsbyrå. Utvecklingsbyrån använder standardprogramvara och fokuserar främst på funktionalitet och information.

Webbplatsen är på väg att tas i drift, men säkerheten har ännu inte åtgärdats. Till exempel är webbplatsen ännu inte tillgänglig via en krypterad anslutning (1: https), det finns inga garantier för att domännamnet hör till webbplatsens ip-adress (2: DNSSEC) och det finns en publik hanteringspanel (3: inloggningspanel) som visar att det handlar om programvaruversion 7.0.2 (4: versionsinformation).

Detta fall ger en angripare alla typer av handtag som lätt kan undvikas. En angripare behöver liten eller ingen ansträngning för att hitta dem och har länge och i stor utsträckning automatiserat denna kunskap för att göra så mycket skada som möjligt på detta sätt.

I den här fallstudien kan en angripare utnyttja sårbarheter på följande sätt: de kan läsa med i internettrafiken på samma nätverk som en Wi-Fi-hotspot eftersom https saknas (1: https), på samma nätverk kan angriparen omdirigera trafik till en falsk sida (2: dnssec), man kan göra försök att logga in på administrationssidan var som helst i världen (3: inloggningspanel) och söka och tillämpa allmänt kända sårbarheter var som helst i världen (4: versionsinformation).

Angriparna har redan den här informationen, så det är viktigt att de människor som måste försvara sig också har den. I alla dessa attacker finns det en grund i öppenhet och god professionalism.

När kända säkerhetsramverk och standardramverk följs på ett kompetent sätt finns inte alla dessa sårbarheter. Tänk på ISO27002, NEN7510, Baseline Information Security Government och liknande. Observera att sådana ramverk inte är praktiska och låter alla mäta och mäta lösningar själva. Som ett resultat kommer en nybörjare i samma situation att skriva en annan plan när det gäller innehåll än en professionell. I grundsäkerheten sätter vi en viss ribba som är relevant i alla fall. Vissa tycker att denna ribba är för hög, andra tycker att den är för låg. I vilket fall som helst är det grunden.

Sårbarheter som inte går att publicera

Basic security fokuserar på grundläggande säkerhetskrav.

Stiftelsens volontärer hittar också ibland allvarliga sårbarheter. Detta är en biprodukt och inte syftet med stiftelsen. Här är hur vi hanterar detta. Aktiva sökningar efter allvarliga sårbarheter görs av den vänligt sinnade organisationen DIVD.Basens säkerhetsavdelning söker alltså aldrig aktivt efter allvarliga sårbarheter.

Om vi av misstag skulle hitta en allvarlig sårbarhet är det nedan vi hanterar den.

När en allvarlig sårbarhet misstänks, övervägs här från fall till fall det tillvägagångssätt som ger störst säkerhet på kortast möjliga tid. Det finns ett antal alternativ som övervägs:

  1. Om det är en ny sårbarhet som ännu inte är känd (inte en CVE) finns det ett antal alternativ. Det beror på var sårbarheten har identifierats och hur allvarlig den är. Följande vägar övervägs:
  2. När det gäller en känd sårbarhet följs grundreglerna kring Coordinated Vulnerability Disclosure. Det undersöks om organisationen har en sådan process på plats.
  3. Man överväger att vidarebefordra rapporten via Security Hotline.
  4. Kommunikation kring den allvarliga sårbarheten kommer att behandlas enligt CVD:s grundregler. Eftersom det inte är vårt mål att hitta och publicera nya sårbarheter kommer kommunikationen om nya sårbarheter, om den överhuvudtaget förekommer, sannolikt att ske via den part som den rapporterades till, Security Hotline, DIVD eller en liknande organisation.

Exempel på sårbarheter som inte kan publiceras är: SQL-injektion, cross-site scripting, användning av svaga lösenord, läckta lösenord, fjärrkörning av kod, buffertöverskridanden och CVE:er.

Exempel på scenario med allvarlig sårbarhet

Det här exemplet bygger på ett verkligt scenario och en känd sårbarhet: inaktivering av en modul som gjorde filer som innehöll lösenord direkt läsbara på förstasidan av en webbplats (inaktivering av PHP). Detta är ett konfigurationsfel.

En volontär söker information på basicsecurity.co.uk. Volontären ser en webbplats: ”oud.belangrijkeoganisation.nl”, som därför kan ha svag säkerhet. Volontären blir intresserad och besöker webbplatsen.

När man besöker webbplatsen verkar det som om något är fel med konfigurationen: webbplatsens källkod kan ses i stället för en vacker webbplats. Källkoden innehåller ett lösenord till en databas och länkar till känsliga filer.

Volontären vet att detta inte är avsikten och rådgör med andra volontärer om vad som är klokt att göra. Detta handlar om en individ och känd sårbarhet, CVD-reglerna följs.

Volontären kontaktar den säkerhetsorganisation som hör till webbplatsen. Information om sårbarheten utbyts och organisationen följer de interna processer som är förknippade med CVD och sårbarhetslösning.

Organisationen löste sårbarheten inom en överskådlig tid. Ibland väljer organisationen att belöna reportern med en godbit eller en plats i hall of fame.