Vertrouwen is goed, controle is beter. Hoofdstuk 9. Taakgebied Security

Vertrouwen is goed, controle is beter.

Hoofdstuk 9

Taakgebied Security

V1.1 / 01 september 2015

MCTL – Taakgebied Security v1.1

Hoofdstuk 9 Taakgebied Security ...................................................... 3 Plaats in het MCTL-framework............................................................................................................ 3 Achtergrond ......................................................................................................................................... 4 Omschrijving gebruikte termen ........................................................................................................... 8 Doel van dit taakgebied ....................................................................................................................... 8 Hoe weet je dat het doel is bereikt? .................................................................................................... 9 Activiteiten ........................................................................................................................................... 9 1.

Uitgifte, wijziging en verwijderen van accounts ........................................................................................ 9

2.

Reset / deblokkering van een password .................................................................................................. 11

3.

Uitgifte van rollen en wijziging / intrekken van toegekende rollen ......................................................... 12

4.

Aanmaken van periodieke overzichten (security gerelateerd) ................................................................ 13

5.

Aanmaken van ad-hoc overzichten (security gerelateerd) ...................................................................... 15 Relaties met andere onderdelen van MCTL ..................................................................................... 16 Opmerkingen ..................................................................................................................................... 16

1.

Awareness ................................................................................................................................................ 17

2.

Koppeling beveiliging met HRM-systeem ................................................................................................ 17

3.

Externe audits .......................................................................................................................................... 17 Nuttige websites en boeken .............................................................................................................. 18

2014 - 2015 MCTL. Kennis is om te delen, niet om te bezitten. Overname met bronvermelding "www.mctl.nl" is daarom vrij.

Taakgebied Security V1.1

01-09-2015

Pagina 9-2


HOOFDSTUK 9 TAAKGEBIED SECURITY Security wordt alom gezien als een gebied dat de nodige aandacht vergt, met name op het operationele vlak. Deze operationele activiteiten worden in dit taakgebied beschreven. Wijzigingen in computertechnologie leiden soms tot consequenties op het gebied van security. Deze consequenties worden bij de wijziging zelf verwerkt en zijn binnen MCTL daarom te vinden binnen het taakcluster Change support. Ook indien een organisatie zelf besluit of vanwege externe bron wordt gedwongen om de security aan te passen, wordt dit in het taakcluster Change support verder (als wijziging) opgepakt. Het kan wel zo zijn dat dergelijke wijzigingen in het taakgebied dat in dit hoofdstuk wordt beschreven worden geïnitieerd. Binnen security als totaal vakgebied dient ook aandacht te zijn voor zaken als het veiligstellen van gegevens via back-ups, mirroring, dubbele locaties etc. Deze aspecten worden echter door de infrasupport en applicatie support en evt. leveranciers voor hun rekening genomen en worden in dit taakgebied daarom verder buiten beschouwing gelaten. De monitoring van bijv. het maken van backups is feitelijk monitoring van de operationele systeem en wordt in het taakgebied monitoring uitgevoerd.

PLAATS IN HET MCTL-FRAMEWORK Het taakgebied Security maakt onderdeel uit van het taakcluster Operationeel support:



01-09-2015

Pagina 9-3


ACHTERGROND Vanuit gebruiksoptiek gezien moet iemand precies zoveel autorisaties krijgen als nodig is voor het uit te voeren werk (“alles is verboden tenzij nadrukkelijk toegestaan”). Het is ook mogelijk als uitgangspunt te nemen dat iedereen alles krijgt en mag, tenzij dat om een of andere reden echt niet kan (“alles is toegestaan tenzij nadrukkelijk verboden”). Er zijn dan vanzelfsprekend nog allerlei tussenvarianten te definiëren. De onderstaande werkwijze rondom security wordt vaak toegepast en neigt sterk naar de eerstgenoemde uitgangspositie. Tegenwoordig wordt vaak een op rollen gebaseerde manier van werken toegepast, waarbij iemand in een bepaalde functie één of meerdere rollen vervult. Ook komt het voor dat een medewerker die een nieuwe functie krijgt, via infrasupport, applicatie of functioneel support dezelfde autorisaties krijgt toegewezen als degene die die functie ook al heeft. Die laatste manier van werken kan ertoe leiden dat allerlei extra autorisaties onterecht worden toegekend en vaak blijven de autorisaties van de vorige functie ook bestaan. Dit is dus niet bepaald een juiste wijze om met security om te gaan. Schematisch is de problematiek samen te vatten in dit schema:

Een persoon kan conform dit schema voor meerdere logische componenten, gegevenssets en hardwarecomponenten geautoriseerd zijn en andersom kunnen logische componenten, gegevenssets en hardwarecomponenten voor meer personen ter beschikking staan. Omdat het aantal personen en het aantal logische componenten, gegevenssets en hardwarecomponenten doorgaans aanzienlijk is, ontstaan al snel heel veel individuele m:n relaties, die zeer moeilijk te beheren zijn. In de praktijk wordt daarom aan beide zijden een bundeling toegepast die schematisch als volgt is weer te geven:

Of nog verder: 2014 - 2015 MCTL. Kennis is om te delen, niet om te bezitten. Overname met bronvermelding "www.mctl.nl" is daarom vrij.


01-09-2015

Pagina 9-4


Hoe sterker de bundeling aan de linker- en rechterzijde, hoe eenvoudiger het beheer, maar ook hoe groter de kans op uitzonderingen. Dat is ook in de praktijk te zien: een indeling van de autorisaties gebaseerd op RBAC (Role Based Access Control) eindigt in de praktijk nogal eens in geworstel met de uitzonderingen op deze indeling. Ook in een autorisatiematrix is een dergelijk effect te zien: ofwel de matrix heeft een dusdanig abstractieniveau dat niet onbelangrijke details allemaal zijn weggelaten en het praktisch nut dus niet hoog is. Ofwel het detailleringsniveau is wel in orde, maar het is een onhandelbaar geheel geworden. Binnen MCTL wordt security vanzelfsprekend vanuit bedrijfsoptiek aangevlogen. De opbouw van een bedrijf kan schematisch als volgt worden samengevat:

Toelichting (van onder naar boven): 1. "De wereld" Ook wel “Public level” genoemd. Op dit niveau is alles te vinden wat voor iedereen altijd toegankelijk is. Een voorbeeld hiervan is een website. Hierbij kan een nuance nog wel zijn dat bijvoorbeeld voor bepaalde gebieden in de wereld delen van de website niet of anders moeten worden getoond (andere taal, maar ook i.v.m. wettelijke bepalingen). Of dat wordt geëist dat voor toegang tot bepaalde delen van een website een account nodig is. Dergelijke vereisten zijn echter niet te herleiden tot een specifiek persoon. Op een website zijn voor iedereen bijvoorbeeld een aantal algemene financiële kerncijfers van het bedrijf te vinden. 2. Bedrijf Op bedrijfsniveau is alles te vinden wat iedereen binnen het hele bedrijf mag gebruiken, maar niemand buiten het bedrijf. Voorbeelden hiervan zijn een tijdregistratiesysteem of het intranet. Ook kunnen hier bijvoorbeeld (financiële) gegevens van diverse bedrijfsonderdelen worden



01-09-2015

Pagina 9-5


geplaatst die alleen voor intern gebruik zijn. 3. Business unit Op business unit-niveau is alles te vinden wat binnen deze business unit benodigd is. Er is een directe relatie met de bedrijfsprocessen die binnen deze business unit worden uitgevoerd. Een voorbeeld is de financiële administratie, waarbij alle software en gegevens rondom het verwerken van financiële gegevens alleen toegankelijk zijn voor medewerkers van deze business unit. Het kan voorkomen dat bepaalde functies / data door meerdere business units gebruikt mogen worden. Bijvoorbeeld het inzien van financiële gegevens kan ook mogelijk zijn voor andere business units (en daarbinnen specifiek voor medewerkers met een bepaalde functie / rol). 4. Functie Het vierde niveau is dat van functie. Op basis van een bepaalde functie moeten bepaalde werkzaamheden kunnen worden uitgevoerd en de bijbehorende functionaliteiten toegankelijk zijn. Omdat functies tamelijk statisch zijn, wordt ook wel gebruik gemaakt van rollen. Een rol omvat dan bepaalde taken met de bijbehorende autorisaties. Tussen functies en rollen bestaat een n:m relatie; binnen elke functie kunnen meerdere rollen worden uitgevoerd en een rol kan bij meerdere functies thuishoren. Binnen een rol kan bijvoorbeeld worden toegestaan dat een factuur wordt goedgekeurd. 5. Persoon Tot slot kunnen activiteiten en autorisaties persoonsafhankelijk zijn. Een voorbeeld hiervan is een persoonlijk e-mailadres of een stukje ruimte op een server om gegevens op te slaan. Een ander voorbeeld is dat verkopers gezamenlijk gebruik maken van een klantendatabase, maar een verkoper alleen de gegevens van zijn "eigen" klanten mag aanpassen.

Binnen deze systematiek wordt gebruik gemaakt van overerving: indien een persoon een bepaalde functie in een bepaalde business unit in een bepaald bedrijf heeft, dan mag deze persoon alles wat bij de persoon hoort, bij de bepaalde functie, bij de bepaalde business unit en bij het bepaalde bedrijf. Aldus ontstaat de rode kolom in het volgende schema:



01-09-2015

Pagina 9-6


Behalve “wie iemand is in een bepaalde rol” kunnen ook nog andere aspecten meespelen in het toekennen van autorisaties. Bijvoorbeeld kunnen autorisaties (mede) geografisch worden bepaald. Afhankelijk van een bepaalde locatie krijgt iemand in een bepaalde rol dan toch geen toegang. Enkele voorbeelden ter illustratie: Voorbeelden beperken autorisaties op basis van geografische informatie: Een bankmedewerker heeft een adviesfunctie. In die functie heeft hij de mogelijkheid direct diverse financiële transacties in orde te maken indien dat in een adviesgesprek samen met een cliënt is besproken en besloten. Dergelijke financiële transacties vragen op de achtergrond wel de nodige maatregelen om ongewenste situaties te voorkomen. Het is als volgt geregeld: Indien een adviseur een financiële transactie wil doen en het gesprek vindt in een bankgebouw plaats, dan wordt deze transactie meteen verwerkt. Vindt het adviesgesprek echter op een andere plek plaats, bijvoorbeeld bij een cliënt thuis, dan kan de transactie wel worden ingevoerd maar wordt met een vertraging van een dag uitgevoerd. Stel dat de adviseur het mes letterlijk op de keel wordt gezet, dan kan de adviseur naar eer en geweten stellen dat dit soort transacties nu eenmaal zo gaan. En stel dat een adviseur op een locatie buiten een bankgebouw en ook niet bij een cliënt is, dus bijvoorbeeld op straat of in zijn auto, dan kan de adviseur al helemaal geen financiële transacties uitvoeren. Andere bekende voorbeelden van het gebruik van geografische informatie in het kader van security zijn de beperkingen in het gebruik van betaalpasjes over de hele wereld, het gebruik van internetbankieren (waarbij een extra beveiliging in werking kan treden in bepaalde gebieden) of het gebruik van creditcards (indien een kaart in Nederland wordt gebruikt en twee uur later in Brazilië). Een ander derde aspect dat ook bij de uiteindelijke autorisatietoekenning een rol kan spelen is de tijd. Afhankelijk van het tijdstip kunnen bepaalde autorisaties al dan niet van toepassing zijn. Enkele kleine voorbeelden ter illustratie: Voorbeelden beperken autorisaties op basis van tijd: Een bij kinderen berucht voorbeeld hiervan is de beperking van internetgebruik op bepaalde tijdstippen (niet tussen 22:00 en 07:00). Een ander voorbeeld is dat er bedrijven zijn die om medewerkers tegen zichzelf te beschermen bijvoorbeeld e-mail een uur na einde werktijd blokkeren. Op basis van een bepaalde positie kan iemand aldus autorisaties toebedeeld krijgen. Deze autorisaties zijn te verdelen over: 1. Toegang tot fysieke apparatuur (Wanneer en waar is bepaalde apparatuur beschikbaar?) Niet alles hoeft op elk apparaat beschikbaar te zijn en uit beveiligingsoogpunt kan fysieke toegang worden beperkt. De verwachting van gebruikers is langzamerhand dat “alles op elke plek op elk moment” gedaan kan worden. Uit oogpunt van beveiliging kunnen hier zeker beperkingen aan worden gesteld. Daarnaast kan het nog zo zijn, dat vanwege de omvang van gegevensbestanden (denk bijvoorbeeld aan bouwtekeningen, ruwe 2014 - 2015 MCTL. Kennis is om te delen, niet om te bezitten. Overname met bronvermelding "www.mctl.nl" is daarom vrij.


01-09-2015

Pagina 9-7


onderzoeksdata of gedetailleerde weergegevens) deze niet overal ter beschikking kunnen worden gesteld. Hoewel dit laatste niet direct een beveiligingsissue is, kan het de invulling van de beveiligingsmaatregelen wel beïnvloeden. Door bepaalde autorisaties slechts op bepaalde fysieke apparatuur te accepteren kan het et gewenste gedrag stimuleren. Het is in dit geval feitelijk oneigenlijk gebruik van de mogelijkheden die autorisaties bieden. 2. Toegang tot logica / functionaliteiten, welke met name door software wordt ingevuld (Wanneer en waar kan iemand met bepaalde logica / functionaliteiten werken) Logica / functionaliteiten die iemand mag gebruiken hoeven niet altijd ter beschikking te staan. Bijvoorbeeld het doen van financiële transacties kan zijn beperkt of afgesloten indien iemand niet in een "vertrouwde" omgeving is, bijv. in de trein 3. Toegang tot bepaalde gegevens (Wanneer en waar staan iemand bepaalde gegevens ter beschikking). Bijv. kan iemand recht hebben op het aanbrengen van mutaties in een klantenbestand, maar dan alleen van de "eigen" klanten en niet van de collega's.

OMSCHRIJVING GEBRUIKTE TERMEN Functie De term functie heeft verschillende betekenissen: 1. Een functie is een toepassing gerealiseerd door computertechnologie (met name software) 2. Een functie is een samenhangend pakket van taken, bevoegdheden en verantwoordelijkheden, dat wordt uitgeoefend door een persoon 3. Een functie is een team of groep mensen die een of meer processen of activiteiten uitvoert (definitie conform ITIL), bijvoorbeeld een Service Desk. Binnen MCTL wordt voor de term functie de tweede definitie gebruikt. Account Een account is een persoonlijk profiel met een inlogcode. Elke gebruiker heeft in principe maar één account. Aan dit account zijn persoonlijke zaken gekoppeld zoals toegang tot een eigen e-mailbox en social media. Het account is gekoppeld aan een functie en aan de rol(len) die die persoon vervult. Rol Een rol omvat een aantal samenhangende activiteiten die door een medewerker kunnen worden uitgevoerd. Een rol is niet vast verbonden aan een medewerker of functie: een medewerker kan één rol tegelijkertijd vervullen, maar ook nul of juist meerdere rollen. In de loop van de tijd kan een medewerker achtereenvolgens meerdere rollen vervullen, terwijl de functie van de medewerker niet wijzigt. Deze manier van omgaan met rollen zorgt ervoor dat medewerkers met redelijk statische functies toch geheel verschillende werkzaamheden kunnen uitvoeren zonder de structuur en samenhang van de security te verliezen.

DOEL VAN DIT TAAKGEBIED Het taakgebied security zorgt ervoor dat de beveiliging van alle computertechnologie, inclusief de opgeslagen gegevens, aantoonbaar van voldoende niveau is.



01-09-2015

Pagina 9-8


Er worden conform het beveiligingsbeleid autorisaties aan medewerkers verleend en indien nodig aanpassingen aan autorisaties van medewerkers uitgevoerd, er vindt bewaking plaats op schendingen van de beveiliging of pogingen daartoe en daarop wordt actie ondernomen. Periodiek wordt de status van de operationele beveiliging gecontroleerd en gerapporteerd. Indien gewenst kan op aanvraag ook een specifieke rapportage op het gebied van security worden samengesteld.

HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel is bereikt:  De security is zodanig dat enerzijds het bedrijfsbeleid is ingevuld en dat anderzijds niemand (sterk) gehinderd wordt in de uitvoering van het werk  Security is waar mogelijk “onzichtbaar” Een aantal indicatoren die hiervoor als basis kunnen dienen:  Totaal aantal accounts versus aantal medewerkers  Groei / daling aantal accounts versus groei / daling aantal medewerkers (inclusief uitzendkrachten, ZZP'ers)  Aantal niet gebruikte accounts (in periode)  Uitkomsten externe audits  Werkelijk security niveau versus gewenste niveau  Aantal incidenten van misbruik van gegevens / security schendingen

ACTIVITEITEN De activiteiten in dit taakgebied zijn de navolgende: 1. 2. 3. 4. 5.

Uitgifte, wijziging en verwijderen van accounts Reset / deblokkering van een password Uitgifte van rollen en wijziging / intrekken van toegekende rollen Aanmaken van periodieke overzichten (security gerelateerd) Aanmaken van ad-hoc overzichten (security gerelateerd)

N.B. Het creëren of wijzigen van een rol is een wijziging en wordt via Change support opgepakt. Een gedetailleerde uitwerking van de activiteiten volgt hieronder in de vorm van diverse flows, zodat direct de verschillende acties en volgorde van die acties zijn te zien.

1. UITGIFTE, WIJZIGING EN VERWIJDEREN VAN ACCOUNTS De flow waarin de te ondernemen acties zijn opgenomen om een account uit te geven, te wijzigen of verwijderen ziet er als volgt uit:



01-09-2015

Pagina 9-9


Input De input is een aanvraag voor de uitgifte, wijziging of intrekking van een of meerdere accounts. Activiteiten De activiteiten zijn achtereenvolgens: 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd. Vervolgens vindt controle plaats: is de aanvraag juist, volledig en toegestaan? Redenen van afwijzing zijn onder andere: een verkeerde indiener, reeds account aanwezig, conflict met andere account of onvolledige informatie. Een aanvraag kan gekoppeld zijn met het HRM-systeem waarbij bij invoer / wijziging / verwijdering van gegevens in het HRM-systeem ook meteen een aanvraag voor het invoeren / wijzigen / verwijderen van een account wordt gedaan. Dit is echter niet geheel dekkend: uitzendkrachten en ZZP'ers worden niet via HRM geregistreerd, maar hebben wel een account nodig. Bovendien hoeft de geldigheidsduur van een account niet gelijk te lopen met het dienstverband. 2. Eventueel verwijderen oude account(s) Wanneer moet een oude account worden verwijderd? Onder andere in de volgende situaties: I. Indien een medewerker zodanig van functie wijzigt dat het oude account niet meer nodig is II. Indien een medewerker uit dienst treedt III. Indien een uitzendkracht of ZZP'er het einde van de werkzaamheden heeft bereikt Een account kan vaak niet direct fysiek worden verwijderd omdat er bijvoorbeeld een e-mailbox aan is gekoppeld, die gedurende zekere tijd wordt geherrouteerd. Of omdat mutaties zijn gekoppeld aan het account, waarbij na verwijdering van het account niet meer terug is te vinden wie de mutaties heeft gedaan. Indien fysieke verwijdering niet direct mogelijk is, dan moet het account worden gedisabled, met een datum waarop wel fysieke verwijdering zal plaatsvinden (dit kan soms jaren zijn; gekoppeld aan de maximale bewaartermijn van gegevens en logging). 3. Eventueel toekennen nieuwe account(s), wijzigen account Indien alleen accounts moesten worden beëindigd, dan kan deze stap worden overgeslagen. Anders worden hier een of meer nieuwe accounts aangemaakt of bestaande aangepast (bijv. een



01-09-2015

Pagina 9-10


naamswijziging). Door de aanvrager en medewerker zelf wordt gecontroleerd of een en ander in orde is. De aanvrager wordt geïnformeerd en indien vereist vindt decharge plaats. 4. Nazorg Check het werkelijk gebruik van het nieuwe account en ook of nog getracht is een oud account te gebruiken. Neem na enige dagen contact op of er nog vragen / wensen / problemen zijn. Output De output wordt gevormd door juiste, nieuwe accounts, juist uitgevoerde wijzigingen in accounts en verwijderde / gedisabelde oude accounts. De flow voor het omgaan met accounts is voor een groot deel te automatiseren; toch blijken in de praktijk handmatige acties nodig vanwege met name systeembeperkingen. Voor sommige software zijn accountinstellingen nodig die niet of alleen tegen heel hoge kosten geautomatiseerd kunnen worden ingesteld vanuit een ander systeem (van waaruit alle accounts worden beheerd).

2. RESET / DEBLOKKERING VAN EEN PASSWORD Het kan voorkomen dat een gebruiker een password is vergeten of meer dan x maal verkeerd heeft ingetypt. Steeds meer bedrijven hebben dit opgelost door middel van selfservice, waarbij op een veilige manier, inclusief checks, de gebruiker zelf zijn password kan resetten / deblokkeren. Indien dit niet mogelijk of niet gewenst is, dan is het mogelijk functioneel support via onderstaande schema ondersteuning te laten verlenen.

Input De input is een aanvraag voor resetten van een password Activiteiten De activiteiten zijn achtereenvolgens: 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd en er wordt een check uitgevoerd of het inderdaad de juiste persoon is. Afhankelijk van de organisatie gaat dit wat meer informeel (indien je in persoon verschijnt, is het al goed, het is alleen niet toegestaan voor anderen een password-reset aan te vragen) tot zeer formeel (je moet met paspoort of ander identiteitsbewijs en je personeelspas verschijnen). Ook wordt gecheckt of een password reset / deblokkering al vaker is aangevraagd. Indien reeds buitengewoon veel password resets / deblokkeringen zijn aangevraagd, dan wordt de



01-09-2015

Pagina 9-11


reden daarvan nagevraagd en eventueel actie ondernomen (via taakgebied Educatie in dit taakcluster, ofwel via een verzoek tot aanpassing van het systeem via taakcluster Change support). 2. Resetten password Het password wordt gereset. Ook bij deblokkering wordt een nieuw wachtwoord gegenereerd. De eenmalige code wordt meegegeven, of ter plaatse moet de medewerker inloggen en zelf direct een nieuw password kiezen. Indien een en ander telefonisch wordt afgehandeld, wordt nadat er is gebeld teruggebeld naar een vooraf in het systeem vastgelegd telefoonnummer. Op deze manier worden onjuiste / ongeoorloofde resets voorkomen. 3. Nazorg Eventueel wordt later nagevraagd of er nog obstakels zijn. Ook kunnen tips worden gegeven hoe een goed password te kiezen, dat toch eenvoudig te onthouden is. Output De output wordt gevormd door een gereset password.

3. UITGIFTE VAN ROLLEN EN WIJZIGING / INTREK KEN VAN TOEGEKENDE ROLLEN NB: het creëren van een nieuwe rol of het inhoudelijk aanpassen van een rol vindt plaats via Change support. Het gaat hier dus uitsluitend om de uitgifte van bestaande rollen, het intrekken van uitgegeven rollen of het wijzigen van de toekenning van een rol (bijv. de termijn waarbinnen deze rol aan een bepaald persoon is toegewezen). Het schema waarin de te ondernemen acties zijn weergegeven ziet er als volgt uit:

Input De input is een aanvraag voor het intrekken, een wijziging of intrekking van een of meerdere rollen voor een account.



01-09-2015

Pagina 9-12


Activiteiten De activiteiten zijn achtereenvolgens: 1. Registratie en intake Allereerst wordt de aanvraag geregistreerd. Vervolgens vindt controle plaats: is de aanvraag juist, volledig en toegestaan? Redenen van afwijzing zijn onder andere: een verkeerde indiener, conflict met andere reeds uitgegeven rol voor het account (i.v.m. vereiste functiescheiding) of onvolledige informatie. 2. Eventueel intrekken toegekende rol(len) Elke keer wanneer om het toekennen van een nieuwe rol wordt gevraagd, is het geen gekke reflex om meteen te checken welke rol(len) tegelijkertijd moet worden ingetrokken. Maar al te vaak worden voortdurend rollen uitgegeven, maar vrijwel geen rollen ingetrokken. Vanuit gebruikers gezien is een en ander begrijpelijk: hoe meer rollen, hoe minder kans op belemmering in de uitvoering van het werk. Maar vanuit het oogpunt van security is dit absoluut een ongewenste gang van zaken. Rollen moeten kunnen worden ingetrokken op een bepaalde datum die al eerder in het systeem is gezet. 3. Eventueel uitgifte rol(len), wijzigen rol(len) Indien alleen een uitgegeven rol moet worden ingetrokken, dan kan deze stap worden overgeslagen. Anders worden hier een of meer nieuw rollen uitgegeven (gekoppeld aan een account) of reeds bestaande uitgegeven rol(len) gewijzigd. Let op: dit is geen inhoudelijke wijziging van de rol, dat is immers een wijziging die wordt afgehandeld in Change control. De wijziging die hier wordt bedoeld is bijvoorbeeld de verlenging van de termijn waarover de rol is uitgegeven. Door de medewerker zelf wordt gecontroleerd of een en ander in orde is. De aanvrager wordt geïnformeerd en indien vereist vindt decharge plaats. Een rol moet tijdelijk kunnen worden toegekend, bijv. ivm vervanging van een collega, functieovergang, tijdelijk geen werk in eigen rol, etc. Daarmee wordt voorkomen dat werknemers elkaars account gaan gebruiken, wat natuurlijk uit den boze is. Bij de uitgifte van een rol kan het zijn dat er aanvullende vereisten gelden, zoals bijvoorbeeld educatie of een aantoonbaar vaardigheidsniveau. 4. Nazorg Check het werkelijk gebruik van de nieuwe rol en ook of nog getracht is bevoegdheden van een oude rol te gebruiken. Neem na enige dagen contact op of er nog vragen / wensen / problemen zijn. Output De output wordt gevormd door juiste nieuw uitgegeven rollen, juist uitgevoerde wijzigingen in toegekende rollen en ingetrokken rollen.

4. AANMAKEN VAN PERIODIEKE OVERZICHTEN (SECURITY GERELATEERD) In deze flow wordt uitgewerkt hoe periodieke overzichten op het gebied van security tot stand komen:



01-09-2015

Pagina 9-13


Input Vanwege het periodieke karakter van deze activiteit is er geen externe trigger als input nodig. Activiteiten De activiteiten zijn achtereenvolgens: 1. Initiatie Overzichten moeten worden geïnitieerd. Voorbeelden van overzichten zijn: 

 

Het wekelijks of maandelijks samenstellen van overzichten met accounts / rollen per systeem / afdeling / business unit, met daarbij de nieuwe en vervallen accounts extra belicht, accounts met meer dan 2 rollen, al langere tijd ongebruikte accounts en rollen, wachtwoorden die al langere tijd niet zijn gewijzigd, etc. Het wekelijks / maandelijks samenstellen van overzichten met security schendingen Het random initiëren van overzichten met het gebruik van accounts, rollen, mogelijk misbruik etc. op dat moment. Bij random kan dan worden gedacht aan het systeem dat ook bij tassencontrole in supermarkten wordt gebruikt. Dagelijks wordt dan via een systeem aangegeven welke controle die dag moet worden uitgevoerd en welk overzicht daarvoor nodig is. Het random karakter van deze controles is essentieel om te voorkomen dat tussen de vaste periodes van controle toch misbruik kan plaatsvinden.

2. Samenstellen overzicht Het bedoelde overzicht wordt samengesteld. Aangezien dit repeterend werk is kan hiervoor het nodige worden geautomatiseerd. 3. Verrijken overzicht Het overzicht wordt, voordat het wordt verstrekt, eerst beoordeeld en voorzien van commentaar en suggesties. In voorkomende gevallen kunnen ook dwingende aanbevelingen worden gedaan. 4. Verstrekken overzicht Het overzicht wordt verstrekt aan de belanghebbende, doorgaans de systeemeigenaar. Indien in het bedrijf een apart onderdeel (afdeling) is ingericht dat zich specifiek bezighoudt met security, dan wordt het overzicht uiteraard daar aan verstrekt.



01-09-2015

Pagina 9-14


Output De output wordt gevormd door overzichten op het gebied van security.

5. AANMAKEN VAN AD-HOC OVERZICHTEN (SECURITY GERELATEERD) In deze flow wordt uitgewerkt hoe ad-hoc overzichten op het gebied van security tot stand komen:

Input Gespecificeerde aanvraag. Activiteiten De activiteiten zijn achtereenvolgens: 1. Controle aanvraag Niet iedereen mag dergelijke overzichten aanvragen en de informatie die in deze overzichten is terug te vinden mag ook niet overal terecht komen. Er kunnen security- en privacygevoelige gegevens in staan, die met de nodige zorg moeten worden behandeld. Met andere woorden: er wordt hier niet alleen gecontroleerd of de aanvrager wel de juiste persoon is, maar ook of de gegevens wel mogen worden geleverd. 2. Samenstellen overzicht Het bedoelde overzicht wordt samengesteld. Aangezien dit repeterend werk is kan hier het nodige aan worden geautomatiseerd. 3. Verrijken overzicht Het overzicht wordt, voordat het wordt verstrekt, eerst beoordeeld en voorzien van commentaar en suggesties. In voorkomende gevallen kunnen dwingende aanbevelingen worden gedaan. 4. Verstrekken overzicht Het overzicht wordt verstrekt aan de belanghebbende, doorgaans de systeemeigenaar. Indien in het



01-09-2015

Pagina 9-15


bedrijf een apart onderdeel (afdeling) is ingericht dat zich specifiek bezighoudt met security, dan wordt het overzicht uiteraard daar aan verstrekt. Output De output wordt gevormd door het gevraagde ad-hoc overzicht.

RELATIES MET ANDERE ONDERDELEN VAN MCTL Dit taakgebied kent de volgende belangrijke relaties:

Ten eerste is er een duidelijke relatie met Gebruikersondersteuning. Daar zullen aanvragen betreffende accounts en rollen binnenkomen. Deze aanvragen worden vervolgens in taakgebied Security afgehandeld. Ditzelfde geldt voor overzichten op het gebied van beveiliging. Daarnaast is er een belangrijke relatie met het taakcluster Change support. Het aanpassen van rollen is namelijk een wijziging en die zal in dat taakcluster worden uitgevoerd. Het zal zeker voorkomen dat in het taakgebied Security blijkt dat een bepaalde rol niet helemaal passend is. Dan wordt hier een wijziging geïnitieerd en vervolgens in het taakcluster Change support verder afgehandeld. Het kan echter zeker ook voorkomen dat direct in Change support aanpassingen aan rollen worden gedaan. In beide gevallen zullen na Transitie nieuwe / gewijzigde rollen ter beschikking staan en in taakgebied Security worden toegewezen.

OPMERKINGEN De volgende laatste opmerkingen zijn nog te maken over het taakgebied Security. 2014 - 2015 MCTL. Kennis is om te delen, niet om te bezitten. Overname met bronvermelding "www.mctl.nl" is daarom vrij.


01-09-2015

Pagina 9-16


1. AWARENESS Beveiliging kent talloze aspecten. Natuurlijk gaat het om techniek, procedures en controle, zoals hiervoor beschreven. Maar het gaat ook om awareness, zoals het netjes omgaan met passwords en gegevens niet zomaar naar een USB-stick kopiëren of op Dropbox of een soortgelijke dienst zetten. Wat enorm kan helpen om medewerkers een beter besef bij te brengen van de ernst van beveiliging en het juist gebruiken van computertechnologie, is een consequente, 100% monitoring op het gebruik van de systemen. Uit oogpunt van privacy ligt dit gevoelig, maar op het moment dat alle handelingen van alle medewerkers worden gemonitord en ook werkelijk actie wordt ondernomen op ongewenst gedrag, kan het beveiligingsbesef sprongen vooruit maken. Alleen al het feit dat iedereen beseft dat alle handelingen later terug zijn te vinden, maakt dat al veel minder ongewenst gedrag zal plaatsvinden. Bijvoorbeeld in een overheidsorganisatie liggen persoonlijke gegevens in een database opgeslagen van bekende Nederlanders. Het is natuurlijk heel verleidelijk om daar als medewerker een kijkje in te nemen, hoewel daar vanuit het werk geen enkele aanleiding voor bestaat. Alleen al het besef dat dergelijke opvraging later is terug te vinden en dát ze er werkelijk op zullen worden aangesproken, weerhoudt veel medewerkers ervan daadwerkelijk dergelijke gegevens in het systeem op te zoeken.

2. KOPPELING BEVEILIGING MET HRM-SYSTEEM Een koppeling met het HRM-systeem biedt mogelijkheden tot het automatiseren van het aanmaken en verwijderen van accounts en rollen. Hierop zijn de volgende knelpunten te noemen: 1. In een HRM-systeem staan vaak functies en geen rollen. Wordt HRM dan ook opgezadeld met het beheer van de rollen en het koppelen van de juiste functie aan de juiste rol? 2. Soms begint iemand al voor de feitelijke omzetting van de functie in een andere functie. De ingangs- en vervaldata in het HRM-systeem komen dan niet overeen met de werkelijk benodigde bevoegdheden 3. Niet alle personen die met een systeem werken staan in het HRM-systeem. Te denken is bijvoorbeeld aan uitzendkrachten of ZZP'ers, maar ook aan personen die eerder of later in de productieketen (afnemers / leveranciers) werken en bepaalde autorisaties gekoppeld aan een account nodig hebben 4. Tot slot een principieel punt: wie gaat er eigenlijk over bevoegdheden in systemen: HRM of het management van de betreffende business unit / afdeling (de systeemeigenaar met andere woorden)?

3. EXTERNE AUDITS Externe audits kunnen tot gevolg hebben dat extra overzichten worden verstrekt. Deze activiteit is hiervoor al besproken. Maar een externe audit heeft ook functioneel support zelf tot onderwerp en dan hebben de personen werkzaam op deze afdeling natuurlijk een heel andere positie. Het is een goede zaak dat een audit zich over de gehele organisatie uitstrekt, zodat uiteindelijk niet alleen verbeterpunten in de gebruikersorganisatie, maar ook bij functioneel support kunnen worden gedefinieerd.



01-09-2015

Pagina 9-17


Voorbeeld van het nut van een audit die zich uitstrekt tot functioneel support. In een organisatie, waarin enorm veel geld om gaat, wordt een audit uitgevoerd. Behalve kritische noten over de gebruikersorganisatie is het uiteindelijke rapport ook, tot grote verrassing van de personen werkzaam op functioneel support, bijzonder kritisch over dit organisatieonderdeel. Het grote manco blijkt te zijn dat er in de gebruikersorganisatie functiescheiding keurig is geïmplementeerd, maar dat functioneel specialisten zonder controle in de productie gegevens kunnen wijzigen en de logging dusdanig is ingericht dat sporen door dezelfde personen vrij eenvoudig zijn te wissen. Functioneel specialisten zijn verder bij wijzigingen op zoveel punten betrokken dat het voor hen mogelijk blijkt in software zaken zodanig te configureren dat daardoor ongewenste situaties (lees: opheffen functiescheiding voor zichzelf en daarmee de mogelijkheid creëren om geld weg te sluizen) kunnen worden gerealiseerd. Na bekomen te zijn van de verrassing worden de nodige verbeteringen aangebracht. Jaren later blijkt hoe nuttig deze aanpassingen zijn: er is namelijk op een zeker moment gefraudeerd. De functioneel specialisten kunnen echter aantonen dat zij dit eenvoudigweg niet gedaan kónden hebben, hoewel de vinger al snel hun kant op wees. Uiteindelijk bleek het lek in de gebruikersorganisatie te zitten waar iemand zich op slinkse wijze meerdere passwords had toegeëigend.

NUTTIGE WEBSITES EN BOEKEN De volgende websites zijn voor taakgebied Security (vanuit functioneel oogpunt gezien) interessant: 

www.mctl.nl MCTL.nl – Website met alle informatie over MCTL; de achtergrond, een beschrijving van het model, video’s, artikelen, etc. etc. Alle documenten, waaronder ook dit document, zijn vanaf deze website te downloaden.

De volgende boeken zijn voor taakgebied Security (vanuit functioneel oogpunt gezien) interessant: 

Hintzbergen, J., Hintzbergen, K., Smulders, A., Baars, H. (2015). Foundation of Information Security. Zaltbommel: Van Haren Publishing



01-09-2015

Pagina 9-18

Vertrouwen is goed, controle is beter. Hoofdstuk 9. Taakgebied Security

Recommend Documents