Tenk deg følgende: Du nyter en rolig kveld hjemme og strømmer favorittserien din. Plutselig fryser videoen, skjermen blir blank for et øyeblikk, og deretter ser alt ut til å gå tilbake til det normale. Men du, som er teknisk kyndig, bestemmer deg for å undersøke. Du oppdager en feil i streamingplattformens kode som gjør at du kan få tilgang til alle andres kontoer. Hva ville du gjøre? Fjerne alle brukerkontoer og håpe på bedre streamingkvalitet? Eller ville du prøve å stjele brukernes kredittkortopplysninger, bare for å få noen måneder med gratis streaming? Forhåpentligvis ingen av delene, det finnes en bedre måte!
I dette innlegget vil vi utforske betydningen av sårbarhetsrapportering, dens etiske aspekter og hvordan mennesker og organisasjoner kan håndtere disse digitale svakhetene. Å oppdage en sårbarhet er bare begynnelsen på en viktig prosess: sårbarhetsrapportering.
Bakgrunn
Så, hva er sårbarhetsrapportering? Det er prosessen med å identifisere, rapportere og rette opp en sårbarhet. Det anbefales at alle organisasjoner får på plass en prosess rundt sårbarhetsrapportering, for å redusere og forebygge sikkerhetshendelser. Det bidrar også til kontinuerlig og proaktiv sikkerhetstesting, utover organisasjonens vanlige sårbarhetsstyringsstrategi. Målet med sårbarhetsrapportering er å forbedre den generelle cybersikkerheten ved å identifisere og rette opp svakheter før de kan utnyttes av en trusselaktør.
Noen leverandører har spesifikke kontaktpunkter for å rapportere sårbarheter. Kontaktinformasjon finnes ofte i en fil som kalles ‘security.txt’. Denne filen er vanligvis i rotkatalogen eller under katalogen ‘/.well-known/’. Et par eksempler er: ‘https://www.svt.se/.well-known/security.txt’, 'https://www.nrk.no/.well-known/security.txt’ og ‘https://www.amazon.com/security.txt’. Selv om det anbefales å publisere en ‘security.txt’-side, gjør ikke alle det. I disse tilfellene må rapportøren finne alternative kontaktruter, for eksempel kundeservice eller e-post.
Den som ønsker å rapportere en sårbarhet kan også gå gjennom dedikerte organisasjoner, som ‘Computer Emergency Response Team’, også kjent som CERT-SE (eller CERT-EU), Nasjonalt Cybersikkerhetssenter (NCSC), Integritetsskyddsmyndigheten (IMY), Datatilsynet og Myndigheten for Samfunnssikkerhet og Beredskap (MSB). Disse organisasjonene kan hjelpe til med å megle med leverandører. I noen tilfeller kan de også hjelpe til med å eskalere problemet, for eksempel hvis leverandøren ikke svarer eller retter opp sårbarheten i tide.
Etter å ha oppdaget og rapportert en sårbarhet, er det vanlig at det søkes om en CVE, som står for ‘Common Vulnerabilities and Exposures’. En CVE-søknad kan sendes inn av den personen som oppdaget sårbarheten ("sikkerhetsforskeren"), eller i samarbeid med leverandøren. CVE-systemet består av en database med kjente sårbarheter som er funnet i systemer, tjenester, applikasjoner osv. CVE-databasen brukes til å holde oversikt over sårbarheter relatert til spesifikke leverandører og produktversjoner. Dette for å sikre at brukere ikke kjører sårbare komponenter eller tjenester.
Det er forskjellige måter å rapportere en sårbarhet på, noen mer foretrukket enn andre. I dette blogginnlegget vil vi nevne forskjellige måter å rapportere en sårbarhet på. Dette inkluderer privat, fullstendig og koordinert sårbarhetsrapportering.
Typer av sårbarhetsrapportering
Privat sårbarhetsrapportering
Den første typen vi skal diskutere er privat sårbarhetsrapportering. Privat sårbarhetsrapportering refererer til prosessen med å rapportere og rette opp sikkerhetssårbarheter på en privat og konfidensiell måte mellom sikkerhetsforskeren eller rapportøren og leverandøren ansvarlig for den aktuelle programvaren, systemet eller produktet. I motsetning til full avsløring, hvor detaljer om sårbarheter blir direkte tilgjengelige for offentligheten, utføres privat rapportering i kulissene.
Denne typen rapportering setter søkelys på konfidensialitet, direkte kommunikasjon og koordinering. Privat rapportering fokuserer på å holde informasjon om sårbarheten konfidensiell for å muliggjøre for leverandøren å vurdere alvorlighetsgraden og rette opp problemet før mulige trusselaktører kan utnytte den.
Rapportøren kommuniserer direkte med leverandøren eller enheten ansvarlig for produktet som inneholder sårbarheten. Dette kan gjøres gjennom etablerte kommunikasjonskanaler, som e-post eller en dedikert sikkerhetskontakt. Det forekommer også ofte samarbeid mellom rapportøren og leverandøren for å forstå sårbarheten, dens mulige innvirkning og de tiltakene som kreves for å avbøte dens konsekvenser eller rette den opp. En tidsramme settes vanligvis for å rette opp og offentliggjøre sårbarheten. Etter at sårbarheten har blitt rettet opp, pleier leverandøren å takke sikkerhetsforskeren, og i noen tilfeller belønne arbeidsinnsatsen i henhold til avtale.
Figur 1: Privat sårbarhetsrapportering - prosess syklus.
Privat sårbarhetsrapportering kan også forekomme innenfor bug bounty-programmer, der organisasjoner tilbyr belønninger eller insentiver til sikkerhetsforskere eller enkeltpersoner som ansvarlig rapporterer sårbarheter. Disse belønningene eller insentivene kan være i form av søknad om CVE-nummer eller penger, noe som bidrar til å fremme etisk hacking og ansvarlig rapportering. En spesifikk gren av privat sårbarhetsrapportering er koordinert sårbarhetsrapportering, som vi vil diskutere senere i innlegget.
Fullstendig sårbarhetsrapportering
Fullstendig sårbarhetsrapportering innebærer at informasjon om en sårbarhet offentliggjøres så tidlig som mulig. Det er ingen generell metode for å offentliggjøre informasjon om sårbarheter, men forskere bruker ofte e-postlister, konferanser eller vitenskapelige artikler for å spre denne typen informasjon. Gjennom denne tilnærmingen er alle parter like informert om sårbarheten. Generelt sett mener talsmenn for fullstendig sårbarhetsrapportering at fordelene med offentlig tilgjengelig sårbarhetsinformasjon veier tyngre enn de mulige sikkerhetsrisikoene. Motstandere foretrekker derimot å begrense denne typen distribusjon, med begrunnelsen at slik avsløring av sårbarheter ofte anses som uansvarlig. Når informasjon om sårbarheter er offentlig tilgjengelig, hjelper det både brukere og administratorer til å få en bedre forståelse og handle i samsvar med sårbarheter som finnes i systemene deres. I tillegg kan denne informasjonen brukes av brukere for å presse leverandører til å rette opp sårbarheter før en trusselaktør får mulighet til å utnytte dem. Dette er spesielt effektivt når det gjelder sårbarheter som en leverandør ellers ikke ville hatt noe insentiv til å rette opp.
Figur 2: Fullstendig sårbarhetsrapportering – prosess syklus.
Sammenlignet med privat sårbarhetsrapportering kan fullstendig rapportering løse noen av de grunnleggende problemene som oppstår med privat sårbarhetsrapportering. I de tilfellene der brukere ikke har kunnskap om en sårbarhet, kan de heller ikke kreve tiltak fra leverandøren, og det er ingen økonomisk drivkraft for leverandøren til å løse det aktuelle problemet. I tillegg er det umulig for administratorer å ta informerte beslutninger om mulige risikoer i systemene deres.
Det er imidlertid også ulemper med denne tilnærmingen. Når denne typen informasjon er offentlig, har trusselaktører samme tid til å utnytte sårbarheten som det tar for leverandøren å rette opp problemet. I tillegg kan det gi leverandøren et dårlig rykte. Av denne grunn betraktes fullstendig sårbarhetsrapportering vanligvis som en siste utvei, for eksempel når leverandøren ikke handler på en sårbarhetsrapport eller om tidsfristen for når en løsning bør være tilgjengelig ikke overholdes.
Koordinert sårbarhetsrapportering
Koordinert sårbarhetsrapportering er en spesifikk metode som går under kategorien privat sårbarhetsrapportering. Metoden legger vekt på samarbeid, struktur og utarbeidelsen av en ansvarlig tidsplan for offentliggjøring. Den muliggjør for leverandører å proaktivt håndtere sikkerhetsproblemer, samtidig som brukere informeres ved riktig tidspunkt. Dette er den foretrukne metoden og sannsynligvis den måten som de fleste organisasjoner bør implementere sin prosess på.
Koordinert sårbarhetsrapportering, også kjent som ansvarlig sårbarhetsrapportering, er en modell der forskeren og leverandøren samarbeider gjennom hele prosessen, fra oppdagelse til offentliggjøring av sårbarheten. Men ikke alle sårbarheter har sin begynnelse gjennom samordnede sårbarhetsrapporter. Noen leverandører ønsker å håndtere sårbarheten uten medvirkning av rapportøren. Men forhåpentligvis kan en avtale inngås, der begge parter ser fordelene med koordinert rapportering og velger denne veien i stedet.
Oppdagelse, verifisering, rapportering, samordning og avsløring er de vanlige stegene i prosessen for koordinert sårbarhetsrapportering. Etter at forskeren har oppdaget og verifisert at sårbarheten utgjør en sikkerhetsrisiko, bør forskeren varsle leverandøren. Dette kan gjøres av forskeren selv eller gjennom en mellommann, som for eksempel CERT eller lignende som nevnt tidligere. Under samordningsperioden er det avgjørende med hyppig kommunikasjon. Denne prosessen krever at forskerne og den ansvarlige leverandøren arbeider tett sammen for å forstå sårbarheten, verifisere resultatene og utarbeide en plan for å håndtere problemet. De to partene blir også enige om en tidsplan for offentliggjøring, som markerer tidspunktet da forskeren får avsløre resultatet for allmennheten. Tidsfristen kan variere fra noen uker til flere måneder, avhengig av sårbarhetens kompleksitet og den tid som kreves for tiltak.
Selv om sårbarheten i utgangspunktet holdes hemmelig, er det endelige målet med koordinert sårbarhetsrapportering å oppnå åpenhet. Når leverandøren har fått mulighet til å håndtere sårbarheten, avsløres detaljene offentlig for å informere brukerne og allmennheten. Når sårbarheten er offentliggjort, kan de to partene enten individuelt eller i fellesskap søke om en CVE, i henhold til avtale.
Figur 3: Koordinert sårbarhetsrapportering – prosess syklus.
Koordinert sårbarhetsrapportering hjelper ikke bare leverandørene å forbedre sin sikkerhet ved å håndtere sikkerhetsproblemer, det oppmuntrer også forskere og andre personer som oppdager en sårbarhet til å rapportere problemet, i stedet for å utnytte det for egen vinning. En annen fordel med koordinert sårbarhetsrapportering er at det normaliserer eksistensen av sårbarheter i vår digitale verden. Sårbarheter er ingenting som bør skjules, og hvis de håndteres riktig, trenger de ikke bare å innebære dårlige nyheter. At en leverandør forekommer i CVE-databasen kan i stedet være en indikator på at leverandøren i spørsmålet legger stor vekt på sikkerheten.
Samarbeidet mellom forskeren og leverandøren vil også bidra til å forebygge fremtidige sårbarheter og muliggjøre for leverandøren å lære av tidligere feil. Samtidig får forskeren sin belønning, enten i form av penger, en CVE eller annet insentiv i henhold til avtale. Koordinert sårbarhetsrapportering fokuserer på å balansere behovet mellom allmenn bevissthet og leverandørenes ansvar for å innen en rimelig tid håndtere og håndtere sårbarheter.
Men...
... hva skjer hvis leverandøren ikke svarer? Eller hvis de ikke vil samarbeide? Dette er dessverre altfor vanlig. Fra leverandørens perspektiv kan en sårbarhetsrapport oppfattes som et drastisk tiltak, spesielt hvis leverandøren ikke har en korrekt prosess for håndtering av sårbarhetsrapporter. Selv om dette er vanlig forekommende, anbefales det ikke at leverandører er fiendtlige mot rapportørene. Dette kan føre til at rapportørene velger en annen vei, for eksempel fullstendig sårbarhetsrapportering, noe som vil legge press på leverandøren for å løse problemene som er rapportert. Det medfører imidlertid risikoen for at trusselaktører kan utnytte sårbarheten før leverandøren har løst den. Av denne grunn er fullstendig sårbarhetsrapportering noe som ikke oppmuntres.
Figur 4: Koordinert sårbarhetsrapportering – alternativ prosess syklus.
Som nevnt tidligere kan CERT bistå personer som rapporterer en sårbarhet. For eksempel, hvis leverandøren ikke svarer, kan CERT hjelpe til med å formidle kommunikasjonen. Hvis sårbarheten gir opphav til datainnbrudd og/eller er i strid med gjeldende personvernlovgivning, kan også den statlige myndigheten IMY eller Datatilsynet kontaktes. IMY er en svensk tilsynsmyndighet som arbeider med tilsyn innen personvern - mens Datatilsynet er den norske motsvarigheten.
I tillegg er leverandøren pliktig til å rapportere alle datainnbrudd som fører til eksponering av personopplysninger (PII) til myndigheten innen 72 timer etter at de har blitt kjent med det. De er også forpliktet til å varsle alle berørte parter, som kunder og brukere.
Ved koordinert sårbarhetsrapportering er det mange krav som leverandørene må møte. I de tilfeller der en leverandør har en mangelfull prosess for koordinert sårbarhetsrapportering, kan prosessen skape flere problemer enn den løser. Kommunikasjon er nøkkelen til vellykket sårbarhetsrapportering. Fremfor alt er det viktig for å forebygge misforståelser rundt alvorlighetsgraden, de implementerte tiltakene, offentliggjøring, etc. Anstrengelser for å håndtere mulige mangler innebærer vanligvis løpende forbedringer i kommunikasjon, samarbeid, samt utviklingen av standardiserte metoder for koordinert sårbarhetsrapportering.
Si farvel til sårbarhetene dine
Nå oppfordrer vi deg ikke til å gå ut og hacke alt du kan få hendene på – det er fortsatt ulovlig. Men for den som synes det høres spennende ut, finnes det lovlige måter for deg å lete etter sårbarheter. Som nevnt tidligere kan du delta i en bug bounty eller et belønningsprogram for sårbarheter (vulnerability reward programs). Et bug bounty-program er et crowdsourcet initiativ som tilbys av leverandører for å oppmuntre uavhengige sikkerhetsforskere og etiske hackere til å oppdage og ansvarlig rapportere sårbarheter i deres programvare, systemer eller produkter. Når du deltar i en bug bounty, er det viktig å være forberedt. Du må ha oversikt over leverandørens adferdskodeks (Code of Conduct) og deres policy. Omfanget av hva som kan testes, reglene for samarbeidet (Rules of Engagement) og de juridiske vilkårene må også studeres. Dette for å sikre at du holder deg innenfor de lovlige rammene når du utfører testene dine. Det er også viktig å bare kommunisere gjennom de dedikerte kontaktkanalene, ikke gjennom uoffisielle kommunikasjonskanaler (for eksempel sosiale medier).
I bunn og grunn er et bug bounty-program et belønningssystem for personer som oppdager og rapporterer feil og sårbarheter i en organisasjons digitale tjenester. Målet er å forbedre den overordnede sikkerheten i programvaren eller systemet ved å identifisere og løse mulige problemer før trusselaktører får mulighet til å utnytte dem.
HackerOne er en bug bounty-plattform som letter bug bounty-programmer for leverandører. Den kobler sammen sikkerhetsforskere eller etiske hackere med selskaper som ønsker å identifisere og løse sikkerhetssårbarheter i deres programvare, nettsteder og systemer. HackerOne fungerer som en mellommann og tilbyr en plattform for koordinering og håndtering av bug bounty-programmer.
Sikkerhet er ikke lenger valgfritt i vår digitaliserte verden. Sårbarheter drukner vår cyberverden, og det kreves samarbeid for å sikre og utrydde så mange trusler som mulig. Som det velkjente uttrykket sier, “det beste forsvar er et godt angrep”. Transparens, åpenhet og samarbeid er det ultimate antiviruset for et tryggere digitalt samfunn.
Referenser
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
https://insights.sei.cmu.edu/blog/the-cert-guide-to-coordinated-vulnerability-disclosure/
https://insights.sei.cmu.edu/documents/1945/2017_003_001_503340.pdf
https://www.bugcrowd.com/resources/guide/what-is-responsible-disclosure
https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/personuppgiftsincidenter/
