DNSSEC Policy (DP) Denna DP gäller gemensamt för:
|
|
- Karl-Erik Sundberg
- för 8 år sedan
- Visningar:
Transkript
1 Författare: Stephen Dorch Sida: 1 av 17 DNSSEC Policy (DP) Denna DP gäller gemensamt för: Borgholms kommun org.nr Emmaboda kommun org.nr Hultsfreds kommun org.nr Högsby kommun org.nr Kalmar kommun org.nr Mönsterås kommun org.nr Mörbylånga kommun org.nr Nybro kommun org.nr Oskarshamns kommun org.nr Torsås kommun org.nr Västerviks kommun org.nr Vimmerbys kommun org.nr Enligt beslut av respektive IT-ansvarig vid tidpunkt enligt tabell sid 2.
2 Författare: Stephen Dorch Sida: 2 av 17 Dokumentkontroll Dokumentation & säkerhet Uppförd av Faktaansvarig Dokumentansvarig Stephen Dorch, Informationssäkerhetssamordnare, Regionförbundet i Kalmar län Stephen Dorch och ITcheferna i Kalmar läns kommuner Stephen Dorch Säkerhetsklass Filnamn Öppen DP v1.0 Godkänd av Datum Namn Funktion DNSSEC styrgrupp Införandeprojektets styrgrupp IT-chef Västervik IT-chef Oskarshamn IT-chef ITsam (Vimmerby) IT-chef Hultsfred IT-strateg Högsby IT-chef Mönsterås IT-chef Kalmar IT-chef Nybro IT-chef Emmaboda IT-chef Torsås IT-chef Borgholm IT-chef Mörbylånga Revisioner Datum Ver. Publicerad Namn Beskrivning v1.0 Nej Stephen Dorch Redovisning till styrgrupp v1.01 Nej Stephen Dorch Mindre uppdatering i om dnssec samt ändring av publicering till publik v1.02 Nej Stephen Dorch Uppdaterad efter remiss från styrgrupp v1.03 Nej Stephen Dorch Uppdaterad efter remiss från kommuner v1.04 Nej Stephen Dorch Uppdaterad med rätt versionshantering
3 Författare: Stephen Dorch Sida: 3 av 17 Innehållsförteckning 1. Om DNSSEC DP & DPS samt säkerhetsdeklaration Registrant, Registrar och Förlitande part Publicering av DP Fysisk, administrativ och personalorienterad säkerhet Fysisk säkerhet Administrativ säkerhet Personorienterad säkerhet Spårbarhet Kontinuitetsplanering Revisionshantering Autentisering Uppdatering / Redigering Övervakning Teknisk säkerhet Skydd av privata nycklar Säkerhet i kommunikationsnätverk DNS struktur Tidsstämpling Distribution Signering Nyckellängder och algoritmer Autentiserade negativa svar Nyckelrullning Signaturlivslängd DNS-postens livslängd ( TTL ) Hantering av DS-poster för barnzoner Hantering av DS-poster till föräldrazonen Uppföljning Granskning och revision Egna krav Kommunernas egendefinierade krav... 17
4 Författare: Stephen Dorch Sida: 4 av 17 Ordförklaringar DNS DNSSEC DP DPS DS FIPS HSM KASP KSK Domain Name System DNS Security Extensions DNSSEC Policy. En övergripande policy på hur DNSSEC ska hanteras i organisationen. DNSSEC Practice Statement. En beskrivning på hur DNSSEC faktiskt tillämpas i organisationen. Delegation Signer. Är en DNS-post där föräldrazonen pekar ut en nyckel i barnzonen som kan användas vid validering av DNSSEC. En amerikansk säkerhetsstandard för säkerhetsmoduler. Hardware Secuirty Module. Specialiserad hårdvara som fysiskt skyddar nycklarna samt kan ge ökad kryptografisk prestanda. Key And Signing Policy Key Signing Key. Huvudnyckeln som signerar det nyckelset som används vid signering av zonen. M-av-N Flerpersonskontroll. Ett antal, M, personer ur en betrodd grupp, N, måste vara på plats för att en operation skall få genomföras.
5 Författare: Stephen Dorch Sida: 5 av 17 NSEC NSEC3 PIN SA SO Säkerhetsmodul TLD TTL Zon ZSK Next Secure. En DNS-post för DNSSEC som används vid autentisering av negativa DNS-svar. Next Secure 3. Vidareutveckling av NSEC. Personal Identification Number. Lösenord. System Administrator. Systemadministratör. Security Officer. En betrodd roll som ansvarar för säkerheten i systemet. Se HSM. Top-Level Domain. Toppdomän. Time to Live. Tiden som DNS-information sparas i en resolver. Är den del i DNS-namnrymden till vilket organisationen har fått ett tilldelat administrativt ansvar. Zone Signing Key. En underliggande nyckel som signerar informationen i zonen.
6 Författare: Stephen Dorch Sida: 6 av Om DNSSEC DNSSEC är en uppsättning poster och protokollmodifieringar som möjliggör identifiering av källan i DNS och gör det även möjligt att säkerställa att innehållet inte har ändrats under överföringen. Uppslagningar med DNSSEC är kryptografiskt signerade och använder sig av asymmetrisk kryptografi i DNShierarkin, där tilliten följer samma distribution som DNSträdet, dvs. tilliten utgår från roten och delegeras på samma sätt som ansvaret för en domän. Detta dokument är en överenskommelse mellan kommunerna i Kalmar län avseende minsta nivå på säkerhetsåtgärder och rutiner relaterat till DNSSEC. Dokumenttypen är DNSSEC Policy, hädanefter förkortas som DP. Målgruppen för DP är IT-tekniker och IT-ansvariga. Innehållet är anpassat till målgruppen med ett för IT-branchen förekommande språkbruk och vedertagna förkortningar som för den oinvigde ter sig tämligen svårtolkat. Varje enskild kommun i Kalmar län har en beskrivning på hur DNSSEC är uppsatt och på vilket sätt kraven i den gemensamma DP:n uppnås. Dokumenttypen för detta ändamål är DNSSEC Practice Statement, hädanefter förkortas DPS. DP och DPS är två av flera relevanta dokument för driften av kommunernas IT-system. Andra relevanta dokument är respektive kommuns informationssäkerhetspolicy, regler och riktlinjer. I vissa fall refereras till dessa dokument som till viss del kan innehålla känslig information och därför är belagda med sekretess. 1.1 DP & DPS samt säkerhetsdeklaration Kommunerna i Kalmar län har en gemensam DP för samtliga kommuner. DP anger en lägsta nivå för drift, förvaltning och rutiner avseende DNS-systemet. Varje enskild kommun har en egen DPS som anger hur kraven i DP uppfylls. Säkerhetsdeklarationen uppdateras som en enskild flik i DPS. - eftersträva en tillitsnivå som motsvarar den överenskomna nivån mellan kommunerna i Kalmar län - dokumentera tillitsnivån i egen DPS - minst en gång per år presentera sin säkerhetsdeklaration för samverkande kommuner. Säkerhetsdeklarationen utgör en del i kommunens DPS. - inga bör-krav är framtagna
7 Författare: Stephen Dorch Sida: 7 av Registrant, Registrar och Förlitande part Den som innehar ett domännamn benämns som Registrant (innehavare). Kommunen är en Registrant och ansvarar för sin kommuns samtliga domäner inklusive subdomäner, domäner relaterade till funktioner och eventuellt kommunala bolag. En Registrar är den part som ansvarar för administration och förvaltning av domännamn för en innehavares räkning. Förlitande part är de som förlitar sig på säkerhetsfunktionen DNSSEC t.ex. validerande resolvrar och andra tillämpningar. - upprätthålla förteckning över aktuella registrarer - ansvara för att generera och skydda sina egna nycklar, oavsett om det sker i egen verksamhet eller hos servicebyrå (externt) - ansvara för att registrera och underhålla DS-poster hos registraren - ha rutin för att hålla sig informerad om relevanta händelser relaterade till DNSSEC - ha en process för att uppdatera sin egen DPS - upprätthålla förteckning över historiska registrarer 1.3 Publicering av DP Den regionala DP:n innehåller endast överenskomna krav och innehåller inte några hemliga uppgifter. Genom att publicera den Regionala DP:n visar vi för andra vilka krav vi ställer på oss själva i syfte att upprätthålla förtroende och tillit. Den regionala DP:n tillgängliggörs för samtliga kommuner på överenskommen plats. - godkänna att den regionala DP:n sparas på en för länets kommuner överenskommen publik hemsida 1. - inga bör krav framtagna 1 Styrgruppen för DNSSEC beslöt att DP:n ska sparas publikt tillsammans med projektrapport och samtliga bilagor
8 Författare: Stephen Dorch Sida: 8 av Fysisk, administrativ och personalorienterad säkerhet Den fysiska säkerheten är till för att skydda den utrustning som hanterar DNS och DNSSEC. Detta för att förhindra manipulation, stöld, olyckor eller motsvarande. Det är viktigt att enbart behörig personal har tillgång till de datorsystem som hanterar DNSSEC. Om obehöriga får tillgång till utrymmet kan de logiska skydden relativt enkelt sättas ur spel. Utrymmet bör även ha skydd mot brand, vätska, strömavbrott och liknande. Om inte samtliga skydd är möjliga att införa, så är det viktigt att man har bra rutiner och säkerhetskopior för att komma igång på en alternativ driftsplats. 2.1 Fysisk säkerhet Med fysiskt säkerhet avses t.ex. behov av fysiskt skydd, åtkomst och behörigheter, UPS/reservkraft, hantering av nycklar, destruktion av data och alternativ lagringsplats. - placera utrustning och media med känslig information i skyddade utrymmen där enbart behöriga personer har tillträde - vid avveckling destruera media som hanterat känslig information - förvara säkerhetskopior på annan fysisk lokation än originalet - ha en alternativ driftmiljö på en fysiskt skild plats i händelse av driftproblem - använda UPS och/eller reservkraftsanläggning på den primära driftplatsen - ha rutiner för att stänga av servrar på ett kontrollerat sätt vid längre strömavbrott - ha detektorer för och skydd mot vätska på den primära driftplatsen - ha system för branddetektering och brandsläckning på den primära driftplatsen - utrusta utrymmet med automatisk släckanläggning på den primära driftplatsen - se till att utrymmet är en egen brandcell på den primära driftplatsen 2.2 Administrativ säkerhet Endast personer vars arbetsuppgifter motiverar det, och som genomgått erforderlig utbildning, ska ges åtkomst till signeringssystemet. Tilldelade behörigheter ska regelbundet granskas. Syftet är att skydda processer/arbetsflöden som hanterar känsliga uppgifter. - ha en roll motsvarande Systemadministratör (SA) som ansvarar för den tekniska hanteringen av DNS - ha en process innebärande att IT-chefen ger aktivt godkännande vid förändring av bemanning eller uppdragsbeskrivning för SA för DNS - enbart tillåta behörig personal att få tillgång till systemen - inga bör-krav är framtagna
9 Författare: Stephen Dorch Sida: 9 av Personorienterad säkerhet Minst två personer inom kommunen ska ges det utpekade ansvaret för systemet, samt ha erhållit nödvändig utbildning för att på egen hand och på ett betryggande sätt kunna administrera systemet och utföra felavhjälpning inom den tid som krävs för att upprätthålla zondatas tillgänglighet. Kompetens och rutiner för SA är exempelvis incidenthantering, krishantering, rutiner, checklistor osv. - upprätta en kravspec för SA-rollen - ha minst två personer som innehar SA-rollen - tillhandahålla relevant och erforderlig utbildning anpassad för rollens omfattning, ansvarsområde och befogenheter - tillse att samma krav gäller för kontrakterad SA som för fast anställd SA för motsvarande roll - tillse att aktuell och uppdaterad dokumentation finns tillgänglig så att SA kan genomföra sina uppgifter på ett säkert och fullgott sätt - repetitionsutbilda SA minst vid de tillfällen då större förändringar sker i rutiner eller i de tekniska system 2.4 Spårbarhet För att i efterhand kunna spåra ändringar i information och vilken information som har förändrats, bör krav på spårbarhet ställas. För att underlätta uppföljning bör det även finnas möjlighet att följa ett revisionsspår av dessa förändringar i befintligt ärendehanteringssystem och där kunna utröna transaktionens ursprung och orsak. För delar av kraven nedan kan loggning ske i dokument/ärendehanteringssystem, som t.ex. Nilex eller liknande. - upprätta en logg över incidenter i systemet och som ger svar på vad, vem och när - upprätta en logg över förändring av konfiguration och/eller data och som ger svar på vad, vem och när (Se vägledning K1) - upprätta en logg över händelser som inträffar vid fysisk åtkomst av systemet och som ger svar på vad, vem och när (i vissa fall kan manuell logghantering vara nödvändig för att hantera fysisk åtkomst) - upprätta en logg över samtliga inloggningar mot system som handhar dnssec och som ger svar på vad, vem och när - tillse att loggar skyddas mot otillbörlig förändring - fastställa frekvens för kontroll av loggdata - fastställa lagringstid för loggar - skriva loggar till ett separat loggsystem utanför DNSSEC-systemet - tillse att det är möjligt att till varje förändring bifoga information, t.ex. en kommentar eller ett ärendenummer (Se vägledning K2)
10 Författare: Stephen Dorch Sida: 10 av Kontinuitetsplanering Vid händelse av att fel inträffar krävs beredskap för att avhjälpa felet och återgå til normal drift. En kontinuitetsplan ska upprättas som innefattar rutiner för att hantera röjt eller otillgängligt nyckelmaterial, samt metoder för att återstarta eller byta till en helt ny valideringskedja. Kontinuitetsplanen och metoderna för återstart ska övas regelbundet. - ha en rutin för att hantera röjt nyckelmaterial - ha en rutin för att återstarta en valideringskedja (t.ex återpublicera ds-post efter att zonen varit osignerad) - ha kunskap om hur man byter till ny valideringskedja (t.ex. vid byte av KSK) - ha kunskap om kontinuitetsplanen (dvs att ha kontroll över vilka rutiner som gäller vid en oväntad händelse) - ha en fastställ katastrofplan (så att återstart av DNSSEC kan ske från alternativ plats) - ha en rutin för test av katastrofplan - ha en fastställ process för genomförande av säkerhetsuppgraderingar - ha en rutin för att öva återstart (t.ex återläsning av backup på testsystem) - ha rutin att hantera otillgängligt material (t.ex ett disk-haveri) 2.6 Revisionshantering Förutom att veta vem som har gjort vad och när, så finns det ibland behov av att kunna gå tillbaka och jämföra vilken information som funnits i systemet vid olika tidpunkter. - tillse att information i DNS revisionshanteras (Se vägledning K3) - tillse att det finns möjlighet att visa skillnaden mellan två olika revisioner (Se vägledning K4) - tillse att det finns möjlighet att återställa data från en tidigare revision (Se vägledning K5) - inga bör-krav är framtagna.
11 Författare: Stephen Dorch Sida: 11 av Autentisering Samtliga användare av systemet ska autentiseras och använda unika och personliga systemidentiteter. För att inte behöva administrera flera uppsättningar systemidentiteter, bör dessa kunna verifieras mot externt behörighetskontrollsystem. - tillse att samtliga användare autentiseras vid användning av systemet (Se vägledning K6) - tillse att personliga användaridentiteter alltid användas (Se vägledning K7) - tillse att användarkonton kan hämtas från externa system, till exempel LDAP eller RADIUS (Se vägledning K8) - tillse att autentisering kan ske mot externa system, till exempel LDAP, Kerberos eller RADIUS (Se vägledning K9) - tillse att samtliga användare kan autentiseras med stark autentisering vid användning av systemet 2.8 Uppdatering / Redigering Ändring av information som publiceras via DNS bör ske på ett sätt som förutom att det uppfyller kraven på spårbarhet och åtkomstkontroll, också minimerar risken för att felaktig information publiceras. Detta kan uppfyllas genom kontroller vid inmatning eller genom att informationen kontrolleras ytterligare en gång innan publicering. - tillse att system som används för uppdatering av DNS innehålla kontroller för att säkerställa att felaktigt formaterat data inte kan publiceras (Se vägledning K10) - tillse att system för uppdatering kunna hantera olika användarbehörigheter, till exempel styra vilka användare som får redigera viss information (Se vägledning K11)
12 Författare: Stephen Dorch Sida: 12 av Övervakning För att säkerställa zonens tillgänglighet och tidigt kunna upptäcka och agera på fel, krävs ingående övervakning av zondata, nycklar och signaturers tillstånd. Det som övervakas är tidssynkronisering, signaturer på slavservrar och deras aktualitet på slavservrar, DS- och NSposter på överliggande zon samt nyckelpostens aktualitet - tillse att övervakningssystemet kontrollerar att signaturer uppdateras enligt gällande konfiguration (Se vägledning K45) - tillse att övervakningssystemet kontrollerar att samtliga namnservrar svarar med korrekta autentiserade positiva svar för zonens SOA- NS- samt DNSKEY-poster (Se vägledning K46) - tillse att övervakningssystemet kontrollerar att samtliga namnservrar svarar med korrekta autentiserade negativa svar (Se vägledning K47) - tillse att övervakningssystemet kontrollerar att samtliga namnservrar är uppdaterade med aktuella data (Se vägledning K48) - tillse att övervakningssystemet kontrollerar att samtliga DNS-slavar har korrekt tid (Se vägledning K49)
13 Författare: Stephen Dorch Sida: 13 av Teknisk säkerhet De privata nycklarna som används för DNSSEC skall enbart hanteras på det system där de skall användas, om inte en tillförlitlig överföring kan säkerställas. Enbart godkända processer och användare skall ha tillgång till nycklarna, detta för att minimera risken att de kan läcka från systemet. Vidare måste säkerhetskopior av nycklarna göras för att säkerställa den framtida driften. Systemet som hanterar DNSSEC-signeringen skall placeras på det interna nätverket som en så kallad hidden-master. De privata nycklarna skyddas då av flera logiska lager och är därmed inte direkt tillgängliga från internet. 3.1 Skydd av privata nycklar Det är viktigt att filen som innehåller nycklar skyddas på ett säkert sätt. De privata komponenterna av nycklar som används för DNSSEC ska aldrig lagras på beständigt lagringsmedia i oskyddad (okrypterad) form. Aktiveringsdata ska skyddas på motsvarande sätt och bytas vid behov. - ha säkerhetskopior av nycklarna som förvaras på en åtkomstsäker fysiskt skild plats - tillse att aktiveringsdata (lösenord) som krävs för avkryptering av privata nycklar förvaltas av utpekade ansvariga SA - tillse att aktiveringsdata byts om någon av de utpekade SA lämnar sin anställning eller ges andra arbetsuppgifter. Ansvaret för att detta utförs vilar på närmaste chef - tillse att nyckelpar slumpmässigt genereras så att det är beräkningsmässigt ogörligt att återskapa - tillse att använda nycklar avsedda för DNSSEC aldrig används för annat ändamål - tillse att lagrade nycklar skyddas mot insyn och förändring (t.ex. kryptering) om separat säkerhetsmodul inte används (se vägledning K19) - tillse att samtliga signeringsnycklar (KSK/ZSK) lagras på krypterat lagringsmedia. Detta som skydd vid t.ex. utbyte av hårdvara - tillse att nyckelhanteringssystemet stödjer lagring av nycklar i en separat säkerhetsmodul (HSM, Hardware Security Module) (Se vägledning K18) 3.2 Säkerhet i kommunikationsnätverk Systemet som hanterar DNSSEC-signeringen skall placeras på det interna nätverket som en så kallad hidden-master. De privata nycklarna skyddas då av flera logiska lager och är därmed inte direkt tillgänglig från internet. - placera den del av systemet som sköter signeringen på det interna nätverket som en så kallad hidden-master - tillse att enbart de sekundära namnservrarna kan nås direkt från internet - tillse att signeringssystemet logiskt separeras från samtliga nätverk så att endast nödvändig trafik kan flöda till och från systemet
14 Författare: Stephen Dorch Sida: 14 av DNS struktur Ett väl fungerande DNS-system bygger inte bara på att DNSSEC finns utan även på att infrastrukturen ser bra ut. Robustheten i DNS uppnås genom att informationen finns replikerad på flera servrar. Det är därför viktigt att tillgängliggöra informationen så att den finns på minst två skilda nätverk (AS-nummer). Kan bland annat uppnås genom att använda två oberoende operatörer. - ha zonen på minst två publika namnservrar - ha namnservrar på minst två olika nätverk (Autonomous System, AS) - ha minst en namnserver tillgänglig över IPv6 - vid upphandling kravställa att tjänsteleverantörer bör vara signerade med DNSSEC - ha minst två namnservrar tillgängliga över IPv6 3.4 Tidsstämpling Det är viktigt att maskinklockor i samtliga enheter är synkade mot en säker gemensam tidskälla. - ha alla klockor synkroniserade mot, av verksamheten utsedda, säkra tidskällor - inga bör-krav är framtagna 3.5 Distribution Följande krav specificerar en miniminivå på system för distribution av DNSSEC-signerade zoner. - tillse att all zonöverföring är skyddad mot förändring och avkortning (trunkering) (Se vägledning K33) - tillse att zonöverföring skyddas mot förändring och avkortning genom TSIG (Se vägledning K34) - tillse att zonöverföring autentiseras genom någon av algoritmerna i familjen HMAC-SHA [10] eller GSS-TSIG [24] (Se vägledning K35) - tillse att zonöverföring inte autentiseras genom algoritmen HMAC-MD5 (Se vägledning K36)
15 Författare: Stephen Dorch Sida: 15 av Signering De krav som ställs vad gäller zonsignering ger en lägsta nivå som skall följas. Använd en algoritm som är allmänt tillgänglig och resurseffektiv för alla inblandade parter. DNSSEC introducerar absoluta tider i och med de digitala signaturerna, som har en starttid och en sluttid vad gäller dess giltighet. Utgångspunkten i detta läge är att det skall finnas tillräckligt med tid för att få personal på plats samt genomföra felsökning innan signaturerna går ut. 4.1 Nyckellängder och algoritmer Algoritmer och nyckellängder ska väljas så att dess styrka står i proportion till nycklarnas användningsperiod och signaturernas giltighetstid. - använda nyckellängder och algoritmer med en styrka som är tillräcklig för ändamålet under respektive nyckels livslängd - använda algoritmer som är standardiserade av IETF, allmänt tillgängliga och resurseffektiva för alla inblandade parter - använda RSA/SHA-256 algortimen med minsta nyckellängd av 2048 bitar för KSK - använda RSA/SHA-256 algortimen med minsta nyckellängd av 1024 bitar för ZSK 4.2 Autentiserade negativa svar NSEC3 används i normalfallet endast då man önskar försvåra för utomstående att genom uttömmande sökning samla in samtliga i zonen ingående poster. För att slippa göra bedömningen om detta skydd är motiverat eller inte, rekommenderas att alltid använda NSEC3 för samtliga zoner. - använda valfri metod för autentiserade negativa svar, NSEC eller NSEC3 - tillse att algoritmer som tillämpar MD5 som hashsumma inte används - begränsa antalet NSEC3-iterationer till 10 för att bibehålla systemets prestanda - tillse att byte av NSEC3-salt sker minst en gång per år 4.3 Nyckelrullning Byte av nyckelsigneringsnycklar kräver interaktion med föräldrazonen. Nycklar som refereras till i ovanliggande zon bytes endast vid misstankar om att nyckeln blivit röjd, om nyckel förlorats eller om omständigheterna föranleder byte av nyckellängd eller algoritm. - ha kontroll på livslängd och bytesintervall av zonsigneringsnycklarna - byta KSK vid behov - byta ZSK var tredje månad (med automatik)
16 Författare: Stephen Dorch Sida: 16 av Signaturlivslängd För att med god marginal kunna hantera driftstörningar under bland annat långhelger och semestertider, rekommenderas att man sätter en förhållandevis lång livslängd på signaturer. Detta bör kombineras med en daglig omsignering. - välja signaturlivslängd och frekvens för omsignering på ett sådant sätt att signaturerna alltid är giltiga tillräckligt länge för att eventuella systemfel kan åtgärdas innan signaturerna går ut - ha signaturlivslängderna satta till 32 dagar - tillse att omsignering sker dagligen 4.5 DNS-postens livslängd ( TTL ) Indikeringen för zondatas maximala giltighetstid (SOA Expire) ska harmoniseras så att zondata i slavservrar som inte uppdateras blir ogiltiga innan signaturernas livslängd går ut. - sätta SOA Expire till ett värde som är mindre än den kortaste signaturlivslängden. Detta för att se till att zonen går ut innan signaturerna går ut - sätta livslängden för nyckelposter för DNSSEC (DNSKEY) till maximalt 1 timma - sätta SOA Expire till 30 dagar ( sekunder) - sätta livslängden för autentiserade negativa svar (NSEC3) till samma värde som angetts för SOA Minimum, vilket dock aldrig bör överstiga 1 timma 4.6 Hantering av DS-poster för barnzoner Det är möjligt att delegera delar av en DNS-domän till en annan administrativ avdelning eller motsvarande. Den andra avdelningen har då en egen uppsättning av DNS-servrar som är ansvariga för informationen. DNSSEC kan fortfarande säkra systemet genom publicering av DS-poster i den egna zonen. Dessa DS poster pekar på vilka nycklar som används för signering hos barnzonen. - tillse att om signerade barnzoner finns ska rutiner för publicering av DS-poster i den egna zonen finnas (Om inga signerade barnzoner finns är kravet uppfyllt) - tillse att om signerade barnzoner finns ska rutiner för avpublicering av DS-poster i den egna zonen finnas (Om inga signerade barnzoner finns är kravet uppfyllt) - tillse att förändringsförfrågan kommer från en behörig person för barnzonen - inga bör-krav är framtagna
17 Författare: Stephen Dorch Sida: 17 av Hantering av DS-poster till föräldrazonen För att zonen skall anses vara signerad av externa parter så räcker det inte bara att aktivera DNSSEC i den egna zonen, utan den måste även signeras genom att en DS-post publiceras i föräldrazonen. - ha rutiner för publicering av DS-poster i föräldrazonen - ha rutiner för avpublicering av DS-poster i föräldrazonen - ha rutiner för beslut om tillbakadragande av DS-post hos föräldrazon - ha ett godkännande från två betrodda personer vid en förändringsförfrågan 5. Uppföljning IT-säkerhet är föränderligt och ska ses över kontinuerligt. Minst vartannat år måste system, rutiner, policy och liknande som hanterar DNSSEC ses över. 5.1 Granskning och revision Granskning och revision kan ske av person med kunskap om och förståelse för DNSSEC och med hjälp av lämpliga verktyg för IT-säkerhetsgranskningar. I säkerhetsdeklarationen, som återfinns som en flik i DPS-mallen, sammanfattas hur kommunen hanterar DNSSEC i relation till de krav som ställs i denna DP. - granska och revidera DPS minst vartannat år med hjälp av interna resurser och regionförbundets informationssäkerhetssamordnare - ha rutin för att tekniskt granska att DPS-deklarationen överensstämmer med den faktiska konfigurationen - ha rutiner för att åtgärda de anmärkningar som framkommer vid granskning och revision - ha rutin för extern revision på system, rutiner, policy och dylikt. 6. Egna krav Kommunerna kan om de så önskar definiera egna krav utöver de som är upptagna i denna DP. De egna kraven framgår av respektive kommuns egna DPS samt i säkerhetsdeklarationen. 6.1 Kommunernas egendefinierade krav Se eventuella egendefinierade krav i kommunens DPS. - uppfylla sina egna skall-krav, se kommunens DPS - - uppfylla sina egna bör-krav, se kommunens DPS -
kirei Vägledning: DNSSEC för kommuner Rapport Regionförbundet i Kalmar län Kirei 2013:02 5 april 2013
kirei Rapport 5 april 2013 Regionförbundet i Kalmar län Kirei 2013:02 Vägledning: DNSSEC för kommuner Innehåll 1 Introduktion... 2 1.1 Bakgrund... 2 1.2 Syfte... 2 1.3 Struktur... 2 2 Kravrekommendationer...
Läs merHot mot nyckelhantering i DNSSEC och lite om hur man undviker dem. Anne-Marie Eklund Löwinder Kvalitets- och säkerhetschef
Hot mot nyckelhantering i DNSSEC och lite om hur man undviker dem Anne-Marie Eklund Löwinder Kvalitets- och säkerhetschef Överväganden Införandet av DNSSEC nödvändiggör en juridisk analys. Vilken riskexponering
Läs merRekommendationer för införande av DNSSEC i kommuner och motsvarande verksamheter DNSSEC DNS
Rekommendationer för införande av DNSSEC i kommuner och motsvarande verksamheter DNSSEC DNS Detta verk är licensierat under en Creative Commons ErkännandeIckekommersiell-IngaBearbetningar 2.5 Sverige http://creativecommons.org/licenses/by-nc-nd/2.5/se/
Läs merRekommendationer för införande av DNSSEC i kommuner och motsvarande verksamheter DNSSEC DNS
Rekommendationer för införande av DNSSEC i kommuner och motsvarande verksamheter DNSSEC DNS Rekommendationer för införande av DNSSEC i kommuner och motsvarande verksamheter Detta verk är licensierat under
Läs merDNSSEC. Slutrapport. Kalmar läns kommuner 2013. Kalmar län, det grönaste länet!
Författare: Stephen Dorch Sida: 1 av 18 DNSSEC Slutrapport Kalmar läns kommuner 2013 Kalmar län, det grönaste länet! Författare: Stephen Dorch Sida: 2 av 18 Innehållsförteckning 1. Sammanfattning... 4
Läs merSignering av.se lösningar och rutiner. Anne-Marie Eklund Löwinder Kvalitets- och säkerhetschef
Signering av.se lösningar och rutiner Anne-Marie Eklund Löwinder Kvalitets- och säkerhetschef Varför ville vi ha DNSSEC i.se? Ökar integriteten I DNS. Ökar säkerheten för.se:s domäninnehavare och deras
Läs merRapport Kalmar Län 2013 Interlan Gefle AB Filialkontor
Kalmar Län 2013 Innehåll Förord...3 Före och efter...3 Vad är DNS och DNSSEC?...4 Att använda DNSSEC...4 Hindra attacker mot DNS-frågor...4 För välbesökta webb-platser...4 Fördjupande information...4 Projektresultat...5
Läs merVägledning för införande av DNSSEC
Vägledning Version 1.0 2010-10-22 Vägledning för införande av DNSSEC Framtagen i samarbete mellan E-delegationen, Sveriges Kommuner och Landsting samt Kommunförbundet Stockholms Län. Vad vill uppnås med
Läs merDNSSec. Garanterar ett säkert internet
DNSSec Garanterar ett säkert internet Vad är DNSSec? 2 DNSSec är ett tillägg i Domain Name System (DNS), som säkrar DNS-svarens äkthet och integritet. Tekniska åtgärder tillämpas vilket gör att den dator
Läs merInformationssäkerhetspolicy
2006-09-07 Informationssäkerhetspolicy Antagen av kommunfullmäktige 2006-09-28, 140 Innehåll 1 INLEDNING...3 2 MÅL FÖR INFORMATIONSSÄKERHETSARBETET...4 2.1 LÅNGSIKTIGA MÅL...4 2.2 ÅRLIGA MÅL...4 3 ORGANISATION,
Läs merSäkerhet. Beskrivning DNSSEC. Teknisk miljö på.se. Dokumentnummer: Senast sparat: 8 december 2008
Dokumentnummer: 2005-24 Senast sparat: 8 december 2008 SE, Stiftelsen för Internetinfrastruktur 2007 Dokumentkontroll Dokumentinformation och säkerhet UPPFÖRD AV FAKTAANSVARIG DOKUMENTANSVARIG JAKOB AMEL
Läs merBilaga 3c Informationssäkerhet
SID 1 (9) Bilaga 3c Informationssäkerhet Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt material inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress
Läs merDNSSEC-rapport Regionförbundet i Kalmar Län
Page 1 (29) Rickard Bellgrim, rickardb@certezza.net Karl Castor, karl@certezza.net Certezza AB Stockholm 2012-06-12 DNSSEC-rapport Regionförbundet i Kalmar Län Kornhamnstorg 61, 2 tr SE-111 27 Stockholm
Läs merVarför och hur införa IPv6 och DNSSEC?
Varför och hur införa IPv6 och DNSSEC? SSNF:s Årskonferens den 22 mars 2012 Linköping Erika Hersaeus Nätsäkerhetsavdelningen Post- och telestyrelsen Post- och telestyrelsen Agenda Vad är IPv6? Varför IPv6?
Läs merPolicy för tekniska och organisatoriska åtgärder för dataskydd. 14 juni 2018 Peter Dickson
Policy för tekniska och organisatoriska åtgärder för 14 juni 2018 Peter Dickson Sida 2 av 6 Innehåll Inledning... 3 Organisation... 3 Allmänt om det tekniska säkerhetsarbetet... 4 Kontinuitetsplanering...
Läs merDNSSEC-grunder. Rickard Bellgrim rickardb@certezza.net [2012-05-23]
DNSSEC-grunder Rickard Bellgrim rickardb@certezza.net [2012-05-23] DNS. NS a.root-servers.net. a.root-servers.net.. NS m.root-servers.net. A 198.41.0.4 m.root-servers.net. A 202.12.27.33. (root).se net.
Läs merChecklista Identitetshanteringssystem för SWAMID 2.0. Utarbetad tillsammans med SUNET CERT och SUSEC
Checklista Identitetshanteringssystem för SWAMID 2.0 Utarbetad tillsammans med SUNET CERT och SUSEC Bakgrund För att upprätta förtroende i en federation krävs inte bara att identitetsutdelningsprocessen
Läs merPolicy Document Number ESS-0002649 Date Mar 14, 2013 Revision 1 (3) Plan för IT Säkerhet
Revision 1 (3) State Released Plan för IT Säkerhet DOCUMENT REVISION HISTORY Revision Reason for revision Date 1 New Document 2013-02-26 List of Authors List of Reviewers List of Approvers Skölde, Daniel/Ulrika
Läs merSystem för DNSSECadministration. Examensarbete Alexander Lindqvist Joakim Åhlund KTH
System för DNSSECadministration Examensarbete Alexander Lindqvist Joakim Åhlund KTH Introduktion Examensarbete - En del i.se:s DNSSEC-projekt Beställare Styrgrupp Projektledare och deltagare Staffan Hagnell
Läs merInformationssäkerhetspolicy för Ånge kommun
INFORMATIONSSÄKERHETSPOLICY 1 (10) Informationssäkerhetspolicy för Ånge kommun Denna informationssäkerhetspolicy anger hur Ånge kommun arbetar med informationssäkerhet och uttrycker kommunens stöd för
Läs merAllmänna villkor för infrastrukturen Mina meddelanden
Allmänna villkor för infrastrukturen Mina meddelanden Bilaga 1 Krav på säkerhet för brevlådeoperatörer version 1.2 (Gäller fr.o.m. 2015-11-11) 2 Bakgrund och syfte Skatteverket tillhandahåller en myndighetsgemensam
Läs merRevisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice 2010.
Revisionsrapport Verket för högskoleservice Box 24070 104 50 Stockholm Datum Dnr 2011-03-08 32-2010-0738 Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice
Läs mer256bit Security AB Offentligt dokument 2013-01-08
Säkerhetsbeskrivning 1 Syfte Syftet med det här dokumentet är att översiktligt beskriva säkerhetsfunktionerna i The Secure Channel för att på så vis öka den offentliga förståelsen för hur systemet fungerar.
Läs merInternetdagarna NIC-SE Network Information Centre Sweden AB
Internetdagarna 2005-10-24--25 Amel 2005-10-24--25 1 Agenda Aktiviteter fram till produktion Koppling mellan certifikat, domän och administratör Vilken support kan DNS-operatörer och domännamnsinnehavare
Läs merVISION STRATEGI REGLEMENTE PROGRAM POLICY PLAN» RIKTLINJE REGEL. Riktlinjer för informationssäkerhet
Riktlinjer Handläggare Vårt diarienummer Datum Sidan 1(8) Jonas Åström KS2016/222 VISION STRATEGI REGLEMENTE PROGRAM POLICY PLAN» RIKTLINJE REGEL Sandvikens kommuns Riktlinjer för informationssäkerhet
Läs merDet nya Internet DNSSEC
Det nya Internet DNSSEC Anne-Marie Eklund Löwinder kvalitets-och säkerhetschef.se (Stiftelsen för Internetinfrastruktur) amel@iis.se http://www.iis.se Min agenda Kort om.se Vad är DNS? Vad är DNSSEC och
Läs merIT-Säkerhetsinstruktion: Förvaltning
n av 7 för Munkfors, Forshaga, Kils och Grums kommun april 2006 av IT-samverkansgruppen n 2 av 7 IT SÄKERHETSINSTRUKTION: FÖRVALTNING Innehållsförteckning IT-säkerhetsinstruktion Förvaltnings roll i IT-säkerhetsarbetet...3
Läs merBilaga 3c Informationssäkerhet
Bilaga 3c Informationssäkerhet stockholm.se Stadsledningskontoret Avdelningen för digital utveckling Hantverkargatan 3D 105 35 Stockholm Växel 08-508 29 000 www.stockholm.se Innehåll 1 Inledning 3 2 Krav
Läs merDatum: 2011-02-10 Version: Författare: Christina Danielsson Senast ändrad:
I N T E R N T Säkerhetskrav på extern part För enskild individs direktåtkomst till Datum: 2011-02-10 Version: Författare: Christina Danielsson Senast ändrad: Dokumentnamn: Säkerhetskrav på extern part
Läs merRegelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga D. Personuppgiftsbiträdesavtal. Version: 2.
Regelverk Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag Bilaga D Personuppgiftsbiträdesavtal Version: 2.0 Innehållsförteckning 1 Allmänt om personuppgiftsbiträdesavtal... 1
Läs merDNSSEC implementation & test
DNSSEC implementation & test Internetdagarna 2006 Uppdrag till Netlight från PTS Testa följande Implementation av DNSSEC Zonsignering och lokal aktivering (i master) Förtroendekedja från.se Aktivering
Läs merUTFÄRDARDEKLARATION (CPS) SJÖFARTSVERKET
UTFÄRDARDEKLARATION (CPS) SJÖFARTSVERKET KUNDCERTIFIKAT VERSION 1 2006-12-06 UTFÄRDARDEKLARATION (CPS) SJÖFARTSVERKET KUNDCERTIFIKAT VERSION 1 Copyright Sjöfartsverket, 2005, doc ver 1.0 The information
Läs merBILAGA 3 Tillitsramverk Version: 1.2
BILAGA 3 Tillitsramverk Version: 1.2 Innehåll Revisionshistorik... 1 Allmänt... 2 A. Organisation och styrning... 2 Övergripande krav på verksamheten... 2 Villkor för användning av Leverantörer... 3 Handlingars
Läs mer! " #$%&' ( #$!
! " #$%&' ( #$! Vad är.se? ISO 3166-1 Alpha 2-kodelement för konungariket Sverige TLD administreras och drivs av en stiftelse Drygt 500 000 registrerade domännamn En daglig tillväxt med ~500 domäner Driften
Läs merkirei Kvalitetsgranskning DNSSEC Rapport Regionförbundet i Kalmar län Kirei 2012:13 10 januari 2013
kirei Rapport 10 januari 2013 Regionförbundet i Kalmar län Kirei 2012:13 Kvalitetsgranskning DNSSEC 1 Bakgrund Regionförbundet i Kalmar län har under 2012 bedrivit ett projekt med syfte att införa DNSSEC
Läs merInformationssäkerhet och earkiv Rimforsa 14 april 2016
Informationssäkerhet och earkiv Rimforsa 14 april 2016 Stephen Dorch, ISMP Information - Organisationens viktigaste tillgång - Säkerhet - Informationen att lita på när jag behöver den - Samordna - Gemensamma
Läs merIcke funktionella krav
1 (9) Underskriftstjänst Svensk e-legitimation 2 (9) INNEHÅLL 1 Inledning... 3 2 Tillgänglighet och kapacitet... 3 2.1 Svarstider... 3 3 Administrativ säkerhet... 4 3.1 Policy och regelverk... 4 3.1.1
Läs merINFORMATIONSSÄKERHET 1 INLEDNING... 2 2 MÅL FÖR IT-SÄKERHETSARBETET... 2
INFORMATIONSSÄKERHET 1 INLEDNING... 2 2 MÅL FÖR IT-SÄKERHETSARBETET... 2 3 RIKTLINJER FÖR ATT UPPNÅ MÅLEN... 3 3.1 ALLMÄNT... 3 3.2 LEDNING OCH ANSVAR FÖR IT-SÄKERHET... 3 3.2.1 Systemägare... 3 3.2.2
Läs merOpenDNSSEC. Rickard Bondesson,.SE
OpenDNSSEC Rickard Bondesson,.SE Rickard.bondesson@iis.se 2009-06-15 1 Av vem? 2009-06-15 2 Detta är OpenDNSSEC 2009-06-15 3 Beskrivning OpenDNSSEC är en komplett DNSSEC zonsignerare som automatiserar
Läs merRiktlinjer för informationssäkerhet
Dnr UFV 2014/1308 Riktlinjer för informationssäkerhet Säkerhetskopiering och loggning Fastställda av Säkerhetschef 2014-11-25 Innehållsförteckning 1 Inledning 3 2 Ansvar 3 2.1 Efterlevnad 3 2.2 Uppdatering
Läs merOpenDNSSEC. Rickard Bondesson,.SE
OpenDNSSEC Rickard Bondesson,.SE Rickard.bondesson@iis.se 2009-08-17 1 Av vem? 2009-08-17 2 Detta är OpenDNSSEC 2009-08-17 3 Beskrivning OpenDNSSEC är en komplett DNSSEC zonsignerare som automatiserar
Läs merKrypteringstjänster. LADOK + SUNET Inkubator dagarna GU, Göteborg, 6-7 oktober 2014. Joakim Nyberg ITS Umeå universitet
Krypteringstjänster LADOK + SUNET Inkubator dagarna GU, Göteborg, 6-7 oktober 2014 Joakim Nyberg ITS Umeå universitet Projekt mål Identifiera de behov som finns av krypteringstjänster Utred funktionsbehov
Läs merSentrion och GDPR Information och rekommendationer
Information och rekommendationer Innehållsförteckning GDPR... 3 Principer... 3 Registrerades rättigheter... 3 Sentrion och GDPR... 4 Laglighet, korrekthet och öppenhet... 4 Ändamålsbegränsning... 4 Uppgiftsminimering...
Läs merRiktlinje för informationssäkerhet
Bilaga 2 Dokumentansvarig: Chef Samhällsskydd och Beredskap Upprättad av: Informationssäkerhetschef Beslutad av: Kommunfullmäktige Gäller för: Anställda och förtroendevalda i Göteborgs Stads förvaltningar,
Läs merIT-SÄKERHETSPLAN - FALKÖPINGS KOMMUN
IT-SÄKERHETSPLAN - FALKÖPINGS KOMMUN 1 INLEDNING...1 2 MÅL FÖR IT-SÄKERHETSARBETET...1 3 RIKTLINJER FÖR ATT UPPNÅ MÅLEN...1 3.1 ALLMÄNT...1 3.2 LEDNING OCH ANSVAR FÖR IT-SÄKERHET...2 3.2.1...2 3.2.2 Systemansvarig...3
Läs merAllmänna villkor för infrastrukturen Mina meddelanden
Allmänna villkor för infrastrukturen Mina meddelanden Bilaga 1 Krav på säkerhet för brevlådeoperatörer version 1.0 2 Bakgrund och syfte Enligt förordningen (2003:770) om statliga myndigheters elektroniska
Läs merInformationssäkerhet - Informationssäkerhetspolicy
Informationssäkerhet - Informationssäkerhetspolicy Informationssäkerhetspolicy 2008-08-29 Innehållsförteckning 1 Inledning... 1 2 Mål för IT-sbäkerhetsarbetet... 2 2.1 Långsiktiga mål... 2 2.2 Årliga mål...
Läs merKontinuitetsplan IT. Bilaga till Informationssäkerhetspolicy
Intendentur och service Chef Fredrik Nilsson STYRDOKUMENT Diarienummer: GIH 2018/245 Datum: 2018-05-09 Beslutat av: Rektor Beslutsdatum: 2018-06-13 Ersätter Dnr: Ö 2013/219 Giltighetstid: Tillsvidare 1(8)
Läs merDenna föreskrift riktar sig till anställda vid Stockholms universitet samt till personer som arbetar på uppdrag av universitetet.
1 (6) 2014-12-03 Dnr SU FV-1.1.2-3513-14 Benita Falenius Informationssäkerhetssamordnare Föreskrift för anställda och personal som arbetar på uppdrag av Stockholms universitet avseende användning av information
Läs merRiktlinjer för informationssäkerhet
Dnr UFV 2014/1308 Riktlinjer för informationssäkerhet Säkerhetskopiering och loggning Fastställda av Säkerhetschefen 2014-11-25 Rev. 2015-03-16 Innehållsförteckning 1 Inledning 3 2 Ansvar 3 2.1 Efterlevnad
Läs merIT-SÄKERHETSPLAN - FALKÖPINGS KOMMUN
IT-SÄKERHETSPLAN - FALKÖPINGS KOMMUN 1 INLEDNING... 1 2 MÅL FÖR IT-SÄKERHETSARBETET... 1 3 RIKTLINJER FÖR ATT UPPNÅ MÅLEN... 1 3.1 ALLMÄNT... 1 3.2 LEDNING OCH ANSVAR FÖR IT-SÄKERHET... 2 3.2.1... 2 3.2.2
Läs merDokumenttyp Riskanalys Område DNSSEC2012. DNSSEC 2012 RISKANALYS Version 0.1. Västervik Ort och datum. Stephen Dorch Analysledare
DNSSEC2012 DNSSEC 2012 RISKANALYS Version 0.1 Västervik 2012 05 02 Ort och datum Stephen Dorch Analysledare Innehållsförteckning 1 Bakgrund 3 2 Omfattning 3 2.1 Deltagande kommuner i analysen... 3 2.2
Läs merMyndigheten för samhällsskydd och beredskaps författningssamling
Myndigheten för samhällsskydd och beredskaps författningssamling Utgivare: Anna Asp, Myndigheten för samhällsskydd och beredskap ISSN 2000-1886 MSBFS Utkom från trycket den 30 oktober 2018 Myndigheten
Läs merTermer och begrepp. Identifieringstjänst SITHS
Termer och begrepp Identifieringstjänst Revisionshistorik Version Datum Författare Kommentar 1.0 2019-02.20 Policy Authority Fastställt 1.1 Policy Authority Mindre justeringar 1. Dokumentets syfte Definition
Läs merBilaga 3 Säkerhet Dnr: /
stockholm.se Utbildningsförvaltningen Avdelningen för utveckling och samordning Hantverkargatan 2F 104 22 Stockholm Växel 08-508 33 000 www.stockholm.se Innehåll 1 Inledning 3 2 Krav på säkerhetsarbete
Läs merSÅ HÄR GÖR VI I NACKA
SÅ HÄR GÖR VI I NACKA Så här arbetar vi med informationssäkerhet i Nacka kommun Dokumentets syfte Beskriver vad och hur vi gör i Nacka rörande informationssäkerhetsarbetet. Dokumentet gäller för Alla chefer
Läs merTermer och begrepp. Identifieringstjänst SITHS
Termer och begrepp Identifieringstjänst Revisionshistorik Version Datum Författare Kommentar 1.0 2019-02-20 Policy Authority Fastställd 1. Dokumentets syfte Definition av termer och begrepp som används
Läs merInformationssäkerhetspolicy IT (0:0:0)
Informationssäkerhetspolicy IT (0:0:0) Kommunalförbundet ITSAM och dess medlemskommuner Revision: 2013031201 Fastställd: Direktionen 20130926 Dnr:0036/13 Kommunalförbundet ITSAM, Storgatan 36A, 590 36
Läs merInformationssäkerhetspolicy. Linköpings kommun
Informationssäkerhetspolicy Linköpings kommun Antaget av: Kommunfullmäktige Status: Antaget 2016-08-30 291 Giltighetstid: Tillsvidare Linköpings kommun linkoping.se Sekretess: Öppen Diarienummer: Ks 2016-481
Läs merBilaga 3c Informationssäkerhet
SID 1 (5) Bilaga 3c Informationssäkerhet Förfrågningsunderlag Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress Hantverkargatan 2
Läs merVästkom. Göteborg 18 november Del 1 av 2. Stephen Dorch, ISMP
Västkom Göteborg 18 november 2015 Del 1 av 2 Stephen Dorch, ISMP Stephen Dorch Regional informationssäkerhetssamordnare AB Svenska Shell 3 år Landstinget i Kalmar Län 20 år Regionförbundet i Kalmar län
Läs merDokumentet är publicerat under Creative Common-licens Sverige
Dokumentet är publicerat under Creative Common-licens Sverige Stiftelsen för Internetinfrastruktur Box 7399, 103 91 Stockholm Tel 08-452 35 00 Fax 08-452 35 02 Org.nr. 802405-0190 www.iis.se Sida 2 av
Läs mer1 Risk- och sårbarhetsanalys
Bilaga 10 1 Risk- och sårbarhetsanalys I detta kapitel utgår vi från identifierade riskscenarier i följande bilagor: Bilaga X Informationsklassning, digitalt stöd i hemmet.xls Vi värderar hur stor sannolikheten
Läs merInformationssäkerhetspolicy för Sunne kommun KS2016/918/01 Antagen av kommunfullmäktige , 57
1 (5) Informationssäkerhetspolicy för Sunne kommun KS2016/918/01 Antagen av kommunfullmäktige 2018-05-07, 57 Postadress Besöksadress Telefon Internet och fax Giro och org.nr Sunne kommun Verksamhetsstöd
Läs merIntroduktion till protokoll för nätverkssäkerhet
Tekn.dr. Göran Pulkkis Överlärare i Datateknik Introduktion till protokoll för nätverkssäkerhet Innehåll Varför behövs och hur realiseras datasäkerhet? Datasäkerhetshot Datasäkerhetsteknik Datasäkerhetsprogramvara
Läs merFörklarande text till revisionsrapport Sid 1 (5)
Förklarande text till revisionsrapport Sid 1 (5) Kravelementen enligt standarden ISO 14001:2004 Kap 4 Krav på miljöledningssystem 4.1 Generella krav Organisationen skall upprätta, dokumentera, införa,
Läs merPolicy för användande av IT
Policy för användande av IT Inledning Det här dokumentet beskriver regler och riktlinjer för användningen av IT inom företaget. Med företaget menas [fylls i av kund] och med IT-avdelning menas vår partner
Läs merBilaga, Definition av roller och begrepp, till policy för IT-säkerhet
Fastighetsavdelningen STYRDOKUMENT Leif Bouvin 07-05-24 dnr A 13 349/ 07 031-789 58 98 Bilaga, Definition av roller och begrepp, till policy för IT-säkerhet Publiceringsdatum Juni 2007 Publicerad Beslutsfattare
Läs merVGR-RIKTLINJE FÖR KOMMUNIKATION OCH DRIFT
Koncernkontoret Enhet säkerhet Dokumenttyp VGR-riktlinje Dokumentansvarig Valter Lindström Beslutad av Valter Lindström, koncernsäkerhetschef Övergripande dokument Riktlinjer för informationssäkerhet Kontaktperson
Läs merInformationssäkerhetspolicy
2009-07-15 1 (9) Informationssäkerhetspolicy Antagen av kommunfullmäktige den 2009-10-21, 110 Kommunstyrelseförvaltningen Postadress Besöksadress Telefon Telefax E-post Hemsida 462 85 Vänersborg Sundsgatan
Läs merSjunet robust DNS. Teknisk Beskrivning
Sjunet robust DNS Teknisk Beskrivning Revisionshistorik Version Författare Kommentar 0-0.9 Björn Gustavsson 0.91 Christoffers Johansson 1. Inledning... 2 2. Syfte... 2 3. Bakgrund... 2 4. Kontaktvägar...
Läs merDNR: KS2016/918/01. Informationssäkerhetspolicy för Sunne kommun KS2016/918/ (1) Kommunstyrelsen
TJÄNSTESKRIVELSE Datum DNR: KS2016/918/01 2018-03-07 1 (1) Kommunstyrelsen Informationssäkerhetspolicy för Sunne kommun KS2016/918/01 Förslag till beslut Förslaget till Informationssäkerhetspolicy för
Läs merRiktlinjer för IT-säkerhet i Halmstads kommun
Riktlinjer för IT-säkerhet i Halmstads kommun VER 1.0 Innehåll Inledning...3 Definition av IT-säkerhet...3 Omfattning...3 Vikten av IT-säkerhet...3 Mål för IT-säkerhetsarbetet...4 Ledning och ansvar...4
Läs merSjunet standardregelverk för informationssäkerhet
Innehållsförteckning 1. Generell... 4 1.1. Styrande dokumentation... 4 1.2. Organisation... 4 Incidenthantering... 5 1.3. Riskhantering... 5 SJUNET specifika regler... 6 2. Förutsättningar för avtal...
Läs merBILAGA 5 - Fö reskrifter fö r Sambiömbud Versiön: 1.0.1
BILAGA 5 - Fö reskrifter fö r Sambiömbud Versiön: 1.0.1 Innehåll 1 Inledning... 2 Om detta dokument... 2 Samverkan... 2 2 Sambiombudets tekniska tjänst... 5 3 Tillitsgranskning av Sambiombud... 5 Initiala
Läs mer1(6) Informationssäkerhetspolicy. Styrdokument
1(6) Styrdokument 2(6) Styrdokument Dokumenttyp Policy Beslutad av Kommunfullmäktige 2017-05-17 73 Dokumentansvarig IT-chef Reviderad av 3(6) Innehållsförteckning 1 Inledning...4 1.1 Begreppsförklaring...4
Läs merTekniskt driftdokumentation & krishantering v.1.0
Tekniskt driftdokumentation & krishantering v.1.0 Denna driftdokumentation avser driftmiljön hos Camero AB:s webbhotell, både delade och dedikerade lösningar. Teknisk dokumentation Cameros webbhotell har
Läs merInformationssäkerhetspolicy för Ystads kommun F 17:01
KS 2017/147 2017.2189 2017-06-29 Informationssäkerhetspolicy för Ystads kommun F 17:01 Dokumentet gäller för: Ystads kommuns nämnder, kommunala bolag och kommunala förbund Gäller fr.o.m. - t.o.m. 2017-08-01-tillsvidare
Läs merHur påverkar DNSsec vårt bredband?
Hur påverkar DNSsec vårt bredband? Mats Dufberg TeliaSonera 2005-10-27 Internetdagarna 2005, DNSsec 1 (?) Kundernas krav på sin operatör Snabb access Det finns en medvetenhet hos kunderna att det kan gå
Läs merUpphandlingssystem och IT-säkerhet. Britta Johansson Sentensia
Upphandlingssystem och IT-säkerhet Britta Johansson Sentensia 1 Säkerhetsfrågor i fokus dagligen 2 IT-säkerhet i upphandlingssystem Deltagare presenterar sig för varandra Myndighet Erfarenhet av elektronisk
Läs merIT-säkerhetsinstruktion Förvaltning
IT-säkerhetsinstruktion Förvaltning 2013-09-24 1.0 IT- S Ä K E R H E T S I N S T R U K T I O N IT-säkerhetsinstruktion Finspångs kommun 612 80 Finspång Telefon 0122-85 000 Fax 0122-850 33 E-post: kommun@finspang.se
Läs merRIKTLINJER FÖR IT-SÄKERHET
FÖRFATTNINGSSAMLING (8.1.3) RIKTLINJER FÖR IT-SÄKERHET Dokumenttyp Riktlinjer Ämnesområde IT Ägare/ansvarig IT-strateg Antagen av KS 2012-02-08 47 Revisions datum Förvaltning KSF, stab Dnr KS/2010:1056
Läs merGöteborgs universitet Intern miljörevision. Exempel på frågor vid platsbesök
Göteborgs universitet 2007-06-26 Intern miljörevision Exempel på frågor vid platsbesök Nedan finns exempel på frågor som kan ställas vid platsbesök inom den interna miljörevisionen. Ytterligare följdfrågor
Läs merRiktlinjer för Informationssäkerhet Falkenbergs Kommun 2009-04-23 Kommunledningskontoret
Riktlinjer för Informationssäkerhet Falkenbergs Kommun 2009-04-23 Kommunledningskontoret Antagen av Kommunfullmäktige 2009-04-23 57 1. Allmänt... 3 1.1 Inledning... 3 1.2 Begreppet informationssäkerhet
Läs merRevisionsrapport Borgholms kommun Caroline Liljebjörn 1 juni 2016
www.pwc.se Revisionsrapport Uppföljning av ITgranskning från år 2013 Caroline Liljebjörn 1 juni 2016 Innehåll Sammanfattning och revisionell bedömning...2 1.1. Bedömningar mot kontrollmål...2 2. Inledning...4
Läs merInformationssäkerhetspolicy inom Stockholms läns landsting
LS 1112-1733 Informationssäkerhetspolicy inom Stockholms läns landsting 2013-02-01 Beslutad av landstingsfullmäktige 2013-03-19 2 (7) Innehållsförteckning 1 Inledning...3 2 Mål... 4 3 Omfattning... 4 4
Läs merInnehåll 1(14) Granskningsdokumentation
1(14) Innehåll Granskningsobjekt... 2 Preliminär riskbedömning... 3 Sammanfattning... 4 Övergripande slutsats/rekommendation... 4 1 Inledning... 5 2 Allmänna åtaganden... 5 3 Organisation och styrning...
Läs merIT-säkerhetspolicy Instruktion 2012-09-17 Kommunfullmäktige. Senast reviderad 2012-08-27. Beskriver IT-säkerhetarbetet.
2012-08-27 Sidan 1 av 6 IT-säkerhetspolicy Dokumentnamn Dokumenttyp Fastställd/upprättad Diarie nummer Fastställd av IT-säkerhetspolicy Instruktion 2012-09-17 Kommunfullmäktige Dokumentansvarig/ processägare
Läs merHälsoläget i.se. DNS och DNSSEC
Hälsoläget i.se DNS och DNSSEC 1 Om.SE:s satsningsområde Hälsoläget 2 2 Introduktion 3 2.1 Syftet med undersökningen 3 2.2 Om undersökningsgruppen 3 2.3 Avgränsningar 4 2.4 Testobjekt 4 3 Sammanfattning
Läs merHandledning i informationssäkerhet Version 2.0
Handledning i informationssäkerhet Version 2.0 2013-10-01 Dnr 1-516/2013 (ersätter Dnr 6255/12-060) Informationssäkerhet 6 saker att tänka på! 1. Skydda dina inloggningsuppgifter och lämna aldrig ut dem
Läs merTestning av Sambi. Testplan. Version PA12. Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24. Copyright (c) 2014 IIS
Testning av Sambi Testplan Version PA12 Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24 Copyright (c) 2014 IIS Dokument kontroll Dokument information och säkerhet Skapad av Faktaansvarig Dokumentansvarig
Läs merSkolorna visar brister i att hantera personuppgifter
Skolorna visar brister i att hantera personuppgifter www.datainspektionen.se Checklista för skolor Personuppgiftslagen (PuL) innehåller en rad bestämmelser som är viktiga att känna till för skolor som
Läs merOrganisation för samordning av informationssäkerhet IT (0:1:0)
Organisation för samordning av informationssäkerhet IT (0:1:0) Kommunalförbundet ITSAM och dess medlemskommuner Revision: 2013031201 Fastställd: Direktionen 20130926 Dnr: 0036/13 Kommunalförbundet ITSAM,
Läs merVäxjö kommun. Övergripande säkerhetsgranskning. säkerhet avseende externt och internt dataintrång. Informationssäkerhetsspecialister:
www.pwc.se Övergripande säkerhetsgranskning av kommunens säkerhet avseende externt och internt dataintrång Informationssäkerhetsspecialister: Viktor Bergvall Linus Owman Certifierad kommunal revisor: Lena
Läs merDin guide till en säkrare kommunikation
GUIDE Din guide till en säkrare kommunikation Introduktion Internet genomsöks regelbundet i jakten på osäkra nätverk och enheter som saknar skydd för olika typer av exponering och intrång. Viktiga system
Läs merProtokollbeskrivning av OKI
Protokollbeskrivning av OKI Dokument: Protokollbeskrivning av OKI Sida 1 / 17 1 Syfte Det här dokumentet har som syfte att beskriva protokollet OKI. 2 Sammanfattning OKI är tänkt som en öppen standard
Läs merPolicy Underskriftstjänst Svensk e-legitimation
Policy Underskriftstjänst Svensk e-legitimation Version 1.0 2014-04-15 1 (7) 1 INLEDNING OCH SYFTE 3 1.1 AVGRÄNSNINGAR 3 1.2 DEFINITIONER 3 2 POLICYPARAMETRAR 4 2.1 DATALAGRING 4 2.1.1 LAGRING AV INFORMATION
Läs merInformationssäkerhetspolicy för Katrineholms kommun
Styrdokument Informationssäkerhetspolicy för Katrineholms kommun Senast reviderad av kommunfullmäktige, 203 2 (10) Beslutshistorik Gäller från 2013-09-16 2015-12-31 2010-08-18 Revision enligt beslut av
Läs merSURFTOWNS SÄKERHETSMILJÖ. Databehandlingsavtal - Bilaga 1
SURFTOWNS SÄKERHETSMILJÖ Databehandlingsavtal - Bilaga 1 Innehållsförteckning Fysisk säkerhet... 2 Loggning... 2 Sårbarhetshantering... 2 Övervakning... 2 Backup... 3 Kryptering... 3 Underleverantörer...
Läs merSjunet Anslutningsavtal Standardregelverk för informationssäkerhet
Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet Innehållsförteckning 1. Generell informationssäkerhet... 4 1.1. Styrande dokumentation... 4 1.2. Organisation... 4 Incidenthantering...
Läs mer