Vimur AB

Assurance level

I tidigare blogginlägg har vi kikat lite på ett par enkla metoder för att öka IT-säkerheten samt generellt på riskhantering och diverse ställningstaganden mot identifierade risker. I det aktuella inlägget går vi vidare till autentisering och auktorisering. Det är lätt hänt att organisationer, i sin strävan mot ökad IT-säkerhet, fastnar i ett tankesätt där mer betraktas som bättre. Risken med den här typen av säkerhetsarbete är att vi någonstans försämrar användarvänligheten och skapar därmed en alltför komplicerad autentiseringsprocess för resurser utan ett sådant behov. För att motverka detta kan vi använda oss av assurance levels, vilket i grund och botten är en term som används för att beskriva hur säker en organisation kan vara på att en användare som har använt inloggningsuppgifter, faktiskt är vem den påstår sig vara.

Assurance, eller försäkran, kan i detta sammanhang mer specifikt kategoriseras i två delar:

Bild på man som jobbar med sin laptop. Bakgrund av digital skärm, virtuell världsomspännande anslutningsikon, diagram, grafgränssnitt.
  1. Förtroendegraden för kontrollprocessen som används för att fastställa identiteten bakom inloggningsuppgifterna.
  2. Förtroendegraden för att individen som använder inloggningsuppgifterna är samma individ som fick dessa utfärdade till sig.

Det fundamentala i denna metodik är att ligga på en rimlig säkerhetsnivå, i enlighet med vilken resurs eller information som skyddas. Organisationer har möjlighet att genomföra detta på olika sätt men för detta blogginlägg väljer jag bland de mesta populära ramverken, framtaget av NIST (National Institute of Standards and Technology) som utgår från att det finns fyra nivåer av assurance eller försäkran.

Nivå 1

På denna nivå finns det minimalt eller inget förtroende alls för den hävdade identitetens validitet. Denna nivå kan till exempel vara lämplig där en kund registrerar sig för att delta i en diskussion på ett forum på en organisations webbsida. En rimlig autentiseringsmetod kan vara ett ID och lösenord som användaren själv skapar, utan någon djupare valideringsprocess. Det är således ingen sms-bekräftelse, ingen bekräftelse av mailadress etcetera. Vi har ingen möjlighet att kontrollera vem individen faktiskt är, åtminstone inte baserat på inloggningsuppgifterna, vilket innebär att om vi lägger oss på denna nivån när det inte är särskilt viktigt att verifiera vem individen är.

Nivå 2

På denna nivå har vi något högre förtroende för den hävdade identitetens validitet. Detta är den allra vanligaste nivån att ligga på och är precis som första nivån, vanligtvis baserad på ett ID och lösenord. Däremot finns det normalt sett en simpel verifieringsprocess genom exempelvis mailadress, telefonnummer eller liknande. Ibland kan det även vara så att användarens ID och/eller lösenord har genererats av en generator eller möjligtvis kan det ges ut av en IT-avdelning. Visserligen kan inloggningsuppgifterna ändå hamna i fel händer av olika anledningar men generellt räknar vi med att de flesta användare är vem de påstår sig vara.

Nivå 3

På denna nivå har vi högt förtroende för den hävdade identitetens validitet. Här är det vanligt att det är ett mer begränsat antal kunder eller anställda som har tillgång till resursen eller informationen. Det beror på att resursen i fråga är värdefull och kan innebära allvarliga konsekvenser vid obehörig tillgång. Av denna anledning måste vi öka vår försäkran om att individen som använder ett konto faktiskt är rätt individ med korrekta behörigheter. För att lyckas med detta kan vi till exempel använda oss av ett ID och lösenord, precis som för nivå 2, och sen lägga till ytterligare en metod för autentisering. Tvåfaktorsautentisering ökar bevisligen säkerheten oerhört mycket men förlänger givetvis inloggningsprocessen och på så vis kan vi omedelbart se en påverkan på användarvänligheten. Ett typiskt exempel där detta används är när en anställd loggar in på sin jobbmejl och verifierar med ett nummer som skickats via SMS. Det kan också vara en kombination av inloggningsuppgifter och ett så kallat smart card som används i autentiseringsprocessen. Det finns olika typer av smart cards men bland de vanligaste är ett kort som användaren stoppar in i en läsare för att autentisera sig.

Nivå 4

På toppen har vi mycket högt förtroende för den hävdade identitetens validitet. Information som kan placeras i denna kategori är till exempel en databas som innehåller den svenska befolkningens brottsregister. Obehörig åtkomst till en sådan databas kan innebära allvarliga bekymmer vad gäller integritet eller eventuellt äventyra viktiga utredningar. På nivå 4 är det vanligt att användaren går igenom en noggrann autentiseringsprocess och det är inte ovanligt att tre eller fler metoder används. Ett exempel kan vara att en användare skriver in ID och lösen, verifierar genom sitt smart card och slutligen till använder en fingeravtrycksläsare eller ögonscanner.

Sammanfattningsvis, finns det inget facit och ingenting är svart och vitt när det gäller den här typen av arbete. Vi gör ett antagande att man på nivå 1 och 2 använder sig av ett ID och lösenord men realistiskt sett är inte ens det är givet. Det handlar helt enkelt om att analysera sina resurser, möjliggöra en konkret värdering av dessa och slutligen förstå konsekvenserna av att obehöriga får tillgång till eller förstör det vi vill skydda. När vi lyckats med detta kan vi gå vidare till att implementera åtgärder och autentiseringsprocesser utifrån värdet på resursen i fråga. På så vis kan vi skapa den balans vi eftersträvar mellan säkerhet och användarvänlighet.

Vill du läsa mer om våra tidigare inlägg om IT-säkerhet rekommenderar vi att läsa Tre principer för en säkrare IT-miljö och Riskhantering.


Ahmad Gazzawi
BI-konsult på Vimur

Har du frågor?
Kontakta Håkan!