ESL Eksamens opgave. Hold 16. Maj 2006

Transkript

1 ESL Eksamens opgave Hold 16 Maj 2006 Side 1 af 42

2 Indholdsfortegnelse Opgave 1 Risikoanalyse... 3 Indledning... 3 Udkast til en generisk model for IT-risikoanalyse... 3 Identifikation af risici... 4 Gennemførelse af risikovurdering... 5 Undgå en risiko... 6 Vurdering af sandsynlighed... 6 Vurdering af konsekvens... 6 Beregning af sårbarhed... 8 Vurdering af sikkerhedsmiljø... 9 Planlægge og gennemføre forbedringstiltag Accept af restrisiko Notat med forslag til håndtering af risikoanalyse for system og data omkring flysikkerhed Baggrund for notatet Forberedelse Identifikation af risici Gennemførelse af risikovurdering Vurdering af sikkerhedsmiljø Planlægning af forbedringstiltag Konklusion Opgave 2 Sikkerhedsrapport til ledelsen Indledning Notat vedr. generisk forslag til systematisk rapportering af IT Sikkerhed Baggrund for notatet Generisk model til systematisk rapportering Datakilder Rapport datawarehouse Udtræk Rapportering Interessenter Indstilling til ledelsen Rapportering vedr. anvendelse af superbrugeradgange Opgave 3 Security Awareness Indledning Notat vedr. initiativer til awareness kampagner for fysisk sikkerhed Baggrund for notatet Formål Planlægning af årets kampagner Tidsplan Kampagne 1: adgang til sikrede områder, kun med arbejdsbetinget behov Kampagne 2: Tyverisikring af udstyr placeret i lufthavnen Kampagne 3: Løbende opmærksomhed omkring brandudstyr Kampagne 4: lås din computer når du forlader den Kampagne 5: Løbende eftersyn af hegn Indstilling til ledelsen Bilag 1.1 Skabelon til risikovurdering af systemer Bilag 1.2 Vurdering af sikkerhedsmiljø Bilag 1.3 Trusselsliste Bilag 2.1 Overblik over en generisk model til rapportering Bilag 3.1 ROSI beregninger til brug i opgave Side 2 af 42

3 Opgave 1 Risikoanalyse Indledning Hos Ridum Airports A/S er der opstået et behov for at sikre at virksomheden fortsat kan leve op til compliance krav, vedligeholdelse af det gode renommé og forsat høj systemtilgængelighed og integritet i data. I forbindelse med mit job som IT-Sikkerhedschef har jeg fået til opgave at fremlægge et udkast til en generisk model for IT-risikoanalyse. Modellen skal kunne anvendes som intern skabelon for alle systemer. Formålet med denne risikoanalyse er at afdække uacceptable risici ved virksomhedens itsystemer, samt at fungere som beslutningsgrundlag for iværksætning af initiativer til forbedring af sikkerheden. Inden vi kan gå i gang med at gennemføre en risikoanalyse er det nødvendigt at fastlægge om vi har tilstrækkelig viden til at kunne gennemføre arbejdet. Da man hos Ridum Airports ikke har en vedligeholdt systemklassifikation er vi som mininum nød til at undersøge om der er defineret systemejere for de systemer som vi ønsker at gennemføre en risikoanalyse for. Hvis der ikke er fastlagt et systemejerskab, eller hvis ejerskabet ikke ligger det rigtige sted skal dette bringes i orden først. Principielt er det også nødvendigt at foretage en klassifikation af systemer og data inden en risikoanalyse kan igangsættes. I vores tilfælde vil jeg dog vælge at se bort fra det. Det kræver dog at de system ejere fra forretningen, der skal bistå med risikoanalysen har virkelig godt styr på indhold af data og funktionalitet i deres systemer. Udkast til en generisk model for IT-risikoanalyse For at kunne gennemføre en it-risikoanalyse er det nødvendigt at fastlægge en arbejdsgang herfor. Jeg har besluttet mig for at basere mig på en simpel arbejdsgang. Jeg har valgt at fremstille 3 skabeloner til at understøtte denne simple arbejdsgange. Disse skabeloner vil blive gennemgået herunder. Der er tale om: - En trusselsliste, som anvendes ved identifikation af risici og prioritering af disse - Et risikovurderingsskema, som anvendes ved fastlæggelse af sandsynlighed, konsekvens og påvirkninger på fortrolighed, integritet og tilgængelighed. - Et skema til vurdering af sikkerhedsmiljøet Jeg har valgt ikke at lave et udkast til en skabelon for planlægning/gennemførsel af forbedringstiltag. Min vurdering er at dette mere handler om opgavestyring og/eller Side 3 af 42

4 projektledelse. Jeg har derfor alene inkluderet et felt i min trusselsliste, som kan indikere de mulige forbedringstiltag. Identifikation af risici Først skridt i en risikoanalyse er at identificere de trusler som vil være relevante at gennemføre en vurdering af. Det er ikke en opgave, man alene kan løse i IT Sikkerhedsfunktionen. Den kræver deltagelse af forretningen. For ikke at bruge en masse unødig energi i forretningen vil det være hensigtsmæssigt at IT sikkerhed forbereder et udkast, så der er noget at arbejde ud fra. Et sådant udkast kan man fremstille ved at kigge på hvad der er foregået f.eks. i det forgangne år. Man kigger altså på de sikkerhedshændelser der har forekommet og fremstiller sin liste udfra det. Når listen er fremstillet kan man tage en dialog med forretningen og de kan så supplere med egne erfaringer omkring hændelser, der har haft indflydelse på deres forretning. I denne fase vil det samtidig være relevant at forholde sig til risici, der endnu ikke er indtruffet. I arbejdet med at fremstille listen bør der ikke være nogen særlige begrænsninger på hvad der kan optages på listen. Der skal naturligvis være tale om noget, der kan formuleres som en risiko. Men med hensyn til små eller store risici, vil det være bedre at filtrere dem fra senere i processen. Resultatet af gennemgangen skal være en liste, der indeholder de trusler/risici som virksomheden pt. har kunnet identificere. Listen er i øvrigt et dynamisk dokument, der altid kan opdateres. Listen kunne f.eks. så således ud: Som det fremgår ovenfor er listen en oversigt over de trusler (risici), som et givent system (system X) er udsat for. For overskuelighedens skyld har jeg valgt at fremstille en trusselsliste pr. system. - nr.: Nummeret identificerer den enkelte trussel og anvendes i hele forløbet med vurdering af risici. - Trussel: Dette er den verbale beskrivelse af den trussel, som systemet er udsat for. - Sårbarhed: Sårbarheden er resultatet af det arbejde, der skal foregå sammen med forretningen omkring vurdering af den enkelte risiko. Sårbarheden er en aggregering af sandsynlighed og konsekvens (mere om det senere). Definitionen af sårbarhed følger den, der anvendes i DS484. Jeg har blot valgt ikke at illustrere den grafisk. Side 4 af 42

5 - Sikkerhedsmiljø: Resultatet af en vurdering af sikkerhedsmiljøet fortæller noget om hvilke foranstaltninger, der allerede er foretaget i miljøet, samt modenhedsniveauet af procedurer og dokumentation. (mere om det senere) - Forbedringstiltag: Når man har identificeret, risici og foretaget en vurdering af sårbarhed og sikkerhedsmiljø kan man med fordel identificere forbedringstiltag. Disse tiltag kan dække over alt fra tilpasning af arbejdsgange til igangsætning af foranalyser på projekter. (mere om det senere) Gennemførelse af risikovurdering At gennemføre en risikovurdering betyder at tage stilling til sansynlighed for at en hændelse forekommer og efterfølgende vurdere konsekvensen af at den er indtruffet. Som det fremgår af ovenstående trusselsliste udtrykkes denne vurdering som den sårbarhed en risiko påfører virksomheden. Jeg har valgt at basere mit udkast til en generisk model for risikovurdering på DS484. Jeg har dog valgt at udbygge modellen med en initiel vurdering af hvorvidt det er muligt at undgå en given trussel, ligesom jeg har valgt at lade en vurdering af truslens indflydelse på fortrolighed, integritet og tilgængelighed være en del af modellen. Den overordnede model jeg baserer mig på har jeg taget fra Leif Christensen s (PwC) ERM indlæg på uddannelsen. Det er bl.a. den, der har givet anledning til min udvidelse af DS484 modellen. Af denne overordnede model fremgår det at man for enhver risiko bør: Afdække hvorvidt truslen kan undgås, Reducere sandsynligheden for at truslen indtræffer, Reducere konsekvensen når en trussel er indtruffet, Håndtere den restrisiko, der er uacceptabel, Indhente ledelsesaccept af restrisikoen. For at kunne eksemplificere arbejdet med at risikovurdere har jeg valgt at tage udgangspunkt i en konkret risiko: Trussel / sårbarhed Axapta bliver utilgængelig fordi det underliggende disksystem løber tør for plads som følge af en løbsk procedure. LAV MID HØJ Denne trussel udgør en risiko for forretningen, og den kan derfor anvendes som eksempel i min gennemgang af den generiske model. Når man skal vurdere den enkelte risiko anvender man skemaet i bilag 1.1 jeg har blot gennemgået skemaet i detaljer her. Side 5 af 42

6 Undgå en risiko Med udgangspunkt i en konkret risiko, bør man indledningsvist vurdere om det kan lade sig gøre at undgå den helt. At undgå en risiko betyder at man ikke skal forholde sig til initiativer der kan reducere sansynlighed og konsekvens. Det sparer derfor ressourcer. I min skabelon for risikovurdering har jeg valgt at lade det at undgå en risiko indgå som et ja/nej spørgsmål. Det er ikke tanken, der skal foretages en dybdegående analyse. Punktet er blot med for at sikre at tanken er blevet tænkt. Eksempel Er det muligt at undgå truslen Vi har undersøgt om fejlen kan rettes indenfor rammerne af det eksisterende system. Da der er tale om en oracle fejl som pt. Ikke er håndteret fra oracles side kan truslen ikke undgås. Ja Nej x Vurdering af sandsynlighed At vurdere sandsynligheden for om en trussel vil forekomme eller ej er ikke nogen eksakt videnskab. Det kan måske lade sig gøre at opstille en formel, der beregner denne sandsynlighed. Det vurderer jeg dog er rimeligt formålsløst og jeg har derfor valgt at basere vurderingen af sandsynlighed på en kvalitativ skala (som i DS484). lav mid høj Benyttes hvis truslen vurderes at forekomme yderst sjældent. Eller den slet ikke er forekommet i praksis. Benyttes hvis truslen vurderes til at forekomme af og til. Eller den i praksis er forekommet mindst en gang. Benyttes hvis truslen vurderes til at forekomme hyppigt. Eller den i praksis er forekommet flere gange. Arbejdsgangen er at man først beskriver den måde man oplever sandsynligheden på og dernæst foretager en kvalitativ vurdering af sandsynligheden. Eksempel: Sandsynlighed (Hvor ofte er truslen observeret) Vi har observeret mangel på diskplads i flere tilfælde. Hver gang på grund af denne løbske procedure. Vi forventer at fejlen vil indtræffe med jævne mellemrum. Der er ikke noget fast mønster. LAV MID HØJ x 3 Vurdering af konsekvens At vurdere konsekvensen af en risiko handler om at sætte værdi på den indflydelse en given risiko vil få for forretningen når den er indtruffet. Når vi taler om konsekvens er risikoen altid indtruffet med den fulde effekt. Det vil ganske givet være muligt at sætte faktuelle tal på mange Side 6 af 42

7 af de konsekvenser, der kan indtræffe, men det vil være meget svært at ramme et rigtigt tal. Som med sandsynlighed har jeg derfor valgt at basere modellen på en kvalitativ skala. lav Benyttes hvis truslens indtræffen vurderes at have en ikke væsentlig effekt på forretningen. mid Benyttes hvis truslens indtræffen vurderes at have en væsentlig skadende effekt på forretningen. høj Benyttes hvis truslens indtræffen vurderes at have en særdeles skadende effekt på forretningen. Arbejdsgangen er at man først beskriver den måde man oplever konsekvensen på og dernæst foretager en kvalitativ vurdering af konsekvensen: Eksempel: Konsekvens (hvordan påvirkes forretningen når truslen er indtruffet) Det vurderes at truslens indtræffen har en væsentligt skadende effekt på forretningen. Vores salgskontor er bl.a. ikke i stand til at fakturerere. Salg kan dog foregå manuelt (og meget besværligt) LAV MID HØJ x 5 I forbindelse med vurdering af konsekvens har jeg valgt at inkludere risikoens påvirkning på henholdsvis fortrolighed, integritet og tilgængelighed. Den primære årsag til at jeg har valgt dette er at jeg ønsker at risici, der har med compliance, integritet og driftsstabilitet at gøre, kommer til at vægte med når sårbarheden skal opgøres. Jeg har valgt at måle fortrolighed, integritet og tilgængelig ud fra en kvalitativ skala, som vurderer i hvilket omfang en konkret risiko har indflydelse på hht. F,I,T. lav Benyttes hvis truslen vurderes at have ingen, eller meget ringe effekt på (F,I,T) mid Benyttes hvis truslen vurderes at have nogen effekt på (F, I, T) høj Benyttes hvis truslen vurderes at have væsentlig effekt på (F, I, T) Ligesom med sandsynlighed og konvsekvens er arbejdsgangen at man beskriver den forventede påvirkning og efterfølgende tager stilling på den kvalitative skala. Eksempel: Hvordan påvirkes fortrolighed når truslen er indtruffet Der er ingen umiddelbare konsekvenser for fortrolighed LAV MID HØJ x 1 Side 7 af 42

8 Hvordan påvirkes integritet når truslen er indtruffet Det vurderes at integriteten af nogen transaktioner kan blive ufuldstændig når databasen går ned. Det sker fordi rollback segmentet ikke kan opdateres. LAV MID HØJ x 3 Hvordan påvirkes tilgængelighed når truslen er indtruffet Det vurderes at have en væsentlig effekt på tilgængeligheden når truslen indtræffer. Hele systemet er nede og det vil i de fleste tilfælde betyde at systemet er nede i flere timer. LAV MID HØJ x 5 Beregning af sårbarhed Når man har udfyldt skabelonen og markeret med x i lav, mid eller høj vil der blive kalkuleret en relativ sårbarhed for risikoen. Denne sårbarhed, overføres til vores trusselsliste. Sårbarheden fremkommer som en beregning på de registreringer, der bliver foretaget i skabelonen. Hver markering giver en værdi (Lav = 1, Mid = 3, Høj = 5). Alle værdier summeres og deles med 5 (antallet af vurderinger). Sårbareheden fastlægges derefter udfra følgende skala: Mindre end 1,5 svarer til lav sårbarhed Mellem 1,5 og 3,5 svarer til Mid sårbarhed Over 3,5 svarer til Høj sårbarhed Da der er tale om en beregning baseret på kvalitative vurderinger kan man ikke sige noget meget specifikt omkring prioritering af risici. Hovedreglen vil dog være at: Lav Sårbarheden er acceptabel og det er ikke umiddelbart nødvendigt at foretage korrigerende handlinger mid Sårbarheden er ikke acceptabel og der bør foretages korrigerende handlinger Høj Sårbarheden er helt uacceptabel og der skal snarest muligst foretages korrigerende handlinger. Hvilke typer af korrigerende handlinger, der skal foretages og hvor hurtigt det skal gå vil i nogen grad afhænge af kvaliteten i sikkerhedsmiljøet. Som hovedregel bør man ikke igangsætte korrigerende handlinger uden først at have vurderet det eksisterende sikkerhedsmiljø. Der kan dog være tale om en så høj risiko at det ikke vil være forsvarligt at afvente en sådan vurdering. Side 8 af 42

9 Vurdering af sikkerhedsmiljø Når risikovurderingen er gennemført, skal der tages stilling til det eksisterende sikkerhedsmiljø. Det er nødvendigt for at identificere om de risici vi har afdækket på den ene eller anden måde håndteres af vores nuværende politikker, retningslinier og procedurer. Sikkerhedsmiljøet er de foranstaltninger vi har etableret for minimere sandsynlighed for at risici indtræffer på et konkret system og for at minimere konsekvensen når de indtræffer. Der findes potentielt rigtigt mange foranstaltninger man kan vurdere i relation til sit sikkerhedsmiljø. Jeg har valgt at basere min skabelon på nogen få foranstaltninger. Antallet af foranstaltninger kan med fordel udvides senere. Det er vigtigt at holde fast i at sikkerhedsmiljøet gælder for systemet og ikke for den enkelte risiko/trussel. Den enkelte risiko/trussel skal dog sætte i forhold til sikkerhedsmiljøet. Arbejdet med vurdere sikkerhedsmiljøet sker i samarbejde med system ejeren. Den del af skabelonen, som man udfylder ser således ud: Som det fremgår af ovenstående er skabelonen delt i 2 (Den fulde skabelon kan ses i bilag 1.2.). - Reduktion af sandsynlighed: som indeholder de elementer, der kan være med til at reducere sandsynligheden for at noget sker. o Godkendt dokumentation er et udtrykt for forankret viden. Når man ved noget om sin installation mindsker det sandsynligheden for fejl o Viden om systemet. Hvis nu dokumentationen ikke er helt i toppen, men vi f.eks. har ansat meget dygtige folk med stor viden. Så kan det igen være med til at mindske sandsynligheden for fejl o Overvågning. Hvis man har etableret en proaktiv overvågning, betyder det at man kan fange kritiske fejl i opløbet og dermed reducere sandsynligheden for at de indtræffer o Af andre typer af foranstaltninger kunne nævnes uddannelse, configuration management, change management. - Reduktion af konsekvens: som indeholder de elementer, der kan være med til at reducere konsekvensen af at noget sker. o Procedurer for håndtering af truslen. Hvis vi har en procedure, der beskriver hvordan vi skal håndtere en trussel når den indtræffer. Så kan det begrænse konsekvensen. o Hvis der eksisterer en eskaleringsliste. Kan vi få fat på de rigtige personer når en trussel indtræffer. Det betyder hurtigere håndtering og mindre konsekvens. o En beredskabsplan er det ultimative værktøj til håndtering af konsekvens. o Af andre typer af foranstaltninger kunne nævnes. Benyttelse af spejlede diske, roll back procedurer ved fejl og redundant strømforsyning. Side 9 af 42

10 Når man har vurderet sit sikkerhedsmiljø fremkommer der igen en kvalitativ vurdering. Denne kvalitative vurdering er et udtryk for styrken i sikkerhedsmiljøet. Stærk Middel Svag Benyttes når det vurderes at sikkerhedsmiljøet er tilstrækkeligt og mindst 5 krydser kan sættes Benyttes når det vurderes at sikkerhedsmiljøet er godt og mindst 3 krydser kan sættes Benyttes når det vurderes at sikkerhedsmiljøet er ringe og under 3 krydser kan sættes Resultatet af denne gennemgang overføres til trusselslisten. Planlægge og gennemføre forbedringstiltag Når hele risikovurderingen er gennemføre og vi har en færdig trusselsliste (se evt. bilag 1.3) skal der nu foretages en vurdering af hvilke forbedringstiltag der skal gennemføres. For at få en indikation af hvilke risici, der skal håndteres først sorteres listen efter sårbarhed, hvor høj sårbarhed kommer først, dernæst efter styrke i sikkerhedsmiljøet, hvor lav kommer først. Dette kan udtrykkes grafisk for at give et overblik over hvordan forholdet er mellem f.eks. høj sårbarhed og et svagt sikkerhedsmiljø, som er de trusler vi umiddelbart bør håndtere. I dette arbejde er det vigtigt at skelne mellem tiltag, der kan indføres indenfor rammerne af de eksisterende budgetter og tiltag, der kræver investeringer. Tiltag, der kan gennemføres indenfor de eksisterende rammer kan med fordel igangsættes, mens det er nødvendigt at indhente økonomi, til de, der kræver investeringer. Accept af restrisiko Når vi har planlagt eller gennemført forbedringstiltag vil der med stor sandsynlighed stadigvæk være antal risici på vores trusselsliste. Det er vigtigt at ledelsens bliver orienteret om disse risici og accepterer dem. Side 10 af 42

11 Notat med forslag til håndtering af risikoanalyse for system og data omkring flysikkerhed Baggrund for notatet Med henblik på at der skal gennemføres en risikoanalyse af vores system til håndtering af flysikkerhed. Har vi i IT sikkerhedsfunktionen udarbejdet dette notat for at redegøre for det forløb, der skal sikre at vi får udført en god risikoanalyse. Forberedelse Inden vi går i gang med selve risikoanalysen er det nødvendigt at identificere system ejeren af flysikkerhedssystemet. Af vores systemklassifikation fremgår det at systemet er ejet af den funktion, der tager sig af landingsservice. Dette skal dog verificeres, så vi sikrer os at vi har adgang til den rigtige information. Da vores risikoanalyse også omfatter de kritiske data, der ligger til grund for flysikkerheden er det også nødvendigt at sikre, der er lavet en opdateret klassifikation af systemets data. Hvis disse data ikke kan tilvejebringes vil vi behandle systemet som et høj risiko system. Identifikation af risici For at frembringe en trusselsliste, som vi kan bruge i det videre arbejde vil vi først og fremmest lave en liste over de sikkerhedshændelser vi har haft på systemet i det forgangne år. Når denne liste er klar vil vi fremsende den til system ejeren sammen med en mødeindkaldelse hvori vi redegør for det forløb, der nu skal til at foregå. På mødet med system ejeren skal vi have fastslået om de risici vi har identificeret er valide set med hans øjne, og listen skal suppleres med trusler han måtte se fra forretningens side. Mødet afsluttes med at alle nikker OK til at listen er tilstrækkelig komplet og der aftales et nyt møde hvor planen er at de enkelte trusler skal risikovurderes. Gennemførelse af risikovurdering På møde nr. 2 skal vi gennemføre selve risikovurderingen. Inden mødet bør alle have forholdt sig til en overordnet væsentlighed af de nedskrevne trusler. Det er nødvendigt for at man hurtigt kan få filtreret det fra, som alligevel viser sig at være uvæsentligt. På mødet skal vi nu gennemgå hver enkelt trussel. Det gøres ved at udfylde vores skabelon. Det vil sige at der for hver risiko skal tages stilling til: 1) kan den undgås 2) hvad er sandsynligheden for at den indtræffer 3) hvad er konsekvensen af at den indtræffer 4) hvilken betydning har truslen for fortrolighed, integritet og tilgængelighed 5) den kalkulerede sårbarhed overføres til trusselslisten. Side 11 af 42

12 Vurdering af sikkerhedsmiljø Inden der skal tages stilling til hvilken forbedringstiltag, der skal igangsættes på baggrund af risikovurderingen. Skal det sammenholdes med en vurdering af sikkerhedsmiljøet for flytrafiksystemet. Hvis denne vurdering af sikkerhedsmiljøet ikke eksisterer skal den udføres, det vil i såfald skulle foregå på et 3die møde mellem it sikkerhed og system ejeren. Planlægning af forbedringstiltag Når vi har gennemført risikovurderingen og vurderingen af sikkerhedsmiljøet. Får vi en liste som vi kan prioritere. Ud fra denne liste kan vi umiddelbart fremstille en oversigt over forbedringstiltag, der måtte ønske. Fordi vores risikovurdering er verbaliseret, vil det umiddelbart være muligt at få hints til initiativer, der kan igangsættes her. Specielt vurdering af fortrolighed, integritet og tilgængelighed vil afsløre hvad der konkret er udfordringen. Når der er fremstillet en endelig liste, som kan betegnes som færdigbehandlet, vil denne blive fremsendt til direktionen. Listen vil give et overblik over det nuværende risikobillede og give en indikation af hvilke initiativer, vi har planlagt i samarbejde med forretningen. De forbedringstiltag, der kan igangsættes med nuværende ressourcer vil umiddelbart blive afviklet, mens de tiltag, der kræver ekstra økonomi vil blive fremlagt for direktionen til godkendelse. Konklusion Ved at gennemføre ovenstående for flytrafiksikkerhedssystemet vil vi opnå en tilstrækkelig sikkerhed for at vi kender de risici, som systemet er udsat for og vi vil være sikret at vi i tilstrækkeligt omfang har forsøgt at imødekomme dem. Hvor det af økonomiske eller praktiske årsager ikke er muligt at håndtere en given risiko. Står det nu alene tilbage at vurdere om vi kan leve med risikoen eller om vi skal forsøge med yderligere forbedringstiltag. Side 12 af 42

13 Opgave 2 Sikkerhedsrapport til ledelsen Indledning Hos Ridum Airport A/S har ledelsen anmodet om at øge informationsniveauet omkring det sikkerhedsarbejde, der foregår i virksomheden. Notatet herunder er et generisk forslag til hvordan man kunne vælge at gennemføre generisk rapportering omkring IT Sikkerhed i Ridum Airports A/S. Når man skal designe en model for at rapportere er det vigtigt at man holder flere ting for øje. Man skal kende sin målgruppe og dens behov. Man skal tage stilling til hvordan data skal fremkomme. Der skal tages stilling til hvor ofte rapportering skal foretages og hvad den konkret skal indeholde. For at kunne løse den stillede opgave har det vist sig praktisk at gøre et antal forudsætninger, der ikke umiddelbart fremgår af opgave teksten: Der findes en ledelsesgodkendt IT politik Der eksisterer en Service Desk Forretningen har fastlagt Key Performance Indicators Ridum Airports har et datawarehouse hvori de i dag konsoliderer forretningsdata. Af opgaven fremgår det at der findes en IT sikkerhedspolitik, som man ikke nødvendigvis lever helt op til. For god ordens skyld vil jeg forudsætte at den er forankret i ledelsen. I forbindelse med håndteringen af den daglige IT drift forudsætter jeg at virksomheden har et Service Desk system. Det er en forudsætningen for at kunne registrere hændelser. Jeg forudsætter derudover at alle sikkerhedshændelser registreres i dette miljø. Da meget af rapporteringen skal rettes mod forskellige målgruppers behov, forudsætter jeg at disse behov bl.a. er formuleret i form af KPI. Af opgaven fremgår det at virksomheden i dag foretager avanceret data analyse på forretningsdata. Jeg forudsætter at dette sker i et datawarehouse baseret på database teknologi. Side 13 af 42

14 Notat vedr. generisk forslag til systematisk rapportering af IT Sikkerhed Baggrund for notatet I forbindelse med vores sammenlægning i koncernen har der vist sig et behov for øget information fra sikkerhedsområdet. Denne information skal være med til at sikre ledelsen at IT Sikkerhedsindsatsen har det rigtige niveau. Rapporteringen er en forudsætning for at vurdere hvordan vi har løst vores opgave i den forgangne periode og anvendes altså til at vurdere om der er behov for tilpasning af indsatsen. For at kunne bruges til det skal rapporten være rettet mod de Key Performance Indicators (KPI) som forretningen har valgt at basere sig på. Indikationen af at virksomheden har det rigtige sikkerhedsniveau er at man er i stand til at leve op til de fastlægte KPI og KSI (Key Security Indicator). Når man ikke er i stand til at honorere disse mål, kan der være tale om en utilstrækkelig indsats. Sammenholdt med risikoanalysen giver sikkerhedsrapportering gives et overblik over sikkerhedsniveauet i virksomheden. Hvis der ikke er nogen væsentlige afvigelser i vores rapportering, og der ikke er nogen elementer i vores risikoanalyse der har status uacceptabel, kan sikkerhedsindsatsen siges at være tilstrækkelig. Generisk model til systematisk rapportering Uden registrering, ingen rapportering. Det lyder enkelt, og det er det også. Hvis ikke vi har styr på de data, der skal udgøre vores rapportering har vi ikke styr på vores rapportering. Eller det kræver i hvert fald en stor indsats med efterbearbejdning af data. En af forudsætningerne for at et generisk rapporteringsmiljø kan fungere effektivt er at alle rapporter, uanset form og modtager, baserer sig på det samme sæt af data. Et eksempel kunne være at ledelsen er interesseret i brud på sikkerhedspolitikken. Det kan man levere f.eks. i form af en graf, der fortæller noget om hvilke retningslinier, man har forbrudt sig imod. Forudsætningen er at bruddene er registreret. Den samme registrering kan så anvendes af en afdelingsleder til at se på hvilke arbejdsgange, der er behov for at kigge yderligere på. Det er vigtigt at data kommer fra den samme kilde, uanset rapporteringsformålet, fordi det øger troværdigheden i rapporteringen og mindsker muligheden for fejl. Derudover begrænser det naturligvis indsatsen til i det hele taget at foretage de nødvendige registreringer, der skal anvendes for at danne den nødvendige rapportering. Når man taler omkring rapportering er en af de vigtigste discipliner at få fastlagt hvilke kilder, der ligger til grund for rapporteringen. Det kan ikke lade sig gøre at automatisere al rapportering, men man kan komme langt med at automatiskere standardrapportering. Udgangspunktet for en generisk model til systematisk rapportering er derfor at finde en metode til at strukturere tilgængelige data og sammenstille dem på en måde så de passer til de behov som målgruppen har. Side 14 af 42

15 Tegningen her ved siden af er et bud på hvordan en generisk model for systematisk rapportering kunne se ud. Modellen tager udgangspunkt i etableringen af et rapport datawarehouse. Fra dette datawarehouse skal man så kunne trække de rapporter, man har brug for. Modellen består af flere elementer: - datakilder - datawarehouse - udtræk - rapportering - Interessenter Se evt. bilag 2-1 for en større udgave af tegningen Datakilder Datakilder til et rapport datawarehouse kan være mange. I praksis er der ikke nogen begrænsning på hvilke data man kan hælde i det. Forudsætningen er blot at data kan struktureres i en form, så de kan rapporteres ensartet. Meget af den rapportering, der med fordel kan leveres fra IT Sikkerhedsfunktionen tager udgangspunkt i hhv. manuelle og automatiserede hændelser. En manuel hændelse er registreringer i vores Service Desk system, mens de automatiserede hændelser er dem, der kommer fra vores System Management miljø. Eksempler på information, der kunne komme fra SNM miljøet kunne være. Alarmer Logfiler Transaktioner Når der sker et konkret brud på sikkerheden skal der genereres en alarm. Alarmen håndteres i den normale drift, mens rapporteringen af dens forekomst overføres til datawarehouset. Det kunne f.eks. være forsøg på at opnå uautoriseret adgang. For at kunne udføre en fornuftig sikkerhedsrapportering, er det vigtigt at kende de logfiler, der fortæller noget om sikkerhed. Et eksempel kunne den logfil, der fortæller noget om tildeling af rettigheder. Hvor forekomsten af tildelinger ikke nøvendigvis giver anledning til alarm, er det vigtigt at disse overføres til vores datawarehouse, så vi kan analysere og rapportere på dem. Når en transaktion skal gennemføres, er det vigtigt for systemernes integritet at transaktionen gennemføres helt. I de tilfælde hvor en Side 15 af 42

16 transaktion går galt, skal den naturligvis rulle tilbage, men der bør ligeledes foretages en opsamling af disse hændelser i vores datawarehouse, så vi kan holde styr på hvordan det ser ud. Databaser Oprettelse, nedlæggelse og administration af databaser, er alle hændelser, der kan betyde noget for systemsikkerheden. Disse aktiviteter bør derfor også logges i vores datawarehouse. Vores Service Desk anvendes til registrering af henvendelser fra medarbejdere i forretningen. Der er i vores Service Desk oprettet de nødvendige kategorier til klassificering af sikkerhedshændelser og det er derfor en formsag at trække den nødvendige rapportering. Service Desk systemet anvendes derudover til oprettelse og styring af Change og configuration management. Eksempler på registering af information i vores Service Desk kunne være Tyveri Tildeling af rettigheder Change Managament Når, der bliver stjålet noget i vores virksomhed kan dette med fordel registeres. Når en medarbejder skal have tildelt nye rettigheder, vil det være oplagt at dette kan ske på baggrund af en registering i vores Service Desk. Når der skal laves ændringer til et system, som f.eks. kan have indflydelse på sikkerheden i et system, kan dette med fordel fremgå af vores Service Desk system. Når alle disse registeringer er på plads i de respektive kildesystemer. Så kan de efterfølgende konsolideres i et rapport datawarehouse. Rapport datawarehouse Rapport datawarehouse er der hvor vi konsoliderer alle alarmer, hændelser, logfiler og hvad der ellers måtte være nødvendigt for at kunne gennemføre en systematisk rapportering om arbejdet med virksomhedens it-sikkerhed. Et rapport datawarehouse er ikke en betegnelse for en teknisk løsning. Det er en beskrivelse af en datamodel for hvordan data skal se ud. Det betyder at man skal tage stilling til hvad elementer, der skal rapporteres på, skal indeholde. Det vil være for meget for dette notat at beskrive en fuld datamodel, men af væsentlige elememter kan nævnes at data skal struktureres så de kan tælles, kategoriseres og registeres med et tilstrækkeligt niveau af detaljer. Selvom et datawarehouse alene kan baseres på en datamodel og f.eks. udtræk fra kildesystemer vil det være en stor fordel om der etableres en teknisk løsning til samling af rapport data. Da der Side 16 af 42

17 ikke er forskel på arbejdsprincipperne bag et forretnings datawarehouse og et rapporterings datawarehouse kan vi umiddelbart anvende vores eksisterende datawarehouse. Et eksempel på strukturering af et dataelement kunne være logfilen fra før. Elementet, der skulle indgå i vores datawarehouse kunne være noget i retning af - kategori: uautoriseret adgang - brugernavn: brugernavnet fra idm systemet - Antal: overføres ikke, dette akkumuleres i datawarehouset - Detaljerede oplysninger: hvilke data, blev der forsøgt adgang til Udtræk Når først datawarehouset er blevet etableret skal der defineres et antal udtræk, som giver os mulighed for at anvende de registrede data i vores rapportering. Det vil være nødvendigt at levere forskellige typer af udtræk: - automatiserede udtræk: Disse er det tætteste man kommer på en generisk standardrapportering. Der vil typisk være tale om meget strukturerede data, som kan fastlægges på forhånd. Et eksempel kunne være logfilen fra før antal uautoriserede adgangsforsøg - Business Intelligence udtræk: Disse udtræk ville typisk kunne anvendes til mere målrettet rapportering. Hvis nu en afdelingsleder beder om en rapport, der kan afdække uautoriserede adgangsforsøg for en bestemt medarbejder, så kan man køre et BI udtræk med brugernavnet som parameter. Disse udtræk vil også typisk konsolidere flere typer af informationer. Hvis en bruger nu har forbrudt sig i et system, hvad har han så ellers haft adgang til. - Søgninger: Der er bare noget rapportering, som man ikke kunne drømme om man havde brug for inden man gik i gang. Der skal derfor være mulighed for at søge frit i datawarehouset hvis man sidder med et konkret behov for information. Rapportering Når de nødvendige udtræk er blevet defineret i vores datawarehouse kan vi begynde og kigge på opbygningen af selve rapporteringen. En god rapport skal opfylde en række kriterier: - Målrettet: Rapporten skal være designet til den, der skal modtage den. Det vil sige den skal dække det behov for information som modtageren har. En god rapport sætter modtageren i stand til at opnå sine egne mål. Hvis rapporten ikke sætter modtageren i stand til at gøre det, vil den for det meste være af informativ karakter og der er så risiko for at den ikke bliver taget alvorligt. Eksempel En rapport til økonomichefen, som fortæller at der ikke har været nogen uautoriseret adgang til regnskabsdata vil kunne støtte ham i hans arbejde når revisionen kommer for at revidere regnskabet. - Rettidig: Hvis en rapport kommer når der er brug for den. Så har den værdi. Hvis den alene kommer som afslutning på hændelser, eller information om ting, der er sket i fortiden så har den igen kun informativ karakter. Et eksempel på en rettidig information kunne være at en afdelingsleder fik en rapport over uautoriserede adgangsforsøg i forbindelse med at han skulle redegøre for sine medarbejderes privilegier ved den årlige revision. Efter revisionen ville selv samme rapport alene have informativ værdi. Side 17 af 42

18 - Troværdig: Det er væsentligt for vores rapportering at den er troværdig. Der er ikke noget, der kan underminere en god rapport, som manglende eller forkerte data. Hvis vi f.eks. afleverer en rapport, der siger at vi ikke har haft nogen uautoriserede adgangsforsøg og det efterfølgende viser sig at være forkert, så har vi et troværdighedsproblem i vores rapportering. Det er derfor vigtigt at kende præmissen for rapporteringen, inden man konkluderer på baggrund af den. - Overskuelig og hensigtsmæssig form: Når det er besluttet hvilke data, der skal indgå i den målrettede rapportering, og niveauet af data er fastlagt er det ligeså vigtigt at man har taget stilling til hvordan data skal fremstilles. Det kan f.eks. ikke nytte noget at man den ene gang viser antal af uautorisede adgangsforsøg i en graf og næste gang med et tal. Man må vælge stil og følge den. Der bør derudover tages stilling til hvordan informationen distribueres. Skal den lægges på intranettet, er det en formel rapport eller måske en . Af den generiske model for systematisk rapportering fremgår det at der skal rapporteres på projekter og aktiviteter. Den detaljerede rapportering omkring projekter og status på disse bør komme fra projektkontoret. Af sikkerhedsrapporteringen bør det kortfattet fremgå hvilke projekter man har gang i, hvilke aktiviteter, der i øvrigt rør sig. Derudover bør risikoanalysen have sit helt eget kapitel i sikkerhedsrapporteringen. Interessenter For at konkretisere rapportering, hyppighed, niveau og indhold følger her en kort gennemgang af de forskellige målgrupper i Ridum Airport. - Direktionen - Mellemledelsen - Medarbejdere - Account Managere Jeg har valgt at inkludere account managere som målgruppe. Det har jeg gjort fordi de i praksis har god føling med hvad der sker hos vores erhvervskunder og det er min vurdering at det har væsentlig værdi for disse kunder at blive informeret om de tiltag vi gør hos Ridum Airports for at forbedre vores produkter. Rapporteringen bør dog ikke foregå ufiltreret, og derfor tilgår den vores account managere, der så selv vælger hvilken information de vil lade gå videre. Direktionen Formål / behov Da det er Direktionens pligt og ansvar at tildele og fratage midler til bl.a. IT Sikkerhedsfunktionen er det væsentligt at de får en information, der kan sikre at de er vidende om forhold der har indflydelse på virksomhedens evne til at udføre sin forretningsstrategi. Direktionen har behov for forskellige typer af information. Side 18 af 42

19 - Kritiske hændelser: Når en hændelse kan have væsentlig indflydelse på forretningen skal direktionen være orienteret, så de kan træffe de nødvendige korrigerende foranstaltninger. - Opfølgning: Direktionen udstikker IT strategien og IT Sikkerhedspolitikken. De skal derfor have information om tingenes tilstand. - Investering: Når vi skal foretage nye investeringer, skal Direktionen have den nødvendige information for at kunne træffe beslutningen omkring økonomi. Risikoanalysen vil typisk være et godt redskab i denne forbindelse. De krav, der stilles fra direktionen til IT Sikkerhedsfunktion vil typisk være forankret i en IT Strategi og en IT Sikkerhedspolitik. At understøtte forretningen betyder altså at man fra IT Sikkerhedsfunktionens side arbejder på at leve op til det, der bliver fastlagt i strategi og politik. Direktionens behov for rapportering er således dokumentation for at den strategi, og de politikker der er udstukket bliver fulgt. Derudover vil det være naturligt at mellemledelsen sørger for at informere omkring performance på de arbejdsgange, de etablerer for at leve op til strategi og politik. Indhold / niveau Indholdet skal være kortfattet og præcist og helst formuleret så det fremgår tydeligt hvordan forretningen bliver påvirket. Eksempelvis: Potentiel lækage af data vedr. VIP landinger I går opnåede en medarbejder uautoriseret adgang til data omkring VIP landinger i lufthavnen. Medarbejderen havde ubegrænset adgang i 3 timer, og foretog i den periode flere søgninger i databasen. Vi har begrundet mistanke om at disse oplysninger kan være lækket til pressen. Den uautoriserede adgang opstod som følge af en computer, der henstod ulåst med administrative privilegier. Vi har indskærpet vores retningslinjer for medarbejderen, der lod skærmen stå ligesom vi har taget initiativ til en awareness kampagne om låsning af computere. Der er ikke konstateret ændringer i data, ligesom den uautoriserede adgang ikke har haft betydning for systemernes tilgængelighed. Vi har umiddelbart spærret medarbejderens adgang til vores systemer og har endvidere overgivet sagen til afdelingschefen og HR for en vurdering af de ansættelsesmæssige konsekvenser. /IT Sikkerhed Hyppighed Rapportering om tingenes tilstand bør foregå på månedsbasis Rapportering omkring kritiske hændelser bør foregå umiddelbart Rapportering omkring investeringer bør foregå efter behov Side 19 af 42

20 Mellemledelsen Det er mellemledelsens pligt og ansvar at tilrettelægge arbejdet i de enkelte funktionsområder på en sådan måde at arbejdet kan ske i overensstemmelse med forretningens strategi, IT stragetien og IT sikkerhedspolitikken og hvad er i øvrigt måtte være af politikker og retningsliner. Mellemledelsen vil typisk have fastlagte budgetter at operere under. Ligesom de også vil være underlagt f.eks. omsætningsmål. Da IT systemerne hjælper dem med at holde omkostningerne i ro og nå deres omsætningsmål har de en naturlig interesse i at blive informeret om hændelser og tiltag, der har indflydelse på dette. Mellemledelsen har behov for forskellige typer af information. - Kritiske hændelser: Når en hændelse har væsentlig indflydelse på et forretningsområde er det vigtigt at ledelsen er informeret. - Opfølgning: En mellemleder godkender f.eks. hvilke adgange hans medarbejdere skal have. Han vil derfor være interesseret i rapportering, der fortæller hvilke adgange, der er tildelt. Det betyder at han kan følge op på at der er foretaget de korrekte tildelinger. Oppetid/svartid: Da mellemlederen jo er anvarlig for omsætningen. Vil hans primære interesse ligge i information om hvordan systemet har været tilgængeligt og hvordan det har performet. - Change Management: Hvis der planlægges f.eks. sikkerhedsopdateringer. Så vil mellemlederen også være interesseret i information. En opdatering kunne jo betyde nedetid i hans forretningsområde. - Forbedringsforslag: For at arbejde bedre sammen med forretningen bør IT sikkerhed generere rapporter, som kan afdække områder hvor man kan hjælpe med at forbedre sikkerheden. Eks. en awareness kampagne rettet mod nedbringelse af tyveri af udstyr (som giver driftsforstyrrelser). Udover dette bør mellemlederne naturligvis have adgang til samme information som Direktionen. Indhold / niveau Indholdet skal være kortfattet og præcist og helst formuleret så det fremgår tydeligt hvordan forretningen bliver påvirket. Niveauet vil være forskelligt alt efter om mellemlederen er f.eks. økonomichef, it chef, ansvarlig for landingstårnet m.v. hovedreglen er dog stadigvæk at informationen skal rettes mod de KPI er som den enkelte mellemleder er ansvarlig for. I HR funktionen vil man være interesseret i information, der fortæller om man lever op til lovgivningen. I Økonomifunktionen vil man være interesseret i information, som har betydning for aflæggelse af regnsskabet (tages der backup, hvem har adgang). I check-in området vil man være interesseret i hændelser, der har indflydelse på systemernes drift. Hyppighed Rapportering omkring kritiske hændelser bør foregå umiddelbart Rapportering omkring opfølgning bør tilrettelægges så det passer ind i arbejdsgangen Rapportering om oppetid/svartid bør foregå på månedsbasis Rapportering om change management bør foregå efter behov Rapportering om forbedringsforslag bør foregå når et behov identificeres. Eller evt. i samarbejde med forretningen i form af rådgivning. Side 20 af 42