Adequate resources voor beveiliging op applicatieniveau

Adequate resources voor beveiliging op applicatieniveau Auteur: Henk van der Heiden > Henk van der Heiden is Managing Director bij Comsec Information Security B.V. en per e-mail te bereiken via [email protected].

Beveiligingsprocessen van systemen betreffen meestal de beveiliging van de infrastructurele laag, de communicatielaag, de fysieke aspecten en het vastleggen van correcte werkprocedures. Het lijkt erop dat er onvoldoende aandacht is voor beveiliging op applicatieniveau. Applicatieontwerpers en -programmeurs beschikken vaak in onvoldoende mate over de benodigde expertise om een veilige en robuuste applicatie te ontwikkelen. Zelfs wanneer alle veilige programmeerhandleidingen gevolgd worden, is het schier onmogelijk een bug-vrije applicatie op te leveren. En een onvoldoende beveiligde applicatie kan men duur komen te staan. In dit artikel willen we toelichten wat de meest voorkomende aanvallen op applicatieniveau zijn en vervolgens wat je eraan kunt doen in de Software Development Life Cycle (SDLC) om tot een veiliger omgeving te komen.

De meest voorkomende aanvallen op applicatieniveau zijn: • Hidden field manipulation Omdat de source-code van een webpagina vaak makkelijk toegankelijk is, geeft dit de mogelijkheid tot het bekijken van ‘hidden fields’. Deze velden worden meestal gebruikt om statusinformatie door te geven aan de server. Helaas geeft dit ook de mogelijkheid tot misbruik van deze velden. Als je naar een (fysieke) winkel gaat waar men camera’s verkoopt, kom je meestal niet zo makkelijk achter de balie of kun je de prijs van deze camera niet zo makkelijk wijzigen zonder dat de eigenaar van de winkel dit merkt. Als je dit thuis via internet doet en je gaat naar de website van deze winkel, dan kun je dit in de meeste gevallen door gebruik te maken van ‘hidden field manipulation’ wel bereiken.

• Cookie poisoning Omdat cookies worden verzonden van de server naar de browser en omdat ze makkelijk te bekijken en te wijzigen zijn, geeft dit een mogelijkheid om de server aan te vallen. Als de applicatie

Een groot aandeel van beveiligingsincidenten ontstaat binnen de organisatie zelf en wordt veroorzaakt door interne bronnen, zowel opzettelijk als per ongeluk. Technische maatregelen, beveiligingsproducten en beveiligingstechnologieën zijn niet voldoende en kunnen geen ultieme oplossing vormen tegen bedreigingen. Tijdens het ontwikkelen van een nieuw systeem worden veiligheidsaspecten

geen rekening houdt met veranderingen in de ‘cookies’, kan dit misbruikt worden voor het wijzigen van data-velden, het bekijken van ongeautoriseerde informatie of het geven van mogelijkheden om zich voor te doen als een andere gebruiker.

• Buffer overflow De server meer informatie geven dan deze verwacht (bijvoorbeeld een tekst met 10.000 tekens in plaats van het maximum aantal van 25 tekens) kan leiden tot het stoppen van de server, het uitvoeren van gewijzigde code, het overschrijven van kritische systeemdata enzovoorts.

• Bekende kwetsbaarheden Zoals hierboven reeds genoemd maken ‘hackers’ vaak beter gebruik van gepubliceerde informatie over kwetsbaarheden door softwaremakers dan diegenen die er gebruik van zouden moeten maken, zoals applicatiebouwers en systeembeheerders.

• Stealth commanding Het veranderen van input velden in webformulieren kan ertoe leiden dat de webserver acties uitvoert die hij normaal gesproken niet zou mogen doen.

door interne ontwikkelings- of beveiligingsteams vaak over het hoofd gezien of ze krijgen een te lage prioriteit. Vaak krijgt de opleveringsdatum voorrang boven de beveiliging vanwege de ‘Time-to-market’ voor de nieuwe diensten en wordt er in Test-fases meer aandacht besteed aan de functionaliteit- en performance-eisen en wordt er minder aan beveiliging gedacht.

• Parameter tampering Het versturen van gemodificeerde data naar webservers kan ertoe leiden dat deze alle ‘member records’ in de database terugmeldt.

• Misconfiguratie Servers en standaard applicaties zijn vaak standaard niet ingesteld op het vereiste beveiligingsniveau. Indien dit niet wordt gedaan bij installatie kan dit leiden tot misbruik.

• Cross-site scripting/forceful browsing Het gebruik van de adreslijn om acties uit te voeren. Dit wordt vaak gedaan door een ‘script-tag’ toe te voegen aan de URL. Zoals met ‘cookie poisoning’ kan dit commando worden uitgevoerd of kan worden uitgebroken uit de server’s root directory als de applicatie dit niet voldoende afvangt.

• Database manipulatie Vrij in te vullen velden/formulieren kunnen worden gebruikt voor het injecteren van ‘SQL-commando’s’. Hiermee kan de database worden gelezen en/of worden gewijzigd.

Het al vroegtijdig, gedurende de ontwikkelingsfase, implementeren van beveiligingsmaatregelen en ‘best practices’ zal zeer kostenefficiënt blijken.

INFORMATIEBEVEILIGING JUNI 2005

25

Met het continu veranderende karakter van de it-wereld en met elke dag weer nieuwe bedreigingen en risico’s, is het zeer kostenefficiënt applicaties te beveiligen vóór hun daadwerkelijke gebruik. Dit kan door de beveiliging van de applicatie al mee te nemen vanaf de eerste ontwikkelingsfase en periodiek beveiligingsaudits en -testen uit te voeren. Zo wordt het beveiligingsniveau gedurende de hele lifecycle bewaakt, ook bij upgrades en nieuwe versies. Het is alom bekend dat hoe later je wijzigingen moet doorvoeren in de applicaties, hoe meer moeite en geld het kost. Het is daarom goed om de beveiligingsmaatregelen al vanaf het begin van de Software Development Life Cycle mee te nemen.

Hoe wordt dit bereikt? Veel bedrijven beschikken niet over de benodigde beveiligingskennis om beveiliging in applicatieontwikkeling door te voeren. Het gaat hier om specifieke kennis van applicatieontwikkelaars en niet bijvoorbeeld de bedrijfsbeveiliging, waarvoor de kennis bij een Information Security Officer aanwezig kan zijn. Ontwikkelaars zijn vooral bezig met functionaliteit, haalbaarheid en andere vergelijkbare zaken. Vandaag de dag weten we dat ze ook bezig zouden moeten zijn met beveiligingsissues. Inmiddels is het daarom alom geaccepteerd dat specialistische kennis en kunde op het gebied van Applicatie Beveiliging bij de ontwikkeling van een applicatie noodzakelijk is. Het combineren van de benodigde beveiligingskennis met ontwikkelings- en programmeervaardigheden is daarbij onontbeerlijk. Deze noodzakelijke knowhow betreft onder andere kennis over producten en oplossingen in de applicatiebranche, ontwikkelexpertise in verschillende talen, architecturen en technologieën, testmethodologie, professionele informatiebeveiligingstools, applicatietools, test-tools, methodologie voor informatiebeveiliging (zoals methodologische en kosteneffectieve codereviews, applicatie specifieke penetratietesten, enzovoort), standaarden in informatiebeveiliging, relevante industrie ‘best-practises’, applicatieplatformen en it-platformen.

goed en gestructureerd aan te pakken. Hieronder beschrijven wij een voorbeeld van zo’n programma.

Applicatiebeveiliging Knowledge Transfer Naast het verhogen van de bewustwording van de beveiligingsnoodzaak, zorgt een training ervoor dat het ontwikkelteam de benodigde kennis krijgt om veilig te ontwikkelen. Deze trainingsmethodiek combineert theorie met praktijk, aangepast op de applicaties en systemen van de klant. De trainingsstappen zijn als volgt: • Beveiligingsbeoordeling Test Voordat de training begint, wordt een intern ontwikkeld systeem als testobject benaderd. Deze wordt geanalyseerd waarna de mogelijke beveiligingsrisico’s worden bepaald. De test bestaat uit zowel een architectuur review, als een in-depth code review. • Veilige ontwikkelprincipes Guide - Deze fase bestaat uit het overdragen van enkele basisprincipes op het gebied van veilige ontwikkeling, resulterend in algemene knowhow en werkelijke implementatiekennis. Om de training op de klant af te stemmen, worden vervolgens trainingssessies gehouden met platformen die in de organisatie gebruikt worden. • Veilige ontwikkelingworkAbsorb shop - Na het verkrijgen van de nodige kennis, wordt deze theorie in de praktijk toegepast in een workshop, waarbij het testsysteem wordt gebruikt. Onderstaand diagram geeft deze methodologische aanpak weer:

Een stapsgewijze methodologisch aanpak van het probleem is dan ook de enige juiste manier om dit probleem

26


TEST - Beveiligingsbeoordeling Deze evaluatie bevat een onderzoek naar de applicatie en een review op conceptueel en designniveau, om op die manier klanten productspecifieke beveiligingsbehoeften vast te stellen. De review brengt probleempunten in de beveiliging van de architectuur of het ontwerp naar voren. Vervolgens gaat onderzoek verder door het uitvoeren van een beveiligingscode review. Onder de evaluatie vallen de volgende elementen: 1. Authenticatiemechanismen (proces, gebruikte mechanismen, beveiligingsdreigingen en -breuken); 2. Autorisatiemechanismen (gebruikersprofielen, handhaving, audit en beheer); 3. Datavalidatie (input, output, opgeslagen data); 4. Datastroom; 5. Foutbehandelingsmechanismen; 6. Auditing mechanismen (soort gebeurtenissen, locatie van logs, leeftijd en validiteit van ‘trace records’); 7. Sessiemanagement; 8. Interfaces met dataservers (bijv. DBMS / Directory); 9. Wachtwoordbeheer-mechanismen (beleid, minimale vereisten); 10. Gebruikersbeheer-mechanismen (login processen, intrekking van toestemming, audit); 11. Systeeminterfaces, intern en extern gericht; 12. Administratiemechanismen en interfaces; 13. HTML- en HTTP-functiegebruik; 14. Gebruik van cryptografie; 15. Potentiële buffer-overruns problemen; 16. Potentiële Denial-of-Service problemen;

17. Gebruik van infrastructureel specifieke beveiligingsmechanismen (IBM Websphere beveiligingsmechanismen en beveiligingsgebruik); 18. Potentiële informatielekkage. De code review, de tweede fase van de beveiligingsbeoordeling, is gericht op het vinden van fouten in onbeveiligde programma’s. Deze fouten kunnen immers gevolgen hebben voor de beveiliging van het systeem, waardoor bijvoorbeeld legitieme gebruikers of hackers ongeautoriseerde opdrachten kunnen geven. Dit kan leiden tot verschillende beveiligingsrisico’s zoals fraude, privacyschennis en denial-ofservice. Hierom wordt de systeemcode onderzocht om beveiligingsgaten te ontdekken en te herstellen door technieken toe te passen als het valideren van alle input, voorkomen van buffer overflows, beveiligen van interfaces en minimaliseren van permissies.

GUIDE - Veilige ontwikkelprincipes De verschillende trainingssessies zullen het beveiligingsniveau in de ontwikkelomgeving en gedurende de hele applicatie/systeem life cycle verhogen. Deze training is bedoeld om de kennis van ontwikkelaars/programmeurs en mensen met beveiligingsfuncties over applicatiebeveiliging te vergroten, verschillende beoordelingstools aan te dragen en praktijkervaring te delen.

inclusief Sanctum Appshield, en KaVaDo InterDo; 5. Geavanceerde aspecten van applicatiebeveiliging, zoals Securde Coding ‘best practises’ in diverse programmeertalen en architecturen (volgens de relevante programmeertechnologieën): • Microsoft .NET: sleutelconcepten in .NET beveiliging, Code Access Security, rolgebaseerde beveiliging (RBS), cryptografische services, beveiligingsbeleid-management, beveiligings-tools; • ASP.NET beveiliging: introductie in ASP.NET, Security flow, ASP.NET authenticatie, ASP.NET autorisatie, RBS, impersonation; • Microsoft DNA: COM/DCOM beveiliging, MTS beveiliging, COM+ 1.0 beveiliging; • Microsoft IIS/ASP/ISAPI: internetauthenticatie, IIS authenticatie, IIS procesidentiteiten, SSL en certificaten, ASP beveiligingshandleidingen, ISAPI beveiligingshandleidingen; • Web services beveiliging: WS-beveiliging motivatie, WS beveiligingsmodel, benaderingen voor authenticatie, autorisatie, integriteit en vertrouwelijkheid, voorbeelden van en referenties naar standaarden als: • XML signatures; • SOAP digital signatures; • XML encryptie; • XML key management specificatie; • Security Assertion Markup Language; • XML Access Control Markup Language .

De volgende punten kunnen bijvoorbeeld in een training aan bod komen:

ABSORB - Veilige ontwikkelingsworkshop

1. Traditionele beveiligingsprincipes; 2. Gebruikelijke webapplicatie-bedreigingen en -aanvallen, inclusief: • Cookie-poisening; • Verborgen veld manipulatie; • Parameter tampering; • Buffer overflow; • Cross site scripting; • Backdoor- en debug-opties; • Forceful browsing; • Stealth commanding; • Misconfiguratie (door derde partij); • Bekende gebreken. 3. Kwetsbaarheid beoordelings-tools en -methodes, inclusief ‘hands-on’ervaring met tools als Sanctum van AppScan en van KaVaDo ScanDo; 4. Applicatie Level Firewalls (ALF),

Na het verkrijgen van de nodige kennis en expertise voor veilige ontwikkeling, kan het ontwikkelteam deze theorie in praktijk brengen. Deze fase vindt meestal plaats binnen een testomgeving, zodat er geëxperimenteerd en geleerd kan worden. Het ontwikkelteam zal samen met de beveiligingsprofessionals proberen de al opgedane kennis te integreren in het ontwikkelproces. Het testobject zal alle technologieën en gebruikte talen bevatten om zo op elk terrein ervaring op te doen. Hiermee worden de eerste stappen gezet naar een veilige ontwikkelprocedure. Het is nu zaak dat het ontwikkelteam de ervaringen en opgedane kennis zich zo eigen maakt, dat de ontwikkelomgeving een veilige wordt en blijft.

Voordelen van beveiliging ‘Knowledge transfer’ De relevantie van veilige ontwikkeling is nu hopelijk aangetoond. De voordelen van het aanleren van de kennis hierover en het opdoen van ervaringen op dit gebied zijn onder andere: • Een vermindering van bestaande beveiligingsrisico’s (door het verhogen van technische beveiligingskennis, het verbeteren van de rapportage bij beveiligingsincidenten en de betere naleving van interne beveiligingsprocedures); • Een reductie in mogelijke beveiligingsincidenten (een direct gevolg van de vermindering in risico); • Een hoger niveau van samenwerking (tussen beveiligingsrollen, de medewerkers, externe beveiligingsadviseurs en het management van de organisatie); • Een betere beveiligingsimplementatie. Het nadeel van deze aanpak is dat het tijd en geld kost en dat je de beschikbare resources moet veiligstellen om getraind te worden. Daarnaast moet je ervoor zorgen dat het kennisniveau op peil gehouden wordt door middel van herhalingstrainingen.

Conclusie Doordat meer en meer bedrijven hun applicaties toegankelijk moeten maken voor meerdere gebruikersgroepen (klanten, partners en eigen medewerkers) en omdat de kwetsbaarheden zich meer en meer naar de applicatielaag begeven, zullen bedrijven ook meer aandacht moeten gaan besteden aan het beveiligen van deze applicatielagen. Een gestructureerd programma om te komen tot een beter bewustzijn van de gevaren hierin als ook het verbeteren van de Software Development Lifecycle zal dan ook noodzakelijk zijn. Het is bekend dat hoe eerder je verbeteringen kan doorvoeren in de eerste fases van software ontwikkeling, hoe goedkoper deze wijzigingen zullen zijn. Een programma zoals hierboven besproken zou dan ook een goede toevoeging kunnen zijn aan het verbeteren van de beveiliging in de applicatielagen.


27

Monitoring van systeemtoegang en -gebruik Auteur: J. van Dorp > Jethro van Dorp is werkzaam bij de Sociale Verzekeringsbank in Amstelveen. Binnen deze organisatie werkt hij als beleidsadviseur security mee aan het formuleren van het beveiligingsbeleid en adviseert hij bij de implementatie daarvan, (e-mail: [email protected]).

Volgens de Code voor Informatiebeveiliging kan het risico van inbreuken op de vertrouwelijkheid en integriteit van kritische bedrijfsinformatie op een aantal manieren gereduceerd worden. Toegangsbeveiliging (hoofdstuk 9 uit de Code) is één van de essentiële manieren om onbevoegde inzage of wijziging van informatie tegen te gaan. Toegangsbeveiliging bestaat volgens de Code in hoofdzaak uit drie aandachtsgebieden: • Autorisatiemanagement: Correct beheer van de verleende autorisaties zodat de rechtmatigheid van de toekenning gegarandeerd is en blijft. • Beveiligen van de toegangsmethoden: Beperking en beveiliging van de technische methoden waarmee toegang verleend wordt tot kritische informatie. • Monitoren van de toegang tot en het gebruik van systemen: Detectie van en reactie op afwijkingen op de beveiligingsafspraken - tijdens het gebruik van en de toegang tot systemen.

grote kans op onterechte (en een teveel aan) waarschuwingen die hij geeft als hij de medewerkers controleert. Bovendien wordt vaak geredeneerd dat een organisatie met voldoende maatregelen ‘in place’ voor autorisatiemanagement, minder behoefte heeft aan monitoring. Toch verdient monitoring binnen elke organisatie de aandacht; het sluiten van een voordeur terwijl de achterdeur openstaat heeft geen nut! Autorisatiemanagement, voornamelijk bestaande uit een set preventieve maatregelen, voorkomt namelijk niet dat medewerkers hun wachtwoorden ‘uitlenen’, dat beheerders tijdelijk een account aanmaken, of hun autorisaties gebruiken voor het resetten van het wachtwoord van een andere account. Voor dergelijk misbruik is de inzet van monitoring nodig. Detectieve maatregelen zijn onmisbaar om een integraal beveiligingsniveau zonder witte vlekken - te realiseren. Veel organisaties blijken dus nog niet, of nog onvoldoende in staat ongewenste systeemactiviteiten te detecteren en er effectief op te reageren. Vaak is er sprake van een nog niet onderkende behoefte of een ontbrekend beleid voor monitoring. Het ontbreken van maatregelen en beleid voor monitoring verhoogt het risico op onbevoegde inzage en wijziging van kritische informatie. Bovendien is de organisatie bij het ontbreken van monitoring vaak niet in staat volledig te voldoen aan de interne- en externe regelgeving.

Probleemstelling Maatregelen voor autorisatiemanagement en de beveiliging van de toegangsmethoden worden reeds breed ingezet. Monitoring - zeker wanneer dit de controle van de systeemactiviteiten van medewerkers betreft - blijft daarentegen een regelmatig bediscussieerd beveiligingsonderdeel. Big Brother wordt niet overal even gastvrij ontvangen. Dat ligt met name aan de privacygevoeligheid van de maatregelen die hij meeneemt en de relatief

28

Voor elk van de procesonderdelen dient een aantal beveiligingseisen opgesteld te worden. Daarnaast moet de inrichting en het in werking stellen van het monitorproces voldoen aan de vigerende weten regelgeving. De volgende paragraaf beschrijft een aantal beveiligingseisen ten behoeve van de inrichting van het monitorproces. Deze eisen dienen in het beveiligingsbeleid van de organisatie opgenomen te worden. Door maatregelen op basis van de beveiligingseisen te implementeren, kan het ongewenste risico dat ontstaat door het gebrek aan controle van systeemactiviteiten, geminimaliseerd worden. Natuurlijk bepaalt een risicoanalyse per te monitoren systeem uiteindelijk in welke mate er beveiligingsmaatregelen per procesonderdeel geïmplementeerd gaan worden.

Doelstelling

Handreiking voor het beveiligingsbeleid

Organisaties die besluiten monitoring in te richten, en Big Brother dus soms met enige aarzeling wel binnenlaten, kunnen monitoring het beste beschouwen als een proces met een aantal procesonderdelen: (1) logging van beveiligingsgerelateerde activiteiten, (2) analyse van de logging, (3) melding van afwijkingen op het beveiligingsbeleid en (4) reactie op de geconstateerde afwijkingen.

Hieronder volgt een opsomming van de beveiligingseisen die in het beleid opgenomen kunnen worden. De eisen bieden overigens geen houvast voor de inrichting van Intrusion Detection Systems of Intrusion Protection Systems. Dergelijke systemen bewaken het netwerkverkeer, terwijl de monitoring in dit artikel zich concentreert op de controle van gegevens in de logging.


Logging Voor elk systeem dat een mogelijke toegang tot kritische informatie biedt, dient bepaald te worden welke gegevens over de activiteiten van medewerkers vastgelegd moeten worden voor de juiste mate van monitoring. Daarnaast dienen systeemloggings en loggingmechanismen voldoende tegen misbruik beveiligd te worden om de betrouwbaarheid ervan te kunnen garanderen.

Analyse Een aan te bevelen uitgangspunt is de inzet van monitoring op systeemniveau. Dit betekent dat er in de reguliere situatie gecontroleerd wordt vanuit het systeem en dat de activiteiten van individuele medewerkers niet zonder aanleiding gevolgd en gecorreleerd worden. ‘Rootaccounts’ vormen hierop, vanwege de nagenoeg onbeperkte autorisaties, een uitzondering; deze worden wel op gebruikersniveau gevolgd. Activiteiten van medewerkers die verdacht worden van fraude of andere ongewenste activiteiten, kunnen over het algemeen alleen gemonitord worden als er sprake is van gefundeerde verdenking én als expliciet toestemming voor de controle verleend is door het hoger management. Bij ‘standaard’-medewerkers (zonder speciale bevoegdheden) dienen alleen de activiteiten gemonitord te worden die te maken hebben met de toegang tot of het gebruik van systemen die direct of indirect toegang verlenen tot kritische gegevens. Voorbeelden van dergelijke activiteiten zijn: • Pogingen om via ongebruikelijke wegen toegang te verkrijgen tot vertrouwelijke klantgegevens en pogingen om deze te kopiëren, te verplaatsen of te verwijderen. • Pogingen om toegang te verkrijgen tot kritische systeemtooling en systeembestanden (waaronder gebruikers- en wachtwoordbestanden). • Pogingen om buiten de normale openstellingtijden toegang te verkrijgen tot systemen. • Pogingen tot het installeren, kopiëren, verplaatsen of verwijderen van systeem(onderdelen). Bij medewerkers met speciale bevoegdheden (bv administrators) dienen ook de activiteiten die te maken hebben met het wijzigen van autorisa-

ties of het wijzigen van systeeminstellingen gelogd te worden. Voorbeelden van dergelijke activiteiten zijn: • Mislukte pogingen tot het verkrijgen van toegang tot hardware, systeemtooling, systeembestanden en databases. • Succesvolle en onsuccesvolle pogingen tot het verkrijgen van toegang tot systeemtooling die gebruikt wordt voor het wijzigen van kritische autorisaties of systeeminstellingen. • Alle activiteiten die worden uitgevoerd met de zogenaamde ‘rootaccounts’. • Wachtwoord resets voor accounts met speciale bevoegdheden.

Melding Meldingen dienen eerst naar een controlerend operationeel beheerder te gaan. De beheerder is (wanneer een geautomatiseerde reactie niet mogelijk of niet wenselijk is) verantwoordelijk voor het in gang zetten van een passende vooraf vastgestelde reactie. Het genereren en versturen van relevante meldingen dient 7x24 uur mogelijk te zijn. In sommige gevallen kan de reactie beperkt blijven tot verificatie van de activiteit. Het resetten van een wachtwoord voor bijvoorbeeld een rootaccount kan natuurlijk terecht zijn. Afwijkingen op de aanbevolen beschikbaarheid van het monitorproces dienen middels een formele procedure beargumenteerd, vastgelegd en op het juiste niveau goedgekeurd te worden. Een dergelijke procedure maakt de acceptatie van het restrisico expliciet. Meldingen en waarschuwingsmechanismen dienen voldoende beveiligd te worden om de betrouwbaarheid ervan te kunnen garanderen.

Reactie Elke reactie op een geconstateerde afwijking dient vooraf in een procedure vastgelegd te zijn zodat er bij het ontvangen van een melding geen twijfel bestaat over: • de manier waarop de controlerende beheerder de melding dient te rapporteren, • aan wie hij moet rapporteren, • met welke prioriteit op de melding gereageerd moet worden, • welke reactie vereist is, • wie de reactie moet goedkeuren en • wie de reactie moet uitvoeren. De reactie op een melding dient te

bestaan uit één of meer van de volgende acties: • het verifiëren van de rechtmatigheid van de activiteit, • het informeren van de betrokkenen, • in het uiterste geval het isoleren van het doelsysteem, • in het uiterste geval het afsluiten van het doelsysteem (of onderdelen ervan), • de gebruiker (geautomatiseerd) waarschuwen, blokkeren of beperken, • het herstellen van het doelsysteem, • het resetten van de wachtwoorden van de gebruikte accounts. Afhankelijk van de impact van een reactie dienen alle reacties of éénmalig vooraf, of per individueel geval door het management goedgekeurd te worden. Het treffen van mogelijke disciplinaire maatregelen ten aanzien van medewerkers wiens activiteiten zijn aangemerkt als ongewenst, is de verantwoordelijkheid van het lijnmanagement van de medewerkers. In sommige gevallen bepaalt de CAO of een ander formeel sociaal beleidsdocument welke disciplinaire maatregelen genomen kunnen worden.

Randvoorwaarden Een implementatie van monitoring op basis van de eerder genoemde beveiligingseisen vereist een zorgvuldige afstemming. De implementatie van monitoring gaat vanzelfsprekend verder dan het uitvoeren van wat technische handelingen. Eerder in dit artikel werd bijvoorbeeld al aangehaald dat een aantal wetten (zoals de Wet Bescherming Persoonsgegevens en de Wet op de Ondernemingsraden) van invloed zijn op de inrichting en het in werking stellen van het monitorproces in de organisatie. De WBP en enkele daarop gebaseerde Achtergrondstudies en Verkenningen stellen eisen aan de manier waarop loggegevens opgeslagen en gedistribueerd worden. Overigens behoeven vastleggingen van systeemactiviteiten die gebruikt worden uit beveiligingsoverwegingen, uit hoofde van de Handreiking Vrijstellingsbesluit paragraaf 8 geen melding naar de Commissie Bescherming Persoonsgegevens (CBP). De WOR schrijft daarentegen in artikel


29

27 lid 1l voor dat regelingen inzake voorzieningen die gericht zijn op of geschikt zijn voor waarneming van of controle op gedrag van de in de organisatie werkzame personen, wel instemming van de OR vereisen. Big Brother mag dus naar binnen, maar moet eerst voor een ballotagecommissie verschijnen voordat hij zijn functie mag gaan uitoefenen. Volgens de door de CBP uitgegeven ‘Checklist voor de Ondernemingsraad’ dient instemming verkregen te worden voor het vaststellen, het wijzigen of het intrekken van een regeling ten aanzien van systemen die gebruikt worden voor het monitoren van personeel. Volgens de WOR artikel 27 lid 3 is geen instemming vereist als de regeling reeds inhoudelijk is vastgesteld in een Collectieve Arbeidsovereenkomst of een regeling van arbeidsvoorwaarden welke is vastgesteld door een publiekrechtelijk orgaan. Verder moet onderzocht worden in welke mate de inrichting van het proces overeenkomt met het geformuleerde HR-beleid. Zeker als een organisatie disciplinaire maatregelen wil gebruiken als sanctie op ongewenste systeemactiviteiten, dient dit vooraf geborgd te worden in een CAO. Overigens dient er ook een vastgesteld en gepubliceerd beleid te zijn waardoor werknemers op de hoogte gebracht worden van het monitorproces dat binnen de organisatie gebruikt wordt.

Kritische succesfactoren Een organisatie die zojuist Big Brother binnen heeft gelaten, dient verder rekening te houden met nog een aantal praktische zaken. Eén daarvan betreft de vereiste inspanning voor het beheer en de exploitatie van het monitorproces. Onzorgvuldig ontwerp van het proces leidt makkelijk tot een overdaad aan meldingen, ook al wordt er gebruikgemaakt van intelligente monitorsoftware. Het behande-

30

len van die meldingen kost niet alleen tijd, maar leidt snel tot controlemoeheid bij een beheerder. Vooraf moet absoluut duidelijk zijn welke controlebehoefte er binnen de organisatie bestaat. Die behoefte dient, zeker in het begin, zo minimaal mogelijk geformuleerd te worden. Zorg ervoor dat alleen datgene gemeld wordt waar ook werkelijk actie op ondernomen kan en moet worden. Het genereren van meldingen die geen actie vereisen, heeft niet alleen geen zin, het verlaagt de alertheid van beheerders.

onder andere tot uitdrukking in de hoeveelheid en de kwaliteit van de beschikbare monitorsoftware voor de diverse platforms (informatie over enkele producten is te vinden aan de hand van de links aan het eind van het artikel). Bij de inrichting van het monitorproces dient echter de risicoklasse van de informatie, en niet de techniek, te bepalen in welke mate er gemonitord wordt. Gebrek aan uniformiteit maakt het monitorproces lastig te beheren, te exploiteren en te verantwoorden.

Een gebrekkig ontwerp vergroot overigens niet alleen de kans op ‘vermoeide’ beheerders, het leidt ook gemakkelijk tot een aanzienlijk capaciteitsbeslag. Er worden tegenwoordig nog maar weinig systemen ontwikkeld die niet over een uitgebreide mogelijkheid tot het opbouwen van een logging beschikken. In heel wat organisaties wordt onbeperkt gebruikgemaakt van die mogelijkheid, voornamelijk uit de angst informatie te verwijderen die later nog eens nodig zou kunnen zijn bij het traceren en bewijzen van bijvoorbeeld fraude. Een goed ontwerp, gebaseerd op een doordacht en goedgekeurd beleid, verkleint de kans op overmatige kosten zonder dat er relevante gegevens verloren gaan. Natuurlijk draagt ook het vaststellen en bewaken van bewaartermijnen bij aan het beheersen van de kosten. Bij het instellen van bewaartermijnen dient rekening gehouden te worden met intern beleid en de geldende wetgeving.

Conclusie

Het succes van de in dit artikel geschetste vorm van monitoring is ook afhankelijk van de mate waarin de monitoractiviteiten gecentraliseerd of geüniformeerd kunnen worden. Veel organisaties gebruiken meerdere technische platformen (mainframe, UNIX, Windows et cetera). In de praktijk kent elk platform/elk besturingssysteem vaak een eigen (beperkte) vorm van monitoring. Dit is historisch zo gegroeid. Door de uitgebreidere technische mogelijkheden, in combinatie met de waarde van de informatie die erop wordt bewaard, staat het monitorproces op mainframes in de regel op een hoger volwassenheidsniveau dan op de andere platforms. Dit komt

Interessante links www.or-online.nl: Informatie over de


Binnen het onderwerp toegangsbeveiliging is monitoring van systeemactiviteiten niet het meest populaire en het meest toegepaste onderdeel. Toch vormt monitoring een onmisbaar sluitstuk in de integrale aanpak van informatiebeveiliging. Preventieve beveiliging door goed beheer van autorisaties is niet voldoende. Monitoring van het gebruik van de autorisaties brengt de beveiliging in evenwicht. Reserveer in de organisatie dus een stoel voor Big Brother. Monitoring moet echter in het beleid en op operationeel niveau geborgd worden. Bij de implementatie moet voldoende aandacht besteed worden aan de geldende externe en interne weten regelgeving. Bovendien is het aan te bevelen in de eerste fase van het ontwerptraject alleen het hoogstnoodzakelijke mee te nemen. Er is al snel sprake van een ‘overload’ aan meldingen, met het daarbij behorende afbreukrisico.

rechten en plichten van een OR www.cbpweb.nl: Alles over de WBP en het CBP www.cert.org: Security improvement modules over logging en monitoring

Software: www.go2vanguard.com: Vanguard Analyzer

www.ca.com: eTrust Audit www.betasystems.com: Beta 89 zSecurity Monitor

www.consul.com: Consul InSight Security Manager

Adequate resources voor beveiliging op applicatieniveau

Recommend Documents