Cloud Services - vad är problemet?

Kvalitets- och säkerhetsfolk har olika problem med "cloud" respektive "services".

När det gäller "cloud" handlar det om möjligheterna att verifera att av verksamheten beställd funktion, tillgänglighet, sekretess och dataintegritet levereras och att de lagar och regler som gäller för verksamheten uppfylls.

Med avseende på "services", eller tjänster, är frågan istället om verksamhetens krav kan uppfyllas av tjänsten.

Tjänster är IT-världens kollektivtrafik. Inslaget av standardisering är stort, och det finns begränsade möjligheter att påverka vad som levereras. Och du har inte rätt att få svar på alla de frågor du kan tänkas ställa.

Jämför gärna med godstransporter. Du kan ha egna specialfordon med egna chaufförer för att transportera dina varor från A till B längs de vägar du väljer på de tider du bestämmer, och du kan ha egen utrustning för att lasta och lossa varorna.

Eller du kan lasta varorna på en pall och köpa tansporten av en logistikfirma. En distributionsbil kommer till A enligt tidtabell och lastar pallen, en annan distributionsbil levererar pallen till B enligt en annan tidtabell. Vem som kör vilka bilar längs vilka vägar vet du inte. Du vet inte hur många gånger pallen lastas om, var det sker eller med vad det görs av vem. Du vet inte vad som finns på pallarna bredvid din. Du vet inte vilken koll de inblandade företagen har på personal, fordon och lokaler. Och du får sällan bra svar på dina frågor.

Men det kan vara helt OK för just det du vill transportera. Det bestämmer du, och det gör du när du väljer - köra själv eller köpa tjänst.

DI:s beslut om integritetsskydd för kundinformation i bank-appar

Datainspektionen har i tillsynsbeslut riktat krav på tre banker att förbättra inloggningen till sina bank-appar. Beslutet anses vägledande för banker verksamma i Sverige.  Se pressrelease på DI:s hemsida. 

I själva besluten finns bl a följande text:

Datainspektionen anser att det kan medföra stora risker för den enskildes personliga integritet om någon obehörig får tillgång till t.ex. uppgifter om konton, transaktioner med namn på mottagaren eller avsändaren och skuldsättning. Uppgifterna skulle kunna användas till att kartlägga, inte bara stora delar av en persons ekonomiska förhållanden, utan även var denne har befunnit sig och dennes inköpsvanor. Uppgifterna om transaktioner kan dessutom innehålla känsliga uppgifter i personuppgiftslagens mening, t.ex. genom att avslöja den enskildes vårdgivare. 

Risken för dataintrång är betydligt högre om man använder sig av enbart lösenord för autentisering, än om man utöver lösenord använder sig av ytterligare någon faktor vid autentiseringen. Den ökade risken beror på att det är lättare att komma åt enbart ett lösenord, än att skaffa sig åtkomst till exempelvis både någons bankkort eller smarta telefon och lösenordet. Dessutom är det lättare för en användare att upptäcka att man har blivit av med till exempel sitt bankkort eller sin smarta telefon, än att någon obehörig har lyckats avslöja lösenordet.

Inom bankväsendet används redan idag lösningar som e-legitimation, koddosor och engångslösenord. Det talar för att kostnaden för att införa en starkare autentiseringslösning inte skulle behöva bli orimligt hög. 

Vid en samlad bedömning av hur pass känsliga de behandlade personuppgifterna är, riskerna som finns med behandlingen av personuppgifterna, de tekniska möjligheter som finns tillgängliga på marknaden samt vad det kostar att genomföra åtgärderna finner Datainspektionen att den autentiseringslösning som [banken] för närvarande använder i sin app inte lever upp till kraven på säkerhetsåtgärder enligt 31 § personuppgiftslagen. 

Alltså: Enbart lösenord för autentisering räcker inte. Det måste finnas någon mer "faktor", dvs något unikt därutöver som kunden kan anses ha god kontroll över, t ex en dosa (med eller utan kort), en papperslapp med engångskoder eller själva smartphonen (dvs en e-legitimation i smartphonen eller något annat unikt och identifierbart innanför skalet). 

Vad har då bankerna för handlingsalternativ?

Ett näraliggande alternativ för många banker i kategorin "minst en pryl till utöver smartphonen" är att använda en autentiseringslösning man redan har, t ex engångskod eller challenge/response-lösning av de typer som används  av flera internetbanken. Det känns som den naturligaste lösningen på kort sikt, både för kunderna och för banken. Den har fördelen att kunderna känner till den, och den fungerar. Min ogrundade uppfattning är att denna lösning är relativt enkel och billig att införa. För kunderna medför den en viss nackdel (minst en pryl till ska finnas till hands vid autentiseringen), men den bör gå att motivera med bättre säkerhet. Såvitt jag förstår behövs den befintliga lösningen ändå i de flesta fall om man vill göra överföringar mm. när man väl är inne i appen, så kundupplevelseförsämringen blir knappast dramatisk.

I den användarvänligare kategorin "bara smartphonen, inga fler prylar" finns exempelvis e-legitimationer typ Mobilt BankID, SMS-OTP, virtuella dosor och "låsning" av kunden till smartphonen. E-legitimation är enligt min uppfattning lösningen på lite längre sikt, inte minst för att lösningen är multilateral och öppnar för utökad funktionalitet och större kundnytta jämfört med de proprietära lösningarna. För att befintliga kunder som inte är kund i annan bank ska kunna fortsätta använda "sin" banks app efter det att påloggningen ändrats behöver banken vara både förlitande part och utfärdade. 

På kort sikt finns SMS-OTP (som blir väldigt klumpig – skriv in koden du just fick till din smartphone på din smartphone…) och "låsning" av kunden till smartphonen på något intelligent sätt. På medellång sikt finns olika slags virtuella dosor.

Jag är inte själv tillräckligt tekniskt bevandrad för att veta vad det finns för möjligheter att registrera något unikt och tekniskt avläsbart (t ex processor-ID, SIM-id) i samband med att man signar sig för att använda appen, men finns det sådana data som är pålitliga och som kan verifieras vid varje påloggning kan det vara ett enkelt sätt att lösa problemet i bakgrunden och låta kundupplevelsen vara oförändrad. En förutsättning för att en sådan lösning ska kunna accepteras är att kunden intuitivt förstår att förlust av smartphonen måste anmälas snarast möjligt till banken. Eftersom detta förmodligen inte känns jättenaturligt för kunden är det sannolikt så att denna typ av lösningar inte kommer att accepteras av myndigheterna vid en granskning.

Uppdatering: DI har i september 2013 beslutat att acceptera teknisk knytning av bankappar till en specifik smartphone. Det, i kombination med en pinkod, medför enligt Datainspektionen en tillräckligt hög säkerhet för att man ska godkänna denna lösning.

Lösningar typ virtuella dosor har risker. Man bör förvänta sig barnsjukdomar, och det är inte säkert att tekniken uppfyller kraven för framtida tjänster. Det innebär att lösningen riskerar att bli kortlivad, särskilt om banken bestämmer sig för att inte bara förlita sig på proprietära lösningar utan börja gå längs det multilaterala e-legitimationsspåret. Men det är mycket möjligt att vissa banker bedömer att det behövs en överbryggning mellan lösenord och e-legitimation för att kunna möta kraven från DI, media och kunder på ett effektivt sätt. Finns det då inte tekniska möjligheter att binda kunden till en viss smartphone på annat sätt blir virtuella (eller fysiska) dosor ett surt äpple att bita i.

Sammanfattningsvis är min bestämda uppfattning att bankerna har allt att vinna på att satsa på e-legitimationslösningar typ Mobilt BankID för sina appar.

Informationssäkerhet - en oteknisk fråga?

Informationssäkerhet handlar väldigt lite om teknik. Framför allt inte om specifika tekniska lösningar. 

Informationssäkerhet råder om riskerna med organisationens information och informationsanvändning är acceptabla. Det brukar de vara om all organisationens information är:

1. ändamålsenlig, dvs tillräckligt riktig, fullständig och aktuell (integritet),
2. tillgänglig för dem som behöver den i sina uppdrag för organisationen,
3. otillgänglig för alla andra (sekretess).

För att uppnå informationssäkerhet bör man bland annat:

1. endast acceptera läsning, tillägg och borttag av information som behöriga vill göra
2. låta bli att ändra i lagrad information
3. dokumentera och övervaka aktiviteter som hanterar information

Ett utmanande (tror jag) exempel:

Om endast behöriga kan lägga till information minskar risken för att fel eller oönskad information läggs till - t ex skadlig kod. Men det kan ändå hända, även med väl utvecklat integritetsskydd. 

Men om endast behöriga kan läsa, lägga till och ta bort information - och ingen kan ändra i lagrad information - kan inte obehöriga, t ex skadlig kod och andra obehöriga applikationer, göra det. Det kan fortfarande hända, om behörighet tilldelas slarvigt. Men sannolikheten att skadlig kod ställer till med elände är lägre om båda skyddstyperna finns och fungerar. 

Lägg till allt detta genomtänkt dokumentation av aktiviteter och snabba larm + åtgärder om aktiviteterna avviker från vad som förväntas så ligger vi hyfsat till.

Vilka olika tekniker som behövs för att skapa denna goda dessert är en helt annan fråga.

Orsaker till oönskade situationer

För några år sedan satt jag som säkerhetschef i Danske Bank Sverige och funderade över orsakerna till säkerhetsproblem av olika slag. De stora studier som Gartner m fl gjorde fokuserade på skadorna som sådana fördelade på olika sätt, men om man vände lite på siffrorna kanske man kunde dra lite slutsatser om var det proaktiva säkerhetsarbetet borde göra störst nytta. Sagt och gjort.

Jag tog två sådana studier från två olika år, dvs totalt 4 st – Gartner och någon annan, mins inte vilken – och gick igenom deras uppgifter om större skadehändelser i större koncerner worldwide under ett år, sammanlagt kanske knappt 500 händelser om jag minns rätt. Min hypotes var att orsaken borde gå att finna i människor – avsiktligt eller oavsiktligt, dvs angripare eller slarv/misstag – i teknik eller i omgivning/miljö. Dessutom borde det gå att läsa ut om det var interna eller externa orsaker. Totalt hade jag således 8 fält att börja pricka in händelser i.

Informationen var inte särskilt omfattande om varje händelse. Det fanns uppgift om bransch och om händelsen i stora drag, men inte om belopp eller typ av skada, bara att den var "allvarlig". Så jag kunde bara summera över antal.

Tyvärr har jag inte kvar källmaterialet, men resultatet har (för-)följt mig genom åren, och jag har inte blivit motsagd när jag presenterat det, tvärtom. Kanske är det enkelheten som tilltalar – slutsatserna är förfärande tydliga. Om de är sanna. Vilket jag faktiskt tror. 

Översatt till frekvenser blev resultatet så här, när man rundar av lite:

Med andra ord:

• Företagen i undersökningarna drabbades av externa attacker med riktigt allvarliga konsekvenser ungefär vart 3:e år i genomsnitt.
• Interna angripare, dvs "insiders", orsakade riktigt allvarlig skada ungefär vartannat år.
• Medarbetares felgrepp ställde till med riktigt allvarlig skada i företaget ungefär var 5:e månad (i genomsnitt!)
• Övriga 5 möjliga orsaksområden bidrog med så få exempel att det inte gick att göra någon vettig statistik på det.

Min slutsats var och är att säkerhetsarbetet – det proaktiva – bör fokusera på att förebygga felaktig hantering i första hand, insiders i andra hand och externa attacker i tredje hand. Övriga orsaker ska naturligtvis också hanteras i det proaktiva arbetet, jag säger inget annat, men i lönsamhetsorienterat säkerhetsarbete får dessa områden relativt sett låg prioritet – i princip.

Efter att ha tänkt ett varv till drog jag slutsatsen att det viktigaste proaktiva säkerhetsarbetet utförs i företagets förändringsprocesser, t ex i projektarbetet. Det är där som sårbarheter kan tas bort eller råkar läggas till. Det mera traditionella säkerhetsarbetet med skydd, kontinuitetshantering etc ska självklart också bedrivas, men om man inte är med aktivt som säkerhetsperson under förändringsarbetet riskerar man att ständigt få slösa sina dyrbara resurser på att reparera andras misstag. Men hur man åstadkommer en säker utvecklingsprocess är en annan diskussion som jag kanske tar upp i ett kommande blogginlägg.

Skam till sägandes prioriterar säkerhetsbranschernas aktörer fortfarande oftast rätt så tvärtom. Skydd mot externa attacker och kontinuitetshantering inför tekniska haverier ligger riktigt högt på topplistorna idag, skydd mot insiders bubblar upp då och då medan åtgärder för att förebygga slarv, okunnighet, ignorans mm ständigt tycks vara "någon annans problem". Det kan bero på att den typen av analys som jag gjorde inte görs regelbundet – jag har inte sett någon som upprepat min lilla studie – och med traditionella analyser når man traditionella resultat som pekar på traditionella lösningar. 

Spelar du någon roll?

Som konsult ser man ibland väsentliga brister hos kunderna. Det handlar sällan om tekniska eller administrativa brister; sådana har i regel inte gått så långt innan de upptäcks, och de kan ofta åtgärdas med enkla eller åtminstone lätt motiverade ändringar.

De riktigt allvarliga bristerna brukar orsakas av att medarbetare på olika nivåer är omedvetna, inte tar ansvar och/eller saknar i sammanhanget väsentliga förmågor. Sådana orsaker är både svårupptäckta och svåråtgärdade, särskilt om de finns högt upp i organisationen.

Otillräcklig medvetenhet och ansvarstagande - och kanske också förmåga - kan exempelvis orsakas av otydlighet i organisationens roller: innehåll, samband och gränssnitt.

I det lilla perspektivet handlar det om den enskilde medarbetaren. Organisationens väsentligaste skyldighet mot medarbetaren är att förklara varför han/hon behövs. Vem tar emot och har nytta av mitt arbete? Vilka krav har denne? Vad ska jag göra för att uppfylla kraven? Vilka tekniska, ekonomiska och administrativa resurser får jag disponera? Vad kan jag kräva för input från andra som gör det önskade resultatet av mitt arbete möjligt, både att genomföra och att förutse? Mot vem riktar jag mina krav?

Medarbetaren ingår normalt sett i en eller flera organisationer inom organisationen. Vem som är chefen definierar organisationsenheten. Arbetsuppgifterna kan ingå i en eller flera överordnade processer. Medarbetaren kan delta i ett eller flera projekt. I alla dessa olika sammanhang har medarbetaren roller, som är förknippade med ansvar och prestationskrav.

Men det är inte säkert att medarbetaren är medveten om alla sina roller, och därmed inte kan förväntas inse sitt ansvar och de tillhörande kraven. Och uppdragsgivaren (chefen, processägaren, projektledaren etc) kanske inte förvissat sig om att medarbetaren har kunskap och förmåga nog för uppdraget.

Är rollerna och deras innehåll, samband, tillhörighet och gränser tydliga i din organisation?

Vet alla medarbetare varför de behövs och vilket ansvar de har?

Hur är det för dig själv?

SKA – Säker Kund-Aktivitet

• Vilken säkerhetsnivå krävs när kunder vill utföra sina ärenden? 
• Hur uppfylls kraven på säkerhetsnivå när kunden väljer att utföra dessa aktiviteter via en viss ”kanal” från en viss plats (personligt möte, telefon, brev, dator eller mobil, skyddat eller öppet nätverk, i företagets lokaler, hemma, på internetcafé eller på annan plats)? 
• Vilka kompenserande kontroller kan göra att de krav som inte uppfylls "naturligt" av vald plats och ”kanal” ändå uppfylls till slut? 

För att svara på frågorna i den praktiska verkligheten brukar jag följa ett rätt enkelt koncept jag kallar SKA – Säker Kund-Aktivitet. Det innebär att

1. först fastställa vilka kundaktiviteter som ska/får förekomma och vad de ska/får resultera i 
2. därefter definiera de principiella kravnivåerna, kopplade till varje fastställd kundaktivitet - oavsett plats och "kanal" - för 
• autentisering och viljeyttring, 
• behörighetskontroll,
• sekretess, aktualitet, riktighet, fullständighet, spårbarhet, tillgänglighet etc.
3. slutligen avgöra huruvida kraven uppfylls – och kundaktiviteten får utföras – på de möjliga platserna och via de möjliga "kanalerna", eventuellt efter kompenserande kontroller. 

Typiskt beskrivs de två första stegen ovan för varje kundaktivitet av en rad i en tabell. Kravuppfyllnaden per plats och ”kanal” redovisas lämpligen i separata tabeller.

Kravnivåerna fastställs ungefär som vid ”vanlig” informationsklassificering, och stegen mellan nivåerna är i regel rätt långa. Skillnaden mot den ”vanliga” informationsklassificeringen är att startpunkten här inte är informationsresurserna och deras ”skyddsbehov” (det kan ibland uppfattas som ett rätt abstrakt angreppssätt) utan kundaktiviteterna och de konkreta konsekvenserna om de t ex utförs av fel person, inte ger avsett resultat eller inte alls kan utföras av någon anledning. Ju större konsekvenser de möjliga bristerna kan medföra desto starkare skydd behövs mot bristerna.

Som exempel kan SKA-synsättet innebära att en viss kundaktivitet får utföras om kundens identitet kan fastställas genom stark autentisering, naturligtvis under förutsättning att övriga krav också uppfylls. Vad som menas med stark autentisering i olika ”kanaler” får sedan fastställas per ”kanal” – det kan t ex betyda autentisering med e-legitimation på nätet och id-kontroll med hjälp av fysisk id-handling vid personligt möte.

Skulle det inte gå att uppnå tillräckligt hög säkerhetsnivå för en kundaktivitet från en viss plats via en ”kanal” – i exemplet kanske det inte går att utföra stark autentisering per telefon – får inte kundaktiviteten genomföras där, och alla förstår varför. Kunderna också.

En viktig finess är att säkerhetskraven kommer att vara relativt stabila över tiden medan säkerhetslösningarna – t ex autentiseringsmetoderna – måste tillåtas variera beroende på hotbildsförändringar och nya teknikval.

SKA utvidgas lätt till två andra i stort sett identiska koncept – SMA, Säker Medarbetar-Aktivitet och SPA, Säker Partner-Aktivitet – för att hantera aktiviteter som medarbetare och partners gör med företagets informationsresurser, både i företagets lokaler och utanför och via olika ”kanaler”. Dessa båda koncept används tillsammans med SKA för att säkerställa att säkerhetskraven både fastställs och uppfylls för alla aktiviteter som berör företagets informationsresurser – dvs vi får med SKA/SMA/SPA en operativt användbar metod att säkerställa att bara tillåtna aktiviteter utförda av behöriga förekommer i företagets informationsmiljö. Det är detsamma som att det totala skyddet för informationsresurserna är tillfredsställande.

Koncepten SKA, SMA och SPA skapar förutsättningar för att upprätthålla nödvändig och tillräcklig säkerhetsnivå i en komplex och föränderlig verklighet. Vi klarar att hålla staketet jämnhögt, helt enkelt.