Under vecka 9 hölls den årliga säkerhetsmässan RSA Conference i San Francisco och Sopra Steria hade representanter från Cyber Security på plats för trendspaning. RSA Conference är ett nischat event för informations- och IT-säkerhet som tidigare år lockat upp till 45 000 deltagare från hela världen. Eventet består dels av en stor utställning med leverantörer av olika säkerhetslösningar, men framförallt ett stort antal parallella pass med oberoende talare som presenterar den senaste utvecklingen inom allt ifrån informationssäkerhet, lagstiftning och olika ramverk till teknik som nätverk, virtualisering och kryptografi (på avancerad nivå!).
Nedan följer en summering av de viktigaste trendspaningarna.
Utan att överdriva skulle man kunna hävda att utvecklingen inom informationsteknik varit fullkomligt omvälvande de senaste 30 åren. Datorer har blivit kraftfullare, mobila och nätverksåtkomst är nästan en mänsklig rättighet. Det mesta har utvecklats i ett rasande tempo, utom metoden vi använder för att logga in. I presentation efter presentation lyfts (sedan länge kända) problem och en överväldigande mängd verklighetsbaserade exempel på hur illa det kan gå när åtkomst styrs med enbart Användarnamn och Lösenord, och vi kan bara konstatera att trendbrottet gällande användning av metoden fortfarande inte inträffat.
De flesta säkerhetsexperter verkar vara överens om att komplicerade lösenordspolicies som kräver en viss komplexitet (minst si och så många alfanumeriska tecken, special tecken, osv.) är helt tandlösa och inte löser det faktiska problemet med Lösenord – som är lösenordet i sig själv. Vi användare är inte dummare än att lösenorden tenderar att bli av sorten 1234Abcd! som lever upp till komplexitetskraven, men ändå inte är speciellt svåra för en illvillig att genom exempelvis phishing lura av oss eller till och med gissa sig till.
Kort och gott: Användarnamn och Lösenord är ett förlegat sätt att logga in. Sluta upp med det!
Det har länge funnits massvis med beprövade alternativ för att tillföra ytterligare faktorer utöver användarnamn och lösenord, men i år var det hetaste spåret FIDO2 och WebAuthn som möjliggör lösenordsfria inloggningar. Stöd för WebAuthn är brett bland de stora aktörerna som också har varit med och utvecklat standarden, och därför fungerar det redan nu i de flesta webbläsare och enheter. Vi tror starkt på denna metod för att skydda våra användares identiteter och konton.
Under veckan redogjorde flera parter för flera av de mest vanligt förekommande säkerhetsproblemen som organisationer råkar ut för eller ställer sig själv inför. Det var egentligen inget nytt utifrån de erfarenheter som vi själva har utifrån vårt dagliga arbete, men däremot är det ju mycket intressant att beakta volymer, trender och andras erfarenheter av de problem som är relativt vanligt förekommande vid användning av molntjänster. Några av “klassikerna” som ligger i topp inkluderar:
En annan faktor som vi också skulle vilja trycka på i sammanhanget är att molnplattformar överlag inte “som standard” erbjuder någon vidare insyn över vad som faktiskt händer i de tjänster som används, utan kunderna har ett stort eget ansvar att både definiera och etablera säkerhetsrelaterad logg- och övervakningshantering. De store molnleverantörerna har sådana tjänster i sitt utbud, men det är upp till varje kund att faktiskt utnyttja dem, men att också vara förberedd på att det kommer att driva kostnader. Detta bör vara en av de faktorer som man som kund tar hänsyn till och sätter i relation till sin förmåga att arbeta proaktivt med säkerhetsrelaterade händelser som berör de tjänster man använder sig av. Det är egentligen ingen skillnad på denna aspekt bara för att man använder en molntjänst då det är lika aktuellt även om det inte handlar om molntjänster. Det betyder ju naturligtvis inte att man hela tiden måste sträva efter överdrivna åtgärder som överträffar skyddsvärdet på tillgångar, utan snarare att övervakning och förmåga att spara bevis på händelser är en del av verktygslådan när man bedömer lämpliga skyddsåtgärder utifrån risker, hotbild, applicerbar lagstiftning och andra källor till seriöst säkerhetsarbete.
Under veckan genomfördes, lite som vanligt nuförtiden, diskussioner om vad som är den bästa mobila plattformen utifrån olika säkerhetsperspektiv. Det fanns ju en tid när man utan att tveka kunde le lite åt Android som plattform jämfört med iOS, men riktigt så är ju inte fallet längre. Att jämföra Android som helhet med iOS är dock inte en speciellt rättvisande jämförelse, inte minst med tanke på den mycket stora mängden distributioner som finns av Android och hur varierande kvaliteten är på dessa distributioner. När det kommer till Android brukar vi rekommendera att man använder en så “ren” distribution som möjligt, d.v.s. där man har så lite tillverkarspecifik mjukvara som möjligt. Inte minst med tanke på historiken om man tittar på sårbarheter i “lull-lull funktioner”, tillverkarspecifika grafiska gränssnitt, tillverkarspecifika appar m.m.. Å andra sidan blir det inte så många kommersiella enheter kvar på marknaden att köpa om man har den ansatsen. Dessvärre är väl massmarknaden mer inriktad på att erbjuda de finaste och flashigaste enheterna istället för de säkraste enheterna.
Sedan ett litet tag tillbaka är det dock ett intressant faktum att man kan se hur 0-day exploits för Androidenheter tingar en högre köpesumma än motsvarande exploits för iOS, det är ett trendbrott helt klart och säger ju lite om hur mycket bättre hygienfaktor Android överlag har fått även om vi så klart ser skräckexempel från vissa tillverkare. Det bör ju också såklart sättas i relation till att Android numera har en sådan stor användningsgrad vilket gör att mängden enheter som potentiellt kan angripas självklart påverkar den kriminella svarta marknaden och dess prissättning.
Under RSA-konferensen genomfördes också ett antal angrepp mot olika typer av mobila enheter med hjälp av det relativt nya exploitverktyget Shevira, för de som är intresserade av att penetrationstesta Android/iOS-enheter är det helt klart ett verktyg att komplettera sin verktygslåda med.
Som fortsättning på temat omvärlden kontra Apple kan vi även peta hål i bubblan om att OSX skulle vara helt fritt från skadlig kod, för så är självklart inte fallet även om operativsystemet länge ansetts vara betydligt säkrare än t.ex. Windows. Under en presentation som handlade specifikt om att sno andras skadliga kod för OSX och göra om det till sin egen lyftes ett stort antal olika exempel på skadlig kod av alla möjliga varianter (Ransomware, backdoors, spyware osv.) fram, men också hur Apple försöker tackla dessa i OSX och hur de försöken kunde kringgås.
Apples olika försök till skydd hade visat sig vara förhållandevis enkla (eller ”triviala” som presentatören uttryckte det) att kringgå och påminde i vissa fall om de mest grundläggande signaturbaserade skydden mot skadlig kod som var populärt på Windows för ett par decennier sen.
Syftet med detta är inte att försöka svartmåla Apple, utan snarare poängtera att ingenting är helt säkert – inte ens OSX. I takt med att Apple-datorer, telefoner och läsplattor, hittat sig till de flesta arbetsplatser och hem har det också blivit fler som försöker hitta sårbarheter att nyttja i dessa till skillnad från en tid då Windows i stort sett dominerade datoranvändning i både hem- och företagsmiljöer. Har ni Apple-datorer så bör ni fundera kring samma säkerhetsaspekter som ni antagligen länge redan gjort för Windows-datorer, dvs. kryptering, skydd mot skadlig kod, centraliserad management osv.
Kubernetes är helt klart ett mycket kraftfullt sätt att drifta skalbara tjänster ovanpå men tyvärr är det lite av ett sorgebarn när det kommer till grundläggande säkerhetsfunktioner och allmän grundhygien. Detta i kombination med ett rullande releaseschema som det stundtals är svårt att hänga med i gör att det är ett stort arbete med att skydda Kubernetesinstanser och de tjänster som rullar ovanpå. Under RSA demonstrerades hur nya sårbarheter i senaste versionen av Kubernetes bl.a. kan missbrukas för att låta en angripare ta administrativ kontroll över ett eller flera Kubernetskluster utan att ha åtkomst till priviligierade konton. Det hela går ut på att man helt enkelt instansierar en ny administrativ API-server som sen tillåts administrera ett eller flera Kuberneteskluster utan att någon givit ut någon sådan behörighet. En annan sårbarhet som demonstrerades var att man kan missbruka loggbufferten för att dölja händelser från att hamna i någon logg eller uppkopplat logghanteringssystem, dessa två sårbarheter i kombination gör att man tyvärr fortfarande får betrakta Kubernetes som lite av ett sorgebarn utifrån ett säkerhetsperspektiv. Det finns många goda egenskaper hos Kubernetes, lite synd att säkerhetsförmågor inte är en av dem än så länge.
Under veckan fördes diskussioner om hur teleoperatörer i allt högre grad gör sig beroende av de stora molntjänstleverantörerna. För de som inte är helt insatta i hur 5G fungerar till skillnad från äldre generationers nät kan man kortfattat säga att man har delat upp några av de funktioner som tidigare satt i operatörernas basutrustning i en så kallad front compute-del som bl.a. sköter kommunikation mellan radiomaster och dess anslutna enheter och back-endhos respektive operatör. Av skalbarhetskäl men också inte minst av ekonomiska skäl har redan eller kommer operatörer att lägga font compute-delen hos någon av de stora molntjänstleverantörerna. Det blir helt enkelt lägre kostnad för många operatörer att drifta dessa tjänster på en kommersiell molnplattform istället för att etablera och underhålla en egen plattform. Det var i och för sig inte helt otippat men ändock är det en intressant och lite oroväckande spaning hur nu även mobilnäten i större omfattning blir beroende av de stora molntjänstleverantörerna. Det är en större centralisering vi ser och det ska bli intressant att se hur svenska operatörer kommer att göra när 5G rullas ut i vårt land.
Efter nästan arton års väntan publicerades officiellt FIPS 140-3 den 22 mars 2019. Standarden baseras på ISO/IEC 19790 samt ISO/IEC 24759 och ersätter föregångaren FIPS 140-2.
Den nya versionen av FIPS 140 är kraftigt omarbetad och introducerar ny terminologi och ett antal nya koncept, så som exempelvis ett ytterligare läge som kallas Degraded som innebär att en kryptomodul fortsatt kan utföra vissa krypto-operationer trots att en icke-kritisk komponent slutat fungera.
Utvärderingsmetoderna för FIPS 140-3 är inte helt färdiga i nuläget så det finns vissa frågetecken kring hur alla olika krav ska tolkas vid certifiering. Däremot är det fortsatt möjligt att certifiera kryptomoduler enligt FIPS 140-2 under 2020 vilket i praktiken sätter ett slutdatum på dessa till 2025, och redan certifierade moduler kommer att vara godkända under den tid de är certifierade för (5 år framåt från certifieringsdatumet).