Konklusionerne i dette kapitel er struktureret ud fra spørgerammens emner, dvs. de temaer undersøgelsen overordnet har haft fokus på, jf. Bilag 1: spørgerammens horisontale dimension.
De enkelte temaer med tilhørende opsummeringer og konklusioner ledsages af nogle udledte anbefalinger til inspiration for andre, der arbejder med informationssikkerhed. En samlet liste over disse anbefalinger findes i kap. 4.
I de allerfleste af organisationerne startede man implementeringen fra bunden af. Man havde ikke eller havde kun delvis sikkerhedsstrategier og –politikker, ligesom der typisk ikke fandtes en informationssikkerhedsorganisation i forvejen.
Organisationerne havde kun i få tilfælde en delvis komplet oversigt over informationsaktiver at tage udgangspunkt i, og man stod også på bar bund i forbindelse med dokumenterede nød- og beredskabsplaner.
Ingen af de mindre organisationer indgår i det mindretal, der faktisk havde sikkerhedsstrategier og –politikker. Flere af de mindre organisationer havde heller ikke en sikkerhedsorganisation, hverken før eller efter projektet.
Det anbefales, at man:
Der er tilsyneladende ingen, som har gennemført en foranalyse forud for selve projektet. Der er heller ingen, der har foretaget en cost benefit vurdering i kølvandet på risikoanalysen. Man har med andre ord ikke systematisk vurderet omkostningerne og prioriteret eventuelle foranstaltninger til imødegåelse af de identificerede risici.
For temmelig mange har manglen på foranalyse og på cost benefit vurdering bl.a. betydet, at projektets omfang - med hensyn til indhold, tid, ressourcer og økonomi - er kommet bag på dem.
For manges vedkommende har der ikke været anvendt nogen specifik arbejdsmetode til gennemførelse af projektet.
De, der har haft en mere struktureret og metodisk tilgang, har bl.a. gjort brug af projekt- og arbejdsgrupper, workshops med undervisning og hands on, implementeringsudvalg, skabeloner, informationsmøder og vejledninger. De har således haft fokus på det pædagogisk formidlende og forankrende aspekt i projektet. Og det er derfor ikke overraskende, at hovedparten af disse organisationer har deres rod i forsknings-, uddannelses- og kulturverdenen.
Som løftestænger for projektet nævner flere:
Beslutningen fra centralt hold om at implementere DS 484 har hjulpet projektet på vej ved at gøre diskussioner overflødige: man skulle det her. Benchmark-resultaterne og Rigsrevisionens besøg har været motiverende og skærpende faktorer og øjenåbnere ikke mindst for ledelsen. Begge dele har bidraget til at sikre ledelsens fokus på projektet.
De fleste af organisationerne har benyttet ekstern konsulentbistand i dele af projektforløbet. Det skal dog bemærkes, at dette kun gælder halvdelen af de mindre organisationer.
Selve standarden DS 484 betragtes som et nyttigt redskab, som en god, uundværlig manual i processen.
Brugen af et it-værktøj dedikeret til arbejdet med informationssikkerhed har derimod ikke i sig selv givet et løft til implementeringen. Tværtimod synes det at have været en hæmsko i forbindelse med både risikoanalysen og gennemførelsen af kampagner og test.
En del af organisationerne nævner eksplicit ITIL[2] som noget, der et langt stykke hen ad vejen går hånd i hånd med informationssikkerhed, og at metoderne gensidigt beriger hinanden. Ved at integrere arbejdet med informationssikkerhed og ITIL har man fået forbedret sine it-processer.
Med hensyn til risikoanalysen giver mange udtryk for, at de har haft en forretningsmæssig tilgang til denne med deltagelse af system- og dataejerne. Disse ejerskaber har typisk været placeret i forretningen og ikke i it-afdelingen. Desuden er man gået pragmatisk til værks og har brugt sin egen risikovurderingsmodel afstemt efter situationen. Det har dog ikke nødvendigvis været nemt at få taget hul på risikoanalysen, og det er bl.a. i denne sammenhæng, man har brugt ekstern konsulenthjælp.
Hvad angår opfyldelsen af kravene i DS 484, har langt de fleste indgået kompromisser undervejs. Det kan igen tages som udtryk for den pragmatiske tilgang, om end den har været mere eller mindre ’frivillig’. Man har været nødt til at gå på kompromis på områder som fx kravet om logning. Og især de mindre organisationer har haft svært ved at opfylde kravet om funktionsadskillelse. Med få ansatte må man leve med, at samme person har flere roller.
Det anbefales, at man:
Forståelsen af projektbegreber som ’foranalyse’ og ’cost benefit vurdering’ forekommer at være uklar. Og man har som nævnt tilsyneladende hverken gennemført en foranalyse forud for projektet eller en cost benefit vurdering i forbindelse med risikoanalysen.
Jf. ovenfor betragter mange selve standarden DS 484 som et nyttigt, uundværligt redskab. Samtidig er det påfaldende, hvor enslydende kommentarerne er om, hvordan det har været at arbejde med dens ordlyd. Man har oplevet den som vanskelig og tung at gå til, hvad angår både dens terminologi og dens struktur. Den har været svær at læse, svær at forstå og derfor også svær at formidle. Det har fx været vanskeligt at skulle arbejde med et begreb som ’ejerskab’.
I forlængelse af, at man har haft problemer med at forholde sig til teksten, og i det hele taget har haft svært ved at spore sig ind på projektets omfang og indhold, jf. også afsnit 3.2, giver man udtryk for, at man har savnet hjælpeværktøjer i form af konkrete, operationelle vejledninger, standard skabeloner og paradigmer, praktiske køreplaner og eksempler til brug for projektet.
Dette sammenholdt med, at organisationerne indledningsvis stod på bar bund i projektet, jf. afsnit 3.1, gør, at forudsætningerne for at starte projektet må siges at have været ringe.
Flere af de mindre organisationer har følt standardens omfang som en belastning og kunne godt have tænkt sig, at den var fleksibel og kunne tilpasses i forhold til organisationens størrelse.
Det anbefales, at man:
Flertallet af organisationerne har udført projektet i it-afdelingens regi, ligesom majoriteten af interviewpersonerne har eksplicit tilknytning til it. De, der udtaler sig om betydningen af projektets placering, siger enten, at det ikke skulle have ligget i it’s regi, eller at det var positivt, at det ikke blev et it-projekt.
Men der er også i interviewundersøgelsen eksempler på, at det er den forretningsorienterede holdning og tilgang til projektet, der er det afgørende. Dvs. at det er muligt at undgå, at det bliver et rent ’it-projekt’, også selv om det er placeret i it-afdelingen.
Der er ikke nogen nævneværdige kommentarer til spørgsmålet om, hvorvidt man havde de nødvendige beføjelser i forhold til ansvaret for projektet. Det kan hænge sammen med det gennemgående træk, at projektlederen har trukket et stort læs enten helt alene eller i samarbejde med få andre. Der tales om ’lonely rider’, enmandsopgave og enmandshær.
Til gengæld er der en lille overvægt, der svarer, at de fik de nødvendige ressourcer, herunder også ekstern hjælp. Samtidig mener hovedparten, at der ikke blev allokeret den fornødne tid til projektdeltagerne. I den kategori ses igen en del af de mindre organisationer. Man kan altså have fået tildelt de nødvendige ressourcer i form af fx økonomi og personer, og samtidig have oplevet, at personerne – projektdeltagerne – ikke har fået tilstrækkelig tid til projektarbejdet.
Det anbefales, at man:
Det er væsentligt at hæfte sig ved, at alle giver udtryk for, at arbejdet med informationssikkerhed har været umagen værd. Det har ganske vist haft sin pris, men ingen siger, at prisen har været for høj i forhold til udbyttet.
Svarene på spørgsmålet om, hvordan man har oplevet selve implementeringsprocessen, fordeler sig nogenlunde ligeligt mellem dem, der har oplevet processen som svær og tung, og dem, der ser meget positivt på den. Det er bemærkelsesværdigt, at de mindre organisationer udtrykkeligt nævner deres størrelse, som årsag til at processen har været tung for dem. Og de understreger, at det har givet dem mere arbejde.
Men uanset hvordan man har oplevet processen, så peger man entydigt på disse resultater som de væsentligste udbytter:
Den øgede forståelse, erkendelse og opmærksomhed går hånd i hånd med det forbedrede, strukturerede sikkerhedsarbejde og dermed det højnede sikkerhedsniveau.
Langt hovedparten af de ændringer og tilpasninger, man har foretaget i kølvandet på arbejdet med informationssikkerhed, omfatter arbejdsprocesser og –procedurer. Det drejer sig ikke så meget om it-mæssige ændringer.
Flere udtaler, at de i virkeligheden gjorde mange af tingene i forvejen, men at sikkerhedsarbejdet er blevet mere struktureret, formaliseret og bevidst med DS 484 som løftestang, krumtap og manual.
Og både det at få kortlagt informationsaktiverne og det at få gennemført en risikoanalyse har for mange haft stor værdi og medført konkrete og håndgribelige resultater.
Det er også værd at bemærke, at relativt mange har oplevet ledelsesforankringen som et væsentligt udbytte hen ad vejen.
De allerfleste er opmærksomme på at følge op på implementeringen. Man tænker i vedligeholdelse og nævner et bredt spektrum af virkemidler til det formål. Set udefra er det vanskeligt at afgøre, om der er tale om planer for fremtiden, eller om virkemidlerne rent faktisk er i brug.
De fleste vurderer, at deres implementeringsgrad ligger i intervallet 70-80%. Det harmonerer godt med, at der er gjort en relativt stor indsats for at øge bevidstheden i organisationerne (se afsnit 3.6). Samtidig er det udtryk for en realistisk vurdering: Der er stadig et stykke vej, før man er helt i hus med implementeringen.
Typisk er man ikke så langt med nød- og beredskabsplanlægningen. Beredskab opleves generelt som et svært område, og flere har endnu ingen nød- og beredskabsplaner. Hos nogle er man heller ikke helt i mål med risikoanalyserne.
Med hensyn til behovet fremover - også i lyset af Statens It - nævner flere, at gryden skal holdes i kog, at der ligger en udfordring i at tænke sikkerhed ind i SLA-arbejdet (arbejdet med Service Level Agreements), og man foreslår at gentage benchmark-undersøgelsen.
I tråd med at man i implementeringsprocessen har savnet konkrete hjælpeværktøjer, jf. afsnit 3.3, ser man frem til en central styring som mulig løftestang for det videre arbejde med informationssikkerhed. Man forventer sig mere standardisering i form af en fælles opfattelse og forståelse af sikkerhedsbegrebet, fælles regelsæt og politikker, som kan genbruges, operationelle driftshåndbøger, skabeloner og et fælles risikostyringsværktøj.
Det anbefales, at man:
Det er de færreste, der indledningsvis har lagt vægt på at informere og kommunikere om projektet. Man henviser til, at det jo var obligatorisk, jf. også afsnit 3.2. Igen fremgår det, at de, der bevidst har anvendt forskellige former for information, formidling og kommunikation også i starten af projektet, hører hjemme i forsknings-, uddannelses- og kulturverdenen.
I lyset af, hvor få der til en start har gjort noget for at ”sælge” projektet, er det bemærkelsesværdigt, hvor mange der undervejs i projektet har taget hånd om at skabe bevidsthed om informationssikkerhed. Man har generelt anvendt en bred vifte af informations- og kommunikationskanaler i bestræbelserne på at bevidstgøre organisationen om sikkerhedsspørgsmålene. Kun et mindretal har ikke fundet det nødvendigt at fokusere på at skabe bevidsthed om informationssikkerhed.
Det er et gennemgående træk, at organisationerne har fundet de indførte foranstaltninger irriterende og besværlige, men at der samtidig er forståelse for nødvendigheden af dem. Flere steder har medarbejderne ikke bare accepteret, men ligefrem ”adopteret” og taget sikkerhedsudfordringerne til sig.
Mange svarer også bekræftende på spørgsmålet om, hvorvidt ansvaret som ejer efterleves nu. Flere peger dog på, at den fulde forståelse og bevidsthed ikke er helt på plads, men at den er undervejs.
Det er karakteristisk, at flere af de interviewede peger på eksemplets magt som et tungtvejende pædagogisk middel til bevidstgørelse om informationssikkerhed. Eksempler på hændelser fra dagligdagen, hvor sikkerheden kompromitteres, er noget, man kan forholde sig til.
Det anbefales, at man:
[2] ITIL: IT Infrastructure Library. En samling anbefalinger af, hvordan man bedst driver sin it-virksomhed. Et internationalt anerkendt bedste praksis-rammeværk for it-leverancer og –services.
Denne side er kapitel 3 af 6 til publikationen "Erfaringer fra implementeringen af DS 484".
Version nr. 1.0 af 01-05-2009
© IT- og Telestyrelsen 2009