Implementatiemaatregel

Volgend minimale validatie van de identiteit MOET worden toegepast bij het beheer van identiteiten:

• Standaard gebruikersaccounts: sterke identiteit vereist;

• Niet-standaard gebruikersaccounts:

  • Voor een account die toegang geeft tot een systeem met data van Informatieklasse 1 (integriteit en vertrouwelijkheid): geen identiteit vereist.

  • Voor een account die toegang geeft tot een systeem met data van Informatieklasse 2 (integriteit en vertrouwelijkheid): zwakke identiteit voldoende.

  • Voor een account die toegang geeft tot een systeem met data van Informatieklasse 3 en hoger (integriteit en vertrouwelijkheid): sterke identiteit vereist.

• Gedeelde gebruikersaccounts en gast accounts: geen identiteit vereist;

• Superuser accounts: geen identiteit vereist (accounts worden automatisch aangemaakt bij opzet van een systeem);

• Persoonlijk beheersaccounts:  sterke identiteit vereist;

• Niet-interactieve accounts: geen identiteit vereist.

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor de registratie, het wijzigen en het verwijderen van identiteiten. Dit proces MOET voldoen aan volgende richtlijnen:

• Identiteiten MOETEN worden geregistreerd in een centraal systeem;

• Elke fysieke persoon die toegang nodig heeft tot een systeem MOET een unieke identiteit krijgen voor alle systemen;

• Een fysieke persoon MAG slechts één enkele identiteit hebben;

• Het beheer van identiteiten MOET gebeuren door geautoriseerde personen binnen of namens de organisatie;

• Er MOET een periodieke controle worden uitgevoerd om na te gaan of een identiteit nog noodzakelijk is;

• Het aanmaken, wijzigen of verwijderen van identiteiten MOET worden gelogd.

Implementatiemaatregel

Het creëren van standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

• Accounts MOETEN worden aangemaakt voor en toegewezen aan natuurlijke personen (individuen) die voor of namens de organisatie werken (intern personeel en contractanten) om dagelijkse taken uit te voeren;

• Elke gebruiker MOET kunnen worden geïdentificeerd door een unieke identiteit, dit MOET een sterke identiteit zijn;

• Aan één en dezelfde medewerker MAG SLECHTS ÉÉN enkele account worden toegekend;

• Elke account MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen,

• Aan elke account is een verantwoordelijke toegewezen verschillend van de gebruiker (bijvoorbeeld leidinggevende) als back-up.

Implementatiemaatregel

De-activatie en verwijderen van standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

• Bij einde dienstverband van een medewerker, MOET de account binnen de 24 uur worden gedeactiveerd (d.w.z onbeschikbaar gemaakt worden om te gebruiken);

• Accounts die niet worden gebruikt MOETEN worden gedeactiveerd na 13 maanden inactiviteit;

• Accounts die werden gedeactiveerd MOETEN permanent worden ingetrokken na 24 maanden inactiviteit;

• Permanent ingetrokken gebruikersaccounts MOGEN NIET opnieuw worden uitgegeven;

• Er MOET een specifieke procedure worden voorzien om “urgente uitdiensttreding” te behandelen, waarbij een account ONMIDDELLIJK wordt gedeactiveerd;

• Waar mogelijk MOET worden ingesteld dat accounts automatisch verlopen op een gedefinieerde datum:

  • Wanneer tijdelijke toegang nodig is, MOETEN accounts onmiddellijk worden gedeactiveerd nadat de gebruiker de taak heeft voltooid waarvoor de toegang was verleend,

  • Accounts toegewezen aan contractanten MOETEN worden ingesteld op basis van de vervaldatum van het contract;

  • Accounts die aangemaakt worden op basis van ondertekende contracten voor een terugkerende taak MOETEN worden telkens geactiveerd voor de duur van hun geplande interventies en worden tussentijds gedeactiveerd.

Implementatiemaatregel

Het creëren van niet-standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

• Accounts MOETEN worden aangemaakt voor en toegewezen aan natuurlijke personen (individuen) die voor of namens de organisatie werken (intern personeel en contractanten) om dagelijkse taken uit te voeren;

• Elke gebruiker MOET kunnen worden geïdentificeerd door een unieke identiteit, dit MOET een sterke identiteit zijn voor systemen die data bevatten met Informatieklasse 3 en hoger;

• Aan één en dezelfde medewerker MAG SLECHTS ÉÉN enkele account worden toegekend per systeem;

• Elke account MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen.

Implementatiemaatregel

De-activatie en verwijderen van niet-standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

• Bij einde dienstverband van een medewerker, MOET de account binnen de 24 uur worden gedeactiveerd (d.w.z onbeschikbaar gemaakt worden om te gebruiken);

• Accounts die niet worden gebruikt MOETEN worden gedeactiveerd na 13 maanden inactiviteit;

• Accounts die werden gedeactiveerd MOETEN permanent worden ingetrokken na 24 maanden inactiviteit;

• Permanent ingetrokken gebruikersaccounts MOGEN NIET opnieuw worden uitgegeven;

Implementatiemaatregel

Het gebruik van gedeelde gebruikersaccounts MAG NIET, als dit in uitzonderlijke gevallen toch noodzakelijk is, MOET dit aan volgende voorwaarde voldoen:

• Motivering voor de uitzondering MOET worden geregistreerd en MOET formeel worden goedgekeurd door een directielid;

• Het gebruik van gedeelde gebruikersaccounts MOET worden gemonitord, inclusief de registratie van het tijdstip van toegang, de reden voor het gebruik van het gedeelde gebruikersaccount en de persoon het account gebruikt;

• Gedeelde gebruikersaccounts MOGEN NIET gebruikt worden voor systeembeheer en andere kritieke functies.

Implementatiemaatregel

Het gebruik van gast accounts MOET aan volgende voorwaarde voldoen:

• Gebruik van een gast account MOET worden geregistreerd en MOET formeel worden goedgekeurd door een directielid;

• Gast accounts MOGEN ENKEL leesrechten hebben op publieke data van Informatieklasse 1 en geen andere toegangsrechten.

Implementatiemaatregel

Het gebruik van superuser accounts MOET aan volgende voorwaarde voldoen:

• Het initiële paswoord van een superuser account MOET ONMIDDELLIJK worden veranderd bij de installatie van een systeem door een paswoord dat enkel gekend is door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats.

• Superuser accounts MOGEN ENKEL worden gebruikt voor de initiële installatie van een systeem en bij noodgevallen;

• Superuser accounts MOGEN NIET worden gebruikt voor de normale beheerstaken aan een systeem, hiervoor MOETEN beheersaccounts worden aangemaakt.

Implementatiemaatregel

Beheersaccounts MOETEN voldoen aan dezelfde implementatiemaatregelen als standaard gebruikersaccounts.

Een medewerker die beheerstaken uitvoert MOET een een beheersaccount gebruiken en niet zijn standaard gebruikers account. Een beheer account MOET gescheiden zijn van de standaard gebruikersaccount en alleen worden gebruikt wanneer de beheerstaken vereist zijn.

Een beheersaccount MAG worden afgeleid uit een superuser account (die alle privileges heeft), maar bij voorkeur worden beheersaccounts voor complexe systemen opgesplitst naargelang het type privileges, zoals bijvoorbeeld aparte beheersaccounts voor:

• Het nemen van back-ups;

• Het creëren van accounts en toekennen van toegangsrechten;

• Het onderhouden van systeem software;

• Etc.

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor de creatie, het wijzigen en het verwijderen van beheersaccounts dat MOET voldoen aan volgende richtlijnen:

• Een beheersaccount kan enkel worden aangevraagd door een leidinggevende en MOET expliciet worden goedgekeurd;

• Een beheersaccount MOET worden toegewezen aan een individuele medewerker en MOET worden verstrekt met sterke identificatie;

• Het gebruik van beheersaccounts MOET strikt individueel zijn en NOOIT gedeeld; indien meerdere medewerkers beheerstaken op een zelfde systeem dienen uit te voeren MOETEN zij elk een aparte beheersaccount gebruiken;

• Het aantal beheersaccounts per systeem MOET tot een minimum beperkt worden;

• De lijst met beheersaccounts per systeem MOET minstens jaarlijks worden herzien en niet gebruikte accounts MOETEN verwijderd worden;

• Er MOET een actieve logging, opvolging en periodieke rapportering van de activiteiten die door een beheersaccount worden uitgevoerd, opgezet worden.

Implementatiemaatregel

Wanneer per uitzondering beheersaccounts dienen toegekend te worden aan niet-medewerkers zoals leveranciers (bijvoorbeeld omwille van onderhoudsactiviteiten) dan MOET dit bijkomend voldoen aan de volgende richtlijnen:

• Accounts MOETEN worden telkens geactiveerd voor de duur van hun geplande interventies en worden tussentijds gedeactiveerd;

• Elke gebruik MOET worden gelogd en nagekeken worden door een leidinggevende ONMIDDELLIJK na het gebruik.

Implementatiemaatregel

Er MOET een formeel en goed gedocumenteerd proces bestaan voor de creatie, het wijzigen en het verwijderen van technische accounts, dat MOET voldoen aan de volgende vereisten:

• Het doel van elk technisch account, de verantwoordelijke persoon en de systemen of diensten die het account gebruikt MOETEN gedocumenteerd worden;

• Elk technisch account MOET uniek zijn voor zijn specifieke functie;

• Het paswoord van een technische account MAG ENKEL gekend zijn door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats;

• Technische accounts die in productieomgevingen worden gebruikt MOETEN gescheiden worden van accounts in de ontwikkelings- en testomgevingen;

• Standaard ingebouwde (built-in) accounts MOETEN, indien mogelijk, worden uitgeschakeld of hernoemd.

• Technische accounts MOETEN de levenscyclus van de systemen of diensten die er gebruik van maken volgen en MOETEN worden verwijderd wanneer deze niet langer nodig zijn.

Implementatiemaatregel

Volgend minimaal authenticatieniveau MOET worden toegepast:

• Hoog

  • Alle externe toegang (komende van buiten de netwerkperimeter van Digitaal Vlaanderen)

  • Alle interne toegang door beheersaccounts

  • Alle interne toegang tot informatieklasse 5

• Substantieel

  • Alle interne toegang tot informatieklasse 3 en 4

• Zwak

  • Alle interne toegang tot informatieklasse 2

  • Toegang door technische accounts, gedeelde accounts en andere gevallen niet beschreven hierboven, mits bijkomende maatregelen

Elk authenticatiemechanisme dat op zijn minst geen gebruik maakt van een unieke gebruikersaccount en wachtwoord MOET formeel worden goedgekeurd.

Implementatiemaatregel

Single sign-on MOET verlopen via het standaard gebruikersaccount.

Single sign-on MAG worden toegepast voor toegang tot en met informatieklasse 3.

Voor toegang tot informatieklasse 4 MAG single sign-on ENKEL gebruikt worden binnen het interne netwerk.

Single sign-on MAG NIET gebruikt worden voor toegang tot informatieklasse 5.

Implementatiemaatregel

Het gebruik van technische accounts MOET voldoen aan volgende richtlijnen:

• Het gebruik van een technische account dient bij voorkeur te gebeuren via een Privileged Access Management (PAM) oplossing;

• Wachtwoorden dienen automatisch te worden gegenereerd via een PAM oplossing of wachtwoordbeheeroplossing;

• Wachtwoorden moeten complex zijn, bestaande uit ten minste 50 karakters;

• Na elk gebruik van een technisch account of ten minste jaarlijks moet automatisch een nieuw wachtwoord worden gegenereerd;

• De uitzonderingen waarbij de wachtwoorden van technische accounts niet via een PAM oplossing worden beheerd (bijvoorbeeld in kader van disaster recovery procedures) moeten formeel worden goedgekeurd.

Implementatiemaatregel

Elke inlogprocedure MOET voldoen aan volgende minimale vereisten:

• Inloggegevens enkel valideren als deze volledig zijn ingevoerd;

• Het ingevoerde wachtwoord niet permanent weergeven wanneer het wordt ingevoerd (bv. sterretjes dienen te worden weergegeven wanneer een gebruiker een wachtwoord invoert);

• Niet aangeven welk deel van de inloggevens (gebruikersnaam of wachtwoord) correct of onjuist is. Als een onjuist of onvolledig wachtwoord wordt ingevuld, dient in het feedback foutbericht, bv. vermeld te worden "gebruikersnaam of wachtwoord is ongeldig";

• Geen legitieme gebruikersaccount weergeven totdat de inlogprocedure met succes is voltooid;

• Geen helpberichten verstrekken tijdens de inlogprocedure die een niet-geautoriseerde gebruiker zouden helpen;

• Het aantal mislukte inlogpogingen beperken tot maximaal 10;

• Na 10 opeenvolgende mislukte inlogpogingen een wachttijd instellen van minimaal 30 minuten vooraleer een nieuwe inlogpoging kan worden ondernomen

Implementatiemaatregel

Sessie -en schermvergrendeling MOET voldoen aan volgende minimale vereisten:

• Informatiesystemen worden geconfigureerd om sessies automatisch te vergrendelen na een periode van inactiviteit van maximum vijftien (15) minuten.

• Applicaties worden geconfigureerd om sessies automatisch te beëindigen na een periode van inactiviteit van maximum acht (8) uur.

Implementatiemaatregel

De organisatie MOET zorgen dat gebruikers bewust zijn van hun verantwoordelijkheden mbt het veilig omspringen met inloggegevens, deze richtlijnen moeten volgende aspecten omvatten:

• Een wachtwoord is altijd persoonlijk, het delen van een wachtwoord met iemand anders mag niet.

• Wachtwoorden mogen niet via een communicatiekanaal worden verspreid (bijvoorbeeld mondelinge, schriftelijke of elektronische distributie, enz.)

• Wachtwoorden mogen niet worden opgeschreven, tenzij via een veilige methode die formeel is goedgekeurd.

• Wachtwoorden mogen niet worden opgeslagen in een geautomatiseerd aanmeldingssysteem (bijvoorbeeld macro of browser), tenzij via een door de organisatie gevalideerde oplossing.

• Wachtwoorden moeten onmiddellijk worden gewijzigd als er aanwijzingen zijn dat deze gecompromitteerd kunnen zijn, in dat geval moeten ook een beveiligingsincident worden gemeld.

• Het gebruiken van hetzelfde wachtwoorden voor privédoeleinden en zakelijke doeleinden dient vermeden te worden.

Implementatiemaatregel

De volgende complexiteitsregels MOETEN technisch worden afgedwongen:

• Het wachtwoord moet:

  • ten minste 12 karakters bevatten

  • hoofdletter(s) bevatten

  • kleine letter(s) bevatten

  • cijfer(s) bevatten

  • speciaal karakter(s) bevatten !\"#$%&'()*+-,./:;<=>?@[]\^`{}|~_

• Het wachtwoord mag geen woordenboekwoord, dialecttaal of jargonwoord uit welke taal dan ook zijn, of een van deze woorden die achterstevoren worden geschreven.

• Wachtwoorden mogen niet gebaseerd zijn op persoonsgegevens (bijv. geboortedatum, adres, naam van familielid, enz.)

• De laatste drie wachtwoorden mogen niet opnieuw worden gebruikt

• Wachtwoorden dienen na 6 maanden automatisch te vervallen

Indien het systeem niet kan worden geconfigureerd om complexiteitsregel technisch af te dwingen, MOET controle op een procesmatige manier gebeuren.

Implementatiemaatregel

Technische maatregelen MOETEN voldoen aan volgende minimale vereiste:

• Informatiesystemen dienen wachtwoordvelden te maskeren of op een andere manier te verbergen om het tonen of afdrukken van wachtwoorden te voorkomen.

• Systeembeheerders dienen ervoor te zorgen dat informatiesystemen de wachtwoorden bij opslag en verzending beschermen tegen openbaarmaking en wijziging, onder meer door het toepassen van passende cryptografische technieken(zie Cryptografie)

  • Cryptografische hash-algoritmen om wachtwoorden in clear tekst te verbergen en brute force-aanvallen te weerstaan.

  • Salting-methoden om ervoor te zorgen dat elk wachtwoord uniek is om aanvallen met regenboogtafels te weerstaan.

• Wachtwoorden dienen apart van de applicatiedata te worden bewaard.

• Gebruikers moeten de mogelijkheid hebben om hun eigen wachtwoord te kiezen en te wijzigen.

• Zowel succesvolle als mislukte inlogpogingen dienen geregistreerd te worden.

Implementatiemaatregel

Het proces voor het toekennen van een nieuw of gewijzigd wachtwoord MOET volgende aspecten omvatten:

• Alvorens initiële wachtwoorden uit te geven of een nieuw wachtwoord te verlenen voor systemen die geen self-service wachtwoord resetfunctionaliteit hebben, moeten een verificatie van de identiteit van de gebruiker worden uitgevoerd.

• Bij het aanmaken van nieuwe gebruikersaccounts moeten de initiële wachtwoorden willekeurig worden ingesteld met behulp van een wachtwoordgenerator. Het initiële wachtwoord mag niet via hetzelfde kanaal gecommuniceerd worden als het kanaal dat wordt gebruikt voor het communiceren van de gebruikersaccount.

• Het geresette wachtwoord moet aan de complexiteitsregels voldoen en mag niet hergebruikt worden.

• Het tijdelijk of initieel toegekende wachtwoord van een gebruiker moet gewijzigd worden bij de eerste aanmelding op een systeem.

Implementatiemaatregel

Bij het bepalen van de toegang van gebruikers of applicaties tot informatie en informatiesystemen MOETEN volgende basisprincipes worden toegepast:

• Need to Know: Toegang tot gevoelige informatie of systemen moet beperkt blijven tot degenen die deze echt nodig hebben, en dit mogelijk slechts voor een bepaalde tijd. Het is aan de eigenaar van de informatie om te bepalen wie toegang moet hebben, zowel voor het lezen als het wijzigen van de informatie, en voor hoe lang deze toegang vereist is.

• Least Privilege: Gebruikers, processen of applicaties dienen enkel over de minimale rechten te beschikken die noodzakelijk zijn voor het uitvoeren van hun specifieke taken of functies.

• Scheiding van Taken: Taken zoals het aanmaken van gebruikersaccounts en het toewijzen van bevoegdheden moeten door verschillende individuen worden uitgevoerd om belangenconflicten en misbruik te voorkomen. In situaties waar scheiding van taken niet haalbaar is, moeten compenserende maatregelen zoals activiteitenmonitoring, evaluatie van audit trails en strikt managementtoezicht worden ingevoerd om de integriteit van het proces te waarborgen.

Implementatiemaatregel

Het gebruik van Role-Based Access Control (RBAC) is AANGEWEZEN waarbij:

• Het verlenen, wijzigen of intrekken van toegangsrechten aan een gebruiker gebeurt op basis van de toegekende rollen.

• Er een centraal en actueel overzicht dient te zijn van de relatie tussen gebruikers, rollen en toegangsrechten.

• Het toekennen, wijzigen of intrekken van rollen aan een gebruiker gebeurt vanuit een centrale betrouwbare bron.

Implementatiemaatregel

Er MOET een formele aanvraagprocedure zijn voor het verlenen, wijzigen of intrekken van toegangsrechten.

Alle aanvragen MOETEN in een centraal systeem worden gelogd.

Volgende attributen MOETEN aanwezig zijn om een auditeerbaar proces te garanderen:

• Basis attributen van het verzoek tot toegang (Datum, tijd, aanvrager, volgnummer, …)

• Onderwerp, als referentie naar het individu die de toegang wenst te gebruiken.

• Motivatie van het verzoek

• Bevestiging van motivatie

• Basis attributen van de validatie van de toegang (Datum, tijd, …)

• Identiteit van de persoon die de goedkeuring(en) geeft.

• (Optioneel: bijkomende opmerkingen)

• Vervaldag van het toegangsrecht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing

• Periodiek herhaalde (her)validatie van een recht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing

Implementatiemaatregel

Toegangsrechten MOGEN pas worden verleend na het voltooien van een validatieprocedure.

Deze procedure MOET consequent het principe van scheiding van taken hanteren, waarbij zelf-autorisatie van een aanvraag niet is toegestaan.

De validatieprocedure MOET afhankelijk zijn naargelang de informatieklasse.

• Informatieklasse 4: Validatie met goedkeuring van een door de organisatie geautoriseerd tweede persoon.
  Voorbeeld: Lokale beheerder doet de registratie en deze wordt gevalideerd door de leidinggevende of de toepassingsbeheerder.

• Informatieklasse 5: Validatie met goedkeuring van door twee door de organisatie geautoriseerde personen, waarvan minimaal één zonder hiërarchische of functionele relatie met de aanvrager.
  Voorbeeld: Lokale beheerder doet de registratie en deze wordt gevalideerd door de leidinggevende of de toepassingsbeheerder, waarna de veiligheidscoördinator de finale validatie bevestigd.

Implementatiemaatregel

• Rollen en de hieraan toegewezen machtigingen MOETEN jaarlijks worden herzien. (Soll)

• De toegewezen rollen of bijkomende toegangsrechten MOETEN periodiek worden herzien naargelang de informatieklasse. (Ist)

  • Informatieklasse 1 en 2: minstens 1 keer per jaar

  • Informatieklasse 3 en 4: minstens 2 keer per jaar

  • Informatieklasse 5: minstens 4 keer per jaar

Ist-Soll-model

Bij de herziening van toegangsrechten verwijst men vaak naar het Ist-Soll-model, dit is een concept waarbij de huidige toestand (Ist) van een proces, systeem of toepassing wordt vergeleken met de gewenste, toekomstige toestand (Soll). In de context van autorisatie en toegangsbeheer betekent dit:

• Ist (Huidige Toestand): Dit vertegenwoordigt de actuele situatie van toegangsrechten binnen een systeem of toepassing. Het omvat welke gebruikers momenteel toegang hebben tot bepaalde informatie of informatiesystemen en hoe deze toegangsrechten zijn geconfigureerd.
  De Ist-oefening dient regelmatig te worden uitgevoerd om tekortkomingen in de toegangsbeheerprocessen te identificeren en te corrigeren. Naarmate de informatieklasse van de te toepassing dient deze oefening frequenter te worden uitgevoerd.

• Soll (Gewenste Toestand): Dit is de documentatie van de gewenste configuratie van toegangsrechten. Het biedt een overzicht van welke rollen toegang zouden moeten hebben tot welke functionaliteiten of welke stappen in een deelproces in de toepassing, of het systeem. De Soll-toestand weerspiegelt hoe toegangsrechten zouden moeten zijn ingericht om optimale beveiliging en efficiëntie te waarborgen.
  De Soll-oefening dient grondig te worden uitgevoerd, omdat deze de basis vormt voor de Ist-oefening en het toegangsbeheerbeleid van je toepassing.

Door het Ist-Soll-model te gebruiken, kan de organisatie discrepanties tussen de huidige en gewenste toegangsrechten identificeren en de nodige aanpassingen maken.

Implementatiemaatregel

Volgende implementatieniveaus van PAM, die een toenemende mate van veiligheid en controle bieden, MOETEN worden gehanteerd, op basis van het toepassingsniveau.

Basis niveau

Toepassingscriteria:

• Tot en met Informatieklasse 3 (Vertrouwelijkheid en Integriteit).

• Niet geschikt voor persoonsgegevens.

• Handmatige processen zijn mogelijk zonder afname van PAMaaS.

Implementatievereiste:

• Toegangsbeheer

  • Sterke identificatie van de PAM-gebruiker.

  • Sterke authenticatie voor operationele activiteiten.

  • Elke toegang is geautoriseerd door de toegangsbeheerder met minstens jaarlijkse validatie van toegangsrechten door de toepassingseigenaar.

  • Permanente, gemonitorde toegang tot het beheer account waarmee gepriviligeerde toegangen worden verworven.

• Change, configuratie en release management

  • Motivatie van de gebruiker om toegang te krijgen is niet verplicht. Er is geen verplichte integratie van change managementinformatie

• Audit

  • Auditeerbaarheid is gebaseerd op documentatie en punctuele ad hoc audits van zowel de operationele processen als de informatie verwerkende configuraties.

Middelste niveau

Toepassingscriteria:

• Tot en met Informatieklasse 4 (Vertrouwelijkheid en Integriteit).

• Persoonsgegevens tot en met Informatieklasse 3 (Vertrouwelijkheid).

• Automatisering van PAM is verplicht, afname van PAMaaS is optioneel.

Implementatievereiste:

• Toegangsbeheer

  • Sterke identificatie van de PAM-gebruiker.

  • Sterke authenticatie voor operationele activiteiten.

  • Elke toegang is geautoriseerd door de toegangsbeheerder met minstens jaarlijkse validatie van toegangsrechten door de toepassingseigenaar.

  • Permanente, gemonitorde en gemotiveerde toegang tot het beheer account waarmee geprivilegieerde toegangen worden verworven.

  • Alle activiteiten tijdens de uitvoering van de geprivilegieerde toegang worden geregistreerd. Session recording, ook manueel, maakt dat de activiteiten in real-time en uitgesteld kunnen bekeken worden.

• Change, configuratie en release management

  • Er gebeurt een verplichte validatie van de motivatie van de gebruiker. 

  • Er is geen dubbele controle van de toegang op voorhand noodzakelijk. Periodieke controle gebeurt ‘post-mortem’ op basis van correlatie van logs die voortkomen uit de processen Change en Release Management en de logs van PAM zelf. (in PAMaaS is dit een standaard rapportage)

• Audit

  • Auditeerbaarheid is gebaseerd op volgende risicorapportering 

    • Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change)

    • Pre-approved changes en operationele activiteiten (Changes) met een maximale duurtijd tot één jaar zijn toegestaan voor operationele teams

  • Periodieke risicorapportering dekt zowel de operationele processen als de informatie verwerkende configuratie

    • Alle activiteiten van de gebruiker van het PAM-proces worden geregistreerd. Dit is de implementatie van het controleprincipe op basis van manueel logboek registratie of geautomatiseerde session recording in combinatie met de log informatie

Hoogste niveau

Toepassingscriteria:

• Tot en met Informatieklasse 5 (Vertrouwelijkheid en Integriteit).

• Persoonsgegevens tot en met Informatieklasse 4 (Vertrouwelijkheid).

Implementatievereiste:

• Toegangsbeheer

  • Sterke identificatie van de PAM-gebruiker.

  • Sterke authenticatie voor operationele activiteiten.

  • Elke toegang is geautoriseerd door de toegangsbeheerder op basis van functionele noodzaak (bvb. Interventie in kader van een incident).

  • Er is geen permanente toegang tot het account met privileged toegangen binnen de informatieverwerking.

  • Permanente, gemonitorde en gemotiveerde toegang tot het beheer account waarmee geprivilegieerde toegangen worden verworven.

  • Alle activiteiten tijdens de uitvoering van de geprivilegieerde toegang worden geregistreerd. Session recording, ook manueel, maakt dat de activiteiten in real-time en uitgesteld kunnen bekeken worden.

• Change, configuratie en release management

  • Er gebeurt een verplichte validatie van de motivatie van de gebruiker. 

  • Er is geen dubbele controle van de toegang op voorhand noodzakelijk. Periodieke controle gebeurt ‘post-mortem’ op basis van correlatie van logs die voortkomen uit de processen Change en Release Management en de logs van PAM zelf. (In PAMaaS is dit een standaard rapportage)

• Audit

  • Auditeerbaarheid is gebaseerd op volgende risicorapportering 

    • Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change)

    • Pre-approved changes en operationele activiteiten (Changes) zijn beperkt tot de reële functionele duurtijd van de activiteiten

  • Periodieke risicorapportering dekt zowel de operationele processen als de informatie verwerkende configuratie

    • Alle activiteiten van de gebruiker van het PAM-proces worden geregistreerd. Dit is de implementatie van het 4EYES principe op basis van manueel logboek registratie of geautomatiseerde session recording in combinatie met de log informatie