Sikkerhedsprincipper – God praksis

Sikkerhedsprincipper - God Praksis

• +

  1.0 Generelt

  1.1 FORORD

  Formålet med dette dokument er at præsentere overordnede sikkerhedskrav samt bud på bedste praksis indenfor feltet IT-sikkerhed på Aalborg Universitet.

  Målgruppen er alle, der kommer i berøring med IT-sikkerhed på AAU. Derudover vil det være særlig relevant for projektledere, systemarkitekter og systemejere.

  Som offentlig institution er AAU pålagt at arbejde efter principperne i ISO27001-standarden, og derfor er dette dokument også udarbejdet med udgangspunkt i denne. Derudover er der medtaget input og viden fra andre relevante standarder, udførte risikovurderinger og andre erfaringer. Som yderligere inspiration henvises til følgende hjemmesider:

  https://www.haandbog.aau.dk/dokument/?contentId=384274 - Politik for Informationssikkerhed på AAU - https://www.sikkerhed.aau.dk/politikker-regler/sikkerhedshaandbog/ - AAU’s sikkerhedshåndbog - https://www.sikkerhed.aau.dk/organisering/ - organisering af arbejdet med IT-sikkerhed på AAU

  Jf. AAU’s vejledning for ”Udformning af politikker, regler, procedurer eller gode råd - sådan gør du”1 , er denne guide på niveau med procedure/gode råd, hvor Sikkerhedshåndbogen forventes at være på regler-niveauet.

  Dette dokument vil være under konstant udvikling, og hvis der opstår tvivl om nogle af punkterne, er det altid muligt at tage fat i Team Sikkerhed for dialog og samarbejde.

   

  1.2 UDDANNELSE

  På AAU skal ledelsen sikre, at brugere og administratorer bliver uddannet i de IT-produkter de benytter og/eller administrerer. Dette skal gøres for at sikre, at et produkt eller et system ikke bliver anvendt på en måde, der kan føre til potentielle sårbarheder i systemet.

  Derfor er det god praksis at man allerede inden et nyt produkt tages i brug, gennemfører uddannelse af de medarbejdere, der forventes at skulle anvende systemet.

  Det skal her også overvejes, om IT-supporten skal inddrages, således at de er forberedt på at modtage spørgsmål om systemet.

  Det kan efter behov overvejes om man også efterfølgende, f.eks. årligt, skal gennemføre yderligere awareness, således at brugerne fortsat har den nyeste viden om systemet. Team Sikkerhed sørger i samarbejde med andre aktører for, at der bliver udført generelle awareness-kampagner omkring IT-sikkerhed på hele universitetet. Dette betyder dog ikke, at man ikke selv kan tage initiativ til awareness på sit specifikke ansættelsessted, hvis man ser et behov herfor. Team Sikkerhed står altid til rådighed for dialog og sparring omkring awareness.

  Som (system-)ejer af et produkt er man ikke kun ansvarlig for den faglige håndtering af produktet – man skal også sikre at især udviklings-, drift- og sikkerhedsafdelingen er godt uddannet mht. sikkerhed af og i produktet.

   

  1.3 TOOLS

  Aalborg Universitet stiller forskellige værktøjer til rådighed for dets medarbejdere. 

  Et af disse værktøjer er f.eks. et værktøj, der kaldes en ”Password manager”. Det stilles i udgangspunktet til rådighed for medarbejdere i ITS, og hjælper med at sikre, at man holder styr på sine passwords gennem en central løsning, fremfor at hver enkelt medarbejder skal benytte hver sin løsning. Det kunne også tænkes, at der var andre områder, hvor et fælles værktøj ville være gavnligt, og Team Sikkerhed er altid parat til at indgå i en dialog og hjælpe med sparring herom. 

   

  *https://www.haandbog.aau.dk/dokument/?contentId=392163

• +

  2.0 Styring af aktiver

  2.1 DATAKLASSIFIKATION OG EJERSKABSDEFINITION

  Der er på Aalborg Universitet udarbejdet en dataklassifikation, som danner grundlag for blandt andet driftsaftaler og sikkerhedsniveauer. Alt efter hvilken klassifikation en given type data har, følger der forskellige regler og krav til hvordan den data må og skal behandles. Overordnet set kan man sige, at jo mere fortrolig en information er, jo bedre skal der passes på dem. Det er i den forbindelse vigtigt at huske, at fortrolighed ikke kun handler om hvorvidt der er persondata i systemet, men også hvorvidt der er tale om fortrolige forretningsinformationer.

  Det følger af AAU’s Sikkerhedshåndbog, at alle informationsaktiver skal have defineret en ejer. Denne ejer har til opgave at sikre, at aktivet bliver klassificeret og håndteret derefter. Det er således aktivejerens ansvar at sikre, at aktivet er underlagt den sikkerhed, som klassifikationen kræver.

  Der foregår et arbejde med at udvikle og definere system/aktiv-ejerens rolle, således at det bliver tydeligt defineret hvilke opgaver der ligger i denne rolle, og hvordan rollen bliver tildelt. 

   

  2.2 DATAMINIMERING

  Dataminimering går ud på netop dette – at minimere mængden af data. Det drejer sig om alt fra indsamling, behandling og opbevaring af data. For at kunne overholde princippet om dataminimering, er det vigtigt at man kan argumentere for hvorfor man har indsamlet data. Hvis man behandler data, hvor der ikke findes saglige og arbejdsrelaterede argumenter for databehandlingen, bør man stoppe behandlingen af den data.

  Dette gælder også i forhold til opbevaringsperioder, således at man ikke opbevarer data i længere perioder, end der er behov for. Her kan der dog også være lovmæssige krav, der er bestemmende for, hvor længe data må og skal opbevares. Såfremt der ikke er sådanne lovmæssige krav, er det vigtigt, at man har en fyldestgørende argumentation for, hvor længe man opbevarer sin data.

  Det er også værd at bemærke, at dette princip ligeledes gælder logfiler, som også skal begrænses til det nødvendige. Logfiler nævnes dog også separat, da de i deres natur er svære at begrænse, da de oftest skal anvendes i situationer, hvor man ikke nødvendigvis på forhånd ved, hvad man leder efter.

• +

  3.0 Adgangsstyring

  Overordnet set er adgangsstyring en meget central sikkerhedskomponent i alle systemer. Der findes mange forskellige måder at opbygge adgangsstyring i systemer, og de kan variere meget i kompleksitet. På Aalborg Universitets centrale systemer er adgangen styret gennem vores Active Directory (AD). Når nye systemer tages i brug, foretrækkes det derfor, at de ligeledes anvender vores AD til brugerstyring, da vi så kan genbruge mange af vores eksisterende processer og procedurer

   

  3.1 KONTI OG RETTIGHEDSSTYRING

  Kravene til kontrol af brugerkonti og rettighedsstyring følger den overordnede klassifikation af systemet. Som udgangspunkt skal et system som minimum understøtte AAU’s generelle sikkerhedskrav, som defineret i bl.a. Sikkerhedshåndbogen. Det er netop af denne grund, at integration til AAU’s AD er at foretrække, da man automatisk opfylder AAU’s sikkerhedskrav. Såfremt et system ikke er integreret til AAU’s AD, eller alternativt bliver administreret i AAU’s Identity-management system (IDM), skal der føres separate kontroller med brugere i dette system. Derudover vil det være ejeren af det pågældende systems ansvar at sikre, at systemet overholder AAU’s minimumskrav, herunder de nedenstående eksempler på god praksis.

   

  God praksis:

  • Alle brugerrettigheder skal gennemgås jævnligt, og mindst hver 6. måned.
  • Administratorrettigheder gives udelukkende på baggrund af et konkret arbejdsmæssigt behov og fjernes så snart behovet forsvinder.
  • Anvendelse af administrator-konti skal begrænses til det absolut nødvendige.
  • Anvendelse af servicekonti skal ligeledes begrænses til det absolut nødvendige.
  • Servicekonti skal ydermere være skræddersyet til formålet, samt have mindst mulige privilegier for at kunne udføre denne service.
  • Servicekonti skal være navngivet, så det er tydeligt at se, at der er tale om en systemkonto.
  • Brugere og privilegier skal kunne spores med audit logs.
  • Audit logs skal altid vurderes i forhold til, om de skal i AAU’s centrale log management system.
  • Der skal være en procedure for, hvordan rettigheder i det enkelte system bliver ændret, tildelt, frataget og nedlagt.

   

  3.2 MULTIFAKTOR ADGANGSBESKYTTELSE

  Det kan ofte være en god idé at anvende multifaktor autentifikation (MFA) i forbindelse med specifikke systemer. Der kan være flere forskellige grunde til at bruge denne type beskyttelse, og hvis man er i tvivl, vil det ofte kunne klarlægges gennem en risikovurdering.

  God praksis:

  • Anvendelse af MFA ved dataklassifikation højre end ”Offentlige informationer”.
  • Overvej hvilken type MFA, der skal anvendes (Microsoft Authenticator, SMS eller mail med engangskode)

   

  3.3 Least privilege

  Det er en fundamental forudsætning for god sikkerhed, at en brugerkonto ikke har flere rettigheder end påkrævet for at kunne løse en given opgave. En medarbejder kan skifte opgaveområder mange gange i løbet af sit arbejdsliv, og det er vigtigt at et system kan understøtte dette, således at en medarbejder ikke akkumulerer unødvendigt mange adgange. Det er derfor vigtigt altid at arbejde ud fra et udgangspunkt om, at en konto skal have så få adgange som nødvendigt for at løse dens opgaver. 

  God praksis:

  • Opsæt adgange ud fra et princip om at ingen i udgangspunktet må have adgang.
  • Medarbejdere bør i udgangspunktet ikke have administratorrettigheder på deres arbejdscomputere.
  • Sørg for at filer og mapper kun er tilgængeligt for de konti, der har et arbejdsmæssigt behov herfor.
  • Services/integrationer skal bruge konti, der er skræddersyet til formålet, samt have mindst mulige privilegier for at kunne udføre denne service. Det gælder ligeledes databasekonti, der benyttes i applikationer mv.
  • Indstil begrænsninger for gæsteadgang, studenter og lignende.
  • Benyt audit logning for at sikre at sporbarheden er intakt, især for administratorkonti og andre konti med særlige og ekstra beføjelser.
  • Rettighederne skal være bygget op således at en bruger ikke kan se, mere end hvad de har behov for. Der skal være relevant afskærmning af data.

   

  3.4 FUNKTIONSADSKILLELSE

  Det bør altid overvejes, om der skal anvendes individuelle konti til forskellige formål, for at undgå en unødvendig akkumulering af brugerrettigheder. Konti bør derfor opdeles baseret på de individuelle krav til forretningssystemet, samt i henhold til adgangsstyring i AAU’s Sikkerhedshåndbog.

  God praksis:

  • Central styring af adgang til de forskellige forretningssystemers funktioner (f.eks. i IDM).
  • Det skal overvejes præcis hvilke data, der skal være tilgængelig til en bestemt bruger-funktion, og rettigheder skal opbygges og tildeles derefter.
  • Brugerrettighederne skal konstrueres således at der som udgangspunkt kun gives læse-adgang, og kun ved et arbejdsmæssigt behov kan der tildeles yderligere rettigheder som f.eks. skrive og slette. 

   

  3.5 ADSKILTE UDVIKLINGS-, TEST- OG PRODUKTIONSSYSTEMER OG DATA

  Ved opbygning af systemer er det centralt, at der er en logisk separation af udvikling, test og produktionsdata. Dette gøres både for at sikre, at fejl i udviklings- og testmiljøerne ikke føres over i produktionsmiljøerne, men også fordi der kan være en markant anderledes sikkerhedsopsætning omkring test- og udviklingsmiljøer.

  Produktions data må derfor ikke benyttes i udviklings- og testmiljøer, medmindre det kan dokumenteres, at data i disse miljøer er underlagt samme sikkerhed som i produktionsmiljøet. Dette gælder også bruger- og rettighedsstyring, som skal sikre, at de personer, der arbejder i test- og udviklingsmiljøerne, ikke får adgang til mere data end absolut nødvendigt, jf. princippet om dataminimering. Adgang til udvikling og test miljø skal altså være omfattet af samme sikkerhedsniveau som produktionsmiljøet såfremt der er følsomme personoplysninger eller produktionsdata i miljøet.

  Anvendelse af data i de forskellige miljøer skal derfor overvejes i henhold til den klassifikation, som data er opmærket med.

  God praksis:

  • Der bør altid være adskilte miljøer til drift, udvikling og test.
  • Hvis der anvendes automatiseret deployment / udrulning, som følger nogle foruddefinerede processer og procedurer, kan det være med til at øge sikkerheden omkring udviklingsprocessen.
  • Udviklere bør ikke have adgang til produktionsmiljøet, da det sjældent er muligt at begrænse deres adgange i dette miljø.
  • Såfremt det er muligt, skal der anvendes reference arkitektur, da det kan øge sikkerheden for, at man tager de rigtige arkitekturmæssige valg.
  • Der må i udgangspunktet ikke anvendes produktionsdata i test og udviklingsmiljøet.

   

  3.5 KRAV TIL UDSTYR

  Udstyr udleveret af AAU følger de minimumskrav, der er defineret i bl.a. Sikkerhedshåndbogen. Disse computere er administreret af ITS og bliver derfor løbede opdateret, så de overholder de gældende sikkerhedskrav. Medarbejderen har dog stadigvæk selv et ansvar for at tage kontakt til ITS, hvis der oplevelse uregelmæssigheder på computeren. Det er også medarbejderens ansvar at sikre, at computeren bliver slukket med jævne mellemrum, så eventuelle opdateringer kan blive gennemført.

  På AAU er det naturligt, at der bliver anvendt egne enheder, kendt som ”bring your own device” (BYOD). Det er en vigtig mulighed at have, men den introducerer også en række sikkerhedsmæssige udfordringer, da de ikke bliver styret af ITS. Det betyder, at der kan være udfordringer med manglende opdateringer, manglende kryptering, manglende logning og sporbarhed.

  Det er derfor vigtigt at overveje nødvendigheden af at bruge en enhed, der ikke er udleveret af AAU. Såfremt det er muligt, skal anvendelsen af BYOD-enheder begrænses til et absolut minimum, og hvis de bliver anvendt, skal det gøres på en måde, hvor man er opmærksom på de potentielle risici, som sådan en enhed medfører.

  God praksis:

  • Medarbejdere bør benytte computere, som er administrerede af ITS, så software opdateres løbende.
  • På alle AAU-computere skal det sikres, at der er antivirus beskyttelse, automatisk opdatering og overvågning fra ITS.
  • På klient-siden skal der benyttes en software firewall, der er en integreret del at Windows, macOS og Linux.
  • Det bør overvejes, om Powershell skal deaktiveres i Windows, såfremt det ikke benyttes dagligt at brugeren.
  • Sikre at alle medarbejder computere har fuld disk kryptering. Dekrypteringsnøgler bør gemmes centralt.
• +

  4.0 Drifts- og IT-sikkerhed

  Det er en velkendt sætning, at der ikke findes noget, der er 100% sikkert. Derfor er den bedste anbefaling at benytte flere lags beskyttelse, da det reducerer chancerne for vellykkede angreb. Disse lag bør ligeledes være spredt ud over forskellige indsatser, hvilket i NIST-rammeværktøjet er defineret som muligheden for at ”Identify, protect, detect, respond and recover”. Det ideelle scenarie er, at man har implementeret sikkerhedsforanstaltninger i alle disse fem kategorier. Dette kan dog være en meget omfattende opgave, og derfor er der i det nedenstående udvalgt særlige områder, der kan tages udgangspunkt i.

  En Configuration management database (CMDB), der er en art inventarliste over ens IT-miljø, og assets lister vil være understøttende værktøjer i forbindelse med afdækning af eventuelt sårbare systemer. Der findes forskellige lister og database af denne natur i AAU, og der foregår et løbende arbejde med at konsolidere disse.

  God praksis:

  • At der er udarbejdet en risikovurdering, der fastsætter rammerne for systemets sikkerhedsniveau
  • Sikre, at der altid patches på både OS-niveau og applikationer, og såfremt det er muligt og relevant, skal denne proces automatiseres.
  • Det bør hele tiden overvejes, om der er applikationer, der er unødvendige at anvende, hvorefter de bør fjernes for at minimere risikoen.
  • Ejeren af systemet bør sikre, at der er en ansvarlig person, der løbende følger med i, hvad leverandøren udgiver af sikkerhedspatches, og som vurderer, hvordan og hvor hurtigt en patch skal implementeres
  • Det er vigtigt, at der er faste procedurer, der sikrer, at der er taget stilling til, hvor lang tid der må gå fra en patch udkommer, til den er implementeret. • Disse punkter gælder også for eventuelle udviklings- og testmiljøer. 

   

  4.1 LØBENDE VURDERING AF SÅRBARHEDER OG TRUSLER

  Det er vigtigt at tage hensyn til, at trusselsbilledet hele tiden forandrer sig, og derfor skal der løbende være en revurdering af de sårbarheder og trusler, som gør sig gældende. Det er sjældent nok at gennemføre én risikovurdering, hvorefter man ikke vurderer systemet igen. Det er en kontinuerlig proces, hvor det hele tiden skal sikres, at der følges op på handleplaner og at de foranstaltninger som en risikovurdering tilsiger, bliver implementeret.

  Der kan være mange kilder til information om trusler og risici, og det er at ejeren af systemet løbende holder sig orienteret omkring disse, således at der kan skrides til handling, hvis der dukker en sårbarhed op.

  Team Sikkerhed arbejder med sektortruslerne såvel som med risikovurderingerne.

  God praksis:

  • Det er vigtigt løbende at holde sig opdateret på det aktuelle trusselsbillede, således at man er på forkant med sårbarhederne
  • En risikovurdering skal genbesøges mindst én gang årligt, eller hvis der opstår behov for det gennem ændringer af systemet 

   

  4.2 MALWARE PROTECTION

  Udstyr der er udleveret af AAU skal være omfatte af en centralt administreret malware/end-point beskyttelse. Data fra disse benyttes i forbindelse med universitets SIEM- og SOC-løsninger.

  God praksis:

  • Der skal være antivirus / end-point beskyttelse på alle enheder.
  • At sikre installation af sikkerhedsopdateringer og patches.
  • Der skal være systemfunktionalitet der sikrer, at mistænkelige links i mails bliver blokeret automatisk.

   

  4.3 SYSTEMOVERVÅGNING

  Systemovervågning bidrager til opretholdelse af daglig drift, kapacitetsstyring og IT-sikkerhed. Anormaliteter kan opspores ved hjælp af universitets SIEM systemer. Dette kan både bruges til overvågning af driftsstabilitet, men også overvågning og opklaring af sikkerhedshændelser. Dette overvågningsarbejde er i nogen grad samlet i Team Sikkerhed, og det er derfor altid muligt at indgå i en dialog omkring systemovervågning af relevante systemer.

  God praksis:

  • Hvis det er relevant, er det vigtigt at få relevante logs afleveret til universitets SIEM systemer.
  • Det er derfor en god idé at tage en dialog med Sikkerhed om mulige misbrugsscenarier og scenarier for driftsnedbrud, så der kan laves alarmer.
  • Definer personer, som skal agere på alarmer og lav beredskabsplaner i tilfælde af, at en sikkerhedshændelse eller driftsafbrydelse opstår. 

   

  4.4 BACKUP & RESTORE

  På AAU skal alle de services, der bliver stillet til rådighed centralt fra, have backup og restore-funktionalitet. Der kan være mange forskellige scenarier og situationer, hvor det er nødvendigt at kunne restore noget, som følge af en brugerfejl, systemfejl, ransomware eller nedbrud.

  Det er vigtigt at sikre, at man har taget stilling til, hvor hurtigt data eventuelt skal kunne gendannes og har afprøvet dette i en beredskabsprøve. Afhængig af hvor kritisk en backup er, kan der være mange forskellige sikkerhedsmæssige hensyn, der skal tages, eksempelvis om backup’en skal være placeret på en anden fysisk lokation, om den skal være afskåret fra netværksadgang osv.

  God praksis:

  • Test sikkerhedskopier regelmæssigt. Gennemfør gendannelse af sikkerhedskopierne, således det sikres, at det man gendanner, også giver den funktion for produktet som man har forventning om.
  • Tag backup af forretningskritiske data dagligt. Øvrige drifts data mindst ugentlig. Frekvensen er bestemt af vigtigheden/dataklassifikationen. • Automatiser backup-funktionen.
  • Sikre at gendannelse har en acceptabel tidshorisont jf. systemets vigtighedsniveau, hvilket også skal testes i forbindelse med gendannelse.
  • Afhængig af kritikalitetsvurderingen skal det overvejes, om backup skal opbevares off-site, således at ransomware ikke kan sprede sig dertil. 

   

  4.5 BEREDSKABSPLANER

  Hvis det er relevant, skal nye produkter skal implementeres i den nuværende beredskabsplan. Den nuværende beredskabsplan bliver vedligeholdt af ITS.

  Systemejer bør sikre, at der er en beredskabsplan for det pågældende system, såfremt klassifikationen af systemet tilsiger dette. Afhængig af klassifikationen kan det også være relevant at udføre tests af beredskabsplanen.

  God praksis:

  • Hvis der er data i systemet, som ikke kan undværes, er det nødvendigt at have en backup af al data. Se pkt. 4.4.
  • Sørg for at have dokumentation for gendannelse af de kritiske systemer.
  • Der skal gennemføres tests af beredskabsplanen, således at man har et overblik over, hvilke eventuelle fejl og mangler der er. Disse kan løbende blive udbedret, således at man får en robust beredskabsplan. 
  • På de kritiske systemer er det vigtigt at teste restorehastigheden, således at man er forberedt på, om tidsforbruget er acceptabelt, eller om der skal implementeres yderligere foranstaltninger.
  • Beredskabsplanen skal løbende evalueres og forbedres, og ejerskabet for denne proces skal være stærkt og fast forankret.

   

  4.6 LOGDATA OG REGELMÆSSIG GENNEMGANG

  Logdata benyttes i Team Sikkerhed til at overvåge sikkerhedshændelser, driftsstabilitet og til at efterforske sikkerhedshændelser. Derudover bliver logdata anvendt mange forskellige steder i AAU til forskellige opgaver. Overordnet set er en af de vigtigste opgaver, at der logges den mængde informationer, som der er behov for, men ikke mere end det. I forbindelse med indkøb af nye systemer er det derfor vigtigt at overveje, hvorvidt der er logdata i systemet, der med fordel kunne blive ført over i den centrale log management platform (SIEM-platform). Derved sikres også en afkobling fra kildesystemet, hvilket er med til at øge loggens sikkerhed.

  Det er vigtigt at forstå, at log management er ikke blot et stort sort ”hul”, men et stort aktiv i daglig drift. Det kan både bruges til kapacitetsstyring, analyse og fejlsøgning, og mange flere ting. Det er derfor vigtigt altid at tage stilling til, om loggen fra ens system kunne være relevant at indsamle centralt. Dette er en dialog, som Team Sikkerhed meget gerne vil indgå i og sparre omkring.

  God praksis:

  • Altid at overveje, om loggen fra ens system kunne være relevant for andre, både fra et sikkerhedsmæssigt og et driftsmæssigt perspektiv.
  • Såfremt loggen er relevant, skal det vurderes hvilke dele af ens system, det giver mening at overvåge, og at sætte alarmer op på denne overvågning.
  • Hold alarmniveauet på et niveau, der sikrer, at man ikke bliver oversvømmet af mindre vigtige alarmer og derved mister syn på de vigtige alarmer.
  • Aktiver alle logfiler, men kun i forbindelse med den proces, hvor der tages stilling til, hvilke der skal beholdes.
  • Det kan være hensigtsmæssigt at sikre, at der er et ensartet udtræk af data, samt at disse overholder CIM modellen. 

   

  4.7 ÆNDRINGSJOURNALER

  Det er vigtigt at have en ændringsjournal for sine systemer, da der kan opstå situationer, hvor en ændring har introduceret en fejl, og man derfor har brug for at kunne finde det tidspunkt, hvor fejlen blev introduceret. Der findes flere forskellige systemer, der kan understøtte denne proces, og det vil ofte være forskelligt fra system til system. Det vigtigste er derfor, at der findes en ændringsjournal, og at den er fyldestgørende og retvisende.

  God praksis:

  • Sørg for, at ændringsjournalen indeholder al den relevante information, som f.eks. er nødvendigt i en fremtidig fejlsøgning.
  • Hav klare mål.
  • Vælg det rette værktøj.
  • Uddannelse af personale. 

   

  4.8 SERVICEVINDUER

  Alle produkter skal have en dokumenteret proces for service og servicevinduer, og ITS CAB orienteres om disse servicevinduer. God praksis:

  • Dokumenter ordinær / faste servicevinduer.
  • Dokumenter ekstra ordinære / haste / nød servicevinduer.
  • Dokumenter standard ændringer, som kan laves uden individuel godkendelse.
  • Dokumenter udmeldingsstrategien, -platform.
• +

  5.0 Kommunikationssikkerhed

  5.1 ADGANGSBESKYTTELSE PÅ NETVÆRKSNIVEAU

  Overordnet set skal der fastholdes en segmentering af netværk og tjenester på netværket. Denne segmentering skal også opretholdes ved implementeringen af nye produkter, og det er ejeren af disse produkters ansvar at indgå i en dialog omkring, hvordan dette sikres mest hensigtsmæssigt.

  Det er også ejerens ansvar at overveje hvilke metoder, brugerne af det nye aktiv kan bruge til at få adgang til aktivet på netværksniveau. Det er herunder vigtigt, at der skal være en form for autentificering af brugerne for netværkstjenesterne.

  God praksis:

  • Adskil studerende, gæster og medarbejdere både på det kablede og det trådløse netværk.
  • Benyt ACL og VLAN eller lignende teknologier til at lave logisk adskilt trafik.
  • Benyt whitelist i forbindelse med netværksadgang. Det kan overvejes, om der skal laves en positivliste, hvor alt andet bliver forbudt.
  • Sikre at følsomme systemer er adskilt fra mindre sikre systemer.
  • Vær særlig opmærksom på systemer, som behandler følsomme personoplysninger, da der kan være helt særlige krav til disse systemer
• +

  6.0 Anskaffelses, udvikling og vedligeholdelse

  6.1 GOD PRAKSIS FOR PLATFORMEN

  Når der er tale om ”Best Practice” for en platform, kan det være meget diffust, og det kan være svært at gennemskue, hvad der er den bedste ”Best Practice”. Mange leverandøre angiver ofte selv god praksis for produktet, hvilket med fordel kan følges. Det er indimellem også muligt at søge inspiration fra 3. parter, f.eks. i ”community grupper”. En vigtig kilde til god praksis kan også findes i de erfaringer, vi selv har gjort os på AAU, hvis systemet er kendt eller har været brugt tidligere. 

   

  6.2 KVALITETSKONTROL

  Når der introduceres nye systemer/produkter, eller ved større ændringer i eksisterende systemer, bør der altid følges en formel ændringsproces, eller changeproces. Denne proces bør i udgangspunktet dække følgende områder: dokumentation, kravspecifikation, test, kvalitetskontrol og implementering. Når et system skal testes, findes der mange forskellige metoder, som alle har forskellige mål og resultater. Det er derfor vigtigt at vælge den test, der er relevant for det man gerne vil undersøge. Som eksempler kan nævnes load test, stress test, UAT (user acceptance test), penetrationstest osv. Fordi de hver især giver forskellige resultater, er det derfor vigtigt at være helt klar over, hvad man gerne vil undersøge, før man igangsætter en test.

  God praksis:

  • • Det er vigtigt at følge en veldefineret handleplan, hvor man bl.a. sikrer, at man får defineret ens scope og det scenarie, man gerne vil gennemgå.
  • • Der skal være et brugbart resultat af testen, f.eks. en rapport.
  • • Hvis det er relevant, kan det være nødvendigt at benytte et uafhængigt review af kode, krav m.v.

   

  6.3 PENETRATIONSTEST

  En metode til at afdække sårbarheder i et givent produktionsmiljø kan være penetrationstest, og disse test bliver normalt inddelt i to kategorier, nemlig Whitebox og Blackbox. Ved kendt (whitebox) test foreligger der information om systemet, herunder hvilke miljøer der findes, hvilke komponenter produktionen består af osv. Overfor dette står en ukendt (blackbox) test, som er ren ”hacking” fra testerens side, hvor de ikke har nogen forudgående viden om det system de skal hacke. Ligesom i det ovenstående giver de forskellige typer tests forskellige resultater, og det er derfor vigtigt at vælge den test, der er rigtig for det pågældende system.

  Disse test kan udføres på on-premises services såvel som på Cloud services.

  God praksis:

  • Hvis det vurderes nødvendigt for systemet, skal der gennemføres enten en whitebox eller blackbox penetrationstest.
  • Under en penetrationstest skal man “overvåge” sit system, for på den måde at sikre sig, at der ikke sker en løbende sænkelse af sikkerhedsniveauer.
  • Der kan også gennemføres sårbarhedsscanninger, som er mindre indgribende end en penetrationstest.
• +

  7.0 Overenstemmelse

  7.1 LOVMÆSSIGE KRAV

  Som en offentlig institution er Aalborg Universitet underlagt flere forskellige typer lovgivning. Det er derfor vigtigt som ejer af et aktiv, at man er opmærksom på, hvilke love og regler der gælder for ens system. En af de mest kendte lovgivninger er GDPR, som et system er omfattet af, såfremt det indeholder personoplysninger. På samme vis findes der lovgivning på økonomiområdet og forskningsområdet. Langt de fleste områder er reguleret af lovgivning, og det er derfor vigtigt at gøre sig klar over, hvad der gælder for ens system, da der ofte kan være en række krav, som man skal efterleve.

  God praksis:

  • Det skal sikres, at man overholder gældende lovgivning, der er relevant for det pågældende system.
  • Hvis man er i tvivl om, hvilke lovgivningsmæssige krav, man er underlagt, kan man rette henvendelse til Kontraktenheden.

  7.2 REGELMÆSSIGE KONTROLLER

  Afhængig af aktivet vil der kunne være forskellige krav til de kontroller, som et aktiv kan være underlagt. Ofte er der tale om krav, der følger af lovgivning, men der kan også være tale om krav fra forretningen, fra en IT-revision eller et certificeringsorgan. Når de forskellige krav er blevet identificeret, skal kontrollen udføres, dokumenteres og handles på, hvis nødvendigt.

  Det er ejeren af aktivet, der er ansvarlig for at kontrollen bliver udført. Det er ikke nødvendigvis ejeren der skal udføre kontrollen, og denne må gerne blive uddelegeret til en udførende person, men ansvaret vil stadigvæk være hos ejeren af aktivet.

  God praksis:

  • Det skal altid undersøges, hvorvidt der er krav til kontroller af et givent aktiv.
  • Kontrollerne skal oftest gennemføres med et fast tidsinterval, og det er derfor vigtigt at systemunderstøtte denne opgave, således at der automatisk bliver udsendt en påmindelse, når kontrollen skal gennemføres
  • Resultatet af kontrollen skal journaliseres i WorkZone
  • Såfremt resultatet af kontrollen medførte, at der skulle udføres en handling, skal denne handling også dokumenteres, herunder hvornår den blev gennemført.
• +

  8.0 Appendix

  EKSEMPLER PÅ LOG INFORMATION

  Et Logningsevent bør, hvis relevant, indeholde følgende information:

  • Bruger ID(s)
  • System aktiviteter
  • Date/time timestamp(s)
  • Oplysninger om vigtige hændelser, f.eks. logon eller logoff
  • Device (enhed) identitet og/eller -lokation
  • Systemidentifikation • Information om vellykkede/afviste adgangsforsøg til systemet
  • Information om vellykkede/afviste adgangsforsøg til data eller andre ressourcer
  • Ændringer af systemkonfiguration • Brug af privileger/rettigheder
  • Brug af systemværktøjer eller applikationer
  • File(r), adgang og typen af adgang
  • Netværksadresser og -protocoler
  • Aktivering eller deaktivering af beskyttelsessystemer, f.eks. antivirus eller intrusion detection system
  • Informationer om transaktioner, der er gennemført af bruger i applikationer
  • Alarm udløst af adgangsstyringsystem

  Disse logs kan indeholde følsomme, personrelaterede og/eller fortrolige informationer. Der bør derfor træffes passende foranstaltninger til beskyttelse af disse logs.

   

  FORKORTELSER

  AAU, Aalborg Universitet

  AD, Active Directory

  AV, Antivirus

  BP, Best Practice

  BYOD, Bring Your Own Device

  CAB, Change Advisory Board

  CIA, Confidentiality Integrity Availability

  CIM, Common Information Model

  CMDB, Change Management Data Base

  GDPR, General Data Protection Regulation

  IdM, Identity Management

  IDS, Intrusion Detection System

  ISO, International Standard Organisation

  ISU, Informationssikkerhedsudvalg

  ITS, IT Support

  ITSM, IT Service Management

  ITIL, IT Infrastructure Library

  MDM, Mobile Device Management

  MFA, Multi Factor Authentication

  NIST, National Institute of Standards and Technology

  SIAM, Service Integration And Management

  SIEM, Security Information and Event Management

  SLA, Service Level Agreement

  SOC, Security Operational Center

  UAT, User Acceptence Test

  VPN, Virtual Private Network

   

  CIA KVADRANT

  Er et værktøj til at hjælpe med implementeringen af cyber sikkerhed samt privatlivskontrol (privacy). Disse fire ”søjler” er fortrolighed, integritet, tilgængelighed og sikkerhed.

  

   

  FORTROLIGHED

  Fortrolighed er evnen til at sikre, at data ikke bliver eksponeret for uvedkommende. Der skal være begrænsninger for adgang til oplysninger og videregivelse, så data kun kan tilgås af autoriserede brugere og tjenester.

  INTEGRITET

  Integritet adresserer bekymringen for, at følsomme data ikke er blevet ændret eller slettet på en uautoriseret måde.

  TILGÆNGELIGHED

  Tilgængelighed handler om evnen til at sikre rettidig og pålidelig adgang til og brug af oplysninger.

  SIKKERHED

  Sikkerhed adresserer reducering af risiko forbundet med integrerede teknologier, der kan udnyttes eller manipuleres af ondsindede aktører.