Arbetet för en säkrare molntjänst: Identifieringen och förebyggandet av säkerhetsrisker

(1)

Institutionen för informatik

Examensarbete i Informatik

Kandidat - Systemvetenskap

Arbetet för en säkrare molntjänst

Identifieringen och förebyggandet av säkerhetsrisker

Författare: Johan Granberg &

Mattias Hansson

Handledare: Lars Magnusson Examinator: Niclas Eberhagen Termin: VT19

Kurskod: 2IK10E

(2)

Sammanfattning

Molntjänster blir allt mer populärt bland företag och organisationer att anamma. Tekniken har möjligheten att medföra många fördelar, dock kan det uppstå säkerhetsrisker med användningen. Hur ska företag kunna identifiera och skydda sig mot de potentiella säkerhetsrisker som då kan komma att uppstå?

Detta arbete har undersökt hur olika organisationer inom olika branscher arbetar mot att kunna säkra och hantera de potentiella säkerhetsrisker som kan uppstå. Detta har gjorts möjligt genom en kvalitativ undersökning i form av fyra intervjuer med IT- säkerhetsspecialister samt en litteraturstudie inom ämnet.

Genom intervjuerna så fick vi reda på hur de berörda organisationerna och företagen arbetar just med säkerheten kring sina system samt de molntjänster som de använder.

Med hjälp av litteraturstudien skapades en bakgrundsteori som sedan ställdes mot den analyserade empirin som insamlats från intervjuer. Detta tillsammans med en analys gav upphov till en diskussion där det stod klart att för att kunna identifiera diverse säkerhetsrisker så är OWASP Top 10 ett essentiellt dokument och verktyg för alla typer av företag och organisationer. För att kunna arbeta mot att förhindra dessa identifierade riskerna så konstaterades det, med flera andra saker, att ett större fokus bör ligga på de redan etablerade autentiserings- och auktoriseringsmodeller som används.

(3)

Summary

Cloud services are gaining more popularity amongst organizations and companies to embrace. This technology has the capacity to bring a lot of advantages but the use of it can also bring a certain amount of security risks. How should the companies and organizations be able to identify and protect themselves against these potential security risks?

This study has investigated how different organizations and companies within different industries work towards securing and dealing with the potential security risks. This has been made possible through a qualitative study in the form of four interviews with IT security specialists as well as a literature study on the subject of matter.

Through the interviews, we learned how the companies and organizations involved work with the security of their systems as well as their cloud services.

Through the literature study a background theory was created which was then compared with the analyzed empirical data collected from the interviews. This together with an analysis gave rise to a discussion where it was clear that in order to identify various security risks the OWASP Top 10 is an essential document for all companies and organizations. In order to work towards preventing these identified risks, it was clear that amongst several things a greater focus should be on the already established authentication and authorization models used.

(4)

Förord

Vi vill börja med att tacka vår handledare Lars Magnusson för all hjälp under detta arbete.

Sedan vill vi även visa vår tacksamhet till alla de informanter som har ställt upp på intervjuer och delat med sig av sina kompetenser.

(5)

Innehåll

1 Introduktion ______________________________________________ 5

1.1 Tidigare forskning ________________________________________________ 5 1.2 Problemformulering _______________________________________________ 7 1.3 Syfte och frågeställningar __________________________________________ 8 1.4 Avgränsning _____________________________________________________ 8 1.5 Målgrupp _______________________________________________________ 8 1.6 Disposition ______________________________________________________ 9 2 Teori ___________________________________________________ 10

2.1 Molntjänst _____________________________________________________ 10 2.1.1 Molntjänstens karaktäristika ____________________________________ 10 2.1.2 Implementeringsmodeller ______________________________________ 11 2.1.3 Servicemodeller _____________________________________________ 11 2.2 Molnsäkerhet ___________________________________________________ 12 2.2.1 Autentisering _______________________________________________ 12 2.2.2 Access control ______________________________________________ 13 2.2.3 OWASP Top 10 _____________________________________________ 14 3 Metod __________________________________________________ 15

3.1 Vetenskaplig ansats ______________________________________________ 15 3.2 Datainsamling __________________________________________________ 15 3.2.1 Sökstrategi _________________________________________________ 15 3.2.1 Urval ______________________________________________________ 16 3.2.2 Genomförande ______________________________________________ 17 3.3 Analys ________________________________________________________ 17 3.4 Tillförlitlighet __________________________________________________ 18 3.5 Etiska överväganden _____________________________________________ 18 4 Resultat _________________________________________________ 20

4.1 Informanter ____________________________________________________ 20 4.2 Empiri ________________________________________________________ 20 4.2 Analys ________________________________________________________ 26 5 Diskussion ______________________________________________ 28

5.1 Metodreflektion _________________________________________________ 31 5 Avslutning ______________________________________________ 32

6.1 Slutsats ________________________________________________________ 32 6.2 Förslag till fortsatt forskning _______________________________________ 32

(6)

Referenser _____________________________________________________i

Bilagor

Bilaga A – Intervjuguide

(7)

1 Introduktion

I detta kapitlet kommer det att genomgås en grundlig introduktion till detta arbete.

Introduktionen kommer att innehålla tidigare forskning inom ämnet, problemformulering och forskningsfrågor, avgränsningar, målgrupp och en dispositionsdel som redogör för hela uppsatsens upplägg.

Tekniken runt molntjänster och hur de fungerar har utvecklats hastigt de senaste åren. I och med detta innebär det att fler och fler företag och organisationer har valt att bedriva sina verksamheter, till och med erbjuda sina tjänster över någon typ av molntjänst. Enligt en prognos av Gartner (2018) så väntas den publika typen av molntjänster öka sin omsättning med 17,3%, dvs. en ökning från 175,8 miljarder dollar från år 2018 till 206,2 miljarder dollar år 2019. Då det kan vara mycket kostsamt att lagra all den producerade data lokalt hos företagen själva, så väljer fler och fler företag att avlasta sig själva genom att lagra den data hos leverantörer av molntjänster som erbjuder lagringsmöjligheter (Barsoum och Hasan 2012, 2375).

Molntjänster använder sig av en virtuell miljö för att kunna husera flera användare och virtuella maskiner innehåller i sig sårbarheter som kan visa sig vara ett hot för säkerheten av den lagrade data i molnet (Singh och Chatterjee 2017). Ett ytterligare element av molntjänster är datamigration över internet. Problemet med detta är att det finns många säkerhetsrisker med webbläsarens API samt i de olika kanaler av nätverk (Singh och Chatterjee 2017).

Då vi författare frekvent kommer i kontakt och använder oss av olika typer av molntjänster, t.ex. Instagram, Google Drive, Steam etc., samt att vi har läst en kurs om IT-säkerhet så fick vi en idé att skriva detta arbete om just IT-säkerhet av något slag. En första tanke var att belysa de olika säkerhetsrisker som specifikt kan uppstå i den publika typen av molntjänster.

Detta skulle sen mynna ut till att rendera i att istället belysa vad man ska göra för att undvika dessa orosmoment och säkerhetsrisker innan de uppstår.

1.1 Tidigare forskning

I sin masteruppsats så undersöker Okonoboh och Tekkali (2011) vilka vanliga typer av säkerhetsrisker som medföljer användning av molntjänster, vilka framtida krav för framtida forskning inom säkerhet hos molntjänster, givet den industriella och nuvarande trenden. Om vi ska se till det som är kopplat till det ämne vi avser att undersöka (säkerhetsrisker hos publika moln) så kommer de fram till att det huvudsakliga orosmomentet är hanteringen av känsliga data och applikationer till molnet, då denna känsliga data är delad med en tredjepartsaktör (Okonoboh och Tekkali 2011). Detta kommer att vara en av de aspekter som även kommer att hanteras i det arbete som vi kommer att genomföra.

Detta tidigare nämnda problem och riskområde gällande känsliga data och information går att läsa vidare om i Vepuri och Rahman (2011) masteruppsats. I denna förklarar de att av de olika molnmodellerna, dvs. privat-, publikt-, hybrid- och communitymoln så är det

(8)

publika molnet som främst ligger i riskzonen för attacker baserat på att den är den vanligaste och att flest människor och organisationer använder denna typ av modell.

Shaikh och Haider (2011) har i sin studie identifierat och studerat ett antal olika artiklar gällande säkerhet och integritet inom molntjänster. Molntjänster lider av stora säkerhetsrisker från användarnas perspektiv, och man nämner att avsaknaden av pålitlig säkerhet egentligen är den enda nackdelen med just molntjänster. Vidare säger man att en ömsesidig överenskommelse mellan tjänsteleverantörer och användare är av yttersta vikt för bättre säkerhet i molntjänster. Användare av molntjänster är rädda för dataförlust och integriteten. Man har vidare identifierat de följande områdena som de största hoten mot säkerheten. Dataförlust, dataläckage, kunders tilltro, användarautentisering, uppsåtlig användarhantering, felanvändning av molntjänster och dess tjänster, samt kapning av sessioner vid dataåtkomst (Shaikh och Haider 2011).

Singh, Jeung och Park (2016) föreslår i sin studie en säkerhetsarkitektur bestående av tre stycken nivåer där säkerheten är beroende av varandra. Den föreslagna säkerhetsklassifikationen som de har tagit fram består av application level, service middleware level och infrastructure level.

Application level är den högsta nivån och levererar den utlagda mjukvaran direkt till klienten. Kunderna behöver inte spendera pengar på att installera mjukvara, utan betalar bara för användandet. På den här nivån så behöver man säkra data från början till slut.

Gemensam säkerhet behövs för att uppnå synlighet, kontroll över data, identiteter och applikation i molntjänster från början till slut.

Service middleware level kan beskrivas som klistret som gör det lättare för mjukvaruutvecklare att kommunicera i molntjänstmiljön. Då vikten av mellanprogram ökar, så ökar också säkerhetsutmaningarna. För att säkra den här nivån så bör man utveckla ett bra autentiseringsschema mellan mellanprogram och användare, förbättra datadelningssäkerhet, samt förbättra spamhantering.

Infrastructure level kan hantera datorkapacitet såsom bandbredd, prestanda och lagringstillträde. Molninfrastruktur abstraherar hårdvaran (virtuella maskiner, server, nätverkskomponenter och lagringssystem) för datoranvändning. Man pratar om att en effektiv och säker autentiseringsprocess och användarabstraktion ska finnas på den här nivån.

Avslutningsvis så nämner de att även om molntjänster har väldigt många fördelar, så är molnet fortfarande sårbart och möter flera säkerhetsutmaningar. Det är därför säkerhet är den stora utmaningen vad gäller anpassning till molntjänster (Singh, Jeung och Park 2016).

Hawedi, Talhi och Boucheneb (2018) tar i sin artikel upp att molntjänstleverantörer inte tar hänsyn till olika variationer för användares behov, då de förser samma säkerhetsmekanism för alla typer av användare. De tar upp ett flexibelt, on-demand och skalbart system som

(9)

kallas för multi-tenant-intrusion detection som är designat för att leverera lämplig och optimerad säkerhet, som tar användarnas behov gällande säkerhetskrav och budget i beaktning.

Knapp, Denney och Barner (2011) skriver i sin studie om nyckelproblem med säkerheten för datacenter. Man tar bland annat upp att man inte bara behöver skydda datacenter mot illvilliga attacker från människor, utan också från misstag och olika typer av naturkatastrofer. Med det ökade samhälleliga beroendet av internetbaserade molntjänster för datalagring och bearbetning har säkerheten för datacenter blivit av största vikt för myndigheter och den informationstekniska industrin (Knapp, Denney och Barner 2011).

General Data Protection Regulation, eller GDPR som det förkortas, färdigställdes år 2016 och tippas vara en av de största omskakanden inom dataintegritet sedan skapandet av internet. GDPR är ett förhållningssätt som alla de 28 medlemsländer i EU måste anamma när det gäller skyddandet och användningen av persondata och information av företag (Meinert 2018). GDPR är en reglering som ger användarna mer kontroll över persondata (Shah 2018). Sedan införandet av regleringen så har invånare i EU-länder rätten att veta hur persondata lagras samt att de även har möjligheten att bli “glömda”, genom att be de företag som har sparat respektives persondata att ta bort den (Shah 2018). Alla dessa regleringar har även bidragit till att organisationer och företag som sparar personinformation och data måste be om tillåtelse om att få samla in och spara denna informationen eller data.

En insiderattack innebär ofta att det stjäls känslig information eller data vilket i sig innebär att datakonfidentialitet eller dataintegritet äventyras, där motiven bakom attacken kan vara finansiella (Mohd Yusop och Abawajy 2014).

När ett system äventyras så är den allmänna uppfattningen att hotet kommer utifrån, det vill säga att någon försöker hacka sig in i systemet för att komma åt det som finns på insidan.

Allt för ofta så visar det sig att gärningsmannen redan finns på insidan och litas på av organisationen eller företaget (Duncan, Creese och Goldsmith 2015). En insiderattack är när en person som har förtroendet samt tillgång till företaget genomför någon typ av attack.

Duncan, Creese och Goldsmith (2015) förklarar att denna typ av attack kan vara ännu mer farlig än en attack från utsidan, detta för att det är mycket svårare att upptäcka och sedermera spåra en sådan attack. Den som utför insiderattacken vet bästa tidpunkt för attacken, vet vart all den känsliga informationen och data är lokaliserad samt vet hur man kommer ut utan att bli upptäckt. Personen behöver i princip inte genomföra en attack för att komma åt det den vill ha, den har redan givits tillgång (Duncan, Creese och Goldsmith 2015).

1.2 Problemformulering

Det finns en del tidigare forskning om just molntjänster och säkerhetsrisker, detta är ett nytt och spännande ämne som hela tiden förändras och förnyas. Den tidigare forskning som finns är just anpassat efter säkerhetsrisker hos molntjänster som en helhet men inte specifikt hos det publika molnet, vilket även är den vanligaste modellen av moln som används av företag (Chou 2015). Detta har gjort att det finns en kunskapslucka att fylla inom detta.

(10)

Man skulle kunna lägga till GDPR-aspekten i vårt arbete då det är ännu en mycket viktig komponent i hantering av persondata och säkerhet, dock är lagen om GDPR så pass ny och därför finns det inte mycket publikationer om GDPR och det publika molnet. Detta har gjort att vi har valt att inte lägga något större fokus på denna aspekt i detta arbete. Skulle man vilja fortsätta med forskningen om hur GDPR kommer påverka arbetet mot att hitta och lösa olika säkerhetsrisker är detta något som skulle fungera bra om det finns en önskan för det längre fram.

1.3 Syfte och frågeställningar

Vi författare ämnar genomföra en beskrivande undersökning med syftet att kunna skapa en större insikt om hur man kan upptäcka potentiella säkerhetsrisker som finns med publika moln, samt hur man ska kunna arbeta i ett förebyggande syfte mot dessa.

Baserat på den tidigare forskning som har studerats samt den problemformulering som har tagits fram så har dessa två frågeställningar utarbetats:

Hur kan man identifiera potentiella säkerhetsrisker i det publika molnet?

Hur arbetar man för att kunna minimera dessa identifierade risker?

1.4 Avgränsning

Denna studie avser att belysa den publika typen av molntjänst. Alltså avgränsas den från de privata-, hybrida- samt community typerna av molntjänster. Anledningen till denna huvudsakliga avgränsningen är att vi som författare mest kommer i kontakt med det publika molnet i form av sociala medier, diverse spelbibliotek, samt att publika moln är de som är mest utsatta. Detta var det som initialt gav oss en undran till hur säkerheten fungerar samt hur man kan jobba proaktivt mot säkerhetsrisker. Själva arbetet i sig, samt arbetsbelastningen på oss författare hade blivit för stor om denna avgränsning inte hade gjorts.

Det kommer även att enbart ligga ett fokus på röster från personer med erfarenhet inom IT- säkerhet och då i synnerhet säkerhet inom molntjänster från diverse verksamheter och organisationer. Detta är något som går i tandem med den målgrupp som studien avser att intressera.

1.5 Målgrupp

Den huvudsakliga målgruppen är de som frekvent kommer i kontakt med IT-säkerhet, i synnerhet säkerheten på webbaserade applikationer såsom publika molntjänster. Detta innebär att målgruppen i fråga främst är säkerhetsansvariga, utbildare, samt personal som rör sig inom IT-miljön på företag.

Vi ser dock gärna att även de som inte jobbar specifikt med IT-säkerhet, utan de som har ett generellt intresse om detta, läser arbetet då IT-säkerhet i dagsläget är ett ämne det finns en stor nytta av att ha kunskap inom.

(11)

1.6 Disposition

I kapitel två kommer konceptet molntjänst att förklaras med tillhörande centrala begrepp för att få en god förståelse om ämnet som kommer att belysas i arbetet. Detta kapitel kommer att agera som startsträcka för kommande kapitel.

I kapitel tre kommer själva arbetsgången att förklaras för att få en inblick i hur arbetet har genomförts. Detta innebär att datainsamlingsmetoden kommer att argumenteras för, vilken typ av vetenskaplig ansats som anammats för detta arbete, samt vilken analys som har gjorts på det insamlade materialet.

I kapitel fyra kommer resultatet att läggas fram med sin tillhörande analys. Detta innebär att den empirin som har samlats in sammanställts och analyserats.

I kapitel fem kommer resultatet att diskuteras. Där kommer även en diskussion för metodval att göras samt reflektioner om arbetet som helhet.

I kapitel sex, tillika det sista kapitlet, så kommer slutsatsen att dras. Med detta menas att frågeställningarna kort kommer att besvaras i mån av det som arbetet tagit fram. Det kommer även vara ett underkapitel om förslag till vidare forskning inom detta ämne.

(12)

2 Teori

I detta kapitlet kommer molntjänster som en helhet att redovisas för, även de säkerhetsmekanismer och verktyg som används för de specifika delarna av molntjänster som ligger i fokus i detta arbete.

Trots att molntjänster och dess säkerhet är ett såpass nytt ämne inom data och IT-sfären så finns det stora mängder forskning om detta. Det vi har valt att fokusera på är den aspekt kring säkerhet.

För att initialt sätta sig in i ämnet så började vi med att titta på de litterära resurser som berör just ämnet molntjänster och säkerhet.

2.1 Molntjänst

För att förstå ämnet så kan man börja med att titta på hur National Institute of Standards and Technology (NIST) definierar begreppet cloud computing. Mell och Grance (2011) menar att NIST definierar cloud computing som en modell för att möjliggöra vanligt förekommande, bekväm, on-demand nätverksaccess till en delad pool av konfigurerbara datorresurser (t.ex. nätverk, servrar, lagring, applikationer och tjänster) som snabbt kan bli distribuerad och släppt med minimal förvaltning eller interaktion från tjänsteleverantören.

Denna definition delas och beskrivs även som den mest kompletta definition av övriga författare av artiklar som vi har läst.

2.1.1 Molntjänstens karaktäristika

Mell och Grance (2011) förklarar att det finns fem olika karaktäristiska drag i molntjänster, som även nämns i stycket ovan. De beskriver dessa karaktäristika som följande:

On-demand self service innebär att en användare ensidigt kan tillhandahålla möjligheter att kunna utnyttja och utöka användning av en server samt lagringsmöjligheter, utan att behöva interagera med leverantören av molntjänsten.

Broad network access innebär att molntjänsten och dess möjligheter är tillgängliga över nätverk och nås via standardiserade mekanismer vilket främjar användandet av olika typer av plattformar, t.ex. mobiltelefoner, surfplattor och datorer.

Resource pooling innebär att leverantörens resurser för hård- och mjukvara är samlad för att kunna leverera till, och tjäna flera användare på en och samma gång, där olika typer av fysiska och virtuella resurser är dynamiskt utdelade beroende på kundernas behov. Exempel på resurser i detta fall är lagring, processering, minne och nätverksbandbredd.

Rapid elasticity innebär att förmågor elastiskt kan tillhandahållas, i vissa fall automatiskt, för att snabbt vara skalbart och möta efterfrågan. För kunden kan förmågorna ofta uppfattas som oändliga och kan disponeras i vilken mängd som helst, vilken tidpunkt som helst.

Measured service innebär att molntjänster automatiskt kan optimera och kontrollera användningen av resurser genom att kunna använda en kapacitet för mätning på någon typ av abstraktionsnivå rimlig för den typ av tjänst som används (t.ex. lagring, processering, bandbredd etc.). Användandet av resurser kan övervakas, kontrolleras samt rapporteras.

Detta förser både leverantören och kunden en transparens gällande den använda tjänsten.

(13)

2.1.2 Implementeringsmodeller

Enligt den definition som NIST (National Institute of Standards and Technology) tar fram så kan man enligt Chou (2015) dela upp molntjänster i fyra olika modeller och mönster;

Privata-, publika-, community- samt hybridmoln. Chou (2015) beskriver dessa modeller som så:

Private cloud opereras enbart för en organisation som inte delar hårdvara eller infrastruktur med andra företag. Ett private cloud förser interna tjänster till dess organisation genom ett av företagets kontrollerade intranät eller datacenter. Denna typ av moln kan erbjuda behövlig feltolerans och säkerhet som företaget efterfrågat.

Public cloud är det som de flesta organisationer har adopterat när det gäller användning av moln. Ett public clouds tjänsteleverantörer (ex. Amazon eller Google) erbjuder deras infrastrukturer för alla olika typer av organisationer där en self-service, on-demand och pay- per-use ligger som grund för användningen. Infrastrukturen för ett public cloud ligger inom leverantören av molnet.

Community cloud är format av delade bekymmer såsom mission, säkerhetskrav, policys samt överväganden av överensstämmelser. Ett community cloud kan skapas och opereras av en enstaka eller flertalet organisationer i ett community, lokaliserat i eller utanför organisationen.

Hybrid cloud är den sista typen av molntjänst. Denna tjänst kombinerar en mängd olika molninfrastrukturer för att kunna uppfylla det specifika behovet. Det är en blandning av public-, private- och community cloud.

2.1.3 Servicemodeller

Molntjänster innehåller tre olika servicemodeller. Chou (2015) listar och förklarar dessa som så:

Software as a service (SaaS) är en populär typ av molntjänst som ger kunderna möjligheten att kunna ansluta till leverantörens eller organisationens applikationer och tjänster genom ett gränssnitt eller en webbläsare. Detta gör att kunderna inte behöver installera någon typ av infrastruktur (t.ex. nätverk, servrar, operativsystem etc.) till sin egna verksamhet. Dessa applikationer och tjänster initieras och körs via leverantörens infrastruktur.

Platform as a service (PaaS) är en modell som tillgodoser organisationers behov genom att husera hela plattformen och infrastrukturen (nätverk, servrar och operativsystem etc.) samt lösningar för kundens sida. PaaS tillåter dock kunderna att kontrollera applikationens mjukvara samt gränssnittet.

Infrastructure as a service (IaaS) ger kunder möjligheter till processering, lagring, nätverk samt andra typer av resurser så att de kan köra selektiva program (operativsystem, mjukvara etc.). Nackdelen med denna modell är att leverantören av molntjänsten sköter om den infrastruktur som används.

Med detta definierat så uppdagas det att det finns vissa ofta förekommande problem- och riskområden med molntjänster överlag som organisationer bör se över. Ahmed och Zolkipli (2016) nämner dessa områden; Data access control, Privacy, Reliability, Legal issues samt Open standard. Det är många fler författare som i sina studier beskriver just dessa områden som risk- och problemområden.

(14)

2.2 Molnsäkerhet

Då mer och mer känsliga data och fler applikationer flyttar över till diverse molntjänster samt körs via virtuella datorresurser, så för detta med sig både grip- och icke gripbara säkerhetsutmaningar (Sun et al. 2011).

Då detta arbete fokuserar mycket på aspekterna kring säkerhet, integritet och förtroende i säkerheten så kommer här nedan en definition på dessa enligt Robinson et al. (2011):

Säkerhet avser konfidentialitet, tillgängligheten samt integriteten av data eller information.

Säkerhet kan även inkludera autentisering och oförnekbarhet.

Integritet avser följandet av diverse juridiska och icke-juridiska normer. I en europeisk kontext så handlar detta ofta om att följa de europeiska dataskyddslagar som finns (i dagsläget GDPR). Även om det skulle vara mycket komplext att kartlägga alla problem med molntjänster som i den stora helheten gällande integritet och skyddsåtgärder för persondata.

Det finns dock globalt accepterade principer för integritet som ger ett användbart ramverk:

samtycke, ändamålsenlig restriktion, legitimitet, transparens, datasäkerhet och deltagande av dataobjekt.

Förtroende handlar om försäkran om att entiteter, data, processer etc. kommer att bete sig på förväntat sätt. Förtroende kan ha många skepnader, t.ex. människa till människa, maskin till maskin, människa till maskin. På en djupare nivå kan förtroende tolkas som en konsekvens av framsteg mot säkerhets- eller integritetsmål.

2.2.1 Autentisering

Autentisering är den process vilket ett system verifierar att en användare är den som den avser sig att vara (Salah et al. 2013). I de flesta fall så uppmanas användaren att mata in sina användaruppgifter som sedan undersöks och verifierar användarens identitet (Salah et al.

2013). Det finns olika typer av användaruppgifter som kan användas för att autentisera och verifiera en användares identitet t.ex. användarnamn och lösenord, certifikat, biometri (t.ex.

fingeravtryck). (Salah et al. 2013).

Single Sign-on

I sin artikel om säkerhetsrisker inom molntjänster så beskriver Zissis och Lekkas (2012) att konfidentialitet inom data i molnet är i korrelation med användarautentisering.

Eftersom molntjänster blir allt vanligare att använda som operativsystem så behöver varje tjänst och service behöva någon typ av säker process för autentisering och auktorisering (Zissis och Lekkas 2012). Då den konceptuella gränsen mellan organisationens egna tjänst och den tjänst som är outsourcad blir mer och mer suddig, är behovet att implementera en typ av Single-Sign-On process (SSO) nödvändigt (Zissis och Lekkas 2012). SSO är en autentiseringsprocess där användaren autentiseras en gång och får sedan tillgång till flera olika resurser (Revar och Bhavsar 2011). Meningen med SSO är att minska antalet inloggningar och lösenord i en heterogen miljö.

OpenID

Som Zhao et al. (2015) förklarar så är OpenID en typ av Cross-domain single sign-on och fungerar som en decentraliserad SSO-mekanism. Det fungerar som så att varje användare har en unik URL som sin identifierare. När en användare vill få tillgång till en tjänst eller

(15)

service så måste denna bevisa sitt ägarskap till denna URL:en innan tjänsteleverantören kan acceptera förfrågan från användaren.

Genom att använda OpenID så kan tjänsteleverantörer acceptera identiteter som kommer från andra domäner, men det är begränsat till enbart OpenID i detta fall (Zhao et al. 2015).

Shibboleth

Shibboleth är ett federerat hanteringssystem för identiteter baserat på Security Assertion Markup Language (SAML) (Zhao et al. 2015). Leverantörerna av identiteter (IDP, identity providers) som använder sig av denna mekanism använder SAML för att skicka användarnas identiteter till tjänsteleverantörerna.

OAuth

Enligt Zhao et al. (2015) så är OAuth (Open Authorization) ett öppet protokoll om autentisering. OAuth gör så att en användare ger tillåtelse till en tredjepartsapplikation att ha oändlig tillgång till användarens resurser som finns på en annan webbserver, allt detta utan att avslöja eller fråga om användarens lösenord eller annan känslig information (Pai et al. 2011). För att förstå hur OAuths protokoll fungerar i sin helhet så är det viktigt att förstå de olika roller som är involverade i en körning av dess protokoll. Pai et al. (2011) beskriver dessa som sådan:

Resursägaren är en entitet som har makten att tillåta andra att ha tillgång till den data och de resurser som man äger. I de flesta fall är detta slutanvändaren.

Resursserver är en entitet som är värd för de skyddade resurserna som ägs av resursägaren.

Entiteten har möjligheten att svara på de förfrågningar som görs för att komma åt resurserna genom att använda så kallade access tokens.

Klienten är en applikation som har möjligheten att göra själva förfrågningarna om resurser till resursservern på uppdrag av resursägaren efter att ha fått auktorisering om detta.

Auktoriseringsserver är den server som utfärdar de tidigare nämnda access tokens till klienten efter en lyckad autentisering av resursägaren och erhållit dess data eller resurs.

2.2.2 Access control

Molntjänster är idag ansedda som en av de mest dominanta paradigmerna inom IT-industrin (Younis, Kifayat och Merabti 2014). Med alla de olika tjänster och typer av service som det kan erbjuda, så finns det fortfarande ett antal utmaningar associerade med att använda någon typ av molntjänst, så som datasäkerhet, misskötande av molntjänster, insider- och cyberattacker. Younis, Kifayat och Merabti (2014) menar då att access control är ett av de mest fundamentala säkerhetskraven.

Enligt Younis, Kifayat och Merabti (2014) så är det fundamentala målet med ett access control system att begränsa användare till enbart det som de är tillåtna att göra, just för att skydda information och data från icke auktoriserad access.

Det finns flertalet olika typer av access control systems, Younis, Kifyat och Merabti (2014) listar upp några av dessa och förklarar grunderna med dem så här:

(16)

Mandatory access control (MAC) är en typ av access control där en central auktoritet har befogenhet att ge möjligheter till tillgång för objekt som skickar en förfrågan om detta. För att kunna säkra tillgången till den data som flödar mellan två objekt så tilldelar MAC varje objekt och subjekt en access class. En access class är en säkerhetsnivå som används för att säkra flödet av information och data mellan objekt och subjekt. Object classification som objekten får är säkerhetsetiketter som används för att klassificera objekten baserat på hur känslig information eller data som de innehåller. Subject clearances är den säkerhetsnivå som används för att reflektera den trovärdighet som subjekten har.

Discretionary access control (DAC) är en modell som tillåter ägarna av objekten som skickas möjligheten att begränsa tillgången till deras objekt eller den data och information som objekten innehåller baserat på användarens identitet eller vilka medlemskap till vissa grupper denna användare besitter. Denna typ av modell är generellt sett inte lika säker som MAC, vilket bidrar till att modellen används i miljöer som inte hanterar och skickar för känslig information.

Role based access control (RBAC) anses vara det mest naturliga sättet att kontrollera tillgång till diverse resurser inom organisationer och företag. I denna modellen så kan ett subjekt ha mer än en enstaka roll samt vara medlem i flera grupper samtidigt. De ger exemplet att en anställd på ett företag kan både ha rollen som sekreterare samt “vanligt”

anställd.

Attribute based access control (ABAC) förlitar sig på en samling attribut som är associerade med det objekt som gör en förfrågan eller någon typ av resurs som ska nås för att kunna ta några beslut. Det finns flera olika sätt att definiera dessa attribut som används för denna modell. Attributen kan t.ex. vara en användares anställningsdatum, position, en roll eller en samling av flera olika attribut. Efter att dessa attribut har definierats så anses de vara diskreta värden som sedan jämförs med olika policys, för att det sedan tas ett beslut om de är godkända för tillgång.

Risk-Based access control (RBAC) föreslogs att användas för att klara av multinationella organisationer som i mångt och mycket möts och styrs av av olika typer av regulationer och policys. Modellen försöker använda olika typer av risknivåer i symbios med diverse miljöförhållanden samt använda sig av principen operativt behov för att kunna ta beslut angående tillgång.

2.2.3 OWASP Top 10

Enligt deras egna hemsida så beskrivs OWASP (Open Web Application Security Project) Top 10 som en icke vinstdrivande välgörande organisation som fokuserar på att förbättra säkerheten hos mjukvara. De beskriver att deras mål är att göra mjukvarusäkerhet synligt så att organisationer kan ta informerade beslut. OWASP säger sig själva sitta i en unik position där de kan förse med opartisk och praktisk information om AppSec, vilket är en årlig IT- säkerhetskonferens, till individer, organisationer och liknande (OWASP, 2017). OWASP Top 10 är ett så kallat “medvetenhetsdokument” för säkerhet inom webbapplikation.

Dokumentet representerar en bred konsensus om vilka de tio mest kritiska säkerhetsriskerna är. Organisationen OWASP uppmanar alla olika typer av företag och organisationer att anamma detta dokument och sedermera starta processen mot att kunna säkra deras webbapplikationer och molntjänster för att kunna minimera dessa risker (OWASP, 2017).

(17)

3 Metod

I detta kapitel så redovisas de undersökningsmetoder som använts för att genomföra detta arbete. Det motiveras även för val av undersökningsmetoder.

3.1 Vetenskaplig ansats

Vi valde till det här arbetet att genomföra en kvalitativ undersökning. De främsta orsakerna till vårt val av metod var att vi ville få fram mer djupgående information. En kvalitativ undersökning genomfördes alltså för att skapa oss en djupare kunskap om ämnet, och få in empiri från olika kompetenta informanter för att kunna besvara våra frågeställning.

3.2 Datainsamling

Arbetet inleddes med att genomföra en litteraturstudie där vi valde ut och läste igenom olika publikationer för att skapa oss en djupare förståelse och kunskap inom ämnet. För insamlingen av empiri så valde vi att genomföra intervjuer, där den litteraturstudie och bakgrundsteori vi genomförde var till stor hjälp för att kunna utforma intervjufrågorna. Vi valde att använda oss av en semistrukturerad intervjuteknik där samma utvalda huvudfrågor ställdes till samtliga informanter för att skapa ett bra bedömningsunderlag, samtidigt som det gav oss möjligheten att ställa vissa följdfrågor till de olika informanterna beroende på deras svar på frågorna.

Vi övervägde till en början att också formulera och skicka ut enkäter, men valde bort det då vi ville få en djupare förståelse för hur man kan jobba förebyggande med de säkerhetsrisker som finns i det publika molnet, vilket intervjuer med kompetenta informanter ger oss. En enkätundersökning hade kunnat gett oss en större bredd, men inte någon möjlighet till att gå in närmre på alla de olika svaren.

3.2.1 Sökstrategi

Som nämnts tidigare i arbetet så finns det större mängder forskning och vetenskapliga artiklar om molntjänster och tillhörande teknik. För att kunna ta del av denna så använde vi oss primärt av OneSearch. OneSearch är en söktjänst som används av olika universitetsbibliotek för gemensam sökning i ämnesdatabaser och bibliotekens egna kataloger. Vi använde oss specifikt av universitetsbiblioteket på Linnéuniversitetets OneSearch vilket gjorde att vi, med hjälp av våra studentkonton, fick tillgång till vetenskapliga artiklar som vi annars inte kunde få tillgång till. Vi använda oss även av Google Scholar tidigt in i arbetet. Dock hade vi svårt att avgöra om de artiklar vi sökte efter var peer reviewed eller inte, vilket inte tydligt framgår i sökningar i Google Scholar. Vi använde oss av både svenska och engelska söktermer för att alternera och se vad som gav bäst resultat. De resultat vi fick med hjälp av våra sökningar gav oss ett stort utbud, ett utbud som inte alltid gav det resultat vi ville komma åt. Alla sökträffar hade huvudämnet molntjänster men inte alla innehöll det som vi var ute efter. De sökträffar som stämde överens med vårt önskade resultat gav oss en indikation på att vårt arbete kan styrkas.

Majoriteten av de resultat som framkom handlade ej om det förebyggande arbetet kring

(18)

säkerhetsrisker, utan de handlade till stora delar om att antingen lista upp vilka olika typer av säkerhetsrisker som finns, alternativt olika framtaganden av säkerhetsalgoritmer.

Här nedan i tabell 1 presenteras de mest frekventa söktermerna vi använde oss samt dess närliggande synonymer som även använts för att få fram sökresultaten.

Sökord cloud

computing

access control

authentication security insider attacks Synonymer och

närliggande söktermer

cloud systems

authorization OpenID security system

internal threats cloud auktorisering OAuth cloud

security molntjänst autentisering molnsäkerhet

moln säkerhet

Tabell 1 – Söktermer från litteratursökningen

3.2.1 Urval

Jacobsen (2002) redogör för tre olika steg i den process som bör genomföras vid urval av informanter till intervjuer. I det första steget skaffade vi oss en överblick över alla företag och personer som vi ville undersöka oberoende av tid, pengar och analysmöjligheter. Vi gjorde enligt detta steget en lista på alla möjliga informanter från både tjänsteleverantörer av molntjänster, samt vilka som använder dessa levererade molntjänster. Detta genomfördes för att få en så bred grund som möjligt tidigt över potentiella informanter. I steg två så redogör Jacobsen (2002) för en indelning av populationen i undergrupper med indelningsvariabler så som kön, civil status och studieinriktning. Då det enda egentliga kriteriet informanterna skulle uppfylla var hur säkerheten kring molntjänster ser ut och fungerar så var många av dessa indelningsvariabler som ålder och kön ej intressanta och relevanta för våra frågeställningar och togs därför inte i beaktning. I det tredje och sista steget så ska man välja ut kriterier för urval av respondenter och informanter (Jacobsen 2002). Vi valde här att använda oss av ett informationsurval.

De fyra olika informanterna valdes ut med hjälp av ett informationsurval. Jacobsen (2002) säger att informationsurval används när man vet att uppgiftslämnare kan ge oss riklig och god information, samt att man vet att de är villiga att lämna information. Då alla dessa informanter är verksamma inom området för säkerhet kring molntjänster visste vi att informationen skulle vara bra och nyanserad. Tack vare tidigare etablerad kontakt och stöd

(19)

från handledare som bistod med kontaktuppgifter visste vi att informanterna var villiga att dela med sig av information.

3.2.2 Genomförande

Den litteraturstudie som vi genomförde i ett tidigt stadie under arbetsprocessen för att orientera oss inom ämnesområdet och skaffa oss mer kunskap om molntjänster och dess olika säkerhetsrisker, utgör till stora delar grunden för de intervjufrågorna som vi formade och valde att gå vidare med. Genom att analysera tidigare publikationer hittade vi olika säkerhetsaspekter som vi kände var relevanta och intressanta att undersöka närmare och mer på djupet genom intervjuer med kompetenta informanter som kunde ge oss nyanserade svar.

Litteraturstudien ligger också till grund för teorikapitlet, som är en bakgrundsteori där det redogörs vad en molntjänst är, vad det finns för olika servicemodeller och implementeringsmodeller etc.

Som nämnt under avsnittet för datainsamling så använde vi oss av en semistrukturerad intervjuteknik, där vi utgick från ett antal huvudfrågor som alla informanter fick besvara.

Beroende på informanternas svar så ställdes sedan lite olika följdfrågor, men huvudfrågorna gav oss ett likvärdigt bedömningsunderlag från samtliga informanter som gjorde det möjligt att ställa upp intervjuerna mot varandra i tabeller för att få en överskådlig bild över likheterna och olikheterna i svaren.

För att dokumentera intervjuerna så förde vi rikliga anteckningar under samtalets gång. Vi valde att inte spela in våra intervjuer då transkriberingen av materialet tar väldigt många timmar, samt att vi inte riktigt kände att det var nödvändigt. För vissa frågor där vi kände att anteckningarna inte riktigt besvarade det vi var ute efter så har vi istället kompletterat genom att ställa om frågan via mail och fått tillbaka ett skriftligt förtydligande.

Av de fyra intervjuer vi genomförde så skedde två av dessa på plats hos informanternas respektive arbetsplats, en via skypesamtal då det var praktiskt omöjligt att träffas på grund av avståndet, och en hemma hos en av författarna på informantens egna begäran.

3.3 Analys

Under intervjuernas gång så registrerade vi noggrant den data vi samlade in genom att föra rikliga anteckningar just för att få en så detaljerad beskrivning som möjligt. (Geertz, refererad i Jacobsen 2002) säger att detta brukar kallas tjocka beskrivningar, rika på detaljer, analyser och variationer. Efter de avslutade intervjuerna så har vi renskrivit, och kommenterat de enskilda intervjuerna, för att sedan annotera dessa. Detta görs för att göra om datan till en översiktligare och mer lättillgänglig massa (Jacobsen 2002). När detta var genomfört så gjorde vi en kategorisering av datan. Detta gjordes genom att samla data till olika grupper för att kunna jämföra de olika intervjuerna med varandra. När kategorierna blivit upprättade så satte vi in den enskilda datan från de genomförda intervjuerna i dessa.

Man tar data från en kontext och flyttar det till en annan. Jacobsen (2002) säger att vi genom

(20)

denna koppling jämför olika enheters utsagor om ett och samma fenomen (kategori).

Slutligen så kopplade vi samman datan, och tolkade den för att se vilka olika samband som fanns.

3.4 Tillförlitlighet

Enligt Jacobsen (2002) så måste den empiri man samlar in vara giltig och relevant, det vill säga valid, samt att den måste vara tillförlitlig och trovärdig, det vill säga reliabel.

Med giltighet och relevans så menar Jacobsen (2002) att det vi de facto mäter är det som vi tror oss mäta. Frågan man får ställa sig då är om den data man samlar in är relevant till ämnet man avser att undersöka. Det man mäter hos några få ska kunna generaliseras och också gälla för flera.

Jacobsen (2002) delar upp giltighet och relevans i två kategorier; intern giltighet och relevans samt extern giltighet och relevans.

Intern giltighet och relevans handlar om det tidigare nämnda, det vill säga om man faktiskt mäter det man tror att man mäter.

Extern giltighet och relevans handlar om resultatet från en datainsamling inom ett begränsat område är giltigt i andra sammanhang. Detta är en indikator på

generaliserbarheten av den insamlade data.

Gällande den data som samlades in för detta arbete så stärks giltigheten då det enbart har genomförts litteraturstudier på vetenskapligt granskade (peer reviewed) artiklar där redan generaliserade data är insamlad. Genom att intervjua personer med snarlika befattning men inom olika branscher så stärker även detta generaliserbarheten av den data som samlats in.

Med tillförlitlighet och trovärdighet så menar Jacobsen (2002) att den undersökning man gör går att lita på. Det får med andra ord inte uppstå några uppenbara mätfel i

datainsamlingen och i resultatet. Ett exempel som Jacobsen (2002) tar upp är att om vi skulle gjort en exakt likadan undersökning, skulle vi fått samma resultat?

Ser vi till den undersökning som genomförts för denna uppsats så stärks reliabiliteten tack vare de intervjuer som genomförts har genomförts med informanter med viktiga positioner på respektive företag. En av oss författare satt och hade hand om intervjun medan den andra antecknade de viktigaste bitarna, på rekommendation från informanterna själva.

De artiklar som använts har valts specifikt ut tack vare att de är vetenskapligt granskade och ger arbetet sedermera en större reliabilitet.

3.5 Etiska överväganden

Som Jacobsen (2002) förklarar att en undersökning i regel innebär att undersökaren bryter sig in i enskilda individens privata sfär. Den grundläggande förutsättningen för en undersökning av något slag är att den som undersöks går med på detta av fri vilja, samt att den som undersöks är medveten om vilka risker och vinster en undersökning kan medföra (Jacobsen 2002).

(21)

Jacobsen (2002) lyfter även vikten av att veta hur känslig den insamlade data är genom att man alltid måste tänka efter hur viktig den data är för den som man samlar in den ifrån.

Gällande de intervjuer och de undersökningar som gjorts för denna uppsats så har alla informanter frivilligt deltagit i intervjuer. Vi har även tagit ställning till att inte ställa frågor som inkräktar på det personliga planet, inga frågor som kan äventyra varken informanternas privat- eller arbetsliv. Det har även tagits ett beslut om att hålla informanternas identiteter anonyma av respektfulla skäl. De hänvisas till som t.ex. Informant A - B eller C etc.

(22)

4 Resultat

I detta kapitel kommer den insamlade empirin att redovisas för. Kapitlet inleds med en kortare presentation av de informanter som ställt upp på intervjuer. Sedermera presenteras den insamlade empirin i form av tabeller.

4.1 Informanter

Informant A har en doktorsexamen i Information Systems Science. Informantens forskningsintressen inkluderar bland annat information och cybersäkerhet, utvecklingsprocesser, affärsmodeller, tillgängligheten på system och organisationsnivå, samt modellering och tillämpad simulering i industriella utvecklingsprocesser. Innan sin akademiska karriär har informanten en femton år lång arbetslivserfarenhet inom både ledning och olika positioner som specialist med produkter, service, process och affärsutveckling.

Informant B har en kandidatexamen inom nätverkssäkerhet och arbetar som it- säkerhetskonsult på ett företag som konsulterar sin IT-säkerhet till ett företag inom försvarsindustrin. Informanten har över ett års erfarenhet inom området.

Informant C har flertalet utbildningar genomförda. Informanten har på förfrågan förklarats genom att informanten arbetar som IT-säkerhetskoordinator inom universitetsväsendet.

Informant D började sitt yrkesliv som drifttekniker för att sedan gå vidare till en internetleverantör där informanten byggde upp deras infrastruktur och konsultade ut IT- tjänster. Det var primärt konsultuppdragen som gjorde informanten intresserad av säkerhet, då rätt mycket handlade om att säkra upp deras IT-miljöer. Idag så har informanten en roll med ett mer uttalat säkerhetsfokus som innefattar hantering av säkerhet i produktionsmiljön, och till viss del över säkerheten i webbapplikationen.

4.2 Empiri

Här kommer alla de svar på intervjufrågorna som samlats in från informanterna att redovisas i tabellform, för att enkelt kunna avläsa vem som har svarat på vad. Det är den renskrivna och den data som besvarar de framtagna intervjufrågorna som redovisas, det vill säga att det är det som besvarar den ställda frågan som står i tabellerna. De fullständiga intervjufrågorna återfinns i en bilaga i slutet av arbetet.

I tabell 2 här nedan så redovisas det analyserade svaret på Q1 gällande autentisering.

Informant Svar Informant

A

Man behöver använda olika nivåer vid autentisering beroende på vad det för tjänst och vilken typ av information som finns i den. Ibland kan man börja med en låg nivå, t.ex. användarnamn + lösenord, och sen om man skall arbeta med känsligare saker så kan man kräva en högre nivå såsom

(23)

certifikat/BankiD eller biometri. Sedan kan även multifaktor behöva användas.

Informant B

Det finns tre olika moln som används. Två för företaget som

informanterna jobbar på, och ett för företaget de konsulterar. De använder tvåfaktorsautentisering för all inloggning. Man måste gå via företagets egna nät för att kunna logga in, vill man fjärransluta får man använda företagets VPN för distansinloggning.

Informant C

Eftersom de inte har någon känslig data så “behöver” de ingen autentisering förutom inloggningsuppgifter och lösenord till de som interagerar med molntjänsten. Anledningen till att det inte läggs så stor vikt på autentisering är att det som ligger sparat hos studenten, dvs. betyg, kurs etc. är public record.

Informant D

Deras kunder har möjligheten att logga in med det ”gamla sättet”, dvs.

med användarnamn och lösenord. Man kan koppla på SMS-faktorisering för inloggning, det gäller för alla som loggar in i applikationen.

Det de har börjat med nu är att de har lanserat inloggning med bankID. Det gör det enklare att skydda känsliga bankoperationer.

Tabell 2 – Intervjusvar från Q1

I tabell 3 här nedan så redovisas det analyserade svaret på Q2 gällande auktorisering.

A

Man bör använda minimalt med behörighet som precis är tillräckligt för att utföra det man ska göra. Ju fler behörigheter man har desto större risk att säkerheten äventyras. Man bör logga in med den rollen som är anpassad för den uppgiften som ska utföras.

Informant B

De använder sig av OAuth 2.0, Googles Tokensystem för auktorisering.

De använder sig även av citrix och VPN-lösningar. Loggar man in via VPN så har man inga rättigheter.

Informant C

Inloggningsuppgifterna ger rättigheter till vissa delar av molnet. De använder en rollbaserad modell för auktorisering.

Informant D

Man använder sig av ett hemmasnickrat verktyg för auktorisering, vilket hänger ihop med API-nycklar.

(24)

I tabell 4 här nedan så redovisas det analyserade svaret på Q3 gällande inspektion av ”döda”

konton.

A

Det är viktigt att man har rutiner, och folk som regelbundet går igenom och kollar detta. När någon slutar på arbetsplatsen så ser man till att ta bort accessrättigheterna direkt efter de har slutat för att se till så att före detta anställda inte längre har åtkomst.

Informant B

Det beror på olika faktorer. Är det på det företaget som informanten arbetar på så förklarar informanten att de genomför AD-checkar som sker en gång i halvåret samt vid offboarding (uppsägningar).

Informant C

Efter att studenten har avslutat sina studier så låser man först kontot.

Kontot ligger kvar i systemet och databasen för att det sen skickas ut mail där studenten uppmanas att om studenten vill, spara något från sitt konto.

Kontot ligger sedan nedstängt men inte borttaget. De anställdas konton stängs ned direkt då risken att en tidigare missnöjd anställd kan ha uppsåt att läcka känslig information efter uppsägning.

Informant D

För deras kunder, aldrig. De förutsätter att de själva gör det. För egna anställningar så har de processer för borttagning av gamla anställningar.

De kollar 2 gånger om året ifall något konto ligger och släpar. Det finns rutiner för detta.

I tabell 5 här nedan så redovisas det analyserade svaret på Q4 gällande process för borttagning av gammal personinformation.

A

Viktigt att regelbundet rensa bort sådant som inte behöver vara

kvar. Detta gäller även tryckt information. Man kan sätta metainfo om dokumenten och använda sig av dokumentssystem som även automatiskt kan ta bort. Detta går t.ex. att integrera med office 365.

Informant B

Det finns en offboardingprocess. När denna process sker, vilket är när en anställd lämnar företaget så går processen till som så att man går igenom alla system som den tidigare anställda fanns i och sedan tar man bort den tidigare anställda från dessa. Informanten förklarar även att viss

information finns kvar i systemen under en viss period, denna var dock lite osäker på hur länge.

Informant C

Universitetet måste ha kvar dokumentation i statistiksyfte. Det finns dock en gallringsplan för vilken information som ska tas bort. Det görs

(25)

bestämmelser om hur länge en viss data ska sparas, när den tidpunkten har nåtts så raderas helt enkelt den data.

Informant D

De har försökt automatisera så gott det går. De har byggt script som rensar ut gammal personinfo automatiskt efter X tid. Sedan har de processer som tar bort personinformation för de anställda.

I tabell 6 här nedan så redovisas det analyserade svaret på Q5 gällande händelse av dataförlust.

A

Man får se till att datan replikeras och att datan inte finns på ett enda ställe, viktigt med redundans. Se till så att det finns backup-rutiner för all viktig data. Viktigt att utbilda kunderna och se till att rutinerna är tillräckligt bra.

Kunderna har ett ansvar över den egna data som informationsägare. Med GPDR i beaktning, tar du inte ditt ansvar så kan det blir rättsliga påföljder.

Informant B

De ser till att ha tillräckligt med backuper samt ser till att det finns redundans på all data och information. Om man märker att data läcker någonstans så undersöker man denna läckan. Informanten förklarar att de uppmanar alltid kunden att göra backuper på sin data eller information ifall detta skulle hända.

Informant C

Universitetet använder sig av sofistikerade backupsystem som gör att systemen är självreparerande vid dataförlust. Det man ska tänka på är att folk stjäl t.ex. mobiltelefoner och laptops. Detta gör att den fysiska säkerheten kan vara en faktor i dataförlust.

Informant D

De försöker givetvis ha redundans på allt. Förloras någon maskin ska detta inte beröra datan som påverkas. På alla databaser så har de streamande backuper som skickar transaktionsloggar som kan återställas. De har städat upp bland gamla ”dåliga” lösenord, samt bett kunder byta upp sig

lösenordsmässigt. Få rutin på detta.

Det går inte att skydda användarna mot de själva i viss utsträckning, utan de måste kunna sköta sig själva. Kunderna bör ha egen rutin för

dataförlust.

(26)

I tabell 7 här nedan så redovisas det analyserade svaret på Q6 gällande OWASP Top 10.

A

OWASP bör ingå som en del av utbildningen. Bör vara en del av den årliga säkerhetsutbildningen av utvecklingsavdelningen.

Informant B

Ja det har de. De genomför även årliga penetrationstester på system där OWASP Top 10-checkar görs.

Informant C

Nej inte informanten veterligen använder de sig av något ramverk.

Informant D

Ja de utgår från allt gällande riskanalys, penetrationstester, klassificering.

Jobbar man med servertjänster mot internet, och pratar om något annat än OWASP Top 10 så förstår ingen vad man pratar om.

I tabell 8 här nedan så redovisas det analyserade svaret på Q7 gällande revision av säkerheten.

A

Det är väldigt vanligt att företag anlitar externa säkerhetskonsulter för revidering av säkerheten. Många kunder kräver att en utomstående säkerhetsexpert genomför detta. Det skrivs ofta in i kontraktet hur ofta revideringarna ska ske.

Informant B

Nej de sköter allt själva. Enligt informanten har de kompetensen, och med tanke på att de jobbar inom försvarsindustrin och militären så vill man inte släppa in några okända i systemen.

Informant C

Ja, Riksrevisionen reviderar universitetet, dock mestadels om det

finansiella. Det görs även internrevisioner på uppdrag från skolledningen, detta är ett krav som ställs på universitetet. De använder sig av eduroam och måste uppfylla vissa säkerhetskrav.

Informant D

Ja, på de tekniska bitarna gör det. Automatiserade penetrationstester sker en gång i veckan på både hemsidan och applikationen. De får notiser om hur läget ser ut efter.

Varje år har de minst ett manuellt penetrationstest genomfört av experter, externa konsulter gör detta. De försöker att aldrig anlita samma byrå allt för ofta för att få fräscha ögon på situationen och kanske upptäcka brister som några andra inte gjorde.

(27)

I tabell 9 här nedan så redovisas det analyserade svaret på Q8 gällande insiderattacker.

A

För att motverka detta så gäller det att användarna har så få privilegier som möjligt så att de inte kan göra vad som helst. Man kan också använda sig av dubbelkommando för vissa typer av processer. Ett bra loggsystem som kan spåra vad som har gjorts, och vem som har gjort vad om det skulle inträffa något.

Informant B

De genomför exportkontroller, det vill säga att de tittar på vilken information som tas ur systemen. Informanten förklarar att under sin utbildning så lär de sig att hålla koll på sina kollegor, hur de mår och så vidare. Missnöjda kollegor är de som gör brotten. Så fort någon data flyttas så gör de en exportkontroll så de ser vem som har flyttat vad och vart.

Informant C

Med rättigheter först och främst. Man kan mildra det hot som uppstår till att det bara drabbar det som folk “kan komma åt”. Det sker då analyser av loggfiler samt att de har satt upp infrastrukturen så att det inte kan sprida sig vidare. Gällande social engineering så litar de på alla sina anställda.

Det är dock något man måste tänka på.

Informant D

Första försvaret är att ha en så bra företagskultur som möjligt, att alla trivs.

Något man anser sig väldigt bra på.

De har en hel del intern loggning över vad som händer, samt aktiva skydd.

Man delar inte konton, ”gör jag detta så kommer det loggas i mitt konto”.

Försöker förhindra skada hos kunderna genom bra loggning, audit etc.

I tabell 10 här nedan så redovisas det analyserade svaret på Q9 gällande den fysiska säkerheten.

A

Man förlitar sig på den ”yttre väggen” med staket, vakter och kodlås. Inga datorer ska stå i skåp eller på golvet med risk för vattenläckage. Lokalerna ska vara brandsäkra. Den fysiska säkerheten anpassas också efter vad datan och informationen är värd i pengar.

Informant B

De använder datahallar i stora bergrum där varje server är inlåst i en bur som man behöver en nyckel till för att komma åt.

Informant C

En fördel att de finns på två orter. Det innebär flera storskaliga datahallar med skak- och brandskydd. De har även dieselaggregat som sätts igång om det skulle behövas elförsörjning.

(28)

Informant D

Man har två datahallar, alla har klassificeringar för skyddsklass, larm, besöksloggar etc. Det finns brandskydd och ytterligare fysisk säkerhet.

4.2 Analys

Auktorisering och Autentisering

Gällande autentisering så förklarar alla informanter, förutom informant B, att de i grunden använder en låg nivå av autentisering, det vill säga användarnamn och lösenord. Då informant B jobbar i en mer säkerhetsklassad miljö så använder de tvåfaktorsautentisering för all typ av inloggning. Informant A påpekar att en högre nivå av autentisering kan tillämpas när man arbetar med mer känsliga saker. Informant C säger att de endast använder sig av en låg nivå då de inte tillhandahåller känsliga data i molnet. Informant D säger att de erbjuder kunderna möjligheten att koppla på sms-autentisering, samt att de börjat använda BankID för känsligare bankoperationer. Man kan tydligt urskilja från informanternas svar att nivån på autentisering anpassas efter hur känsliga data som tillhandahålls i molnet.

När det kommer till auktorisering så framkommer det att alla informanter använder sig av någon typ av system för auktorisering, dock olika system. Informant A och C både använder och förespråkar en rollbaserad modell för auktorisering. Informant B använder specifikt OAuth 2.0 med Googles tokensystem. Informant D använder en egenutvecklad modell för auktorisering.

Datahantering

Det framkommer att samtliga informanter arbetar med någon typ av process när det kommer till hantering av personinformation och data. När det gäller inspektion av “döda” konton så lägger de företag som informanterna har som arbetsgivare mer fokus på att inspektera de

“döda” konton som finns inom deras egna företag. En avvikelse i detta avseende är dock att informant D förklarar att de ej sköter inspektionen av dessa “döda” konton åt deras kunder, de förutsätter att kunderna som nyttjar deras tjänster gör detta själva. Värt att notera är att informant D arbetar inom E-ekonomibranschen.

Vad gäller borttagning av gammal personinformation så är alla informanter eniga om att det bör finnas någon typ av process för detta, det framkommer även att alla informanter och deras företag använder sig av en eller flera olika processer för detta. Värt att notera är att samtliga informanter förklarar att viss personinformation måste sparas i deras system om deras t.ex. tidigare anställda, så som ekonomiuppgifter och så vidare. En avvikelse i detta är att informant C, som arbetar inom universitetsväsendet, förklarar att de måste spara viss information om tidigare studenter med syftet att föra statistik om kurser och så vidare.

När det kommer till händelse av dataförlust, så är förklarar samtliga informanter att det viktigaste är redundans i data, att ha backuper på all data. Informant B förklarar att om man märker av en dataläcka så är det viktigt att spåra var det läcker samt vart den läckta data är på väg. Samma informant förklarar även att de uppmanar sina kunder att själva göra backups på sin egna data och information. Informant C nämner att det är viktigt att tänka på att

(29)

fysiska enheter stjäls, t.ex. mobiltelefoner, laptops och så vidare. Enligt informanten gör detta att den fysiska säkerheten är en faktor i detta.

OWASP Top 10

En av frågorna behandlar OWASP Top 10 och om det har tagits i beaktning för att bygga upp säkerheten. Informant A säger att det bör ingå som en del av utbildningen. Informant B säger att de genomför årliga penetrationstester på system där OWASP Top 10-checkar görs.

Informant C har ingen koll på om det har använts. Informant D säger att de utgår från det gällande riskanalyser och penetrationstester etc. Informant C är en tydlig avvikelse på den här punkten. Alla andra informanter pratar om att det är en hörnsten i säkerhetsarbetet. En informant uttrycker sig som att om man inte pratar om OWASP Top 10 när det gäller säkerhet så förstår inte alla vad man menar.

Säkerhetsrevision

Samtliga informanter är eniga om att man, av säkerhetsskäl, ska låta sig revidera sina säkerhetsmekanismer. Informant C och D klargör även att det sker utomstående revision på deras säkerhet. Informant B, som arbetar med säkerhetsklassad information inom försvarsmakten, klargör dock att de sköter sin egen revision då de inte vill att någon utomstående ska ha tillgång till data, information samt deras interna system. De har även kompetensen att göra det enligt informanten.

Informant D redogör för sin organisations säkerhetsrevision genom att förklara att det genomförs veckovisa penetrationstester på både hemsidan och deras applikation. Det klargörs att de även genomför minst ett manuellt penetrationstest genomfört av experter varje år, externa konsulter gör detta. De försöker att aldrig anlita samma byrå allt för ofta.

Interna hot

Gällande interna hot såsom insideattacker så finns det två utstående teman som man kan se.

För det första så redogör samtliga informanter om att de nyttjar de loggfiler som talar om vem som har gjort vad samt vad som har flyttats vart. Informant B och D lyfter även den mänskliga faktorn. De förklarar att de är måna om hur deras anställda mår och så vidare.

Informant B nämner specifikt att det är de missnöjda kollegorna som genomför brotten.

Informant D förklarar att det första försvaret mot inside attacker är att ha en så bra företagskultur som möjligt. Det vill säga att alla som arbetar ska trivas så mycket som möjligt.

Fysisk säkerhet

När det gäller best practice för den fysiska säkerheten så är samtliga informanter överens om att datahallarna måste vara brandskyddade, samt att servrarna i datahallarna är placerade på ett sådant sätt som gör att de inte skulle ta skada vid eventuella läckage eller liknande.

Alla informanter påpekar också att det finns någon form av skydd mot obehöriga, såsom till exempel staket, larm, lås etc. Oavsett vad det är för typ av data man tillhandahåller bör det finns någon form av yttre säkerhet. Informant A påpekar att den fysiska säkerheten anpassas efter vad data och informationen är värd i pengar.