Sponsrat

28 maj, 2020

Om ID-kapningar och bedrägerier

Bakgrund 

I IT-säkerhetspoddens avsnitt tillsammans med PA Prabert (Vice Koncernchef) och MySafety försäkringar kom givetvis snabbt in på ID-kapningar och bedrägerier eftersom det är något som försäkringsbolaget forskar i. Årligen släpps en rapport i ämnet och trenderna är tydliga. 

MySafety försäkringar bildades 1999 och har specialiserat sig kring försäkringar och just ID-kapningar. 2007-2008 började företaget titta noggrant på ID-kapningar på nätet och hur problemet kom från USA och började eskalera inom Sverige. Till och med näthat finns försäkringar emot där företaget ger hjälp och assistans ifall man utsatts för näthat. 

MySafetys undersökning 

Undersökningen bygger på ID-kapningar som har drabbat både företag (under 250 personer) och privatpersoner. Tyvärr är slutsatsen, sedan undersökningen börjades 2014, skrämmande. Det är många svenska som blir utsatta – 200 000 svenskar drabbas årligen.  

2019 minskade antalet något men redan nu ser man att det ökar igen. 2019 kan bero på att tekniken kommit ikapp attackerarna men nya tillvägagångssätt hittas hela tiden och 2020 pekar alltså uppåt igen. 

Det kanske mest skrämmande är att det görs betydligt fler försök till ID-kapningar. Två miljoner försök görs varje år eller ett försök var tionde minut. Alltså 10% av dessa lyckade. Så man kan enkelt göra slutsatsen att alla kommer någon gång drabbas av ett försök, och i värsta fall, en lyckad ID-kapning. 

Undersökningen visar också att Svenskarna visar ungefär att 50-80% har oro för kapning på nätet.  

Vad är en ID-kapning? 

Ja, enklast kan man säga att man anskaffar sig en annan person identitet där det absolut vanligaste är att använda någon annans bankkort. Nummer två på listan är att teckna lån i en annan person namn. 

Undersökningen visar att det ofta rör sig om att personer blir bestulna på ungefär 5.000 till 10.000 personer vilket kan anses vara en låg summa rent brottsligt, men eftersom det görs så många gånger blir beloppen väldigt stora.  

Dessvärre blir få brott uppklarade och majoriteten av ärenden hos polisen läggs ner.

Mer finns att läsa här.

Har vi blivit bättre? 

Svårt att säga. PA Prabert har sett i undersökningen att BankID har sjunkit rejält men en faktor är gemensam. Det här handlar om Social Engineering där personer luras genom telefonsamtal och i just dessa tider använder bedragarna Covid 19 som anledning till kontakt med personen. 

En kapad identitet bevakas 

MySafety letar efter kapade identiteter. En proaktiv bevakning som undersöker till exempel Dark Web. Kunden laddar ner en att och får en notifieringifall ens personuppgifter eller bankkortsnummer dyker upp på skumma siter. 

Så i bästa fall kan man alltså hinna stoppa ett pågående bedrägeri. Om inte alla brott, så kanske det första för det är vanligt att flera bedrägerier görs på samma stulna identitet.  

Hur ska man tänka då? 

PA Prabert summerar med hur man ska tänka för att skydda sig: 

  • Generellt sett ska man vara misstänksam 
  • Titta på epostadress och webadress 
  • Postnord och andra företag ber ofta inte om BankID eller komma från skumma siter 
  • “Saker som verkar för bra, är förmodligen för bra att vara sant” 
  • Använd starkt och unikt lösenord 
23 maj, 2020

Show Notes för #77 – Säkerhetsläget med mySafety

(från vänster) PA Prabert, Mattias Jadesköld och Erik Zalitis. Inte i bild: alla IT-säkerhetsproblem på Internet och brottslingarna som snor din identitet.

Avsnittet heter 77 – Säkerhetsläget med mySafety
Det spelades in 2020-05-15 och lades ut 2020-05-24.
Deltagare: Mattias Jadesköld, Erik Zalitis och PA Prabert.
Show notes skrivna av Erik Zalitis.

Det är ju ett återkommande citat från mig att ”detta är det sämsta året hittills … åtminstone fram till nästa år”. Och attackerna ökar hela tiden. Men faktum är att den senaste rapporten från mySafety visar på en mer nyanserad bild där förra året har sett en liten minskning av vissa brott. Så vad är på gång?

Denna gång får ni ett sponsrat avsnitt där vi och försäkringsbolaget mySafety går igenom slutsatserna man dragit och hur man kan skydda sig mot dessa id-kapningar.

Mattias frågar ”hur skrämmande är det?”. Svaret är att två miljoner Svenskar varje år utsätts för någon form av försök till id-brott och av dessa lyckas 10% av dem på något sätt.

Åldringar är särskilt utsatta visar det sig, men detta innebär inte att andra är säkra. Faktum är att brottslingarna visat sig vara mästare på den typ av social ingenjörskonst som krävs för att lura till och med den mest skeptiska person. De är proffs på vad de håller på med. Och den som står med skammen att ha blivit lurad, vill ofta inte prata om det. Jag frågade om inte detta gynnar bedragarna, och PA säger att det tyvärr är så.

Länkar

MySafety
https://www.mysafety.se/

Deras rapport, som kom ut 2020-06-04:
https://www.mysafety.se/sites/default/files/mysafety_ID-kapn.rapport_maj_2020_web_0.pdf

20 mars, 2020

När det gått snett i verkligheten inom Open Source

I IT-säkerhetspoddens tredje, och sista, är Linus Karlsson (Security Specialist) från Debricked med oss och pratar om när det gått snett I verkligheten. 

Riskerna att inte uppdatera Open Source och beroende applikationer

Ett vanligt fenomen är dåliga rutiner på att uppdatera sin mjukvara  (eller dependencies som det benämns i avsnittet). Linus tar fallet med Equifax som exempel. 

Equifax är ett stort kreditupplysningsföretag I USA som drabbades av en läckage där 145 miljoner människors information läckte. Ungefär hälften av USAs befolkning. Information som namn, adresser och körskortsuppgifter läckte. 

Grundorsaken berodde på att Equifax nyttjade ett bibliotek, som är väldigt vanlig, som heter Apache struts. Biblioteket används för att skapa webtjänster baserat på Java. 

Trots att Equifax upptäckte sårbarhet i Apache struts tog det ungefär ett halvår innan de presenterade detta. Anledningen vara att biblioteket inte uppdaterats och konsekvenserna blev att Equifax fick sitt varumärke svärtat samt att de fick betala tillbaka oerhört mycket pengar. De fick bland annat erbjuda gratistjänster till sina kunder. 

Om man litar på A, som litar på B, betyder det automatiskt så att man litar på B? 

Linus tar ett annat exempel som är mycket mer sofistikerat och som bygger på just att man litar på sin mjukvara och på så viss även litar på mjukvarans beroende program. 

Den här gången drabbar det registryt NPM, eller rättare sagt Event Stream som är ett populärt paket bland java-script. Paketet gör en väldigt specifik grej, och i just detta fall, strömmar av event. Paketet är oerhört populärt och nyttjas i massor av mjukvara. 

Event Streams skapare blir kontaktad av en okänd person som har ett antal förslag på förbättring och skickade dessa. Allt kändes som att personen agerade i all välmening. Förbättringarna godkändes, men ytterligare en dependencies smögs med. Det syntes men eftersom personen verkade schysst lade man ingen större notis om det, eftersom det inte innhöll något skadligt. 

Men en månad senare uppdaterades just den här dependencies med ny kod. Den här gången skadlig!  

Attacken var väldigt sofistikerad, och riktad, eftersom den skadliga koden aktiverades bara när mjukvaran hanterade Bitcoins. Dessutom om balansen på Bitcoin-plånboken hade hög likviditet. På så vis upptäcktes det inte lika lätt. 

Konsekvenserna är okända men skadliga koden skeppas tillsammans med mjukvara för Bitcoin. 

Hur kan man skydda sig mot detta? 

I första exemplet gäller det givetvis att se till att ha en tydlig patchrutin. Mjukvaran ska vara uppdaterad. Man måste också ha koll på vilka beroenden som finns i mjukvaran och att även dessa är uppdaterade. 

Det andra exemplet är knepigare eftersom det nästan är ett Social Engineering-attack där skaparen av mjukvaran luras att uppdatera sin kod. Ett tydligt svar finns inte riktigt utan det diskuteras fortfarande huruvida det är grundaren som var oansvarig medan en annan stor grupp tycker att man inte kan ha sådana förväntningar på en person som skapat mjukvaran på sin fritid. Dessutom en person som inte har tid att uppdatera mjukvaran längre. 

Vem man ska lita på kanske inte är det viktiga utan mer mekanismen hur man tar in ny mjukvara, och upprätthåller den, i sin kod. 

13 februari, 2020

Machine learning inom Open source

I IT-säkerhetspoddens andra specialavsnitt är Emil Wåreus (Head of Data Science på debricked) tillbaka. Den här gången pratar vi om hans favoritämne – machine learning. 

Att nyttja Maskininlärning har på sista tiden blivit betydligt billigare och det finns ramverk att arbeta med som kan tillämpas till sin mjukvara. 

Säkerhetsföretaget debricked hanterar extremt mycket data i sitt analysverktyg för att identifiera sårbarheter i open source. Därför används maskininlärning för att processa all information. 

Maskininlärning inte samma sak som AI 

Emil har tidigare byggt robotar (eller autonoma agenter), till exempel drönare som följde efter människor, och där noterade han att begreppet maskininlärning missförstås. Ofta blandas det ihop med AI fast det är helt separata saker. Så för att förtydliga: 

  • AI kan beskrivas, ur ett autonom-agent-perspektiv, som human, det vill säga en agent som kan förstå sin omgivning och ta beslut helt utan styrning. 
     
  • Maskininlärning däremot, ur samma perspektiv, kan delvis uppfatta omgivningen men är bättre på varseblivning. Den fungerar väl i en stängd miljön men om man tar drönararbetet som exempel är omgivningen fysisk. Maskininlärning som teknik kan då inte “förstå” omgivningen men däremot analysera bilder. Problem kan uppstå där till exempel maskininlärning kan tro att en ko kan vara i en hästhage (där ett AI, som förstår omgivningen, förmodligen skulle anta det är en häst eftersom den förstår att det är en hästhage). Det är således viktigt att träna sin maskininlärning. 

Processad information måste bli rätt 

Vi tar oss an den amerikanska databasen NVD igen, där Emil upptäckte att sårbarheterna som presenterades var missvisande. 

Sårbarheter presenteras som att 60% av produkter som visas endast har en sårbarhet och 90% med under sex sårbarheter. Det blir alltså svårt att se allvarligheten i de olika mjukvarorna och vilka projekt som innebär störst risk att nyttja. 

Debricked tar hjälp av sin egen maskininlärningsalgoritm för att samla NVD tillsammans med issues på Github (repository med mjukvaror) för att få kvalité på informationen. Den tittar till exempel på språkbruket i skapade issuen och vad för ord som den innehåller för att bilda sig en uppfattning. På så vis kan algoritmen avgöra vad som är en säkerhetsbrist och vad som till exempel är en bugg. 

Den guidar utvecklare i rätt riktning och att göra rätt. 

Algoritmen läser miljoner rader av text (från flera olika repositories) och förstår och kategoriserar problemet. 

Träna sin algoritm 

Maskininlärning måste hela tiden tränas på sådant den känner till och på sådant den inte känner till. Tekniken kallas Semi-supervised learning och där använder debricked Googles TensorFlow. 

Vi återanvänder häst-exemplet. Emil tränar sitt dataset med ett antal bilder på hästar och sådant som är markerat som “inte häst”. Sedan massor av bilder på sådant som är helt okänt. Algoritmen processar bilderna och förstår, och blir ännu mer träffsäker, på vad som är en “häst i en bild”. 

Det finns färdigtränade algoritmer för till exempel bildanalys och text men inte mycket för att upptäcka säkerhetsbrister. Där är debricked ledande och slår andra som gör liknande. 

 
Vad är en säkerhetsbrist? 

Debrickeds algoritm kan läsa nästan vilken text som helst och avgöra om det är ett säkerhetsproblem som beskrivs eller inte. Företaget arbetar vidare med att kategorisera vikten av hur allvarlig bristen är. 

Emil poängterar vikten att förstå sitt område som dataanalytiker. Man måste kunna till exempel säkerhet för att kunna utveckla maskininlärning som hanterar säkerhet. Man måste hela tiden jobba och undersöka hur träffsäker sin maskininlärning är. Det går inte att ha en algoritm som förutspår sju av tio fel och genererar för mycket falska larm (false positive). Det är viktigt att den data som levereras till kund är minst över 90% korrekt, så kunden kan fokusera på rätt saker. 

Avslutande tips 

Emil avrunda med tips inom maskininlärning 

  • Det är viktigt att ha låg false positive men att arbeta med att öka informationen att ta in utan att sänka kvalitén med hög träffsäkerhet 
  • Arbeta med erkända ramverk (t.ex. TensorFlow) 
  • Arbeta med matematiken för att optimera effektivt och för att förstå sin data 
  • Förstå din domän först (område) som maskininlärningen ska hantera 
  • Maskininlärning är ett medel för att nå ditt mål 
31 januari, 2020

Statistik inom Open source

Affärsmodell med Open source 

Allt fler företag väljer att skapa mjukvara baserat på öppen källkod (Open source). I IT-säkerhetspoddens avsnitt pratar vi med Emil Wåreus Head of Data Sience på debricked om risker kopplat till öppen mjukvara och statistik (eller fun facts).

Statistiken är viktig att förstå för att välja rätt öppen källkod och hur komplext det kan vara för att undvika säkerhetsrisker. 

   Öppen källkod kan jämförs som en rörelse där skapare nyttjar öppen källkod och publicerar sina anpassningar på internet för hela Open source-scenen. Engagemanget är stort och förslag med funktionell och säkerhetsmässiga förbättringar diskuteras inom rörelsen.  

   Det kan tyckas märkligt att företagare lämnar ut sin affärsidé och delar med sig till vem som helst och för att förstå hur det hänger ihop tar vi oss till 80-talet. Trenden var då att man såg sin mjukvara just som själva affärsidén. Resultatet blev en statisk mjukvara (eller proprietär kod) med ett hackigt community. . 

   Open source startade samtidigt på konsumentsidan där engagemanget blev stort bland användare. När det nu är utbrett på företagssidan är en vanlig affärsmodell open core där kärnan är öppen medan tilläggstjänster såsom support och konsultarbeten blir affärsmodellen. På så vis behålls engagemanget i Open source och samtidigt kan företagare vara lönsamma genom att hjälpa sina kunder med vad de faktiskt efterfrågar. 

Flera hundra beroenden 

Det många inte vet är att en öppen källkod ofta inte är just en mjukvara. Tvärtom. Vanligare är snarare att mjukvaror använder flera hundra direktimporterade mjukvaror som den är beroende av. Beroenden med sina egna öppna källkod och sårbarheter. Emil Wåreus tar ramverket React som exempel som är en plattform baserad på Java och skapat av Facebook. Verktyget är väldigt populärt just nu för att skapa webapplikationer och bygger på just öppen källkod. Men få känner till att React har ungefär 3.500 beroenden. Hur ska man ha koll på vilka man använder och vilka säkerhetsrisker det finns att nyttja ett sådant ramverk? 

   Här finns fördelen med den öppna källkodsscenen där man kan ta del av andras upptäckter och idéer till skillnad mot stängd mjukvara där tillverkaren ansvarar för att upptäcka sårbarheter och täppa till dessa. 

   För att reda ut svårigheterna finns debrickeds mjukvara som analyserar mjukvaran inom tre områden – sårbarheter, licensieringen och hälsokontroll (health check), där det sistnämnda undersöker just communityt för att analysera hur högt engagemanget såsom bidragande medlemmar. Det hela poängbedöms av debricked vilket hjälper upphovsmakarna att välja rätt öppen källkod. 

Flera datakällor för att upptäcka sårbarheter 

Debricked är integrerat med Amerikanska NISTs “National Vulnerability Database” (NVD) som är en öppen databas där man kan hitta kända sårbarheter i öppen källkod. Här rapporterar communities (till exempel Github) till NVD för analys. NVD undersöker vilken typ av sårbarhet som avses och om det är kopplat till säkerhet eller inte. Ungefär femtio nya sårbarheter registreras – per dag! 

Statistik från NVD visar vilka projekt som innehåller mest sårbarheter. Bild nedan visar de högst rankade just nu.  

   Men NVD räcker inte för att upptäcka sårbarheter så därför är databasen bara en av datakällor som debricked nyttjar. En stor del upptäcks inte eftersom NVD har koll på 50.000 projekt som har ungefär 120.000-130.000 sårbarheter. Debricked däremot hittar över 200.000 sårbarheter relaterat till säkerhet eftersom de samlar in från flera datakällor. 

   Den andra stora källan är, numera Microsoft-ägda GitHub, som debricked nyttjar som datakälla. Här undersåker debricked så kallade issues på Github. 

   Om man skapar en enkel websida baserad på öppen källkod med populära verktyg och installerar enligt standard kan man räkna med ungefär 10.000-15.000 beroende mjukvaror med hundratals sårbarheter. Nästa steg blir att analysera sårbarheten som oftast (ungefär 30%) kan täppas till genom att uppdatera. Men resten är klurigare. Man ska ställa sig frågan – använder jag den här mjukvaran? Eller kan jag bygga runt det på något vis?  

Fyra råd 

Emil Wåreus ger fyras råd för öppna källkodsprojekt.  

  • Använd debricked tidigt i processen innan du importerar mjukvara för att förstå hur säker den är och undersök poängbedömningen.  
  • Sätt policys för att blockera osäker mjukvara. På så vis hjälper man utvecklare att göra rätt och förhindra att fel kod importeras 
  • Räkna på mjukvaran som är tänkt att användas. Räkna hur mycket tid och pengar det krävs för att säkra mjukvaran 
  • Använd inte gammal mjukvara 

Man får också väga “springa framåt” mot “håll tätt bakåt” i projektet. 

Facebook Spotify Soundcloud Apple Rss

Senaste avsnitten

Scroll to top