{{item.title}}
{{item.text}}
{{item.title}}
{{item.text}}
NSIS, eller National Standard for Identiteters Sikringsniveauer, er udarbejdet af Digitaliseringsstyrelsen i forbindelse med overgangen fra NemID og NemLog-in 2 til MitID og NemLog-in 3. NSIS er den danske fortolkning af den europæiske eIDASforordning.
NSIS arbejder med tre sikringsniveauer: lav, betydelig og høj. Fremover skal alle tjenesteudbydere vurdere, om deres tjenester skal udbydes på et lavt, betydeligt eller højt sikringsniveau. Dette niveau kaldes LOA (Level Of Assurance). Vurderingen skal bero på en konkret risikovurdering af de systemer og data, der gives adgang til. Er det eksempelvis data, som i henhold til GDPR bliver klassificeret som følsomme personoplysninger, og gives der adgang til data for et stort antal personer, må antagelsen være, at der skal kræves LOA = høj for at få adgang til disse data. Men det er en vurdering, som tjenesteudbyderen skal foretage og håndhæve efterfølgende. Kræver tjenesten LOA = betydelig, kan man som identitet ikke tilgå tjenesten, medmindre man som minimum kan fremvise det samme sikringsniveau = betydelig.
Adgang til en tjenesteudbyders tjenester styres gennem en føderation. En føderation er kendetegnet ved, at tjenesteudbyderen som udgangspunkt ikke kender de identiteter, der skal tilgå tjenesten, men i stedet får en billet fra ”kunden”, der indeholder informationer om identiteten hos kunden. Dermed bliver det et tillidsforhold, der opstår mellem ”kunden” og tjenesteudbyderen. Et tillidsforhold, som NSIS er med til at sætte standarden for.
Som protokol til denne dataudveksling anvendes SAML. Digitaliseringsstyrelsen har udarbejdet en særlig dansk version i forbindelse med MitID og NemLog-in 3 kaldet OIO-SAML 3.0, som MitID og NemLog-in 3 skal overholde.
LOA-værdien skal i henhold til OIO-SAML 3 være stemplet i den SAML-billet, der udstedes hos ”Kunden”, således at tjenesteudbyderen kan afgøre, om identiteten hos ”kunden” skal have adgang til tjenesten eller ej.
PwC’s fortolkning af NSIS-standarden er, at den LOA-værdi, der stemples i SAML billetten til tjenesteudbyderen, er nødt til at blive beregnet dynamisk ”just in time”. Dette skyldes, af NSIS arbejder med en række sikringsniveauer på ”kunde”-siden, og det er disse sikringsniveauer, der samlet set giver LOA-værdien. Sikringsniveauerne på ”kunde”-siden vil variere, alt efter hvilken situation den enkelte identitet befinder sig i. De sikringsniveauer der omtales i dette design er:
Eksempelvis kan en identitet være logget ind på to forskellige pc’er med forskellige identifikationsmidler. På den ene pc er der logget ind med brugernavn og password, og på den anden er der logget ind med et smartcard og pinkode. Sessionen, der er autentificeret med smartcard og pinkode, vil som minimum have en AAL = betydelig og vil derfor give andre muligheder for at tilgå offentlige systemer end den session, der blot er autentificeret med brugernavn og password og dermed er AAL = lav. Man er derfor nødt til at kunne skelne mellem de to forskellige login sessioner, selvom de er foretaget med samme identitet.
Hvis man som virksomhed i dag udelukkende anvender NemID og medarbejdersignatur som autentifikations- og loginmetode mod offentlige systemer, vil der være en række forandringer, som man skal implementere for at blive i stand til at anvende den nye offentlige infrastruktur. Dette skyldes bl.a., at den nuværende medarbejdersignatur-nøglefil udfases og erstattes af en ny erhvervsidentitet via NemLog-in 3.
I den nye infrastruktur vil virksomheden anvende enten 1) NemLog-in 3 som identity provider (logintjeneste) til at tilgå de offentlige systemer og en af de MitID-autentifikationsmetoder, som bliver tilgængelige, eller virksomhedens egen identity provider (lokal IdP) og lokalt udstedte identifikationsmidler.
Hvis man som virksomhed anvender det, der kaldes lokal IdP, altså at virksomheden selv er ansvarlig for at udstille identiteter mod de offentlige systemer, er der en række andre krav, som man skal være opmærksom på. Langt de fleste virksomheder vil typisk anvende en kombination af de her nævnte metoder.
Dette designnotat er primært henvendt til virksomheder med egen lokal IdP. Formålet med designnotatet er at gøre virksomheden i stand til at vurdere, hvilke tekniske tiltag der skal foretages i virksomhedens infrastruktur for at kunne leve op til NSIS-standarden og fremvise en praktisk tilgang til krav til implementeringen.
Med egen IdP er det virksomheden selv, der har hele ansvaret for sikkerheden i forhold til den identitet, der skal have adgang til det offentlige system, herunder compliance i forhold til NSIS. Dette illustreres i tegningen nedenfor. Såfremt virksomheden ønsker at tilgå offentlige systemer med LOA = betydelig eller høj, vil det kræve en revisionserklæring som bevis på compliance.
Designet forholder sig specifikt til de tekniske forhold, som er relevante for at kunne leve op til NSIS-standardens tre sikringsniveauer IAL, AAL og FAL og den resulterende LOA-værdi (lav, betydelig, høj), som tjenesteudbydere kommer til at kræve for at muliggøre login mod tjenesten.
De organisatoriske forhold, som NSIS ligeledes omhandler, er ikke uddybet i dette design.
I afsnittet herunder gennemgås de tre væsentlige sikringsniveauer, som forefindes på ”kunde”-siden IAL, AAL og FAL, og hvordan virksomheden kan ændre sine tekniske systemer.
IAL-værdien er en forholdsvis statisk værdi, som er tilknyttet selve identiteten. IAL-værdien har primært at gøre med organisatoriske forhold, hvordan identiteten blev verificeret af virksomheden, og hvilke kontroller der er udført i den forbindelse, herunder hvilke legitimationsbeviser der er fremvist ved udlevering af identifikationsmidlet.
Verifikation af identiteten via en MitID-autentifikation vil være en gyldig metode til at fastslå IAL-værdien.
Når det siges, at IAL-værdien er forholdsvis statisk, hænger det sammen med den livscyklus, som et identifikationsmiddel gennemløber. Bl.a. kan der være behov for at tilbagekalde et identifikationsmiddel. I et sådan tilfælde skal IAL-værdien naturligvis tilsvarende ændres.
IAL-værdien (lav, betydelig, høj) registreres for identiteten i et it-system, typisk virksomhedens HR-system.
Det skal være muligt for identiteten dynamisk at slå denne værdi op.
For virksomheder, som anvender en identity management (IdM)-løsning, vil det være oplagt at overføre IAL-værdien som en af identitetens attributter fra HR til IdM, således at IAL-værdien kan findes ved et dynamisk opslag i IdM-løsningen på identiteten.
Såfremt virksomheden anvender en IdM-løsning til at administrere identiteter, kunne IAL-værdien automatisk sættes et niveau ned efter en given periode (fx fra betydelig til lav), således at der indbygges en forebyggende kontrol. Kun en aktiv handling i form af en gen-verifikation vil da kunne løfte IAL-værdien igen.
I IdM-løsningen vil det være muligt at indbygge kontroller, såsom ACL eller kryptering, således at kun få relevante konti har adgang til at kunne ændre IAL-værdien.
AAL-værdien beskriver det sikringsniveau, med hvilket selve autentifikationen er foretaget. Når virksomheden anvender lokal IdP, vil AAL-værdien kunne fastsættes på to måder:
AAL-værdien er dermed dynamisk og må på ingen måde stemples på identiteten som en prædefineret værdi. AAL-værdien skal sættes ved hvert login og/eller step-up-autentifikation.
Det er uden for scope for dette designnotat at gennemgå, hvilket AAL-sikringsniveau der kan opnås ved forskellige kombinationer af identifikationsmidler (fx brugernavn og password kombineret med en anden faktor fra en mobiltelefon).
De nævnte to autentifikationsmåder vil i høj grad spille sammen med den slutbrugeroplevelse, som man ønsker, at virksomhedens brugere skal have. Dette hænger sammen med, hvor mange gange identiteten skal autentificeres i løbet af en dag. Hvis den nødvendige AAL opnås med login på pc’en, forventes det, at man i henhold til NSIS kan bevare denne AAL-værdi og benytte den i efterfølgende SAML-billetter, også selvom pc’en i perioder har været i skærmlåst tilstand.
Ved step-up-autentifikation må det forventes, at identiteten skal autentificere sig, hver gang en ny tjeneste tilgås. Når en tjeneste forlades, bør SAML-token blive ugyldiggjort, og dermed skal der autentificeres igen, næste gang den samme eller en anden service tilgås. Dette vil naturligvis påvirke slutbrugeroplevelsen af arbejdsprocessen, og for mange autentifikationer i løbet af en arbejdsdag vil nedsætte effektiviteten.
Specielt i sundhedssektoren vil der være særlige use-cases, der skal understøttes for at opnå en god slutbrugeroplevelse, bl.a. grundet den udbredte brug af fælles pc’er, der er logget ind med en fælles konto. Anvendelse af fælles konti vil ikke være acceptabelt under NSIS.
NSIS beskriver ikke direkte, hvilken lifetime en SAML-billet kan tillades at have, men PwC har antaget, at lifetime maksimalt bør være en time – og ideelt set kun med gyldighed for den igangværende session.
Rent teknisk er AAL-værdien den sværeste at håndtere, da der ikke findes en AAL-værdi, som bringes med rundt i fx et Windows-økosystem sammen med brugerens gøren og laden. På Windows-platformen er det en Kerberos-billet, som giver brugeren autentifikation (og autorisation) til at udføre opgaver i Windows-miljøet og eventuelle andre miljøer, der ligeledes anvender Kerberos.
Ved login på en Windows-platform vil det være den såkaldte authentication provider, der afgør, hvilket identifikationsmiddel, der bliver anvendt ved login. Hvert identifikationsmiddel har hver sin egen authentication provider. Dermed vil man kunne skelne mellem et login, der er foretaget med brugernavn/password (og en AAL = lav), og fx et login, der anvender en pinkode i kombination med et smartcard. (Forventet AAL = betydelig / høj).
Selve fødereringskomponenten, kaldet identity provider (IdP), vil være den komponent, der er ansvarlig for at udstede identiteten imod en offentlig eller privat tjenesteudbyder.
De sikringselementer, der er omtalt i NSIS-standarden, omhandler primært, hvordan it-sikkerheden er implementeret i forhold til selve IdP-komponenten, og det vil således være it-sikkerheden, der primært vil være genstand for den it-revision, der skal fastsætte FAL-niveauet.
For at IdP’en dynamisk kan beregne LOA-værdien på baggrund af MIN [IAL, AAL, FAL)], vil det være revisors opgave at stemple FAL-niveauet i en fil eller lignende, hvorfra værdien kan læses til den dynamiske beregning.
Såfremt der anvendes en enterprise access manager-løsning som IdP, vil det være muligt at beskytte FAL-værdien på forskellige måder, således at integriteten af værdien kan dokumenteres over tid.
Som nævnt i afsnittet herover, skal der være en komponent, der kan beregne LOA-værdien dynamisk og stemple denne værdi i den dynamiske SAML-token.
Såfremt virksomheden anvender en enterprise access manager-løsning som IdP, vil opsætningen af denne kunne definere et regelsæt, der dynamisk trækker på de relevante informationer og stempler den korrekte dynamiske LOA-værdi i SAML-billetten.
Denne artikel er udarbejdet alene som en generel orientering om forhold, som måtte være af interesse, og gør det ikke ud for professionel rådgivning. Du bør ikke disponere på baggrund af de oplysninger, der er indeholdt i denne publikation, uden at indhente specifik professionel rådgivning. Vi afgiver ingen erklæringer eller garantier (udtrykkeligt eller underforstået) hvad angår nøjagtigheden og fuldstændigheden af de oplysninger, der findes i publikationen, og, i det omfang loven tillader, accepterer eller påtager PricewaterhouseCoopers Statsautoriseret Revisionspartnerselskab, dets aktionærer, medarbejdere og repræsentanter sig ikke nogen forpligtelse, ansvar eller agtpågivenhedspligt for eventuelle konsekvenser, som følger af, at du eller andre handler eller undlader at handle i tillid til de oplysninger, der findes i publikationen, eller for eventuelle beslutninger truffet på baggrund af publikationen.
William Sharp
NIS direktivet regulerer virksomheder og myndigheder på cyber- og informationssikkerhedsområdet. Direktivet bliver udmøntet i nationale bekendtgørelser og fungerer som bindende lov, hvilket betyder, at din organisation vil skulle efterleve kravene i bekendtgørelsen.
NIS2-direktivet udvider kravene og sanktioneringen af cybersikkerhed for at harmonisere og strømline sikkerhedsniveauet på tværs af medlemslandene, og med skærpede krav for flere sektorer, betyder det, at din organisation skal forholde sig til blandt andet risikostyring, kontrol og tilsyn.
NIS2 udvider i væsentlig grad omfanget af organisationer, og skelner mellem ”essentielle entiteter” og ”vigtige entiteter” (se samtlige sektorer i tabel nedenfor).
Omfanget af sektorer udvides (se samtlige sektorer i tabel nedenfor), da Kommissionen ønsker at dække alle organisationer, der varetager vigtige funktioner i samfundet. Det betyder altså, at NIS2 også vil gælde for sektorer som fødevareproduktion, affaldshåndtering og hele forsyningskæden.
I energisektoren har omfanget eksempelvis været begrænset til virksomheder, der producerer, forsyner eller balancerer energi i el- og naturgassektoren. I NIS2 forventer vi, at forsyningskæden, fx vindmølleproducenter, ligeledes bliver omfattet af kravene, da direktivet forsøger at sikre en 360 graders harmonisering af cybersikkerhed.
NIS2-direktivets skærpede krav til cybersikkerhed omfatter også offentlige myndigheder - læs mere her.
NIS2-direktivet stiller både krav til ledelse, risikostyring, forretningskontinuitet og rapportering til myndighederne:
Med implementeringen af NIS2-direktivet skal myndighederne udvide tilsynet både i dybden og bredden. I dybden, fordi tilsynsmyndigheder er forpligtet til at håndhæve kravene i direktivet, og i bredden, fordi omfanget af direktivet er udvidet til at gælde flere sektorer.
Essentielle entiteter kan forvente løbende tilsyn såsom revisioner, rapportering og peer reviews, mens vigtige entiteter kan forvente tilsyn, tvungne revisioner og rapportering, hvis der er mistanke om, at organisationen ikke lever op til kravene.
Mulighed for sanktionering omfatter bl.a. bøder, tvungne revisioner, sanktionering af ledelse mv.
Se eller gense webcasten, hvor PwC's eksperter går i dybden med, hvordan CFO'en og direktionen skal forholde sig til efterlevelse af NIS2-direktivet, der regulerer de driftskritiske aktiver i jeres organisation. Du får overblik over de væsentligste elementer i NIS2, samt hvordan du finder ud af, om jeres organisation er omfattet af direktivet, og hvordan I sikrer jer, at I efterlever kravene.
Playback of this video is not currently available
Konkret kan vi hjælpe med:
Har I brug for hjælp, er I velkomne til at kontakte PwC’s Technology & Security-afdeling.
PwC’s Cyberteam er en del af PwC’s Technology & Security-afdeling, som tæller op mod 200 konsulenter. Vi har derfor adgang til en lang række specialister inden for bl.a. cyber- og informationssikkerhed og kan bistå med rådgivning og vejledning – fra juridisk og forretningsmæssig rådgivning til teknisk rådgivning.
PwC er en del af et bredt NIS2-netværk på tværs af EMEA, der består af 150 erfarne fagfolk inden for cybersikkerhed, risikostyring, incident response, governance, compliance og jura. Dette netværk er blevet etableret for at kunne give vores kunder den bedst mulige rådgivning om kravene i NIS2-direktivet.
Vi hjælper med at forstå regulativet, og hvad det har af betydning for din virksomhed eller organisation, herunder at identificere, hvor I allerede opfylder kravene, og undersøge, hvor der er behov for indsats. Vi støtter jer desuden på bedst mulig måde i at igangsætte tiltag, så I overholder de lovgivningsmæssige krav, der stilles – både lokalt og på EU-plan.
Hvis I vil vide mere, er I velkommen til at kontakte os.
Vær på forkant med nye tiltag og tendenser i erhvervslivet. Du bliver også inviteret til agendasættende events, hvor vi sammen får ny viden, perspektiver og relationer.
Seneste publikationer, analyser og undersøgelser om emner som skat, regnskab, IFRS, revision, moms, told og afgifter.