DNSSEC Policy (DP) Denna DP gäller gemensamt för:

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 -