Vejledning IT- og Telestyrelsen København den 21. februar 2008



Relaterede dokumenter
DS 484:2005. Standard for informationssikkerhed -Korte uddrag fra DS484

Bilag 5 Aarhus Kommune. Udpluk af IT-sikkerhedspolitik Regler Virksomhedens regler for informationssikkerhed 1.0. Opbevaring/sletning af informationer

NOTAT. Køge Kommune It-sikkerhed Overordnede retningslinjer ITafdelingen. Fællesforvaltningen. Dato Sagsnummer Dokumentnummer

Faxe Kommune. informationssikkerhedspolitik

IT-sikkerhedspolitik. for Social- og Sundhedsskolen Esbjerg

It-revision af selvejende institutioner Seminar i Rigsrevisionen den 5. maj 2015

Bilag 1 Databehandlerinstruks

IT- og informationssikkerheds- politik (GDPR) For. Kontrapunkt Group

Status for ændringer. Informationssikkerhedspolitik for Region Hovedstaden. Version 1.2

Ledelsen har sikret, at der er etableret en hensigtsmæssig itsikkerhedsorganisation

Version: 1.0 Maj Informationssikkerhedspolitik for Struer Statsgymnasium

Procedure for tilsyn af databehandleraftale

3. Generelt a) Databehandlerens behandling af data sker alene efter dokumenteret instruks fra den dataansvarlige og alene til det aftalte formål.

Region Syddanmark Politik for it-sikkerhed Oktober 2009 Version 0.6

Bekendtgørelse om ændring af bekendtgørelse om ledelse og styring af pengeinstitutter m.fl.

Informationssikkerhedspolitik for <organisation>

ISAE 3000 DK ERKLÆRING MARTS RSM plus P/S statsautoriserede revisorer

Politik <dato> <J.nr.>

Informationssikkerhedspolitik

Overordnet Informationssikkerhedspolitik

IT-sikkerhedspolitik for Lyngby Tandplejecenter

Informationssikkerhedspolitik For Aalborg Kommune

Hjørring Kommune. Overordnet I-sikkerhedspolitik for Hjørring Kommune

KOMBIT sikkerhedspolitik

IT-sikkerhedspolitik for

Overordnet organisering af personoplysninger

Eksempel på KOMBITs instruks til ISAE 3000 revisionserklæring

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik

Aarhus Kommune. IT-sikkerhedspolitik. Politik

Instrukser for brug af it

Informationssikkerhedspolitik. for Aalborg Kommune

Overordnet organisering af personoplysninger

Forslag til. Vordingborg Kommunes. Overordnede bestemmelser. IT- informationssikkerhed

Indholdsfortegnelse Indledning Formål Omfang Holdninger og principper... 4

SOPHIAGÅRD ELMEHØJEN

IT-sikkerhedspolitik S i d e 1 9

BILAG 5 DATABEHANDLERAFTALE

Assens Kommune Sikkerhedspolitik for it, data og information

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik

Databeskyttelsespolitik for DSI Midgård

MedComs informationssikkerhedspolitik. Version 2.2

Informationssikkerhed Version

Databehandleraftale vedrørende brug af. WinPLC og relaterede services. Version 1.0 d. 1. november Parterne. Kundenr.:

Databehandleraftale mellem Aarhus Kommune, Børn og Unge og leverandørnavn indsættes

It-sikkerhedspolitik for Farsø Varmeværk

Tabulex ApS. Februar erklæringsår. R, s

Databehandleraftale mellem Aarhus Kommune, Børn og Unge og [leverandørnavn indsættes]

PSYKIATRIFONDENS Informationssikkerhedspolitik

Overordnet it-sikkerhedspolitik for Rødovre Kommune

1 Informationssikkerhedspolitik

INFORMATIONS- SIKKERHEDSPOLITIK

Informationssikkerhedspolitik. Frederiksberg Kommune

AFTALE OM BEHANDLING AF PERSONOPLYSNINGER. Mellem. [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren )

Bilag X Databehandleraftale

Politik for informationssikkerhed i Plandent IT

IT driftsaftale Bilag 7: IT-sikkerhedsbestemmelser

Informationssikkerhedspolitik Frederiksberg Kommune

DATABEHANDLERAFTALE. Mellem. [XXXX] Kommune [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Kommunen )

DATABEHANDLERAFTALE. Mellem parterne: Den dataansvarlige myndighed Regioner og kommuner (herefter Dataansvarlig )

1 Informationssikkerhedspolitik Hvorfor vil vi sikre vores informationer? Hvad dækker begrebet "informationer"? 2

Databehandleraftale Bilag 8 til Contract regarding procurement of LMS INDHOLD

Netic A/S. Erklæring fra uafhængig revisor vedrørende behandlingssikkerhed for persondata i relation til Netic A/S serviceydelser.

DATABEHANDLERAFTALE. Mellem. Silkeborg Kommune Søvej Silkeborg CVR. nr.: (herefter Kommunen )

Overordnet It-sikkerhedspolitik

Ikast-Brande Kommune. Informationssikkerhedspolitik (efterfølgende benævnt I-Sikkerhedspolitik) Maj 2016 Sag nr. 2015/06550

Halsnæs kommune. Informationssikkerhedspolitik Oktober Informationssikkerhedspolitik Halsnæs kommune.

Tøystrup Gods udfører al håndtering af personlige data i overensstemmelse med gældende lovgivning.

Databeskyttelsespolitik for Netværket Smedegade, en social institution, der primært hoster data og programmer hos databehandlere

Databehandleraftale. Dags dato er indgået nedenstående aftale mellem

Dragør Kommune Borgmestersekretariat, IT og Personale Marts

Databehandleraftale. (De Dataansvarlige og Databehandleren i det følgende hver for sig benævnt Part og under ét Parterne )

Region Hovedstadens Ramme for Informationssikkerhed

Databeskyttelsespolitik

Databehandleraftale. Dags dato er indgået nedenstående aftale mellem

Ishøj Kommune Ishøj Store Torv Ishøj CVR [behandlernes navn] [behandlerens adresse] [Postnummer] CVR.

DATABEHANDLERAFTALE. Mellem. Furesø Kommune Stiager Værløse CVR. nr.: (herefter Kommunen )

Ver. 1.0 GENTOFTE KOMMUNES INFORMATIONSSIKKERHEDSPOLITIK

Underbilag Databehandlerinstruks

Dragør Kommune. Operationelle bilag til IT-sikkerhedspolitikken. Bilag 7. Retningslinjer for IT-medarbejdere

Udkast til svar på Rigsrevisionens rapport om it-sikkerheden på SDN [Godkendt af MedComs styregruppe den 12. februar 2016]

Vejledning i informationssikkerhedspolitik. Februar 2015

Tabulex ApS. Februar erklæringsår. R, s

Databehandleraftale. Dags dato er indgået nedenstående aftale mellem

Kontraktbilag 7: Databehandleraftale

Politik for Datasikkerhed

DATABESKYTTELSESPOLITIK

Databehandleraftale. (den Dataansvarlige og Databehandleren i det følgende hver for sig benævnt Part og under et Parterne )

Front-data Danmark A/S

It-sikkerhedstekst ST8

Tønder Kommune BILAG 10

Skanderborg Kommune. ISMS-regler. Informationssikkerhedsregler for hvert krav i ISO. Udkast 27001:2017

Fredericia Kommunes Informationssikkerhedspolitik 1 FREDERICIA KOMMUNE AFDELING TITEL PÅ POWERPOINT

Hovmosegaard - Skovmosen

Front-safe A/S. Revisionserklæring (RS3411, type B) vedrørende generelle it-kontroller i tilknytning til driften af Remote Backup.

Ballerup Kommune Politik for databeskyttelse

IT-SIKKERHEDSPOLITIK FOR HOFFMANN BILER A/S

IT sikkerhedspolitik for Business Institute A/S

Vejledning til brug af Bank RA Revisionsinstruks

DATABEHANDLERAFTALE. Mellem. Svendborg Kommune Ramsherred Svendborg CVR. nr.: (herefter Kommunen ) XXXXXX xxxxxx xxxx

! Databehandleraftale

Transkript:

ejledning IT- og Telestyrelsen København den 21. februar 2008 FESD-standardisering Sikkerhedsvejledning i henhold til DS 484 ersion 1.0

Kolofon: FESD-standardisering. Sikkerhedsvejledning i henhold til DS 484 ersion 1.0 Denne vejledning kan frit anvendes af alle. Citeres der fra vejledningen i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Datastandardiseringskontoret, FESDstandardiseringsgruppen i samarbejde med de tre FESD-leverandører Software Innovation A/S, Accenture I/S og CSC Danmark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita ützhøft, mail-adresse rla@itst.dk Accenture I/S Arne Jacobsens Allé 15 2300 København S Telefon: 72 28 80 00 Web-adresse: http://www.accenture-fesd.dk/ CSC Danmark A/S Retortvej 8 1780 København Telefon: 36 14 40 00 Web-adresse: http://www.fesd-alliancen.dk/ Software Innovation A/S Nærum Hovedgade 10 DK-2850 Nærum Telefon: 45 58 88 88 Web-adresse: http://www.softwareinnovation.dk/ Ministeriet for idenskab, Teknologi og Udvikling IT- og Telestyrelsen IT-Arkitektur kontoret National IT and Telecom Agency Ministry of Science, Technology and Innovation Holsteinsgade 63 DK-2100 København Ø Telf. +45 35 45 00 00 Fax. +45 35 45 00 10 http://www.itst.dk itst@itst.dk 2 / 49

Indholdsfortegnelse Forord... 5 rug af vejledningen... 5 DE A Formål... 7 DE Sikkerhedsvejledning i henhold til DS 484... 8 Indledning... 8 Eksterne samarbejdspartnere... 8 Risikovurdering... 9 Samarbejdsaftaler... 11 Klassifikation af informationer og data... 14 Medarbejdersikkerhed... 15 Sikkerhedsprocedure før ansættelse... 15 Ansættelsesforholdet... 16 Fysisk sikkerhed... 17 Placering af udstyr... 17 Sikker bortskaffelse eller genbrug af udstyr... 18 Styring af netværk og drift... 18 Driftsafviklingsprocedurer... 19 Ændringsstyring... 20 Funktionsadskillelse... 20 Adskillelse mellem udvikling, test og drift... 21 Ekstern serviceleverandør... 22 Serviceleverancen... 22 Overvågning og revision af serviceleverandøren... 23 Styring af ændringer hos ekstern serviceleverandør... 23 Styring af driftsmiljøet... 24 Kapacitetsstyring... 24 Godkendelse af nye eller ændrede systemer... 24 Sikkerhedskopiering... 26 eskyttelse af systemdokumentation... 27 Informationsudveksling... 27 Elektronisk post og dokumentudveksling... 29 ogning og overvågning... 30 Opfølgningslogning... 30 eskyttelse af log-oplysninger... 33 3 / 49

Administrator- og operatørlog... 33 Fejllog... 34 Adgangsstyring... 34 Administration af brugeradgang... 34 Udvidede adgangsrettigheder... 35 Styring af systemadgang... 36 Identifikation og autentifikation af brugere... 37 Anskaffelse, udvikling og vedligeholdelse... 38 Sikkerhedskrav til informationsbehandlingssystemer... 38 Korrekt informationsbehandling... 38 alidering af inddata... 38 Kontrol af den interne databehandling... 40 alidering af uddata... 41 Styring af driftsmiljøet... 42 Sikkerhed ved systemtekniske filer... 42 Sikring af testdata... 43 Styring af adgang til kildekode... 44 Samarbejdsaftale mellem virksomhed og leverandør... 46 Indledning... 46 Indhold af samarbejdsaftale... 46 Ordforklaring... 48 4 / 49

Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: At der kan foretages sagsbehandling på tværs af flere organisationer At myndigheder, der arbejder med åbne sager, kan lægges sammen At der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Nærværende dokument er dog ikke en standard, men en vejledning. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Denne vejledning indeholder supplerende spørgsmål, i forbindelse med implementeringen af et FESD system, i henhold til de beskrevne sikringsforanstaltninger i DS 484. Fra 1. januar 2007 skal statsinstitutionerne overholde de basale krav i DS 484, herunder også implementering af supplerende sikkerhedsforanstaltninger, såfremt risikovurderingen tilsiger det. asale krav er de punkter, der ikke er markeret med *, i det efterfølgende afsnit samt i de tilsvarende krav i DS 484. DS 484 er den danske standard for IT-sikkerhed, som er obligatorisk for staten og som kommunerne samt regionerne også kan anvende. Denne vejledning erstatter ikke behovet for at foretage en risikoanalyse inden ibrugtagningen af et FESD system. Det bemærkes, at overholdelse af alle punkter i denne vejledning ikke i sig selv er ensbetydende med overholdelse af DS 484, idet DS 484 som sådan dækker over flere punkter udover de FESD relevante punkter, nævnt i denne vejledning. Kravene fokuserer på sikkerhedsniveauet hos virksomheden og leverandøren og på samarbejdet mellem virksomhed og leverandør i forbindelse med et FESD projekt. ær opmærksom på, at hvis FESD systemet indeholder personfølsomme data, så er virksomheden fortsat forpligtet til at overholde reglerne i persondataloven og sikkerhedsbekendtgørelsen. Det gælder også for leverandør og evt. ekstern databehandler. rug af vejledningen Denne vejledning kan benyttes som grundlag for en drøftelse mellem virksomheden og leverandøren i forbindelse med en planlægning af implementering af et FESD-system. Det er virksomhedens ansvar at FESD systemet er sikkerhedsmæssigt risikovurderet, og er sikret i henhold til den valgte balance mellem risici og omkostninger. Det er derfor en afgørende forudsætning, at virksomheden inden drøftelse med leverandøren har foretaget en ledelsesgodkendt risikovurdering med henblik på at afdække egne sikkerhedsbehov og sikkerhedskrav. Anvendelse af vejledningen forudsætter, at virksomheden har: Gennemført en generel risikoanalyse Gennemført en generel risikoanalyse for FESD systemet En sikkerhedsstyringsorganisation på plads 5 / 49

iden om DS 484 og sikkerhedsprocesser Gennemført generel DS 484 implementering Det er ikke afgørende, at virksomheden og leverandøren kan svare bekræftende på alle supplerende spørgsmål. Det afgørende er, at virksomheden har taget eksplicit stilling til spørgsmålene og forstår rækkevidden for egen og leverandørens sikkerhed. 6 / 49

DE A Formål Formålet med denne vejledning er at skabe dialog mellem virksomheden og leverandøren om de sikkerhedsmæssige konsekvenser af implementering og drift af et FESD system. everandøren skal indgå i et aftaleforhold med virksomheden, som lever op til kravene i DS 484 afsnit 6.2.3 samarbejdsaftaler, der henvises i øvrigt også til afsnittet Samarbejdsaftaler i denne vejledning. Aftaleforholdet skal indgås for både nye og eksisterende installationer. everandøren skal ligeledes sikre, at kravene håndteres således, at virksomheden kan verificere etableringen og vedligeholdelsen af det aftalte sikkerhedsniveau jævnfør afsnit 10.2 i DS 484. Dette gælder også hvis leverandøren vælger at outsource til 3. part. ejledningen behandler de dele af DS 484, som er relevante i forbindelse med implementering og drift af et FESD system, og afdækker således den information, der skal tilvejebringes for at kunne foretage en konkret vurdering af trusler og sårbarheder samt disse håndtering i henhold til kravene i DS 484. ejledningen er ikke kravstillende i forhold til leverandøren og dennes løsning, udover hvad der er gældende jf. FESD rammeaftalen. irksomheden og leverandør skal således sikre de aftalemæssige forhold i forbindelse med eventuelt yderligere krav. Det skal endvidere bemærkes, at vejledningen ikke erstatter de samarbejdsaftaler, der stilles krav om i DS 484 afsnit 6.2.3. irksomheden skal således sikre disses indgåelse, samt aftaler om verifikation af etablering og vedligeholdelse af det aftalte sikkerhedsniveau, jf. afsnit 10.2 i DS 484. I øvrigt henvises til afsnittet Samarbejdsaftale mellem virksomhed og leverandør, hvor der overordnet specificeres hvad samarbejdsaftalen skal indeholde. 7 / 49

DE Sikkerhedsvejledning i henhold til DS 484 Indledning I dette afsnit beskrives de punkter i DS 484, som virksomheden og leverandøren bør tage stilling til i forbindelse med et FESD projekt. Forventes FESD systemet at indeholde klassificeret information, som beskrevet i Statsministeriets cirkulære nr. 204 af 7. december 2001, skal der i forbindelse med implementering rettes henvendelse til Politiets Efterretningstjeneste med henblik på godkendelse af virksomhedens installation. For myndigheder under Forsvarsministeriets område, skal henvendelse dog rettes til Forsvarets Efterretningstjeneste. Overskriften til de enkelte underafsnit er enslydende med de tilsvarende overskrifter i DS 484. Der indledes med henvisninger til de relevante afsnit i DS 484 og eventuelle henvisninger til FESD kravspecifikationen, samt eventuel yderligere henvisninger til lovgivningen. De enkelte afsnit indeholder en kort beskrivelse af sikkerhedsproceduren samt et skema, der indeholder de enkelte DS 484 krav. Denne vejledning stiller spørgsmål til kravene. Det er kravene, der skal opfyldes. Spørgsmålene er alene medtaget for at inspirere til en drøftelse af kravene. Samtlige skemaer indeholder en ansvarskolonne. Formålet med denne kolonne er at give et forslag til, om det er virksomheden eller leverandøren, eller evt. begge, der har det overordnede ansvar for kravet. Kolonnen kan også ses som et forslag til, hvem der har ejerskab til ydelsen. I kolonnen er der benyttet følgende forkortelser: irksomhed. Det betyder ikke, at virksomhed og leverandør ikke skal samarbejde om punktet, men blot at forslaget er, at det er virksomheden der tager teten. everandør. Her gælder det samme som ovenstående, blot med modsat fortegn. egge. ær særlig påpasselig med, at der er ejerskab til opgaven. ær opmærksom på, at leverancer ofte opdeles i udviklingsydelser og driftsydelser. Det vil være forskellige dele af DS 484, der vil skulle opfyldes af leverandøren, ved disse to forskelligartede leverancer. Desuden er der ved udviklingsydelser forskel på, om ejerskabet af det leverede produkt overføres til kunden eller forbliver hos leverandøren. Dette vil ligeledes medføre, at forskellige dele af DS 484 skal opfyldes af leverandøren, og andre skal opfyldes af virksomheden selv. iser risikovurderingen, at FESD systemet indeholder information af væsentlig betydning for virksomheden, skal sikkerheden omkring systemet afspejle dette. Svarene i risikovurderingen skal anvendes til at dimensionere de forholdsregler, som skal være på plads hos virksomheden og leverandøren for at opretholde et ensartet og tilfredsstillende sikkerhedsniveau. Eksterne samarbejdspartnere I henhold til DS 484 afsnit 6.2, 6.2.1 og 6.2.3 skal der, i forbindelse med implementering af et FESD system, foretages en risikovurdering og udarbejdes en samarbejdsaftale med leverandøren, som sikrer, at virksomhedens ønskede sikkerhedsmålsætning ikke kompromitteres. Hvis FESD systemet integrerer med registre, der indeholder personfølsomme data og disse registre er placeret hos en ekstern databehandler, så skal der i henhold til persondataloven indgås en skriftlig aftale med den eksterne databehandler. For yderligere information henvises til Datatilsynets hjemmeside: Krav om skriftlig kontrakt med databehandlere. 8 / 49

Risikovurdering Det kan udgøre en risiko at give en leverandørs medarbejdere adgang til FESD systemet, blandt andet fordi leverandørens styring af sikkerhed kan være utilstrækkelig. Der skal således foretages en risikovurdering og udarbejdes en samarbejdsaftale. Samarbejdet baseres på en formel kontrakt. egge parter skal være enige i de sikkerhedskonditioner, der er knyttet til samarbejdet. Kontrakten skal færdigbehandles og underskrives, før dens tekniske og kontrolmæssige indhold implementeres. everandøren må ikke få adgang til data før risikovurderingen er gennemført, de relevante sikringsforanstaltninger er implementeret, og der er indgået en formel samarbejdsaftale (se afsnit 6.2.2 og 6.2.3 i DS 484). IT- og Telestyrelsen har udarbejdet en vejledning i udarbejdelse af risikovurdering som kan findes på www.itsikkerhedsportalen.dk eller via dette link: ejledning om risikovurdering. Identifikation af risici i forbindelse med eksternt samarbejde skal omfatte følgende: De informationsbehandlingsfaciliteter samarbejdspartneren skal have adgang til. Hvilken form for adgang samarbejdspartneren skal have: fysisk adgang logisk adgang om adgangen skal være via internt net eller via opkobling Er det nok at leverandøren får adgang til FESD systemet, eller skal der også gives adgang til andre systemer, f.eks. User Directory (AD), DMS, fagsystemer, CMS, portaler osv., er der risici forbundet herved, og tager eksisterende sikkerhedsmekanismer højde for de risici? I forhold til f.eks. User Directory, er der normalt kun behov for læseadgang. Er der også behov for skriveadgang og hvad er konsekvenserne? Hvis systemet benytter en eksisterende DMS server i virksomheden, hvilke adgange kræver leverandøren så for at kunne oprette og initiere databasen og påføres der evt. virksomheden yderligere risici herved? Hvilke konti skal oprettes på eksisterende DMS server for at systemet kan afvikles og vedligeholdes af leverandøren og kræver det særlige modforholdsregler? il der blive overflyttet data fra virksomheden til leverandør i forbindelse med implementering og test - og kan disse data sikres og hvad er konsekvenserne hvis data kompromitteres eller offentliggøres? Skal der installeres andre komponenter for at sikre kommunikationen mellem FESD systemet og øvrige systemer, og hvordan sikres det, at komponenterne ikke kompromitterer fortrolighed, tilgængelighed og integritet? Skal FESD systemet logge ind på andre systemer således, at man kan hoppe fra FESD systemet til andre af virksomhedens systemer f.eks. CPR, CR, R, GIS? Følgende spørgsmål bør tages med i risikovurderingen i forhold til leverandøren og leverandørens supportmedarbejdere: Hvor sikker skal virksomheden være på identiteten af leverandørens medarbejdere? Skal der udleveres adgangskort? (Udlevering af adgangskort kan kun ske mod fremvisning af billedlegitimation) Hvilke risici er der, hvis adgangskortet også giver adgang til lokationen udenfor normal kontortid? 9 / 49

Den forretningsmæssige værdi af de involverede informationsaktiver. eskyttelsesforanstaltninger for informationsaktiver, der ikke er omfattet af samarbejdet. Samarbejdspartnerens personale. Autorisations- og verifikationsprocedurer Samarbejdspartnerens informationslagrings-, behandlings- og kommunikationsudstyr og de hertil knyttede sikringsforanstaltninger. Konsekvenserne af manglende tilgængelighed og ukorrekte informationer. Procedurer for håndtering af sikkerhedsrelaterede hændelser. Særlig lovgivning, samarbejdspartneren skal tage hensyn til, og Hvilke risici er der, hvis kortet giver adgang til serverrummet? Hvad er konsekvenserne, hvis der arbejdes uovervåget i serverrummet? Hvad er konsekvenserne, hvis der gives remote adgang til systemet og i givet fald hvilken form for adgang, f.eks. vpn, adsl, modem, osv.? Hvordan sikres, at leverandørens bærbare computere, som sluttes til et utal af kunder, ikke udgør en risiko for virksomheden? Er det reguleret om adgang til systemet kun må ske via en af virksomhedens standard arbejdspladser? Skal der oprettes specifikke leverandør logins til systemerne? Hvordan skal logning og kontrol af leverandørens adgang ske? Må leverandøren logge sig på døgnet rundet? Er data i FESD systemet vital for virksomhedens forretning? Hvilke konsekvenser har det, hvis systemets data kompromitteres? Er data, opbevaret andre steder end i systemet, underlagt de samme sikkerhedsforanstaltninger som FESD systemet f.eks. hvis der benyttes eksisterende DMS server eller backupsystem? Hvis der ligger følsomme/klassificeret data i systemet, skal der så stilles krav om at leverandørens medarbejdere har ren straffeattest? Skal leverandørens medarbejdere sikkerhedsgodkendes efter de samme retningslinjer som virksomhedens egne medarbejdere? Hvordan verificeres leverandørens medarbejdere, skal der f.eks. vises pas eller kørekort? Hvordan tildeles rettigheder til personer, der skal have adgang til systemet? Må leverandørens bærbare computere tilsluttes netværket? Må mobiltelefon være tilstede 10 / 49 f.eks. pga. indbygget kamera? Er virksomheden klar over konsekvenserne, hvis leverandøren hindres adgang eller gives ukorrekte oplysninger, i forbindelse med skærpede krav til tilgængelighed, f.eks. manglende oppetid? Er der krav om at virksomheden og leverandøren underretter hinanden om sikkerhedsrelaterede hændelser, f.eks. virus? Indeholder systemet klassificeret/følsomme data?

andre kontraktforhold, virksomheden og/eller samarbejdspartneren skal tage hensyn til. Hvorledes samarbejdet vil påvirke øvrige interessenter. Foreligger der en liste over kritisk lovgivning for området? Informeres leverandøren om nye lovgivningsinitiativer på den identificerede liste? Skal der foretages godkendelse hos Datatilsynet? Samarbejdsaftaler Samarbejdsaftalen med leverandøren skal sikrer at virksomhedens sikkerhedsmålsætning ikke kompromitteres. Det er afgørende for sikkerheden og samarbejdet, at aftalen er skriftlig og eksplicit. Samarbejdsaftalen skal kunne anvendes og refereres til i det daglige arbejde. Følgende punkter skal vurderes ved indgåelse af aftalen: irksomhedens informationssikkerhedsmålsætning. De aftalte sikringsforanstaltninger som eksempelvis: 1. procedurer til beskyttelse af virksomhedens informationsaktiver 2. eventuelle fysiske beskyttelsesforanstaltninger 3. beskyttelse mod skadevoldende programmer, jf. 10.4.1 4. procedurer for konstatering af eventuelle sikkerhedsbrud 5. procedurer for returnering eller destruktion af information ved aftalens udløb eller på andet aftalt tidspunkt (se eksempelvis Persondatalovens 41, stk. 4) 6. procedurer til beskyttelse af integritet, tilgængelighed og autenticitet 7. restriktioner vedrørende kopiering og videregivelse rugeruddannelse Fremgår virksomhedens målsætning for informationssikkerhed tydeligt i samarbejdsaftalen? Er der sikret videreførelse af kravene såfremt dele af leverancen outsources? Følgende spørgsmål bør vurderes: 1. Hvilke procedurer skal leverandøren overholde, skal leverandørens supportmedarbejdere aflevere C og evt. straffeattest? 2. Skal der udleveres adgangskort? 3. Skal leverandørens bærbare computere have installeret antivirusprogrammer for at blive tilsluttet virksomhedens interne netværk? 4. Er der aftalt kommunikationskanal/kontaktperson for evt. sikkerhedsbrud hos virksomheden eller leverandøren? 5. Findes der en oversigt over udleveret materiale som ønskes returneret eller destrueret ved aftalens ophør? Er det aftalt, om det udleverede materiale må kopieres? 6. Hvordan sikres, at modparten er den korrekte person fra den virksomhed, der er indgået samarbejdsaftale med? Er der aftalt tid for tilgængelighed (service vinduer)? Hvordan sikres, at den software, som leverandøren producerer, er den samme, som den virksomheden modtager (f.eks. hash på filer)? 7. Må samarbejdsparterne distribuere udleveret materiale? Er der aftalt uddannelse? Kan leverandøren levere uddannelsen? rugerbevidstgørelse Er der som led i indførelse af systemet behov for, at brugerne 11 / 49

Mulighed for eventuel udveksling af personale Ansvaret for installation og vedligehold af informationsbehandlingsudstyr og programmel Rapporteringsomfang, -struktur og -format Procedurer for ændringsstyring Adgangskontrolprocedurer 1. Den forretningsmæssige begrundelse for at give samarbejdspartneren adgang 2. Tilladte adgangs- og identifikationsmetoder 3. Autorisationsprocedure for brugeradgang og tildeling af rettigheder med præcisering af, at adgangstildeling og -rettigheder skal være strengt arbejdsbetinget 4. Krav til lister over brugeradgang og -beføjelser 5. Præcisering af at enhver uautoriseret adgang er forbudt 6. Procedure for spærring af adgangsrettigheder Procedurer for rapportering og efterforskning af sikkerhedsbrud og - hændelser samt overtrædelse af samarbejdsaftalen eskrivelse af det informationsbehandlingsudstyr, de systemer og de informationer (inkl. klassifikation, jf. 7.2.1), der er omfattet af aftalen Det aftalte kvalitetsmål for serviceydelsen f.eks. orienteres om hvilke fil formater og fil størrelser, der må gemmes i systemet? Er det nødvendigt, at leverandøren arbejder hos virksomheden eller omvendt? Er der behov for udstationering af leverandørens medarbejdere hos virksomheden efter, at leverancen er gennemført? Er ansvarsplacering aftalt i forbindelse med installation af hardware og software? Er der indgået en vedligeholdelsesaftale på hardware og software? Er det tilstrækkelig med mundtlig rapportering eller skal der afgives skriftlig rapportering? Af hvem og under hvilke omstændigheder må der foretages ændringer i systemet? Overholder leverandørens procedurer for ændringshåndtering virksomhedens egne procedurer? 1. Er der en begrundelse for at give samarbejdspartneren adgang til systemet? 2. Må leverandøren benytte fælles brugerkonti? Må leverandøren få adgang uden forudgående tilladelse? 3. Hvem må tildele leverandøren adgang til systemet (både logisk og fysisk)? 4. Er der behov for at dokumentere, hvad leverandøren må få adgang til? 5. Er det tydeliggjort, at selvom der er adgang til andre lokaliteter eller systemer, så er dette ikke tilladt? 6. Er det klart hvordan og under hvilke omstændigheder, de tildelte rettigheder spærres eller fjernes? Hvis der opstår et sikkerhedsbrud, er det så aftalt hvem der kan forestå efterforskningen? Hvis samarbejdsaftalen misligholdes, er der så aftalt evt. sanktioner? Er det beskrevet hvilket systemer og informationer, der kræver særlig beskyttelse? Er der udarbejdet en SA? Tager kvalitetsmålene højde for afhængighed til 3. parts systemer? 12 / 49

eskrivelse af de aftalte servicemål, deres overvågning og afrapportering Retten til at overvåge og afbryde den aftalte serviceydelse Retten til revision af kontraktens overholdelse, evt. ved brug af ekstern revisor Eskaleringsprocedure ved problemhåndtering eredskabsplaner, herunder krav til maksimal reetableringstid De respektive parters ansvarsforhold i relation til aftalen Ansvarlighed i forhold til lovbestemmelser, fx Persondataloven. Dette er specielt vigtigt ved aftaler med udenlandske samarbejdspartnere Forhold omkring ophavsrettigheder og licenser Aftaleforhold i forbindelse med samarbejdspartnerens eventuelle underleverandører etingelserne for genforhandling/afslutning af samarbejdsaftalen 1. ed brud på aftalen 2. ed ændringer til sikkerhedskravene 3. Dokumentationen af aftalens indhold og omfang, licenser, aftaler og rettigheder skal til stadighed holdes ajour. Er der aftalt oppetidskrav? Indeholder den indgåede SA en beskrivelse af servicemålene, deres overvågning og afrapportering? Er det aftalt, om det er leverandøren eller virksomheden eller 3. part, der skal overvåge overholdelse af de indgåede servicemål? Er der aftalt sanktioner i forbindelse med manglende overholdelse af de indgåede servicemål? Er der behov for, at virksomhedens eller leverandørens revisor overvåger kontraktens overholdelse? Er der aftalt entydige eskaleringsprocedurer i forbindelse med drift og vedligeholdelse af systemet? Er det aftalt hvor kritisk systemet er for virksomheden? Er der lavet planer for retablering af systemet? Er det aftalt, at beredskabsplaner skal afprøves og evt. i hvilken grad? Er der enighed om ansvarsfordelingen i alle punkter i samarbejdsaftalen? Er der særlige nationale lovkrav som skal overholdes i forbindelse med kontrakten, f.eks. persondatalovens bestemmelse om overførsel af oplysninger til tredjeland Hvordan sikres, at de indkøbte licenser svarer til det aktuelle forbrug? Hvordan sikres, at systemets software ikke kopieres og evt. benyttes hos 3. part uden forudgående aftale med leverandøren? Er det tydeliggjort, om det er virksomheden eller leverandøren, der indgår aftale med underleverandører? Er det tydeligt, at den indgåede samarbejdsaftale også har indvirkning for underleverandører? Følgende spørgsmål bør stilles: 1. Hvis samarbejdsaftalen brydes, er det så aftalt under hvilke omstændigheder, aftalen kan eller skal ændres? 2. Hvis der sker ændringer i sikkerhedskravene, skal de beskrevne sikkerhedsforhold i aftalen så ændres? 3. Er der procedurer for, hvordan samarbejdsaftalen holdes ajourført? 13 / 49

Klassifikation af informationer og data I henhold til FESD kravspecifikationen, krav 9.1.1, 9.1.2, og 9.2.1-9.2.5, samt DS 484 afsnit 7.2, 7.2.1 og 7.2.2 skal det sikres, at FESD systemet får et passende beskyttelsesniveau. Systemets kritiske informationer og data skal identificeres og klassificeres. Informationer og data i systemet kan have varierende sensitivitets- og væsentlighedskriterier nogle har behov for særlige sikringsforanstaltninger og specielle procedurer for at sikre informationernes tilgængelighed, integritet og fortrolighed. I forbindelse med klassifikation af information, er det vigtigt ikke at overklassificere data. Et FESD system med tilhørende støttesystemer skal kunne leve op til de sikkerhedskrav, den højest anvendte sikkerhedsklassifikation foreskriver. Følgende punkter skal overholdes i forbindelse med klassificering af data: Klassifikationsproceduren skal omfatte en periodisk revurdering, jf. 11.1.1. Den udpegede ejer, jf. 7.1.2, er ansvarlig for klassifikationen og den periodiske revurdering. Klassifikationen skal tage hensyn til den ophobningseffekt, der omtales i 10.7.2. Informationer og data i systemet kan klassificeres i nedenstående 4 kategorier. Offentlige informationer og data defineret som informationer og data, som alle, der udtrykker et ønske om det, kan få adgang til. Interne informationer og data defineret som informationer og data, der kun må anvendes og kommunikeres internt, og som i den daglige drift er nødvendige for de brugere, der skal anvende dem. Klassificeret data kan over tid blive uklassificeret, der skal derfor foretages en periodisk revurdering. Kan systemet håndtere, at klassificeret data har en datomarkering for, hvornår dataene ikke er klassificeret længere? I visse tilfælde kan det også være nødvendig at foretage en opklassificering af data, f.eks. i forbindelse med ressortændringer, hvor den afgivende organisation har klassificeret dataene lavere end den modtagende. Kan systemet håndtere opklassificering af data? Kan der alternativt laves et udtræk i systemet indeholdende klassificeret data, der skal revurderes? Er dataejeren opmærksom på, at der skal foretages revurdering af klassificeret data? Er data, der er klassificeret, stadig nødvendig eller kan det slettes, evt. efter aflevering til Statens Arkiver? Følgende spørgsmål bør stilles i forbindelse med håndtering af klassifikation: 1. Indeholder FESD systemet et klassifikationsfelt på dokumentniveau (journalpost)? 2. Fremgår klassifikationen også på papirversionen af f.eks. et udgående brev eller en udgåede e-mail? 14 / 49

Følsomme informationer og data defineret som de informationer og data, som kun særligt betroede brugere kan få adgang til for at kunne udøve deres betroede arbejdsfunktioner, og hvor et brud på fortroligheden kan have skadelig virkning for virksomheden eller den part som informationen omhandler. Fortrolige informationer og data defineret som informationer og data, der har en særlig sensitiv karakter, som kun ledelsen kan få adgang til, eller informationer som kun særligt betroede medarbejdere får adgang til i forbindelse med betroede arbejdsfunktioner, og hvor et brud på fortroligheden kan have særdeles skadelig virkning. Medarbejdersikkerhed Sikkerhedsprocedure før ansættelse I henhold til DS 484 afsnit 8.1 og 8.1.1 skal det sikres, at alle nye medarbejdere, der skal have adgang til følsomme data i FESD systemet, er opmærksomme på deres særlige ansvar og rolle i forbindelse med brug af systemet for derigennem at minimere risikoen for menneskelige fejl, tyveri, svindel og misbrug af data. Alle ansøgere til såvel faste som midlertidige stillinger og eksterne konsulenter, skal kontrolleres før en ansættelsesaftale indgås, specielt hvis de skal have adgang til følsomme data i FESD systemet. Eventuelle sikkerhedsopgaver og -ansvar skal være klart definerede og forklares tydeligt til ansøgere under ansættelsessamtalen. Personer, der ikke gennemgår virksomhedens almindelige ansættelsesprocedure, f.eks. konsulenter og vikarer, skal også informeres tydeligt om roller og ansvar i forbindelse med sikkerhed. De supplerende spørgsmål skal anvendes til at vurdere, om virksomhedens beskrivelse af sikkerhedsopgaver og ansvar er tilstrækkelig klar og entydig. eskrivelsen af sikkerhedsopgaver og -ansvar skal omfatte medarbejderens ansvar for: 15 / 49

At overholde virksomhedens sikkerhedsretningslinjer og politik. At beskytte virksomhedens informationsaktiver mod misbrug. Eventuelle specifikke sikkerhedsopgaver. Egne handlinger. At rapportere sikkerhedshændelser og -trusler. Har den nye medarbejder eller evt. den nye eksterne konsulent fået en kopi af sikkerhedsretningslinjerne og sikkerhedspolitikken for virksomheden og er de gjort bekendt med vigtigheden af overholdelse af disse regningslinjer? Er det nødvendigt, at der som led i ansættelsen af ny medarbejder eller ekstern konsulent, fremvises straffeattest? Fremgår det entydigt af sikkerhedsretningslinjerne, hvordan den enkelte medarbejde kan beskytte virksomhedens informationsaktiver? Er det entydigt, om arbejdsfunktionerne indeholder sikkerhedsopgaver? Er det entydigt, hvordan den enkelte medarbejde bidrager til at opretholde sikkerhedsniveauet f.eks. ved at kontrollere identiteten af gæster i virksomheden og være opmærksom på hvilke vedhæftede filer der må åbnes i e-mails o.l.? Informeres medarbejderen eller den eksterne konsulent om, hvem/hvorhen mistanke om sikkerhedshændelser skal rapporteres? Ansættelsesforholdet I henhold til DS 484 afsnit 8.2 og 8.2.1 skal det sikres, at alle medarbejdere er opmærksomme på relevante sikkerhedstrusler og sårbarheder, og at de har den fornødne viden og uddannelse til at udføre deres daglige arbejde inden for rammerne af virksomhedens informationssikkerhedspolitik og -retningslinjer. edelsen skal sikre sig, at alle medarbejdere implementerer og fastholder informationssikkerhed i overensstemmelse med virksomhedens sikkerhedspolitik, retningslinjer og procedurer. ær opmærksom på, at hvis FESD systemet indeholder personfølsomme data, så er virksomheden endvidere forpligtet til, i henhold til sikkerhedsbekendtgørelsens 6, at holde sine medarbejdere instrueret om, hvorledes behandling af disse data kan ske forsvarligt. edelsens ansvar omfatter følgende for alle medarbejdere: At de er blevet tilstrækkeligt informeret om deres roller og ansvar i forbindelse med sikkerhed, før de tildeles adgang til virksomhedens systemer og data. At de er gjort bekendt med de nødvendige retningslinjer, således at de kan leve op til virksomhedens informationssikkerhedspolitik. At de er motiverede for at leve op til virksomhedens informationssikkerhedspolitik og retningslinjer. At de opnår et opmærksomhedsniveau i spørgsmål vedrørende informationssikkerhed, Er medarbejderen klar over hvilke konsekvenser det har at få adgang til følsomme/klassificeret data i et FESD system? Er det tydeligt, at der skal udvises ekstra påpasselighed ifbm. følsomt/klassificeret information, hvis data skal anvendes uden for systemet f.eks. på papir? ed medarbejderen hvilke procedurer, der skal følges for at overholde sikkerhedspolitikken? Fremgår der f.eks. af retningslinjerne, at der ikke må sendes CPR numre ubeskyttet over Internettet? Er medarbejderen klar over deres egen betydning og rolle i at understøtte virksomhedens sikkerhedspolitik? Er medarbejderen klar over, at det kan have betydelige implikationer for virksomheden hvis informationerne i FESD systemet kompromitteres? Gennemføres der regelmæssige bevidstgørelses kampagner for virksomhedens sikkerhedspolitik, herunder værdien af informati- 16 / 49

der er i overensstemmelse med deres roller og ansvar i virksomheden (jf. 8.2.2). At de holder sig inden for de retningslinjer og bestemmelser, der er for ansættelsen, inkl. virksomhedens informationssikkerhedspolitik og korrekte arbejdsmetoder. onerne i FESD systemet? Er det tydeligt i hvilken omfang, sikkerhedsretningslinjerne er obligatoriske eller frivillige at følge? Hvis reglerne f.eks. stiller begrænsninger om udsendelse af personfølsomme data, er medarbejderen så orienteret om, at det også betyder, at der ikke må sendes personfølsomme data til f.eks. en privat hjemme adresse? Fysisk sikkerhed I henhold til DS 484 afsnit 9.1 og 9.2.1 skal det sikres, at virksomhedens lokaler og informationsaktiver beskyttes mod uautoriseret fysisk adgang samt fysiske skader og forstyrrelser. I forbindelse med fysisk beskyttelse af information, skal virksomheden og leverandøren vurdere, om egne fysiske rammer sikrer fortrolighed og tilgængelighed tilstrækkeligt. Placering af udstyr Udstyr skal placeres eller beskyttes, så risikoen for skader og uautoriseret adgang minimeres. Følgende punkter skal overholdes i forbindelse med placering af udstyr: Udstyr skal placeres, så behovet for uvedkommendes adgang til arbejdsområdet minimeres. Udstyr, hvorpå der behandles kritiske/følsomme informationer, skal placeres, så informationerne ikke kan ses af uvedkommende. urderes det som nødvendigt, at sagsbehandlere, der arbejder med følsom information, er placeret i separate lokaler? Sidder sagsbehandlerne placeret så uvedkommende ikke kan aflæse informationen på skærmen? Udstyr, som kræver særlig beskyttelse, skal placeres særskilt for at undgå unødige generelle beskyttelsesforanstaltninger. Udstyr skal placeres eller beskyttes, så risikoen for mulige fysiske trusler som tyveri, brand, varme, eksplosioner, røg, vand, støv, rystelser, kemiske påvirkninger, strømforstyrrelser, kommunikationsforstyrrelser, elektromagnetisk stråling, hærværk osv. minimeres. Der skal være klare retningslinjer for fortæring og rygning i nærheden af udstyr. * Trusler fra omgivelserne, som eksempelvis temperatur og Er server udstyr, backup bånd og lignende, der kræver særlig beskyttelse, placeret i tilstrækkelige beskyttede omgivelser? Er der vandførende rør i eller i nærheden af serverrummet? Arbejdes der med brændbart materiale i nærheden af serverrummet? Er det tilladt at medbringe drikkevarer o.l. i serverrummet? Dette er et skærpet krav og overholdelse afhænger af den enkelte 17 / 49

fugtighed, skal overvåges. risikovurdering. * Der skal være etableret beskyttelse mod lyn og overspænding på alle indkommende elektricitets- og kommunikationslinjer, jf. DS/IEC 1024-1. Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. I særligt forurenende områder skal særlige beskyttelsesforanstaltninger etableres, fx beskyttelse af tastatur. * Udstyr, der benyttes til behandling af følsomme informationer, skal om fornødent beskyttes mod udstråling for at undgå kompromittering. Er der behov for at anvende udstyr uden for normal kontormiljø og i så fald, er der så retningslinjer for hvordan det skal ske, f.eks. mht. bærbare computere, PDA o.l.? Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. Sikker bortskaffelse eller genbrug af udstyr I henhold til DS 484 afsnit 9.2.6 skal det sikres, at følsomme/fortrolige data fjernes inden udstyr kasseres eller genbruges. Alt udstyr med lagringsmedier skal kontrolleres for at sikre, at kritiske/følsomme informationer og licensbelagte systemer er fjernet eller overskrevet, i forbindelse med at udstyret bortskaffes eller genbruges. Når et lagringsmedie har indeholdt følsom information, skal man være opmærksom på, at denne information stadig kan befinde sig fysisk på mediet efter sletning. Skal informationen fjernes helt, skal lagringsmediet overskrives med et særligt værktøj eller destrueres fysisk. Følgende punkter skal overholdes i forbindelse bortskaffelse eller genbrug af udstyr: Enheder med kritiske/følsomme informationer skal enten fysisk destrueres eller overskrives i henhold til en anerkendt metode. Standardslettefunktioner og reformatering er ikke tilstrækkelig beskyttelse, da informationerne stadig ligger på datamediet. Er enheder med følsomt/klassificeret information tydeligt markeret? Kan udstyr genanvendes uden risiko for kompromittering af tidligere lagret information på udstyret? Hvis udstyr skal genanvendes, er der så progammel i virksomheden, der sikrer, at følsomt/klassificeret information ikke kan genanvendes? Hvis leverandøren hjemtager data f.eks. for produktion af arkiveringsversioner til Statens Arkiver, hvordan sikrer leverandøren så, at disse data slettes korrekt efter brug? Styring af netværk og drift I henhold til DS 484 afsnit 10.1 og 10.1.1 skal der sikres, en korrekt og betryggende driftsafvikling af virksomhedens FESD system. Ansvar og retningslinjer for styring og drift af virksomhedens FESD system skal være fastlagt. Herunder driftsinstruktioner og reaktionsprocedurer til imødegåelse af uønskede hændelser. Dette gælder uanset om virksomheden selv drifter løsningen eller drift er outsourcet. 18 / 49

Følgende punkter skal overholdes i forhold til operationelle procedurer og ansvarsområder: For at reducere risici på grund af uagtsomhed eller overlagt misbrug skal funktionsadskillelse gennemføres, hvor det er relevant. Er der procedurer, der sikrer, at det er forskellige personer, der godkender og opretter brugere hvis ikke, er der så kontrollerende foranstaltninger? Er der procedurer, der sikrer, at det ikke er den samme person, der udfører ændringer i driftsmiljøet som den person, der godkender ændringerne? Driftsafviklingsprocedurer I henhold til DS 484 afsnit 10.1.1 skal det sikres, at driftsafviklingsprocedurerne er dokumenterede, ajourførte og tilgængelige for driftsafviklingspersonalet og andre med et arbejdsbetinget behov. Driftsafviklingsprocedurer er en del af virksomhedens informationsaktiver og skal derfor indgå i en formaliseret ændringsstyring, herunder en ledelsesmæssig godkendelse. Dette gælder uanset om virksomheden selv drifter løsningen eller drift er outsourcet. Fordi tilgængelighed i et FESD system kan være en afgørende forudsætning for virksomhedens drift, skal drift afviklingsprocedurerne derfor afspejle virksomhedens forventning til tilgængelighed af FESD systemet. Procedurerne skal omfatte samtlige informationsbehandlingsopgaver, herunder: ehandling og håndtering af information Sikkerhedskopiering, jf. 10.5 Afviklingsplanlægning, herunder driftsmæssige bindinger til andre systemer og fastlagte tidsterminer Fejl- og undtagelseshåndtering, herunder begrænsninger vedrørende brug af systemhjælpeværktøjer, jf. 11.5.4 Kontaktpersoner ved operationelle eller tekniske problemer Procedurer for håndtering af særlige uddata og databærende medier, eksempelvis brug af særlige blanketter eller håndtering af fortrolige/følsomme uddata, herunder også sikker destruktion af fejlbehæftede uddata, jf. 10.7.2 og 10.7.3 Retablerings- og genstartsprocedurer ved systemfejl Er det tydeliggjort, hvordan de dokumenter, der beskriver driftsafvikling, må håndteres og anvendes? Er der beskrevne procedurer for sikkerhedskopiering? Er der beskrevne procedurer for batch kørsler og afhængigheder til andre systemer? Er der beskrevne procedurer for hvad der skal ske hvis en kørsel eller lignende fejler og hvem der kan tilgå hjælpeværktøjer, der kan identificere og rette fejlen? Findes der et kontaktpunkt hos leverandøren og virksomheden, der kan behandle forespørgsler af teknisk- og operationel- karakter? Er der behov for procedurer for kopiering af information, der ikke vedrører sikkerhedskopiering, f.eks. til test? Er der procedurer for at alle papirer, der ikke skal anvendes, bliver destrueret betrykkende? Er der procedurer for, hvem der må genstarte FESD systemet (både HW og SW), hvordan det genstartes og hvornår det må genstartes? 19 / 49

Styringen af kontrolspor og øvrige systemtekniske logninger, jf. 10.10. Er der vished for, at kun autoriseret personel kan tilgå og ikke ændre kontrolspor og log information? Ændringsstyring I henhold FESD krav 7.1.13, samt til DS 484 afsnit 10.1.2 skal det sikres, at ændringer til forretningskritisk informationsbehandlingsudstyr, -systemer og -procedurer skal styres gennem en formaliseret procedure. Ændringer i FESD systemet kan have utilsigtede konsekvenser, f.eks. kan rettelse af en fejl i en del af systemet medføre fejl i andre dele af systemet. Det er afgørende for et FESD systems tilgængelighed, at ændringer og test er veldokumenteret. Følgende punkter skal overholdes i forhold til ændringsstyring: Entydig identifikation og registrering af væsentlige ændringer Krav til planlægning og afprøvning af ændringer Er det tydeligt og præcist, hvilke ændringer der skal gennemføres og er de nødvendige? Er det afprøvet, at ændringen ikke har andre konsekvenser end tilsigtede? Gennemføres ændringer i henhold til dokumenteret testplan? urdering af ændringens konsekvenser, herunder sikkerhedskonsekvenser inkl. konsekvenser for beredskabsplanen, jf. 14.1.5 En formaliseret godkendelsesprocedure En informationsformidlingsprocedure Nødprocedure ved fejlslagne ændringer ogningsprocedure, jf. 10.10. Er ændringen afprøvet i et testmiljø? Er effekten af opdateringer af applikationer, operativsystem og database kendt for FESD systemet, f.eks. opdateringer af Office versioner, MDAC, Internet Explorer o.l.? Hvem kan godkende testen hos virksomheden? Har virksomheden fremsendt testcases til leverandøren? Er der procedurer, der beskriver, hvordan leverandøren har udbedret fejlretningen og står inde for kvaliteten? Hvor omfattende vurderer leverandøren ændringen? Er der mulighed for at genetablere systemet til det niveau systemet havde før ændringen blev implementeret? Har virksomheden en systematisk oversigt/dokumentation af, hvornår og hvordan ændringer er implementeret? Funktionsadskillelse I henhold til FESD kravspecifikationen, krav 8.3.1, samt DS 484 afsnit 10.1.3 skal det sikres, at der etableres funktionsadskillelse for at minimere risikoen for uautoriserede eller utilsigtede ændringer eller misbrug af systemet. irksomheden skal være opmærksom på leverandørens funktionsadskillelse i forbindelse med kodning, og om leverandøren kan sandsynliggøre, at der foreligger procedurer, som også følges. Følgende punkter skal overholdes i forhold til funktionsadskillelse: Det skal sikres, at samme person ikke har adgang til at tilgå, ændre og anvende FESD systemet, uden at Er det forskellige personer, der ændrer kode i test og efterfølgende lægger det i produktion? Er den person, der ændrer koden, den samme person, der godkender 20 / 49

dette er godkendt eller vil blive opdaget. Samme person må ikke både godkende og initiere en given handling. ed tilrettelæggelse af funktionsadskillelse skal risikoen for indbyrdes aftaler medarbejderne imellem indgå. Hvis funktionsadskillelse ikke kan gennemføres i eksempelvis mindre virksomheder, skal der iværksættes kompenserende kontrolforanstaltninger, fx overvågning, logning eller lignende. rettelsen hos leverandøren? Er den person, der godkender en sikkerhedsændring (oprettelse af brugere og grupper), den samme person, der også udfører arbejdet i systemet? Er der formaliserede procedurer for sikkerhedsrettelser i systemet, hermed tænkes på ændringer af gruppetilhørsforhold i FESD systemet? Er der kompenserende foranstaltninger hvis funktionsadskillelse ikke kan gennemføres? Adskillelse mellem udvikling, test og drift I henhold FESD kravspecifikationen, krav 7.1.10, samt til DS 484 afsnit 10.1.4 skal det sikres, at udviklingsog testmiljøet er adskilt fra driftsmiljøet for at undgå uautoriseret adgang eller ændringer. Drift og test-/udviklingsmiljøer bør holdes fysisk adskilt både hos virksomheden og leverandør. Det kan have negative konsekvenser for tilgængeligheden af et FESD system, såfremt det ikke er tilfældet. DS 484 kræver ikke fysisk adskillelse, men virksomheden skal eksplicit gøre sig bekendt med risici og acceptere konsekvenserne heraf ved manglende adskillelse. Følgende punkter skal overholdes i forhold til adskillelse mellem udvikling, test og drift: Retningslinjer for overførsel af forretningskritiske systemer fra udviklings- og testmiljøet til driftsmiljøet. * Udviklings- og testmiljøet skal være systemteknisk eller fysisk adskilt fra driftsmiljøet. Udviklings- og hjælpeværktøjer må kun findes i driftsmiljøet, hvis det er påkrævet, jf. 11.5.4. Testmiljøet skal være så identisk med driftsmiljøet som muligt. Er der procedurer for, hvornår et system er af en sådan kvalitet, at det kan flyttes fra udvikling til test og igen fra test til drift? Er der aftalte kvalitetskrav til systemets funktionalitet og stabilitet som skal opfyldes før et system skal gå fra udvikling til test og fra test til drift? Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. Er udviklings- og testmiljø adskilt fra produktionsmiljø? Følger adskillelsen af systemerne også de underlæggende systemer i særdeleshed den underlæggende database? Er der licenser til opretholdelse af både test og udviklingsmiljø? Er det kun nødvendige programmer og funktioner, der er tilstede i produktionsmiljøet, det gælder både for leverandør og virksomhed? Er debug værktøjer kun tilgængelige i test og udviklingsmiljø? Hvordan sikres, at test og produktionsmiljø er så identiske som muligt? Er kapaciteten i testmiljø og driftsmiljø datamæssigt sammenligneligt? Er det sikret, at der i forbindelse med test i testmiljøet ikke fo- 21 / 49

* Hvis en bruger har behov for adgang til både udviklings-, testog driftsmiljøerne, skal vedkommende benytte forskellige brugerprofiler. Følsomme/fortrolige data må ikke benyttes i udviklings- og testmiljøet, medmindre adgangskontrolforanstaltningerne er lige så restriktive som i driftsmiljøet, jf. 12.4.2. retages ændringer, men at disse ændringer altid laves i udviklingsmiljøet? Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. Er det sikret, at samme brugerprofil ikke har adgang til både udvikling, test og drift? I det omfang produktionsdata er nødvendige til test, er klassificerede/følsomme data så sikret på samme måde i testmiljøet som i produktionsmiljøet? Ekstern serviceleverandør I henhold til FESD kravspecifikationen, krav 7.1.7, samt DS 484 afsnit 10.2 skal det sikres, at det ønskede sikkerhedsniveau opretholdes ved samarbejde med en ekstern serviceleverandør, idet virksomheden skal være opmærksom på, at den fortsat har det overordnede ansvar for informationssikkerheden. Følgende punkter skal overholdes i forhold til en ekstern serviceleverandør, herunder en ASP-løsning: Der skal være udpeget en ansvarlig kontakt både i virksomheden og hos serviceleverandøren. De eksterne serviceleverandører som FESD systemet er integreret til datamæssigt f.eks. CPR, CR, R o.l., er der så et eksternt kontaktpunkt hos hver af disse udbydere? Hvis FESD systemet eller systemets data ikke er placeret hos virksomheden, er der så et eksternt kontaktpunkt hos den/de eksterne serviceleverandører? Serviceleverancen I henhold til DS 484 afsnit 10.2.1 skal det sikres, at der er indgået en aftale med den eksterne serviceleverandør, og at de aftalte sikrings- og kontrolforanstaltninger, serviceydelser og servicemål bliver etableret, leveret og opretholdt, jf. 6.2. irksomheden og leverandøren bør indgå en egentlig Service evel Agreement (SA) med målepunkter, hvis opfyldelse sikrer driftsstabiliteten af FESD-systemet. ed statusmøder mellem virksomheden og leverandøren skal SA punkterne vurderes. For at sikre aftalens overholdelse er det vigtigt, at virksomheden løbende har indsigt i og forholder sig kritisk til: Serviceleverandørens løbende kapacitetstilpasning Kvaliteten af og realismen i serviceleverandørens beredskabsplaner. Herudover skal en eventuel overgangsperiode plan- Er der aftalt løbende kapacitets overvågning af serverne, f.eks. memory, diskplads, backup, databaser og netværksforbindelser? Er der aftalt under hvilke omstændigheder, der skal ske kapacitets udvidelser eller indskrænkninger? Hvilke sikringsforanstaltninger har den eksterne serviceleverandør gennemført for at afskærme virksomheden for utilsigtede hændelser hos leverandøren, f.eks. brand, medarbejderafgang, tyveri o.l.? Hvis der sker en uforudset hændelse hos den eksterne serviceleverandør, hvordan kommer leverandøren så tilbage fra nød drift til normal 22 / 49

lægges omhyggeligt. drift? Overvågning og revision af serviceleverandøren I henhold til DS 484 afsnit 10.2.2 skal det sikres, at virksomheden regelmæssigt overvåger serviceleverandøren, gennemgår de aftalte rapporter og logninger samt udfører egentlige revisioner, for at sikre, at aftalen overholdes, og at sikkerhedshændelser og problemer håndteres betryggende. Følgende aktiviteter skal gennemføres løbende: Overvågning af det aftalte serviceniveau * Regelmæssige møder med gennemgang af driftsrapport, herunder sikkerhedshændelser Gennemgang af og opfølgning på sikkerhedshændelser, driftsproblemer, fejl og nedbrud Gennemgang af sikkerheds- og driftsrelaterede logninger Indgåelse af aftale, planlægning og opfølgning på løsningen af udestående problemer. Hvordan måles og afrapporteres de servicemål der er aftalt? Er der aftalt konsekvenser af manglende overholdelse af serviceniveauet? Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. Er der aftalt gennemgang af hændelser i forbindelse med statusmøder? Er der aftalt procedurer for kontrol af logs, og hvem der må udføre kontrollen? Er der en foranstaltning, der automatisk adviserer virksomheden eller den eksterne serviceleverandør, i forbindelse med særlige kritiske hændelser i loggen? Er der aftalt eskalationsprocedurer? Er det aftalt om 3. part (for eksempel virksomhedens IT-revisor) må få adgang til driftsmiljøet med henblik på at bistå virksomheden i vurdering af driftskvalitet? Styring af ændringer hos ekstern serviceleverandør I henhold til DS 484 afsnit 10.2.3 skal det sikres, at en ekstern serviceleverandørs ydelser følger de samme retningslinjer som virksomhedens egen ændringsstyring, jf. 10.1.2. i DS 484. ær opmærksom på, at kravene til ændringsstyring også skal omfatte eventuelle underleverandører, jf. 6.2.3 i DS 484. Ændringsstyring hos en serviceleverandør skal tage højde for følgende specielle forhold: * irksomhedens egne ændringsønsker: 1. udvidelser af de eksisterende serviceydelser 2. udvikling af nye systemer 3. ændringer i virksomhedens politikker og procedurer 4. nye sikringsforanstaltninger til forbedring af sik- Dette er et skærpet krav og overholdelse afhænger af den enkelte risikovurdering. 23 / 49