Een eerste verdedigingslinie binnen cybersecurity is identity & access management (iam). Daarmee geef je personen alleen toegang tot data en applicaties waar zij vanuit hun functie recht op hebben. Zo voorkom je dat er, bewust of onbewust, regels worden overtreden of datalekken plaatsvinden. Nu het it-landschap door de komst van multi-cloud-omgevingen en saas-oplossingen verandert, moet je als organisatie bestaande iam-oplossingen tegen het licht houden om die verdediging hecht te houden.
Het versterken van je cybersecurity is geen project met een begin en een eind. Organisaties beseffen dat security een onlosmakelijk onderdeel is van de bedrijfsstrategie. Security groeit als het ware mee met de doelstellingen en ambities van een organisatie. Dat dit besef groeit, is een goede ontwikkeling. In de praktijk blijkt het echter lastig deze focus te behouden. Dit heeft te maken met de forse verschuivingen in het it-landschap, wat gevolgen heeft voor de inrichting en effectiviteit van iam, de basis van cybersecurity. Dit komt doordat het aantal remote-medewerkers explosief is gestegen, mede onder invloed van de pandemie. Tot voor kort meldden de meeste werknemers zich op een vaste locatie aan, vaak op kantoor, op het netwerk. Nu gebeurt dit op afstand via een veelvoud aan mobiele devices. In het verlengde van deze ontwikkeling zien we dat veel applicaties ‘as-a-service’ worden afgenomen en zo eenvoudig ter beschikking worden gesteld aan medewerkers.
Kwetsbare security
We zien dan ook dat veel organisaties met stoom en kokend water remote werken hebben uitgerold, puur om de businesscontinuïteit niet in gevaar te brengen. Het cybersecuritybeleid hobbelt daar achteraan, met alle risico’s van dien. Elke applicatie uit de cloud heeft weer een eigen inlogprocedure, waardoor de kans bestaat dat medewerkers wachtwoorden gaan kopiëren. Dat maakt de security kwetsbaar. Zeker wanneer je bedenkt dat organisaties in toenemende mate met flexibele arbeidskrachten werken, die tijdelijk toegang moeten hebben tot systemen en informatie. Datzelfde geldt min of meer voor ketenpartners of auditors, die je tijdelijk toegang wil geven tot een afgeschermd deel van je infrastructuur. Er ligt hoe dan ook een uitdaging voor iam, omdat al die remote applicaties en wisselende gebruikers gekoppeld moeten worden aan het centrale iam-systeem.
Specifieke wensen
Dit gaat bijvoorbeeld fout bij iam-omgevingen die niet zijn te koppelen met applicaties die niet standaard zijn. Denk aan legacy-applicaties, waaraan door de jaren heen zo veel maatwerk is gepleegd dat iam-systemen hier niet mee kunnen integreren.
Daarnaast zien we dat iam-systemen een beperkt aantal inlogmethoden ondersteunen. In de productieomgeving heb je andere authenticatiemiddelen nodig dan in een datacenter of in een rechtbank. Je wilt rechtdoen aan de specifieke uitdagingen van de eindgebruiker maar aan ook de bijbehorende securityeisen.
Zwakke plekken identificeren
Om van iam weer die hechte verdedigingslinie te maken, moet je eerst een stap terug zetten. Breng opnieuw in kaart welke applicaties je organisatie in gebruik heeft. Kijk niet alleen naar de lijst applicaties waar it de licenties voor betaalt, maar zoek ook naar applicaties in de schaduw-it; die zijn er namelijk altijd. Vervolgens analyseer je de data die in deze applicaties omgaan: hoe gevoelig en waardevol is die data, welke regelgeving is er op van toepassing, en wie heeft er toegang tot die data? Kijk dan naar de verschillende gebruikersgroepen die je kunt identificeren, zodat je eenvoudig rechten aan grotere groepen medewerkers kunt toewijzen.
Ten slotte moet je de koppeling maken met human resources. Kijk naar de verschillende hr-processen, hoe bewegen de joiners, movers en leavers zich? Wanneer je al deze aspecten helder voor ogen hebt, kun je de zwakke plekken in de infrastructuur identificeren en kun je de iam-omgeving optimaliseren.
Shared responsibility model
Als organisatie kun je in de verleiding komen om de iam-oplossing te gebruiken die native worden aangeboden door publieke-cloudproviders. Het is immers eenvoudig te implementeren en te gebruiken. Dat is een gevaarlijke gedachte. In het shared responsibility-model ben je als organisatie zelf verantwoordelijk voor een groot deel van de securitymaatregelen. Bovendien wil je iam als een centrale oplossing positioneren die ook de on-premise applicaties en data beschermt. Ga dan ook met je vertrouwde en strategische security partner om de tafel om iam goed in te richten. Dat vergt weliswaar een forse inspanning, maar het is noodzakelijk deze belangrijke verdedigingslinie op orde te brengen.
(Auteur Guido Gerrits, directeur access management solutions bij Thales Nederland.)
IAM vormt – als proces – inderdaad de basis van het informatiebeveiliging maar deze basis wankelt door meerdere factoren. Dus don’t mention the war want bedrijfsspionage is tegenwoordig makkelijker dan ooit door niet alleen puntoplossingen in de cloud maar ook omdat leavers op de payroll via een andere inhuur constructie weer joiner worden met een ander belang maar daarover mag dan niks gezegd worden. Zeker niet bij de overheid waar dubbele petten heel gewoon zijn waardoor de segregation of duties veelal boterzacht is en de integriteit in het proces ver te zoeken is. Stoom en kokend water zijn voor de klokkenluider want in de informatiehuishouding wordt beveiliging veelal niet als de functionele toevoeging gezien waardoor het privacy-by-design principe een papieren tijger is.
Oja, het gaat dus niet alleen om het wie-is-wie en tot wat heeft deze identiteit toegang maar ook om het waarom want zoals we allemaal wel weten is nieuwsgierigheid geen rechtmatige grond. Als je dan toch IAM tegen het licht houdt misschien ook eens naar het proces zelf kijken want er is niet alleen een koppeling met HR nodig aangezien dat de contructie van geheimhouding middels een arbeidscontract niet werkt bij verplaatsing van de arbeid naar bijvoorbeld de cloud. En de laatste paragraaf gaat dan ook voorbij aan de verwerkersovereenkomsten met de exornatieclausules waar idee van Shared Responsibility compleet onzin is als we de kleine lettertjes aangaande IAM lezen. Een provider kan namelijk vaak alleen maar een RBAC-model leveren en legt de invulling hiervan, net als op- en afvoer van gebruikers, terug bij de organisatie die deze taak vervolgens veelal bij de IT afdeling legt die niet geïnformeerd wordt door HR over de joiners en leavers op de payroll.
Don’t mention the war als het om ‘disconnected processes’ gaat terwijl we al lang geen statische loopgravenoorlog meer hebben door paradigma’s zoals SOA, aangaande #metoo zijn we net als Defensie de foto’s kwijt omdat we provider niet betaald hebben en niet aan data portabliteit gedacht hebben.