Dokumenttyp Riskanalys Område DNSSEC2012. DNSSEC 2012 RISKANALYS Version 0.1. Västervik Ort och datum. Stephen Dorch Analysledare

Transkript

1 DNSSEC2012 DNSSEC 2012 RISKANALYS Version 0.1 Västervik Ort och datum Stephen Dorch Analysledare

2 Innehållsförteckning 1 Bakgrund 3 2 Omfattning Deltagande kommuner i analysen Avgränsningar Inledning och genomförande Definitioner Krav Definition av sannolikhet och konsekvens Resultat Kritiska - 6 st Allvarliga 2 st Betydande - 6 st Stora - 2 st Mindre - 2 st Försumbara - 2 st Protokoll riskanalys 7 Stephen Dorch (9)

3 1 Bakgrund Kommunerna i Kalmar län har fått utvecklingsmedel ur 2:4 krisberedskap för införande av DNSSSEC för samtliga kommuners huvuddomän. Se projektspec för ytterligare information. 2 Omfattning 2.1 Deltagande kommuner i analysen Analysen genomfördes som en aktivitet under ett ordinarie projektmöte. Medverkande på analysen IT-säkerhetstekniker från Oskarshamn, Mönsterås, Hultsfred och Vimmerby kommun. Analysen leds av Stephen Dorch, Informationssäkerhetsamordnare på regionförbundet och projektledare för DNSSEC projektet. 2.2 Avgränsningar Analysen omfattar endast kommunerna i Kalmar län då endast kommunerna omfattas av projektet. Anledningen är att utvecklingsmedel 2:4 krisberedskap är riktade till kommunernas. Därför avgränsas analysen till att inte omfatta landstinget, regionförbundet eller privata utförare. 3 Inledning och genomförande Analysledaren ger deltagarna en kort bakgrundsbild och för kring definitioner, krav, sannolikhet och konsekvenser. 3.1 Definitioner Följande definitioner är centrala för analysen Hot Potentiell orsak till en oönskad incident, vilken kan resultera i skada på ett system eller organisation. Sårbarhet Svaghet gällande en tillgång eller grupp av tillgångar, vilken kan utnyttjas av ett eller flera hot. Konsekvens Konsekvensen är ett mått på den skada ett hot skulle ha på verksamheten om det inträffade. Påverkan kan exempelvis vara direkt eller indirekt, ekonomisk eller medmänsklig. Sannolikhet Sannolikheten anger hur troligt det är att hotet kommer att inträffa Riskvärde Produkten av sannolikheten för en händelse och dess konsekvenser Stephen Dorch (9)

4 3.2 Krav Kravställare är IT-cheferna som i projektet representeras av utsedd styrgrupp. Utöver de kommunala IT-cheferna ställer även Länsstyrelsen och Myndigheten för Samhällsskydd och beredskap (MSB) utifrån innehållet i ansökan och regelverket för 2:4 krisberedskap. Indirekt finns kravet formulerat som en målbild i den nationella digitala agendan som regeringen har antog Definition av sannolikhet och konsekvens För att få ett relevant, verkningsfullt och användningsbart resultat är det av vikt att skalan av sannolikhet och kompetens anpassas till den verksamhet som ska analyseras Sannolikhet Graden av sannolikhet anpassades till nedanstående värden: Värde 1 Försumbar sannolikhet, (=Det kommer förmodligen inte att inträffa under projekttiden) Värde 2 Liten sannolikhet, (=Det finns en liten sannolikhet att det inträffar under projekttiden) Värde 3 Stor sannolikhet, (=Det finns en stor sannolikhet att det kan inträffa under projekttiden) Värde 4 Troligt, (=Det är troligt att det kommer att inträffa under projekttiden) Konsekvens Graden av konsekvens anpassades till nedanstående värden: Värde 1 Ringa konsekvens, (= Om risken inträffar har det i stort ingen direkt påverkan på projektet) Värde 2 Måttlig konsekvens, (=Om risken inträffar har det måttlig påverkan på projektet) Värde 3 Betydande konsekvens, (=Om risken inträffar har det betydande konsekvens på projektet) Värde 4 Allvarlig konsekvens, (=Om risken inträffar har det mycket allvarlig påverkan på projektet) Stephen Dorch (9)

5 4 Resultat Sammantaget identifierades 20 risker, som utifrån sannolikhet och konsekvens har rangordnats. Samtliga risker finns beskrivna i med åtgärdsförslag i tabellen kapitel 5 nedan. 4.1 Kritiska - 6 st 6 risker anses kritiska, med ett riskvärde på av 16. Gemensamt för dessa är brist på tid, resurser, kompetens samt risken för att leverantörerna inte levererar tillräckligt god kvalité. 4.2 Allvarliga 2 st 2 risker anses allvarliga, med ett riskvärde på 8. Gemensamt för dessa är svårigheter att få in material och återrapportering i tid från kommunerna. Stephen Dorch (9)

6 4.3 Betydande - 6 st 6 risker anses allvarliga, med ett riskvärde på 4-6. Gemensamt för dessa är att kompetensökningen uteblir samt att det uppstår informationsbrister, dålig återrapportering samt brister vid informationsinsamling. Vidare finns risker för felaktig konfigurering och felaktig hantering av verktyg samt att resultat av tester och analyser ej tas tillvara. 4.4 Stora - 2 st 2 risker anses betydande, med ett riskvärde på 3. Dessa är risker för att infört system inte är framtidssäkrat samt att det skulle en föreligga en möjlig negativ inställning till förändringar typ så här har vi alltid gjort. 4.5 Mindre - 2 st 2 risker anses mindre, med ett riskvärde på 2. Dessa är risken att anlitat företag kommer på obestånd eller att det är uppenbara brister i förstudien. 4.6 Försumbara - 2 st 2 risker anses försumbara, med ett riskvärde på 1. Dessa risker är tekniska och består i att införda versioner inte skulle vara kompatibla eller att införda primära och sekundära DNS er inte skulle vara redundanta. Stephen Dorch (9)

7 5 Protokoll riskanalys ens resultat dokumenteras i nedanstående tabell som visar prioritet, riskvärde samt åtgärdsförslag. Risk nummer Beskrivning av risk Sannolikhet Konsekvens Riskvärde Åtgärdsförslag Ansvarig 1 Felkonfiguration i skarp läge Följ upp tester, validera, säkerställ åtgärdsplaner 2 Ej tillförlitligt verktyg dvs passar ej valda program Följ upp tester, validera, säkerställ åtgärdsplaner. Fastställ hur rutinen ska se ut i respektive km 3 Saker som alltid funkar blir svåra att lösa när det väl strular DNS tjänsten funkar normalt sett, vilket gör att man sällan kontrollerar. Fastställ hur rutinen ska se ut i respektive km. Dokumentera vad som är gjort, och när saker ska göras, övervakning. Reundans och bakup, restore, övning/testrestore 4 Införa versioner som inte är kompatibla (ex för gammal bind vers, ger problem med signering) Förstudien visar på detta. Ska upptäckas vid "bakgrundskoll", förteckning av adm sys som klarar ställda krav. Lokal PL 5 Sekundar och primär dns ej tillräckligt redundanta Om km ska bli mer självständiga mot ISP, så ska vi säkerställa redundans i plattformen. 6 tredje part ej tillgånglig, ex konkurs Välj part med omdöme, samverka, kravställning IT-chef 7 Teknikertid/resurser räcker inte till eller tillsätts ej IT-chefens ska tillsätta resurser IT-chef 8 Organisationsförändring ändrar förutsättningarna Konsekvens kan bli stora om flytt av serverar ingår. It-chef 9 Bristfällig förstudie Konsekvens ringa beroende på hur vi kravställt förfrågan, samt egen insikt. Kontrolera utkast till rapporten mot andra rapporter, t.ex iis osv. PL och tekn koord Stephen Dorch (9)

8 10 Att utbildningen inte ger förväntad effekt Produktspecifikt eller generell, kanske en av varje? Viktigt att vi specar förväntningar! Lokal PL 11 Kompabilitet med det som kommer, dvs lösningen ska vara framtidssäkrad, ex ipv Del av förstudien, Konsekvensen blir längre fram, utanför projektet PL 12 " så här har vi alltid gjort" - en parts förhålningssätt försvårar möjligheterna till gem reg plattform Öppet förhållningssätt mellan km IT-avd. PL 13 Inventering från kommunerna komer ej in i tid = försvårar förstudien Hänger ihop med teknikertid. Viktigt med en bra mall, bra förfrågningsunderlag. Effekten blir sämmra kvalité för berörd km. Lokal PL 14 Informationsutbyte är bristfällig ( problemguide, informationskälla) Frågor till tekn koordin, konsulter och övrigt ställs på projektplatsen. PL 15 Återrapportering fungerar ej En tydlighet i vad som ska återrapporteras måste fram, och när. Gör en "trappa" med delmål. Grön/rödosv. På en tillämpbar nivå. PL Lokal PL 16 Tider enligt projektspec stämmer ej Respektive IT-chef tilldelar resurser. Styrgrupp plus IT-chef 17 Att vii inte får ut det vi förväntar oss av projektets konsulter Skriv bra kravspec. Säkerställ vad vi vill ha. Fast pris. Bet sker efter godkänt lev. Det ska vara "GRÖNT" 18 Resultat av tester tas ej tillvara i slutkonfig Motiovera särsklt varför avvikelsen sker. Säkerställ förändringshanteringen. Resultat av testmiljö bör/ska verifieras av ext konsult. Sätt upp testmiljö/domain. Lokal PL 19 Tidplan för genomförandet knapp Man tappar 3 månader. Utvecklingstid ligger ofta på sommaren, då det ev är lite lugnare i verksamheten. PL 20 Allt som ska signeras signeras inte Oklart om vilka domäner som ska signeras, samt revers lookup. Kolla upp vad som gäller, se till att det som ska ingå finns med i inventering. Verkar som att "allt" ska ingå. Vad signeras inom projektet, och vad är ok om det ligger utanför, mn i genomförandeplan. PL kollar i utlysning och mot MSB. Stephen Dorch (9)

9 Stephen Dorch (9)