Transcript Rapport it-säkerhet – Hjälpmedel inom eHemtjänst

Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
Säkerhetsaspekter
gällande eHemtjänst-produkter
HJÄLPMEDEL INOM EHEMTJÄNST .................................................................................................................... 2
BEHANDLING AV PERSONUPPGIFTER ............................................................................................................................. 2
KRAV 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 - KRAVKATALOG ......................................................................................................................... 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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
1
administrativa, operativa och tekniska skyddsmekanismer ä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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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,
2
MSB, klassningsmodell . 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
för att kunna betraktas som säkert. Dessa krav är exempelvis:




2
3
3
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.
Läs mer om informationsklassning på MSBs webb, www.informationssakerhet.se
Kraven står att finna på https://testalosenord.pts.se.
Sida 4 av 18
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15


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
4
anses vara mycket svårt att knäcka .
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 15
faktorsautentisering 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 elegitimationsnä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.
Observera att två lösenord efter varandra inte är en 2-faktorsautentisering, eftersom man måste
blanda de olika informationsformerna.
5
Sida 5 av 18
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
6
journaler , 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)
7
tillhandahåller över protokollet NTP .
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
8
alla mjukvara kräver en ytterligare auktorisation . 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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
KRAV
Ö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 §)
TYP
SKALL
KRAV
Överordnat krav: Om systemet hanterar personuppgifter skall det gå att
gallra uppgifter för enskild individ (PuL 12 §)
TYP
SKALL
KRAV
Överordnat krav: Om systemet hanterar personuppgifter skall det gå att
ta del av de uppgifter som rör användaren (PuL 26 §)
TYP
SKALL
KRAV
TYP
Enheter som tas ur drift (avvecklas) skall raderas från samtlig data som
SKALL
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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.
KRAV
TYP
Webbtjänsten skall kunna tillhandahålla följande protokoll för säker
SKALL
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.
KRAV
TYP
I de fall lösenord används inom systemet skall dessa vara krypterade
SKALL
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.
KRAV
TYP
System (och organisation) som använder sig av kryptering skall ha en
SKALL
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.
KRAV
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.
TYP
SKALL
Skydd av data vid integration med andra system
KRAV
TYP
Systemet som vänder sig mot medborgare och utförare skall
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
KRAV
TYP
I det fall automatiserade integrationer finns (exempelvis webbservices och
SKALL
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
KRAV
TYP
Om systemet hanterar känslig information skall all typ av åtkomst baseras
SKALL
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.
KRAV
TYP
Alla användare och alla administratörer skall använda unika användar-ID.
SKALL
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.
KRAV
TYP
Åtkomst till systemets loggar skall vara behörighetsstyrda.
SKALL
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.
KRAV
TYP
Tjänsten skall acceptera SAMLv2 (eller senare versioner).
SKALL
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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.
KRAV
TYP
SAML-biljetterna skall skickas signerade samt kommunikationen skall ske
SKALL
ö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.
KRAV
TYP
SAML-konfiguration skall kunna ske genom import av metadata.
SKALL
Motivering: För att kunna delta i en större federation måste en SAML-implementation
kunna importera och hantera en s.k. metadatafil.
KRAV
Metadata skall/BÖR kunna exporteras ut från tjänsten/systemet för att
publiceras hos federationssamordnaren.
TYP
BÖR
KRAV
TYP
Övriga åtkomstvägar till tjänsten utöver autentiserade sessioner från
SKALL
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
KRAV
TYP
Å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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
Loggning och spårbarhet
KRAV
TYP
Tjänsteleverantör skall visa att regelbunden kontroll och verifiering görs
SKALL
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.
KRAV
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.
TYP
SKALL
Sida 15 av 18
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
9
I och med att tjänsten kommer användas på ett sätt som troligen omfattas av PuL och
10
SolPuL 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)
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.
10
Sida 17 av 18
Säkerhetsaspekter gällande
eHemtjänst-produkter/tjänster
2012-11-15
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
11
följande dataskyddsnivåer :
Kryptering
Klassning 1
Inget krav
Protokoll
Inga krav
Klassning 2
Minst DES
SSH
SSL 3.0
TLS 1.0+
IPsec
Nyckelhantering Inga krav
Ej i klartext,
Skickas out-of-band
Tabell 1: Krypteringskrav på klassat data
Klassning 3
Minst AES-128
3DES/TDEA
RC4
SSH
SSL 3.0
TLS 1.0+
IPsec
Certifikat
Klassning 4
AES-256
SSH
SSL 3.0
TLS 1.0+
IPsec
Certifikat,
lagrade i HSM
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