Skip to content

Sårbarhetsrapportering: En balansgång mellan säkerhet, ansvar och etik

Föreställ dig följande: Du njuter av en lugn kväll hemma och streamar din favoritserie. Plötsligt fryser videon, skärmen blir blank för ett ögonblick, och sedan verkar allt återgå till det normala. Men du, som är teknikkunnig, bestämmer dig för att undersöka. Du upptäcker en bugg i streamingplattformens kod som gör att du kan komma åt alla andras konton. Vad skulle du göra? Ta bort alla användarkonton och hoppas på bättre streamingkvalitet? Eller skulle du försöka stjäla användarnas kreditkortsuppgifter, bara för att få några månader av gratis streaming? Förhoppningsvis inget av det, det finns ett bättre sätt!

I det här inlägget kommer vi att utforska betydelsen av sårbarhetsrapportering, dess etiska aspekter och hur människor och organisationer kan hantera dessa digitala svagheter. Att upptäcka en sårbarhet är bara början på en viktig process: sårbarhetsrapportering.

Bakgrund

Så, vad är sårbarhetsrapportering? Det är processen för att identifiera, rapportera och åtgärda en sårbarhet. Det rekommenderas att alla organisationer implementerar en process kring sårbarhetsrapportering, för att minska och förebygga säkerhetsincidenter. Det bidrar också till kontinuerlig och proaktiv säkerhetstestning, utöver organisationens ordinarie sårbarhetshanteringsstrategi. Målet med sårbarhetsrapportering är att förbättra den övergripande cybersäkerheten genom att identifiera och åtgärda svagheter innan de kan utnyttjas av en hotaktör.

Vissa leverantörer har specifika kontaktvägar för att rapportera sårbarheter. Kontaktuppgifter finns ofta i en fil som kallas ”security.txt”. Vanligtvis finns denna fil i rotkatalogen eller under katalogen ”/.well-known/”. Ett par exempel är: "https://www.svt.se/.well-known/security.txt” och ”https://www.amazon.com/security.txt”. Trots att det är rekommenderat att publicera en ”security.txt”-sida, så gör inte alla det. I dessa fall får rapportören hitta alternativa kontaktvägar, t.ex. kundtjänsten eller e-mail.

Den som vill rapportera en sårbarhet kan också gå genom dedikerade organisationer, så som ”Computer Emergency Response Team”, även känt som CERT-SE (eller CERT-EU), Integritetsskyddsmyndigheten (IMY) och Myndigheten för Samhällsskydd och Beredskap (MSB). Dessa organisationer kan hjälpa till att medla med leverantörer. I vissa fall kan de också hjälpa till att eskalera problemet, till exempel om leverantören inte svarar eller åtgärdar sårbarheten i rätt tid.

Efter att ha upptäckt och rapporterat en sårbarhet är det vanligt att forskaren ansöker om en CVE, vilket står för ”Common Vulnerabilities and Exposures”. En CVE-ansökan kan lämnas in av den individ som upptäckte sårbarheten, eller i samarbete med leverantören. CVE-systemet består av en databas med kända sårbarheter som hittats i system, tjänster, applikationer osv. CVE-databasen används för att hålla reda på sårbarheter relaterade till specifika leverantörer och produktversioner. Detta för att säkerställa att användare inte kör sårbara komponenter eller tjänster.

Det finns olika sätt att rapportera en sårbarhet, vissa mer föredragna än andra. I det här blogginlägget kommer vi att nämna olika sätt att rapportera en sårbarhet. Det inkluderar privat, fullständig och samordnad sårbarhetsrapportering.

Typer av sårbarhetsrapportering

Privat sårbarhetrapportering
Den första typen vi kommer att diskutera är privat sårbarhetsrapportering. Privat sårbarhetsrapportering hänvisar till processen att rapportera och åtgärda säkerhetssårbarheter på ett privat och konfidentiellt sätt mellan säkerhetsforskaren eller rapportören och leverantören ansvarig för den aktuella programvaran, systemet eller produkten. Till skillnad från fullständigt avslöjande, där detaljer om sårbarheter blir direkt tillgängliga för allmänheten, utförs privat avslöjande bakom kulisserna.

Den här typen av rapportering fokuserar på konfidentialitet, direkt kommunikation och samordning. Privat rapportering fokuserar på att hålla information om sårbarheten konfidentiell för att möjliggöra för leverantören att bedöma allvarligheten och åtgärda problemet innan potentiella hotaktörer kan utnyttja den.

Rapportören kommunicerar direkt med leverantören eller enheten ansvarig för produkten som innehåller sårbarheten. Detta kan göras genom etablerade kommunikationskanaler, såsom e-post eller en en dedikerad säkerhetskontakt. Det förekommer också ofta samarbete mellan rapportören och leverantören för att förstå sårbarheten, dess potentiella påverkan och de åtgärder som krävs för att mildra dess konsekvenser eller åtgärda den. En tidsram sätts vanligtvis för att åtgärda och offentliggöra sårbarheten. Efter att sårbarheten har åtgärdats brukar leverantören tacka säkerhetsforskaren, och i vissa fall belöna arbetsinsatsen enligt överenskommelse.

Privat sårbarhetsrapportering – processcykel.
Figur 1: Privat sårbarhetsrapportering – processcykel.

Privat sårbarhetsrapportering kan också förekomma inom bug bounty-program, där organisationer erbjuder belöningar eller incitament till säkerhetsforskare eller individer som ansvarsfullt rapporterar sårbarheter. Dessa belöningar eller incitament kan vara i form av ansökan om CVE-nummer eller pengar, vilket hjälper till att främja etisk hackning och ansvarsfull rapportering. En specifik gren av privat sårbarhetsrapportering är samordnad sårbarhetsrapportering, vilket vi kommer att diskutera senare i inlägget.

Fullständig sårbarhetsrapportering
Fullständig sårbarhetsrapportering innebär att information om en sårbarhet publiceras offentligt i ett så tidigt skede som möjligt. Det finns ingen generell metod för att offentliggöra information om sårbarheter, men forskare använder ofta e-postlistor, konferenser eller vetenskapliga artiklar för att sprida den här typen av information. Genom detta tillvägagångssätt är samtliga parter lika informerade om sårbarheten. Generellt sett anser förespråkare för fullständig sårbarhetsrapportering att fördelarna med publikt tillgänglig sårbarhetsinformation väger tyngre än de potentiella säkerhetsriskerna. Motståndare föredrar å andra sidan att begränsa den här typen av distribution, med motiveringen att sådant avslöjande av sårbarheter ofta anses vara oansvarigt. När information om sårbarheter finns publikt tillgängligt hjälper det både användare och administratörer att få en bättre förståelse och att agera i enlighet med sårbarheter som finns i deras system. Dessutom kan denna information användas av användare för att pressa leverantörer att åtgärda sårbarheter innan en hotaktör får möjlighet att utnyttja dem. Detta är särskilt effektivt när det gäller sårbarheter som en leverantör annars inte skulle ha något incitament att åtgärda.

Fullständig sårbarhetsrapportering – processcykel.
Figur 2: Fullständig sårbarhetsrapportering – processcykel.

Jämfört med privat sårbarhetsrapportering kan fullständig rapportering lösa några av de grundläggande problemen som uppkommer med privat sårbarhetsrapportering. I de fall då användare inte har kunskap om en sårbarhet, kan de inte heller kräva åtgärder från leverantören, och det finns ingen ekonomisk drivkraft för leverantören att lösa det aktuella problemet. Dessutom är det omöjligt för administratörer att fatta informerade beslut om potentiella risker i sina system.

Det finns dock även nackdelar med detta tillvägagångssätt. När denna typ av information är offentlig har hotaktörer samma tid att utnyttja sårbarheten som det tar för leverantören att åtgärda problemet. Dessutom kan det ge leverantören ett dåligt rykte. Av denna anledning betraktas fullständig sårbarhetsrapportering vanligtvis som en sista utväg, till exempel när leverantören inte agerar på en sårbarhetsrapport eller om tidsfristen för när en åtgärd bör vara tillgänglig inte hålls.

Samordnad sårbarhetrapportering
Samordnad sårbarhetsrapportering är en specifik metod som går under kategorin privat sårbarhetsrapportering. Metoden lägger vikt vid samarbete, struktur och framtagandet av en ansvarsfull tidslinje för offentliggörande. Den möjliggör för leverantörer att proaktivt åtgärda säkerhetsproblem, samtidigt som användare informeras vid rätt tidpunkt. Detta är den föredragna metoden och förmodligen det sätt på vilket de flesta organisationer bör implementera sin process.

Samordnad sårbarhetsrapportering, även känt som ansvarsfull sårbarhetsrapportering, är en modell där forskaren och leverantören samarbetar genom hela processen, från upptäckt till offentliggörande av sårbarheten. Men inte alla sårbarheter har sin början genom samordnade sårbarhetsrapporter. Somliga leverantörer önskar åtgärda sårbarheten utan medverkan av rapportören. Men förhoppningsvis kan en överenskommelse slutas, där båda parter ser fördelarna med samordnad rapportering och väljer denna väg i stället.

Upptäckt, verifiering, rapportering, samordning och avslöjande är de vanliga stegen i processen för samordnad sårbarhetsrapportering. Efter att forskaren har upptäckt och verifierat att sårbarheten utgör en säkerhetsrisk bör forskaren meddela leverantören. Detta kan göras av forskaren själv eller genom ett medlande organ, som till exempel CERT eller liknande som nämndes tidigare. Under samordningsperioden är det avgörande med frekvent kommunikation. Denna process kräver att forskarna och den ansvariga leverantören arbetar nära tillsammans för att förstå sårbarheten, verifiera resultaten och ta fram en plan för att åtgärda problemet. De båda parterna kommer också överens om en tidslinje för offentliggörande, vilket markerar den tidpunkt då forskaren får avslöja resultatet för allmänheten. Tidsfristen kan variera från några veckor till flera månader, beroende på sårbarhetens komplexitet och den tid som krävs för åtgärd.

Även om sårbarheten initialt hemlighålls är det slutgiltiga målet med samordnad sårbarhetsrapportering att uppnå öppenhet. När leverantören har fått möjlighet att åtgärda sårbarheten, avslöjas detaljerna offentligt för att informera användarna och allmänheten. När sårbarheten väl är offentliggjord kan de båda parterna antingen enskilt eller gemensamt ansöka om en CVE, enligt överenskommelse.

Samordnad sårbarhetsrapportering – processcykel.
Figur 3: Samordnad sårbarhetsrapportering ­– processcykel.

Samordnad sårbarhetsrapportering hjälper inte bara leverantörerna att förbättra sin säkerhet genom att åtgärda säkerhetsproblem, det uppmuntrar också forskare och andra personer som upptäcker en sårbarhet att rapportera problemet, snarare än att utnyttja det för egen vinning. En annan fördel med samordnad sårbarhetsrapportering är att det normaliserar existensen av sårbarheter i vår digitala värld. Sårbarheter är ingenting som bör mörkas, och om de hanteras korrekt behöver de inte bara innebära dåliga nyheter. Att en leverantör förekommer i CVE-databasen kan i stället vara en indikator på att leverantören i fråga lägger stor vikt vid säkerheten.

Samarbetet mellan forskaren och leverantören kommer också att hjälpa till att förebygga framtida sårbarheter och möjliggör för leverantören att lära sig av tidigare misstag. Samtidigt får forskaren sin belöning, antingen i form av pengar, en CVE eller annat incitament enligt överenskommelse. Samordnad sårbarhetsrapportering fokuserar på att balansera behovet mellan allmän medvetenhet och leverantörernas ansvar att inom en rimlig tid hantera och åtgärda sårbarheter.

Men…
… vad händer om leverantören inte svarar? Eller om de inte vill samarbeta? Detta är tyvärr alltför vanligt. Från leverantörens perspektiv kan en sårbarhetsrapport ses som en drastisk handling, särskilt om leverantören inte har en korrekt process för hantering av sårbarhetsrapporter. Även om detta är vanligt förekommande, rekommenderas det inte att leverantörer är fientliga mot rapportörerna. Detta kan leda till att rapportörerna väljer att ta en annan väg, exempelvis fullständig sårbarhetsrapportering, vilket kommer sätta press på leverantören att åtgärda de problem som rapporterats. Det medför dock risken att hotaktörer kan utnyttja sårbarheten innan leverantören har åtgärdat den. Av denna anledning är fullständig sårbarhetsrapportering något som inte uppmuntras.

Figur 4: Samordnad sårbarhetsrapportering – alternativ processcykel.
Figur 4: Samordnat sårbarhetsrapportering – alternativ processcykel.

Som nämnts tidigare kan CERT bistå personer som rapporterar en sårbarhet. Till exempel, om leverantören inte svarar, kan CERT hjälpa till att förmedla kommunikationen. Om sårbarheten ger upphov till dataintrång och/eller är i strid mot gällande dataskyddslagstiftning, kan även den statliga myndigheten IMY kontaktas. IMY är en svensk tillsynsmyndighet som arbetar med tillsyn inom dataskyddsområdet.

Dessutom är leverantören skyldig att rapportera alla dataintrång som leder till exponering av personuppgifter (PII) till myndigheten inom 72 timmar efter att de fått kännedom om det. De är också skyldiga att underrätta alla berörda parter, såsom kunder och användare.

Vid samordnad sårbarhetsrapportering finns det många krav som leverantörerna behöver möta. I de fall då en leverantör har en bristfällig process för samordnad sårbarhetsrapportering, kan processen skapa fler problem än den löser. Kommunikation är nyckeln till framgångsrik sårbarhetsrapportering. Framförallt är det viktigt för att förebygga missförstånd kring allvarlighetsgraden, de implementerade åtgärderna, offentliggörande, etc. Ansträngningar för att hantera potentiella tillkortakommanden innefattar vanligtvis pågående förbättringar i kommunikation, samarbete, samt utvecklingen av standardiserade metoder för samordnad sårbarhetsrapportering.

Ta farväl av dina buggar

Nu uppmanar vi dig inte att gå ut och hacka allt du kan lägga händerna på – det är fortfarande olagligt. Men för den som tycker det låter spännande, finns det lagliga sätt för dig att leta efter sårbarheter. Som nämnts tidigare kan du delta i en bug bounty eller ett belöningsprogram för sårbarheter (vulnerability reward programs). Ett bug bounty-program är ett crowdsourcat initiativ som erbjuds av leverantörer för att uppmuntra oberoende säkerhetsforskare och etiska hackare att upptäcka och ansvarsfullt rapportera sårbarheter i deras programvara, system eller produkter. När du deltar i en bug bounty är det viktigt att vara förberedd. Du behöver ha koll på leverantörens uppförandekod (Code of Conduct) samt deras policy. Omfattningen av vad som får testas, reglerna för samarbetet (Rules of Engagement) och de juridiska villkoren behöver också studeras. Detta för att säkerställa att du håller dig inom de lagliga ramarna när du utför dina tester. Det är också viktigt att endast kommunicera genom de dedikerade kontaktkanalerna, inte genom inofficiella kommunikationskanaler (exempelvis sociala medier).

I grunden är det ett belöningssystem för personer som upptäcker och rapporterar buggar och sårbarheter i en organisations digitala tjänster. Målet är att förbättra den övergripande säkerheten i programvaran eller systemet genom att identifiera och åtgärda potentiella problem innan hotaktörer får möjlighet att utnyttja dem.

HackerOne är en bug bounty-plattform som underlättar bug bounty-program för leverantörer. Den kopplar samman säkerhetsforskare eller etiska hackare med företag som vill identifiera och lösa säkerhetssårbarheter i deras programvara, webbplatser och system. HackerOne fungerar som en mellanhand och tillhandahåller en plattform för samordning och hantering av bug bounty-program.

Säkerhet är inte längre valfritt i vår digitaliserade värld. Sårbarheter dränker vår cybervärld och det krävs samarbete för att säkra upp och utplåna så många hot som möjligt. Som den välanvända frasen lyder, ”the best defence is a good offense”. Transparens, öppenhet och samarbete är det ultimata antiviruset för ett säkrare digitalt samhälle.

Referenser

https://securitytxt.org/

https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html

https://www.hackerone.com/vulnerability-disclosure/vulnerability-disclosure-whats-responsible-solution

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/