Säkerhetsaspekter gällande ehemtjänst-produkter

Säkerhetsaspekter gällande ehemtjänst-produkter HJÄLPMEDEL INOM EHEMTJÄNST... 2 BEHANDLING AV PERSONUPPGIFTER... 2 PÅ KRYPTERING... 3 AUTENTISERING... 4 BEHÖRIGHETER... 7 LOGGNING OCH SPÅRBARHET... 7 BACKUPER... 8 AUTOMATISK UTLOGGNING... 9 UPPDATERINGAR... 9 AVSLUTANDE KOMMENTARER... 10 APPENDIX 1 - KATALOG... 11 BEHANDLING AV PERSONUPPGIFTER, LAGRING AV DATA... 11 AUTENTISERING... 13 FEDERERING... 13 ÅTKOMST, ACCESS... 14 LOGGNING OCH SPÅRBARHET... 15 APPENDIX 2 EXEMPEL PÅ FRÅGEUNDERLAG TILL TILLVERKARE... 16 ANVÄNDARKONTOTS AKTIVERING... 16 KLIENTKOMMUNIKATION... 16 SKYDD AV BRUKARENS ENHET, OPERATIVSYSTEM MM... 16 ADMINISTRATIONSGRÄNSSNITT OCH CENTRALT SYSTEM... 17 LOGGNING OCH INSAMLING AV DATA... 17 INCIDENTHANTERING... 17 ÖVRIGT... 17 APPENDIX 3 TEKNISKA SPECIFIKATIONER... 18 KRYPTERING... 18 Sida 1 av 18

Hjälpmedel inom ehemtjänst Detta dokument redovisar generella informationssäkerhetskrav som kommuner (och eventuellt andra organisationer) bör ställa på leverantörer av produkter och tjänster inom ehemstjänstområdet. Kraven har tagits fram efter att ett antal tjänster har studerats ur ett informations- och IT-säkerhetsperspektiv för Västerås Stads räkning. I och med att den tekniska utvecklingen har gått framåt, samt att fler brukare inom hemtjänsten börjar bli mer tekniskt mogna, så finns det nu ett antal hjälpmedel på marknaden som kan vara ett stöd och komplement till traditionell hemtjänst. Exempelvis kan besök föraviseras till brukarna genom notifieringstjänster och videotelefoni kan komplettera ett hembesök och underlätta kontakt med anhöriga. Produkter och tjänster inom ehemtjänstområdet är under utveckling men de har ännu inte fått någon stor spridning på marknaden. Det görs pilottester inom ett antal kommuner, men den stora användarbasen finns inte idag. Av förklarliga skäl har produktoch tjänsteleverantörerna istället fokuserat på att få till en funktion som är tilltalande och möjlig att presentera, testa och utvärdera. Informationssäkerhet är alltså ett område som ofta får stryka på foten i ett initialt utvecklingsskede. Icke desto mindre så är det ett område som behöver hanteras redan från början vid en produktutveckling. Det är ofta svårt att i efterhand bygga på säkerhetsmekanismer om ett system har kommit en bit i sin utveckling. Som kund och presumtiv beställare är det alltså av vikt att redan från början våga ställa krav att tillräckliga administrativa, operativa och tekniska skyddsmekanismer 1 är påtänkta eller inplanerade i produkterna. Så utöver de rent funktionella kraven, måste beställaren ställa krav på säkerhet i produkterna redan från början. Det finns några krav framtagna i Appendix 1 som vägledning kring hur ett ehemtjänstsystem kan kravställas utifrån ett informationssäkerhetsperspektiv. Behandling av personuppgifter I och med att tekniska lösningar börjar användas i närheten av brukarna krävs det att lösningarna motsvarar de krav som ställs inom Personuppgiftslagen (1998:204), PuL. Tolkningen av skyddsåtgärder för att skydda uppgifter som hamnar under PuL har gjorts i flertal fall av Datainspektionen (DI). Enligt 31 personuppgiftslagen ska den personuppgiftsansvarige vidta lämpliga tekniska och organisatoriska åtgärder för att skydda de personuppgifter som behandlas. Åtgärderna ska åstadkomma en säkerhetsnivå som är lämplig med beaktande av de tekniska möjligheter som finns, kostnaden för åtgärderna, särskilda risker med behandlingen och hur pass känsliga uppgifterna är. 1 Med skyddsmekanismer menas kontroller som läggs på olika nivåer i organisationen och produkten/tjänsten. Det kan vara allt från att leverantören har en incidentberedskap, delade roller mellan utveckling och drift och att tjänsten skyddas med brandväggar, antivirus och kan uppdateras med nyare programvara (patchning). Sida 2 av 18

Känsliga personuppgifter enligt 13 personuppgiftslagen ska vid överföring via öppet nät, till exempel Internet, förses med skydd i form av kryptering. Uppgifterna får dessutom överföras via öppna nät endast till identifierade mottagare vars identitet är säkerställd med en teknisk funktion. Till viss del kan vissa tjänster även tolkas falla under lagen (2003:389) om elektronisk kommunikation, då med tanke på skyddsåtgärder i enlighet med kapitel 6. Många av systemen låter data om den enskilda användaren lagras, t.ex. i form av kontouppgifter, loggar och information kring användningen. Det är då tre krav som ställs på systemet, vilka följer av PuL: att det ska gå att gallra uppgifter för enskild individ (PuL 12 ) att det ska gå att ta del av de uppgifter som rör användaren (PuL 26 ) att tjänsten ska använda adekvata skyddsmekanismer för att förhindra obehörig åtkomst till uppgifterna (PuL 31 ) Om tjänsten till största delen körs hos leverantören (t.ex. i form av molntjänst ) måste också ett personuppgiftsbiträdesavtal skrivas mellan parterna för att säkerställa att leverantören följer de instruktioner som beställaren kräver. Observera att det är den personuppgiftsansvarige (utsedd person på t.ex. en kommun) som ansvarar för att behandlingen av personuppgifter sker i enlighet med personuppgiftslagen och det förändras inte av att personuppgiftsbehandlingen utförs av ett personuppgiftsbiträde (d.v.s. leverantören). Inom detta område är det också intressant att ta reda på om leverantören i sin tur använder sig av en tjänsteleverantör (t.ex. har servrarna i en molntjänst) och hur det avtalet ser ut. Krav på kryptering DI, med stöd i PuL 31, ställer krav att när man ska kommunicera känsliga personuppgifter via ett öppet nätverk, som till exempel Internet, så måste överföringen av uppgifterna vara skyddad med hjälp av kryptering. Vad som menas med begreppet öppet nätverk är inte fullständigt beskrivet, men en vedertagen tolkning är att ett nätverk som inte är under någon parts fulla kontroll (beställaren, leverantören och brukaren) kan anses som öppet nätverk. Kryptering innebär att informationen inte kan tolkas av obehörig part som inte har tillgång till de hemliga nycklar som används för att kryptera datat. Det innebär alltså att krypteringsnycklarna måste hållas skyddade, precis på samma sätt som den information som skyddas. Olika typer av kryptering är olika säker. En mer detaljerad genomgång av olika krypteringstekniker och krav finns i Appendix 3. Exempel 1 Ett system som erbjuder hemstjänstpersonal och/eller anhöriga att se en persons position i realtid publiceras som webbtjänst. Den som loggar in för att ta del av personens Sida 3 av 18

nuvarande person loggar in med användarnamn och lösenord. För att inte användarnamn och lösenord ska sändas i klartext över Internet, måste tjänsten publiceras över SSL/TLS med giltigt och verifierbart servercertifikat. Det är heller inte särskilt bra att känsliga uppgifter (positioneringsdata) skickas okrypterat (fullt läsbart) över Internet. Exempel 2 En databas med samtliga brukare inom ett hemtjänstområde är uppsatt som stöd för ett antal verksamhetssystem, t.ex. för att kunna föra anteckningar om utfört arbete och underlag till kontodatabaser för tjänster såsom videotelefoni och positionstjänster. Denna databas kommer med största sannolikhet innehålla uppgifter av en sådan karaktär att skyddsnivån kan klassas som nivå 3 enligt Myndigheten för samhållsskydd och beredskap, MSB, klassningsmodell 2. Det innebär att kommunikation till och från databasen behöver krypteras, t.ex. genom IPsec eller SSL/TLS. I vissa fall (beroende på skyddsmekanismerna kring databasen och det tekniska stödet i databasen) så ska även informationen i databasen krypteras (helt eller delvis) i enlighet med tabellen ovan. Autentisering På samma sätt som data skyddas mot oavsiktlig avlyssning genom kryptering, måste tillgången till data kunna skyddas på samma sätt. På samma vis som i fallet med kryptering så styrs kraven om autentisering genom DI:s tolkningar av i PuL 31. För sätt att bevisa sin identitet går det att använda olika sorters lösningar. Som grundläggande teknik används användarnamn och lösenord. Detta kan te sig enkelt och tillräckligt vid en första anblick, men är i själva verket mycket sårbart. 1) Användarnamn och lösenord kan komma obehörig till del, t.ex. genom att skriva upp på lapp eller att skadlig kod på datorn kan fånga upp det. 2) En användare som har många system med användarnamn och lösenord som autentiseringslösning tenderar att använda samma uppgifter (eller i vart fall samma lösenord) i alla, eller många, system. Kommer man över uppgifterna i ena systemet kan en attackerare enkelt komma in i alla andra system med samma lösenord. 3) En användare som är skicklig med att använda olika lösenord för olika system måste troligen skriva upp dessa i en lista. I det fallet är listan sårbar att försvinna eller kopieras. Lösenordskrav I det fall tjänsten enbart kräver lösenord, måste detta lösenord kunna möta ett antal krav 3 för att kunna betraktas som säkert. Dessa krav är exempelvis: Vilka tecken som helst ska kunna matas in. Det får inte vara någon begräsning i att inte använda svenska tecken (å, ä eller ö) eller andra tecken (t.ex.! # %&/(~^)=). Lösenordet måste bestå av minst 8 tecken. Minst tre av de fyra teckenuppsättningarna måste förekomma (versaler, gemener, siffor och icke-alfanumeriska tecken). Lösenordet får inte vara samma, eller liknande, användarnamnet. 2 Läs mer om informationsklassning på MSBs webb, www.informationssakerhet.se 3 Kraven står att finna på https://testalosenord.pts.se. Sida 4 av 18

Ett tidigare använt lösenord får inte återanvändas. Byte av lösenord bör ske med jämna (eller ojämna) intervall. Lösenord får inte heller lagras i klartext i tjänstens databas (eller motsvarande) samt att den kryptering som används för att hantera lösenorden måste vara så säker att det ska anses vara mycket svårt att knäcka 4. 2-faktorsautentisering DI ställer krav på att ett skydd för känslig data är att använda så kallad 2-faktorsautentisering, vilket har tydliggjorts i ett flertal publicerade tillsynsärenden. Det innebär en inloggning med hjälp av två skilda former av information, till exempel ett smart kort och ett lösenord. Skilda former av information är Något man vet (t.ex. pinkod eller lösenord) Något man har (en fysisk tingest, lösenordsdosa, smart kort) Något man är (t.ex. fingeravtryck eller röstigenkänning) Ett praktiskt exempel är vid uttag av pengar ur en bankomat med "något man har" (kontokortet) och "något man vet" (pinkoden). Samma sak gäller vid inloggning till en internetbank med eid: något man har (certifikatet) och något man vet (pinkoden). På motsvarande sätt kan man säga att användarnamn och lösenord är en 1- faktorsautentisering 5 genom att bara hantera något man vet. Tillitsnivåer Under senare tid (från 2010) har ett nytt begrepp börjat användas inom området för autentisering, nämligen tillitsnivå. Drivande i detta arbete är den nyligen inrättade e- legitimationsnämnden (www.elegnamnden.se). Problemet som man försöker lösa med att tillämpa detta begrepp är att olika typer av inloggningsmetoder (autentisering) är olika bra. Den skala man använder för att mäta begreppet har fyra steg där 1 är lägst och 4 högst. Bara för att man använder sig av en tvåfaktorslösning innebär inte att man kan var säker på att identiteten är den rätta. Man lägger alltså en vikt i hur den elektroniska identiteten lämnats ut. Ett smart kort som lämnats ut i en låda i receptionen till vem som helst som passerar är troligen inte säkrare än en inloggning med användarnamn och lösenord, utan troligen sämre. Begreppet kan åskådliggöras genom följande beskrivning: Tillitsnivå 1: inloggningsuppgifter att logga in till Facebook eller Google Tillitsnivå 2: inloggningsuppgifter utdelade till elever av klassföreståndaren Tillitsnivå 3: inloggning genom elektroniskt id utdelat av t.ex. BankID/Telia/Nordea/ SITHS Tillitsnivå 4: inloggning med speciella elektroniska id 4 Med detta menas (med teknisk jargong) att lösenorden ska lagras hashade samt saltade. 5 Observera att två lösenord efter varandra inte är en 2-faktorsautentisering, eftersom man måste blanda de olika informationsformerna. Sida 5 av 18

Som går att utläsa av listan ovan, så ökar den tillit man kan sätta till att personen (eller datorn/servern/systemet) i andra änden verkligen är den som den utger sig för att vara. Tillitsnivå 1: Ingen eller väldigt låg tilltro till uppgiven identitet. Det är ju alltid möjligt att ansluta sig anonymt (och med falskt namn) till tjänster såsom Facebook, Twitter och Google. Inloggningsmetoden är nästan alltid användarnamn och lösenord. Tillitsnivå 2: Viss tilltro till uppgiven identitet. Genom att lämna ut inloggningsuppgifter till elever (eller vårdnadshavare) genom klassföreståndaren innebär att man vet som är mottagaren. Andra sätt kan vara att innehavarens identitet har verifieras genom t.ex. reguljär postgång till folkbokföringsadressen. Godtagbara autentiseringsmetoder innefattar lösenord med komplexitetskrav (se avsnittet ovan om lösenordskrav). Tillitsnivå 3: Hög tilltro till uppgiven identitet. Ett elektroniskt id lämnas ut till någon som man är väldigt säker på är rätt person. Detta kan ske genom personlig närvaro och traditionell legitimering med id-kort. Dagens e-legitimationer från bankerna och vårdens inloggningskort (SITHS) är bra exempel. Autentiseringsmetoden får inte vara användarnamn och lösenord, utan måste vara tvåfaktorslösning (se tidigare avsnitt). Tillitsnivå 4: Mycket hög tilltro till uppgiven identitet. Omfattar också inloggning genom tvåfaktorslösning, men där särskilt höga krav har satt på hur den elektroniska identiteten hanteras vid ansökan, identifiering endast vid personligt besök och utlämning endast av särskilt utbildad personal samt att den elektroniska legitimationen aktiveras först vid leverans genom aktiveringskod som skickas till folkbokföringsadressen. Tillitsnivåerna kan ofta knytas ett-till-ett mot motsvarande klassning av information. Information som är klassat som nivå 3 ska alltså endast vara åtkomlig efter autentisering med en metod som anses vara under tillitsnivå 3. Federering De flesta applikationer är idag publicerade genom ett webbgränssnitt. Detta kan ge möjligheter att istället för att i applikationen genomföra en autentisering, ta hjälp av en tredjepart som utför autentiseringen, utfärdar ett intyg som sedan accepteras av tjänsten. Denna teknik kallas för federering och används redan nu av många verksamheter samt att denna typ av lösning begärs som en del av lösningen vid upphandling av många organisationer i offentlig sektor. Integrationen mellan tjänsten och kommunen som är av federativ typ innebär rent praktiskt att en användare som vill logga in i tjänsten automatiskt blir omstyrd till en inloggningssida. Inloggningssidan tillhandahålls av kommunen. Där loggar användaren in med hjälp av t.ex. BankID (tillitsnivå 3). Efter lyckad inloggning styrs användaren automatiskt tillbaka till tjänsten där access ges. Lösningen bygger på en standard som kallas SAML. Exempel 1 Ett ehemtjänstsystem som visar en persons aktuella position genom GPS presenterar informationen i en webbtjänst. Tjänsteleverantören har i samråd med kunden beslutat att åtkomst till systemet enbart får ske efter lyckad tvåfaktorsautentisering. Istället för att Sida 6 av 18

tjänsteleverantören bygger upp ett sådant autentiseringssystem så beslutar man att kunden (kommunen) ska stå för autentiseringen då man redan har ett sådant system uppbyggt för att autentisera vårdnadshavare för åtkomst till ett skolsystem. Exempel 2 Ett system som har känslig information om brukare lagrat kräver enbart att systemadministratörer behöver logga in med användarnamn och lösenord. Under tiden har det växt fram en praxis att den som först kommer till arbetsplatsen på dagen loggar in i tjänsten med ett grupp-id och lösenord och sedan delar alla systemadministratörer på denna inloggning. Efter ett tag görs en revision när man misstänker att känslig information har spridits på ett otillbörligt sätt. Revisionen kan inte slå fast hur informationen hanterats vid en viss tidpunkt då det i loggarna inte går att se Vem som varit den faktiska administratören vid ett visst tillfälle och sålunda vilka aktiviteter som utförts av respektive systemadministratör. Vilka som har tillgång till inloggningsuppgifterna då samma användarnamn (gruppid) och lösenord har använts under lång tid. Det till och med kan vara någon utomstående som loggat i systemen eftersom användarnamnet och lösenordet har spridits i ett flertal e-postmeddelanden som råkat gå till fel mottagare. Behörigheter En säker autentisering ger tillgång till tjänsten, men det ska inte betyda att samtliga funktioner skall vara tillgängliga till alla. Systemet skall vara uppbyggt hierarkiskt med ordnade administratörsroller och användarroller. Andra roller kan också behöva användas beroende på användningsområde. Beroende på systemets eller tjänstens användningsområde måste också åtkomst till information begränsas till att omfatta enbart den eller de delar som krävs för användaren. Behörighet (även kallad access) kan baseras på olika typer av bedömningskriterier såsom rollinnehav, typ av inloggning (användarnamn/lösen eller 2-faktors), tid på dygnet osv. Loggning och spårbarhet Händelser i ett system måste loggas för att det i efterhand ska kunna läsas ut vad som har hänt, när det har hänt och vad resultatet blev. Utan loggning går det inte att göra någon form av uppföljning. Loggning brukar ofta härledas till tekniska krav, d.v.s. att man ska kunna felsöka - tekniker letar i loggarna för att kunna finna orsaker till felbeteenden. Detta är bara en anledning till att föra loggning. Ett system behöver också kunna föra logg på vem som gjort vad och när. Inte minst är det viktigt ur integritetssynvinkeln. Ett bra exempel på detta är sjukvårdens journalsystem som tillåter i princip alla anställda att söka i samtliga Sida 7 av 18

journaler 6, men att det i efterhand går att avgöra om en person hade rätt eller inte att göra en viss journalsökning. Loggar används också för att kunna bedöma om obehörig åtkomst har inträffat. I dessa fall måste dock loggarna vara väl skyddade mot manipulation. I fall obehörig åtkomst (t.ex. hackerattack) har inträffat, så brukar den som berett sig åtkomst också sopa igen spåren efter sig. Om då loggarna sparas på samma system som intrånget skett på, är det oftast väldigt enkelt att även ta bort komprometterande spår. I det fall det sparas känslig information i loggarna måste även loggarna hanteras med samma skyddsåtgärder som andra känsliga data inom systemet. Dessa krav gäller både lagring, autentisering, behörighet och radering. Likväl som loggar sparas med en notering om användar-id (där sådant är tillämpbart), måste alla loggar tidsstämplas. Tiden som noteras i loggningen ska vara spårbar tillbaka till en känd källa, t.ex. den tidskälla som SP (Sveriges Tekniska Forskningsinstitut) tillhandahåller över protokollet NTP 7. Likväl som det driftsatta systemet ska logga händelser, ska utvecklingsprocessen kunna vara spårbar. Det handlar om att ta hand om och dokumentera kravställning från alla intressenter, hur kraven omsätts i verklighet, hur felrapporter och incidenter hanteras samt på sättet nya versioner rullas ut och verifieras. Exempel 1 Ett system loggar tydligt alla händelser till en central loggserver. Systemet i sig innehåller känslig information och är väl skyddat med såväl tekniska som administrativa skyddsmekanismer, t.ex. så krävs att samtliga systemadministratörer loggar in med eid på smarta kort. Då även loggarna bedöms innehålla känslig information (t.ex. namn och personnummer på brukarna) så skyddas även loggservern på samma sätt som källsystemet. Det innebär att ingen kan göra en sökning i loggarna utan att först autentisera sig med eid på ett smart kort. Exempel 2 En tjänsteleverantör har ett antal servrar som används för att köra tjänsten. Alla servrar loggar till en central loggserver. Först när man misstänker ett intrångsförsök upptäcker man att samtliga servrar har olika tider och att ingen central tidssynkronisering har gjort. Följden blir att det inte går att fastställa händelseflödet vid det misstänkta intrånget, eftersom det inte går att korrelera loggarna. Backuper Backupmedia som hanterar data som klassats som känsligt måste hanteras på samma sätt som all annan känslig data. Detta innebär allt från lagring, återläsning, åtkomst och hur det förstörs. 6 Detta är designat så därför att om en patient kommer in akut till sjukvården, ska inte rättighetsproblem vara ett hinder för behandlande personal att utföra sitt arbete. Bedömningen är att man i efterhand ska kunna avgöra om en journalläsning varit korrekt. 7 NTP = Network Time Protocol. NTP-tid från SP:s servrar och från Netnods servrar är direkt spårbar till den svenska officiella tidsskalan UTC (SP). Sida 8 av 18

Exempel En tjänsteleverantör har varit noggrann att göra backup på samtliga sina system, där vissa system innehåller känslig information. När det är dags att kasta de uttjänta backupbanden, slängs dessa utan annan åtgärd i soporna. Vid återvinningsstationen hittar en person dessa backupband och inser att de är funktionsdugliga och tar hem dessa. Eftersom inga data är raderade på banden så kan denna utomstående person få full tillgång till den information som ligger på backupbanden. Automatisk utloggning Verksamhetssystem som kräver inloggning bör också logga ut en användare vid inaktivitet. Om inte användaren aktivt har gjort något i systemet under en viss tid, skall användaren automatiskt loggas ut och en ny inloggning (se autentisering ovan) krävas. Hur lång denna inaktivitetstid skall vara måste vara baserad på typ av tjänst och sättet som tjänsten administreras och hanteras. Uppdateringar Mjukvara, och även hårdvara, förändras över tiden. Nya funktioner läggs till och säkerhetshål som upptäcks täpps till. I tjänster som innehåller mjukvara från många olika leverantörer krävs det att alla delar hålls uppdaterade för att minska risken att få ett säkerhetshål utnyttjat. Det måste ställas krav på vem som är ansvarig för uppdateringar, när dessa kan installeras, hur länge det får dröja efter att en uppdatering släppts till dess den är installerad och vad som ska gälla om den inte är installerad. Som grund bör man ställa att samtliga servrar och klienter ska kunna hantera antivirus, kunna ha lokala brandväggar samt kunna bli uppdaterade med de senaste patcharna. En del verksamhetssystem kan vara auktoriserade, vilket kan innebära att förändringar i alla mjukvara kräver en ytterligare auktorisation 8. En auktorisationsprocess tar tid och är ofta kostsam, vilket kan ge upphov till att man som innehavare av systemen låter bli att uppdatera dem. Detta innebär risker som är svåra att upptäcka innan det är för sent. En dator med en tjänst som består av gammal programvara som inte längre supportas av tillverkaren kan råka ut för att bli utsatt för risker (och attacker) som sedan länge har täppts till i senare versioner av programvaran. Sådana system bör övervägas om de ska tas in, eller om man kan placera dessa på ett helt eget nätverk, avskilt från all övrig utrustning. Exempel Ett system som tillåter brukarna att kunna genomföra videotelefonisamtal på den vanliga TV-apparaten har en svart låda som kopplas till brukarens TV och till en videokamera. Den svarta lådan är en liten dator som innehåller komponenter som ett operativsystem (t.ex. Linux) och en liten webbserver för att erbjuda fjärradministration. Samtliga komponenter är öppen källkod som satts samman för att tjänsten ska bli optimal för brukaren. 8 Auktoriserade system är vanliga inom medicinska vården. Sida 9 av 18

Vid ett tillfälle så upptäcks ett allvarligt säkerhetshål i den webbserverprogramvara som används i den svarta lådan. Dock uppmärksammas inte denna uppdatering av tjänsteleverantören så komponenten uppdateras inte. Då den svarta lådan är kopplad på en internetuppkoppling så dröjer det inte länge förrän någon har upptäckt den ouppdaterade webbservern. Ett intrång görs, t.ex. genom buffertöverskrivning. Resultatet blir att programvaran i den svarta lådan blir skadat och tjänsten slutar att fungera och det enda sättet att återställa systemet hos brukaren är att ominstallera den svarta lådan. Avslutande kommentarer Det är viktigt att påpeka att informationssäkerhet inte är bättre än den svagaste länken i ett system, tjänst eller process. Oavsett tjänst och produkt behöver man som kund/beställare/brukare se över leverantörens förmåga att leva upp till de fyra grundpelarna inom informationssäkerhet: sekretess, riktighet, spårbarhet och tillgänglighet. Sida 10 av 18

Appendix 1 - Kravkatalog Nedan följer ett exempel på hur krav kan skrivas gentemot leverantörer vid upphandling. Observera följande två punkter: 1) Dessa krav är bara de absolut lägsta krav man kan ställa och baseras på bl.a. DI:s rekommendationer. Ytterligare krav på högre informationssäkerhet, driftsäkerhet och tillgänglighet bör ställas med tanke på produktens/tjänstens användningsområde. 2) Om det är upphandling genom LOU så kanske kraven behöver omformuleras för att bättre kunna hanteras vid upphandlingsförfarandet. Behandling av personuppgifter, lagring av data Överordnat krav: Om systemet hanterar känslig information skall tjänsten använda adekvata skyddsmekanismer för att förhindra obehörig åtkomst till uppgifterna (PuL 31 ) Överordnat krav: Om systemet hanterar personuppgifter skall det gå att gallra uppgifter för enskild individ (PuL 12 ) Överordnat krav: Om systemet hanterar personuppgifter skall det gå att ta del av de uppgifter som rör användaren (PuL 26 ) Enheter som tas ur drift (avvecklas) skall raderas från samtlig data som innehåller personliga uppgifter. Detta kan ske på sätt som motsvarar de beskrivna i NIST 800-88. Motivering: Datamedia som ska kasseras/slängas måste först raderas från känslig data. Detta gäller självfallet även papper, USB-minnen och hårddiskar i skrivare. Det finns riktlinjer för hur man kan gå tillväga för att förstöra utrustningen tillräckligt mycket för att inga data ska kunna återläsas. Rekommendationerna i NIST 800-88 ger exempel på vilka metoder som kan användas för att radera/förstöra information och informationsbärare. Sida 11 av 18

Kryptering DI, med stöd av PuL, ställer krav att när man ska hantera känsliga personuppgifter via ett öppet nätverk, som till exempel Internet, måste själva överföringen av uppgifterna vara skyddad med hjälp av kryptering. Webbtjänsten skall kunna tillhandahålla följande protokoll för säker informationsöverföring (i de fall det är tillämpligt): SSLv3 TLSv1.0, eller senare Osäkra protokoll (såsom SSLv2) skall vara avstängda. Motivering: I fall känslig information ska vara åtkomligt över webben är det viktigt att man bara stödjer de protokoll och standarder som kan anses säkra. SSLv3 är sedan 2001 ersatt av TLSv1 och den senaste presenterade standarden är TLSv1.2. I de fall lösenord används inom systemet skall dessa vara krypterade enligt good practice, vilket torde vara salt+hash Motivering: Om obehörig råkar få tag på lösenordsdatabasen (motsv) så ska man inte kunna återskapa lösenorden särskilt enkelt. Att bara hasha lösenorden är i dag enkelt att knäcka; många kända händelser visar detta. Att tillföra ett salt till krypteringen försvårar avsevärt. En anledning till att man vill skydda lösenorden är att många personer (trots rekommendationer om annat) har samma lösenord till flera tjänster. Om en tjänst råkar få sina lösenord publicerade i klartext kan många andra tjänster också vara sårbara för fortsatta attacker. System (och organisation) som använder sig av kryptering skall ha en krypteringsnyckelpolicy som motsvarar hanteringen av den känslighet av data som nyckeln krypterar. Motivering: Om inte nyckeln hanteras på samma säkra sätt som man ska hantera det känsliga datat som är i systemet, är krypteringen i princip meningslös. Nyckelhantering handlar bl.a. om hur nycklar skapas, hanteras, lagras, arkiveras och förstörs. Den typ av krypteringsteknik som används skall minst motsvara den nivå som rekommenderas för data klassat som nivå 3 i SKL:s rapport Säkerhetskrav och specifikationer för informationsutbyte via Internet, 2010. Motivering: Svag eller dålig kryptering är inte värt något. Skydd av data vid integration med andra system Systemet som vänder sig mot medborgare och utförare skall kommunicera med standardprotokoll HTTP(S) över standardportar. Motivering: Standarder finns av en anledning. Ska en webbtjänst publiceras, ska det vara över standardportarna. Annars är risken stor att man måste ändra i brandväggsregler hos den uppkopplande parten för att få åtkomst. Sida 12 av 18

I det fall automatiserade integrationer finns (exempelvis webbservices och IPsec-tunnlar) skall dessa erbjudas med dubbelriktad autentisering med hjälp av certifikat. Motivering: Oftast integrerar man med andra tjänster över web services. Där finns idag inbyggt stöd för autentisering och tjänsteleverantören ska aktivera och använda sig av denna funktion. Integrationer brukar ske över organisationsgränser, vilket än mer gör det viktigt att veta att motparten är den korrekta. Autentisering Om systemet hanterar känslig information skall all typ av åtkomst baseras på tvåfaktorsautentisering med en tillitsnivå motsvarande LoA 3 enligt NIST 800-63. Motivering: DI har som krav att åtkomst till data innehållande känslig personliga uppgifter skall ske med tvåfaktorsautentisering. Detta medför också att sättet som man distribuerar den andra faktorn, t.ex. en lösenordsdosa eller smart kort måste följa vissa strikta rutiner. NIST 800-63 är en standard som kan användas som underlag, men inom kort (våren 2013) kan man troligen peka på ett svenskt regelverk inom detta område, utgivet av e-legitimationsnämnden. Ett utkast finns redan nu att finna på deras webbsida, www.elegnamnden.se. Alla användare och alla administratörer skall använda unika användar-id. Motivering: För att kunna föra loggar baserade på individbasis måste varje konto vara kopplad till specifik individ. Detta gäller speciellt administratörskonton. Finns det ett generellt administratörskonto ska detta konto inte användas förutom i nödfall. Ett sådant generellt kontos lösenord ska därför förvaras på säker plats. Åtkomst till systemets loggar skall vara behörighetsstyrda. Motivering: Alla inom en organisation ska inte kunna komma åt alla system- eller händelseloggar, än mindre ha tillåtelse att ändra i dessa. Risken är att obehörig kan utföra en aktivitet som sedan kan raderas ur loggarna. Loggar kan i sin tur användas för att samla information om enskild person/brukare. Federering De flesta applikationer är idag publicerade genom ett webbgränssnitt. Detta ger möjlighet för applikationen att ta hjälp av en tredjepart som utför autentiseringen och utfärdar ett intyg som sedan accepteras av tjänsten, istället för att applikationen själv hanterar autentiseringen. Denna teknik kallas för federering och används redan nu av många verksamheter samt att denna typ av lösning är belagt med skall-krav från många organisationer i offentlig sektor vid upphandling. Tjänsten skall acceptera SAMLv2 (eller senare versioner). Motivering: Det finns ett antal olika federeringstekniker t.ex. Oauth, SAML och Open ID. Den offentliga förvaltningen i Sverige (baserat på branchpraxis och kommande krav från Sida 13 av 18

e-legitimationsnämnden och stora federationer såsom Skolfederationen, SAMBI och Swamid) har valt att använda sig av SAMLv2 med profilerna egov2.0 och saml2int. SAML-biljetterna skall skickas signerade samt kommunikationen skall ske över SSLv3/TLS1.0 Motivering: SAML tillåter att kommunikation kan gå okrypterat, men eftersom en federerad inloggning troligen ger åtkomst till känslig data bör även inloggningen krypteras av integritetsskäl. SAML-konfiguration skall kunna ske genom import av metadata. Motivering: För att kunna delta i en större federation måste en SAML-implementation kunna importera och hantera en s.k. metadatafil. Metadata skall/bör kunna exporteras ut från tjänsten/systemet för att publiceras hos federationssamordnaren. BÖR Övriga åtkomstvägar till tjänsten utöver autentiserade sessioner från utsedd(a) IdP(er) skall vara avstängda. Om tjänstens inloggnings-funktion och/eller autentisering innehåller bakvägar skall leverantören ansvara för att dessa vägar är avstängda. Motivering: Det är ofta att en leverantör hanterar SAML-inloggning (federerad inloggning) men samtidigt har kvar den gamla typen av inloggning, t.ex. användarnamn och lösenord vilket ger direkt access till tjänsten. Detta måste kravställas att inte finnas kvar. Likaså bör man kravställa att all administratörsåtkomst måste minst autentiseras på samma sätt som användaråtkomst. Åtkomst, access Åtkomstnivå bör kunna kopplas till olika autentiseringsnivåer/ BÖR -metoder/-tider/-platser etc. Motivering: Alla ska inte komma åt allt alltid och överallt. Detta krav knyter an till kravet att samtliga använder i systemet ska ha unika användar-id. Sida 14 av 18

Loggning och spårbarhet Tjänsteleverantör skall visa att regelbunden kontroll och verifiering görs av åtkomstloggar samt att resultat av denna verifiering meddelas kund. Motivering: Loggar som inte analyseras är bara till 50% användbara, nämligen som bevis eller hjälp när en händelse väl har inträffat. En regelbunden analys gör samma sak, men ger också möjlighet att fånga upp sådant som är onormalt och som kan klassas som incidenter. Tjänsten skall innehålla ett konfigurerbart stöd för loggning av aktiviteter (automatgenererade eller manuella) med uppgift om aktivitetstyp, användare och tidpunkt (enligt UTC). Motivering: Loggar ska alltid vara tidsstämplade med en spårbar tid så att loggkorrelering kan göras. Sida 15 av 18

Appendix 2 Exempel på frågeunderlag till tillverkare Nedan är ett generellt exempel på frågeformulär som skulle kunna skickas till leverantörer av produkter/tjänster vid en inledande dialog och utvärdering av produkterna. Användarkontots aktivering 1) Hur ser lösenordspolicyn ut: längd, krav på komplexitet osv? 2) Var kan man ändra lösenordet? Hur sker identifieringen vid lösenordsbyte? 3) Vilket dataskydd (kryptering) finns det för webbtjänsten (och andra ingående komponenter)? Används HTTPS? 4) Hur överförs lösenord och användarnamn till integrerade tjänster? Vilken typ av dataskydd görs? Vilken typ av verifiering görs från er sida att det är korrekt system man kommunicerar med? 5) Går det att använda sig av striktrare autentiseringsmetod än användarnamn/lösen, t.ex. eid (BankID, Telia, Nordea, SITHS)? Stödjer systemet federativ inloggning? Klientkommunikation 1) Vilken typ av kommunikation och typ av data? 2) Vilken typ av dataskydd (kryptering) används? 3) På vilket sätt verifieras att det är er tjänst kommunikationen går emot? Vad sker om denna verifikation inte kan genomföras? 4) Kan loggning stängas av från användaren? Går loggnivån att sätta lokalt? Vilken typ av loggdata skickas (läs: hur känslig är logginformationen som skickas)? Skydd av brukarens enhet, operativsystem mm 1) Vilket operativsystem körs i botten? 2) Hur är detta härdat (t.ex. avinstallation av oviktiga applikationer)? 3) Skyddas det med brandvägg och/eller antivirus. I så fall, hur uppdateras detta? 4) Vilken eller vilka fjärranslutningsmetoder är påkopplade? 5) Hur autentiseras en användare vid fjärranslutning för att t.ex. genomföra konfigurationsförändringar, uppdateringar och justeringar? 6) När och hur uppgraderas mjukvaran i brukarens enhet, t.ex. när rättningar har släppts för att laga funna säkerhetsbrister? Sida 16 av 18

Administrationsgränssnitt och centralt system De administratörsgränssnitt som tjänsten använder sig av är något som varken brukaren eller kunden får ta del av. Det intressanta är även här: vilka har tillgång till gränssnittet, hur identifieras/autentiseras användaren, vilket skydd av trafiken (kryptering) användas, vilka skydd för intrång användas etc. 1) Vilka tekniska, operativa och administrativa skydd finns för att skydda kundernas/ brukarnas data i det centrala systemet? Exempel på detta är brandväggar, IPS/IDS, krav på tvåfaktorsautentisering, kryptering av känslig information etc. 2) Beskriv aktivering av ny (eller utbyte av) trasig enhet samt avaktivering. 3) Beskriv aktivering och avaktivering av konton och behörigheter. 4) Beskriv åtkomst till loggar (vem eller vilka, typ av inloggning etc.). 5) Beskriv vilken del av personalen som har tillgång till administrationsgränssnitten och vilken utbildning/kompetens som ställs som krav innan de ges åtkomst. Loggning och insamling av data I och med att tjänsten kommer användas på ett sätt som troligen omfattas av PuL 9 och SolPuL 10 så krävs det att man ska kunna 1) ta del av, 2) kunna rätta och 3) ta bort data som kan kopplas till enskild individ. Nedan används ordet loggar för all typ av individkopplad data, men det kan även handla om användarkontouppgifter (epostadress, telefonnummer etc). 1) Vad loggas och hur länge sparas loggarna? 2) Hur skyddas och sparas ev. backuper av loggarna? 3) Vem har tillgång till loggarna? 4) Går det att gallra (rensa) i loggarna baserat på enskild individ? Kan enskild individ ta del av vad som finns registrerat om sig i ert system? 5) På vilket sätt förstörs loggarna när de inte längre behövs? Incidenthantering Om ett intrång görs i ert system eller att ni får vetskap att det har skett hos annan part vilka rutiner finns då att tillgå? Övrigt Är det något som inte är medtaget, men som ni vill göra uppmärksammat, så är det absolut välkommet! 9 Personuppgiftslag (1998:204) 10 Lag (2001:454) om behandling av personuppgifter inom socialtjänsten. Denna lag hanterar inga säkerhetsaspekter, utan är endast ett tillägg till PuL för att ge tillåtelse till bl.a. socialtjänsten att lagra känsliga personuppgifter. Sida 17 av 18

Appendix 3 Tekniska specifikationer För att göra texten mer lättlåst ovan, så har tekniska specifikationer kring kryptering och krypteringsnyckelhantering flyttats hit. Kryptering Som det är angivet i texten ovan så är olika typer av kryptering olika säker. Sveriges Kommuner och Landsting, SKL, gjorde 2010 en utredning i denna fråga och i rapporten Säkerhetskrav och specifikationer för informationsutbyte via Internet specificeras följande dataskyddsnivåer 11 : Klassning 1 Klassning 2 Klassning 3 Klassning 4 Kryptering Inget krav Minst DES Minst AES-128 AES-256 3DES/TDEA RC4 Protokoll Inga krav SSH SSL 3.0 TLS 1.0+ IPsec SSH SSL 3.0 TLS 1.0+ IPsec SSH SSL 3.0 TLS 1.0+ IPsec Nyckelhantering Inga krav Ej i klartext, Skickas out-of-band Certifikat Certifikat, lagrade i HSM Tabell 1: Krypteringskrav på klassat data I tabellen ovan nämns klassning vilket står för en sammanvägning av de olika skyddsbehoven av sekretess, integritet och tillgänglighet. Dataskyddsnivån värderas genom att följa modellen för klassificering av information som myndigheten för samhällsskydd och beredskap, MSB, gav ut 2009. I dokumentet står det bland annat att för nivå 3 gällande sekretess: Information där förlust av konfidentialitet innebär betydande negativ påverkan på egen eller annan organisation och dess tillgångar, eller på enskild individ. Information klassat i enlighet med nivå 3 skulle alltså få ett krav på sig att hanteras krypterat när det sänds över öppna nätverk, minst med skydd motsvarande kryptering med AES-128. I samband med information som utväxlas inom området för hemtjänst, är den troliga klassningen av informationen och informationssystemen klass 3. Genom att ställa krav på vilken kryptering som ska användas, måste man också ställa krav på att sämre kryptering inte ska kunna användas. Som konkret exempel ska osäkra tekniker som t.ex. SSL v2 vara avstängt på de tjänster som exponeras. 11 Motsvarande arbete har också gjorts på uppdrag av för Apotekens Service AB och kan läsas på http://www.apotekensservice.se/documents/risk_sakerhet/tillampning_kryptografis ka_algoritmer.pdf Sida 18 av 18