ISO 27002:2022- Controle 5.16 – Identiteitsbeheer

Wat is het doel van controle 5.16?

5.16 gaat over het vermogen van een organisatie om te identificeren wie (gebruikers, groepen gebruikers) of wat (applicaties, systemen en apparaten) op een bepaald moment toegang heeft tot gegevens of IT-middelen, en hoe aan deze identiteiten toegangsrechten worden verleend binnen het netwerk.

5.16 is een preventieve controle die houdt het risico in stand door op te treden als de belangrijkste perimeter voor alle betrokkenen informatiebeveiliging en cybersecurity operationele activiteiten, evenals het beheer van de primaire modus dat het identiteits- en toegangsbeheerframework van een organisatie dicteert.

Kenmerken van controle 5.16

Eigendom

Aangezien 5.16 in de eerste plaats een onderhoudsfunctie vervult, moet het eigendom worden overgedragen aan IT-personeel aan wie Global Administrator-rechten zijn toegewezen (of gelijkwaardig voor niet-Windows-gebaseerde infrastructuur).

Hoewel er andere ingebouwde rollen zijn waarmee gebruikers identiteiten kunnen beheren (bijvoorbeeld domeinbeheerder), moet het eigendom van 5.16 berusten bij de persoon die de uiteindelijke zeggenschap heeft. verantwoordelijkheid voor het gehele netwerk van een organisatie, inclusief alle subdomeinen en Active Directory-tenants.

Algemene richtlijnen

Naleving van controle 5.16 wordt bereikt door een combinatie van het waarborgen dat op identiteit gebaseerde procedures duidelijk worden verwoord in beleidsdocumenten, en het monitoren van de dagelijkse naleving door het personeel.

5.16 somt zes hoofdprocedures op die een organisatie moet volgen om te voldoen aan de vereiste normen op het gebied van infosec en cyberbeveiligingsbeheer:

• Wanneer identiteiten aan een persoon worden toegewezen, mag alleen die specifieke persoon zich authenticeren met die identiteit en/of deze gebruiken bij toegang tot netwerkbronnen.

Conformiteit – Het IT-beleid moet duidelijk bepalen dat gebruikers geen inloggegevens mogen delen, en dat andere gebruikers niet op het netwerk mogen rondzwerven met een andere identiteit dan de identiteit die aan hen is toegewezen.

• Soms kan het nodig zijn om aan meerdere personen een identiteit toe te kennen – ook wel een ‘gedeelde identiteit’ genoemd. Deze aanpak moet spaarzaam worden toegepast, en alleen om aan een expliciete reeks operationele vereisten te voldoen.

Conformiteit – Organisaties moeten de registratie van gedeelde identiteiten behandelen als een aparte procedure voor individuele gebruikersidentiteiten, met een speciale goedkeuringsworkflow.

• Zogenaamde 'niet-menselijke' entiteiten (zoals de naam al doet vermoeden, elke identiteit die niet aan een daadwerkelijke gebruiker is gekoppeld) moeten op het moment van registratie anders worden beschouwd dan op gebruikers gebaseerde identiteiten.

Conformiteit – Net als bij gedeelde identiteiten moeten niet-menselijke identiteiten op hun beurt hun eigen goedkeurings- en registratieproces hebben dat het onderliggende verschil erkent tussen het toekennen van een identiteit aan een persoon en het toekennen van een identiteit aan een asset, applicatie of apparaat.

• Identiteiten die niet langer nodig zijn (leavers, overtollige assets etc.) moeten door een netwerkbeheerder worden uitgeschakeld of geheel worden verwijderd, zoals vereist.

Conformiteit – IT-personeel zou dat moeten doen regelmatig audits uitvoeren die identiteiten opsommen in volgorde van gebruik, en identificeren welke entiteiten (menselijk of niet-menselijk) kunnen worden opgeschort of verwijderd. HR-personeel moet identiteitsbeheer opnemen in hun offboarding-procedures en het IT-personeel tijdig informeren over vertrekkers.

• Dubbele identiteiten moeten koste wat het kost worden vermeden. Bedrijven moeten zich over de hele linie aan de regel 'één entiteit, één identiteit' houden.

Conformiteit – IT-personeel moet waakzaam blijven bij het toewijzen van rollen binnen een netwerk en ervoor zorgen dat entiteiten geen toegangsrechten krijgen op basis van meerdere identiteiten.

• Er moeten adequate registraties worden bijgehouden van alle 'belangrijke gebeurtenissen' met betrekking tot identiteitsbeheer en authenticatie-informatie.

Conformiteit – De term 'belangrijke gebeurtenis' kan op verschillende manieren worden geïnterpreteerd, maar op een basaal niveau organisaties nodig hebben om ervoor te zorgen dat hun governance-procedures identiteitsregistratiedocumentatie, robuuste wijzigingsverzoekprotocollen met een passende goedkeuringsprocedure en de mogelijkheid omvatten om op elk gewenst moment een uitgebreide lijst van toegewezen identiteiten op te stellen.

Aanvullende begeleiding

Naast de zes belangrijkste operationele overwegingen worden in 5.16 ook vier stappen genoemd die organisaties moeten volgen bij het creëren van een identiteit en het verlenen ervan. toegang tot netwerkbronnen (het wijzigen of verwijderen van toegangsrechten wordt behandeld in controle 5.18):

• Opstellen van een businesscase voordat een identiteit wordt gecreëerd

Conformiteit – Het is belangrijk om te erkennen dat identiteitsbeheer exponentieel moeilijker wordt met elke nieuwe identiteit die wordt gecreëerd. Organisaties mogen alleen nieuwe identiteiten creëren als daar een duidelijke noodzaak voor is.

• Zorg ervoor dat de entiteit waaraan de identiteit wordt toegewezen (menselijk of niet-menselijk) onafhankelijk is geverifieerd.

Conformiteit – Zodra een business case is goedgekeurd, moeten de procedures voor identiteits- en toegangsbeheer stappen bevatten om ervoor te zorgen dat de persoon of het asset die een nieuwe identiteit ontvangt, over de vereiste bevoegdheid beschikt om dit te doen, voordat er een identiteit wordt gecreëerd.

• Het vaststellen van een identiteit

Zodra de entiteit is geverifieerd, moet het IT-personeel een identiteit creëren die in lijn is met de vereisten van de business case, en die beperkt is tot wat is vastgelegd in de documentatie van eventuele wijzigingsverzoeken.

• Definitieve configuratie en activering

De uiteindelijke stap in het proces met zich meebrengt het toewijzen van een identiteit aan de verschillende op toegang gebaseerde machtigingen en rollen (RBAC) en eventuele bijbehorende authenticatieservices die vereist zijn.

Wijzigingen ten opzichte van ISO 27002:2013

Snel naar

27002:2022 / 5.16 vervangt 27002:2013/9.2.1 (Gebruikersregistratie en -uitschrijving) – dat zelf deel uitmaakte van de User Access Management-controleset van 27002:2013. Hoewel er enkele overeenkomsten zijn tussen de twee controles – vooral in onderhoudsprotocollen en het deactiveren van redundante ID's – bevat 5.16 een veel uitgebreidere reeks richtlijnen die proberen identiteits- en toegangsbeheer als een end-to-end-concept aan te pakken.

Menselijke versus niet-menselijke identiteiten

Het belangrijkste verschil tussen de controle uit 2022 en de voorganger uit 2013 is de erkenning dat, hoewel er verschillen zijn in het registratieproces, menselijke en niet-menselijke identiteiten voor algemene netwerkbeheerdoeleinden niet langer als verschillend van elkaar worden behandeld.

Met de opkomst van modern identiteits- en toegangsbeheer en op Windows gebaseerde RBAC-protocollen spreken IT-governance en best practice-richtlijnen min of meer door elkaar over menselijke en niet-menselijke identiteiten. 27002:2013/9.2.1 bevat geen richtlijnen voor het beheren van niet-menselijke identiteiten, en houdt zich uitsluitend bezig met het beheer van wat het 'Gebruikers-ID's' noemt (dwz inloggegevens die worden gebruikt om toegang te krijgen tot een netwerk, samen met een wachtwoord).

Documentatie

Zoals we hebben gezien bevat 27002:2013/5.16 niet alleen expliciete richtlijnen over de algemene veiligheidsimplicaties van identiteitsbeheer, maar ook over de manier waarop organisaties informatie moeten vastleggen en verwerken voordat een identiteit wordt toegewezen, en gedurende de hele levenscyclus ervan. Ter vergelijking: 27002:2013/9.2.1 vermeldt slechts kort de begeleidende rol die IT-governance speelt, en beperkt zich tot de fysieke praktijk van identiteitsbeheer, zoals uitgevoerd door IT-personeel.

Nieuwe ISO 27002-controles