Het steeds complexer wordende IT-landschap betekent voor organisaties een groeiende uitdaging dit aantoonbaar onder controle te houden. De eerste uitdaging is het in kaart brengen van de beveiligingsstatus van dit landschap. Deze informatie is niet alleen nodig in verband met compliance-eisen vanuit wet- en regelgeving zoals de Sarbanes-Oxley (SOx), privacywetgeving en de Payment Card Industry Data Security Standard (PCI DSS), maar het stelt organisaties ook in staat tijdig en adequaat te reageren op belangrijke beveiligingsmeldingen en de steeds complexer en professioneler wordende externe dreigingen. De tweede uitdaging ligt in het adequaat handelen naar aanleiding van de gedetecteerde beveiligingsmeldingen en -dreigingen. Dit stelt organisaties beter in staat te reageren op dreigingen en geeft hen ook meer inzicht in het risico dat zij lopen. Dit artikel geeft een introductie tot Security Information & Event Management (SIEM) als oplossing voor de gerezen vraagstukken.

Inleiding

Moderne computernetwerken staan onder een continue dreiging van hackers en ongeautoriseerde handelingen van (malafide) medewerkers. IT-omgevingen worden complexer, onder andere door fusies en acquisities. Externe IT-dienstverleners krijgen een steeds grotere rol juist doordat zeer specialistische kennis nodig is voor specifieke IT-omgevingen. De afhankelijkheid van informatietechnologie groeit. Hierdoor neemt het aantal (bekende) beveiligingsincidenten dagelijks toe en stijgen de kosten daarvan ([KPMG10], [McAf11]).

In reactie hierop hebben organisaties geprobeerd zichzelf te beschermen door het implementeren van beveiligingsmaatregelen zoals antivirussoftware, firewalls en intrusion detection systemen. Deze producten zijn stuk voor stuk nuttig maar creëren ook nieuwe problemen. Immers, de complexiteit van het IT-landschap neemt toe, net als het aantal beveiligingsmeldingen. Dit stelt bedrijven voor twee uitdagingen. Enerzijds het in kaart brengen van de beveiligingsstatus van het IT-landschap en anderzijds adequaat handelen naar aanleiding van de gedetecteerde beveiligingsmeldingen en -dreigingen.

Aan deze uitdagingen zijn twee belangrijke aspecten verbonden: ‘inzicht’ en ‘tijdigheid’. De uitdaging is om op grond van de miljoenen beveiligingsmeldingen te komen tot tijdige en relevante inzichten. Dit op een slimme geautomatiseerde manier. Deze ‘slimme manier’ moet de menselijke factor in de operationele uitvoering zo klein mogelijk houden om de reactiesnelheid en de kosten zo laag mogelijk te houden. De alternatieven, zoals het (laten) uitvoeren van een grote hoeveelheid IT-audits of het (periodiek) handmatig doorzoeken van logbestanden, zijn vaak geen reële optie. Deze alternatieven kennen vaak een vrij lange aanloop- en doorlooptijd, met veel menselijke betrokkenheid en daarmee relatief hoge kosten.

De markt heeft deze wens inmiddels onderkend. Onder de naam Security Information & Event Management (SIEM) ontplooien diverse organisaties en leveranciers initiatieven die handig inspelen op de geschetste situatie en de wensen van het management. Dit artikel heeft als doel helderheid te scheppen over zaken die meespelen in de volgende vragen: Wat is SIEM? En hoe kan een SIEM-voorziening helpen de wensen over ‘tijdig inzicht’ in te vullen? Daarnaast zullen we ingaan op leerervaringen uit de praktijk.

Wat is SIEM?

In de loop der tijd zijn diverse definities en interpretaties van SIEM ontstaan, mede doordat SIEM tevens een marketingconcept is geworden. SIEM kan begrepen worden als:

… de combinatie van software en hardware die is toegewezen om geautomatiseerd IT-gerelateerde beveiligingsinformatie te verzamelen, te combineren en te analyseren, met als doel om tijdig inzicht te krijgen en proactief te reageren op activiteiten die een negatieve invloed kunnen hebben op de vertrouwelijkheid, integriteit of beschikbaarheid van data of IT-middelen.

Onder ‘IT-gerelateerde beveiligingsinformatie’ verstaan wij het volgende:

Gebeurtenissen die een negatieve invloed hebben op het beveiligingsniveau. Een voorbeeld is het aanmaken van een gebruikersaccount met beheerrechten op een kritieke applicatie.
Afwijkingen van de technische configuratiestandaarden (baselines). Denk hierbij bijvoorbeeld aan een incorrect wachtwoordbeleid op een server.
Kwetsbaarheden binnen de IT-middelen. Bijvoorbeeld het toestaan van onveilige communicatie naar een server.

Kort gezegd maakt een SIEM-voorziening gebruik van bestaande logging- en monitoringfaciliteiten. Zij combineert deze informatie tot relevante informatie en rapporteert hierover. Deze rapportages kunnen zowel betrekking hebben op de beveiligingsstatus van IT-middelen als op beveiligingsgerelateerde activiteiten. Enkele veelvoorkomende voorbeelden van het gebruik van SIEM zijn:

het geautomatiseerd monitoren van systemen, applicaties en/of databaselogging met de mogelijkheid in een vroeg stadium misbruik van systemen te detecteren en hierover te rapporteren;
het geautomatiseerd monitoren van systemen, applicaties en/of databaselogging met als doel continu inzicht te hebben in de staat van de ‘compliance’ met interne of externe vereisten;
het ondersteunen in het onderzoek naar een incident door loginformatie uit het verleden te analyseren en de verschillende gebeurtenissen op de verschillende systemen (grafisch) weer te geven.

Deze definitie en voorbeelden zijn nog steeds vrij breed, vandaar wellicht ook dat SIEM inmiddels een paraplubegrip is geworden. Het is daarom nuttig om aan te geven wat wij niet verstaan onder SIEM:

Een Service Level Management-voorziening. Er zijn producten op de markt die bijvoorbeeld de beschikbaarheid en prestaties van IT-middelen bewaken. Deze gegevens worden vervolgens gebruikt om aan te tonen dat (al dan niet) aan (klant)afspraken is voldaan. SIEM-systemen kunnen hier wel een bijdrage aan leveren, maar richten zich meer op de activiteiten die op deze IT-middelen worden uitgevoerd.
Een gecentraliseerde opslagfaciliteit van logbestanden. Sommige producten bieden de functionaliteit logbestanden beveiligd op te slaan. Het doel hiervan is om bij beveiligingsincidenten achteraf te kunnen vaststellen wat er is gebeurd. Een SIEM-voorziening bewaakt het IT-landschap continu en vrijwel real-time. Zij beperkt zich niet tot analyse nadat beveiligingsincidenten of fraude in volle omvang aan het licht zijn gekomen.
Een voorziening die volledige beveiliging geeft, of de werking van alle andere beveiligingsproducten overneemt. De effectiviteit van een SIEM-voorziening zal juist mede afhangen van de logbestanden van de andere beveiligingsproducten.

C-2011-2-Boer-01

Figuur 1. Schematische weergave van het gewenste procesverloop bij beveiligingsincidenten.

Hoewel SIEM-voorzieningen soms worden ingezet om te valideren of systemen kwetsbaar zijn voor bepaalde aanvallen door hackers, gaan we hier in dit artikel niet op in.

Er zijn diverse grote spelers op de markt die SIEM-voorzieningen aanbieden. Vaak wordt een complete oplossing in één suite aangeboden. In een aantal gevallen wordt echter onderscheid gemaakt tussen Security Event Management (SEM) en Security Information Management (SIM). Een SEM-voorziening richt zich op het ‘real-time’ monitoren en managen van beveiligingsgebeurtenissen. SIM-voorzieningen richten zich op het opslaan van loginformatie en het gebruik van deze informatie voor het genereren van compliancerapporten.

Grote spelers op de SIEM-markt zijn onder andere ([Gart10]):

ArcSight: ArcSight – onlangs overgenomen door HP – biedt één van de meest complete SIEM-voorzieningen.
RSA Envision: RSA Envision wordt geleverd door EMC en biedt een volledige SIEM-voorziening.
QRadar SIEM: QRadar SIEM wordt geleverd door Q1 labs en biedt een volledige SIEM-voorziening.
Symantec Security Information Manager (SSIM): wordt geleverd door Symantec en biedt een volledige SIEM-voorziening.
LogLogic: LogLogic levert losstaande SEM- en SIM-producten die samen een volledige SIEM-voorziening vormen.

SIEM: het bereiken van ‘tijdig inzicht’ over het gehele IT-landschap

Hoe kan een SIEM-voorziening helpen de wensen over ‘tijdig inzicht’ in te vullen? De kracht van een SIEM-voorziening zit er met name in dat zij organisaties in staat stelt loginformatie uit het gehele IT-landschap te verzamelen en te analyseren op beveiligingsgebeurtenissen, configuratieafwijkingen en kwetsbaarheden. Dit levert een totaalbeeld op van de beveiligingsstatus van het IT-landschap.

Het IT-landschap kan grofweg worden onderverdeeld in vier verschillende lagen:

applicaties, bijvoorbeeld ERP-programma’s zoals SAP;
besturingssystemen, bijvoorbeeld Windows-, Linux- en Unix-varianten;
middleware en databases, bijvoorbeeld webservers, Oracle en MS SQL;
netwerk, bijvoorbeeld firewalls en intrusion detection systemen.

C-2011-2-Boer-02

Figuur 2. Positionering van de SIEM-voorziening binnen een applicatielandschap.

Op elk van de vier lagen kan onderscheid worden gemaakt tussen ongewenste gebeurtenissen, afwijkingen van configuratiestandaarden en kwetsbaarheden.

De grote hoeveelheid loginformatie waarmee de SIEM-voorziening wordt gevoed, vertegenwoordigt niet alleen relevante beveiligingsgebeurtenissen. Een groot deel van de gelogde activiteiten bestaat uit toegestane gebeurtenissen of gebeurtenissen die opzichzelfstaand geen incident vertegenwoordigen. Een typisch voorbeeld is het vastleggen van foutieve inlogpogingen. Wanneer de foutieve inlogpoging zich slechts eenmaal voordoet is dit geen incident. Wanneer binnen korte tijd tien of meer foutieve inlogpogingen van dezelfde gebruiker zijn gedetecteerd, is er mogelijk wel sprake van een incident (wellicht probeert een onbevoegd persoon het wachtwoord te raden). In het hiervoor genoemde voorbeeld zal de SIEM-voorziening slechts één melding weergeven; tien foutieve inlogpogingen door gebruiker ‘x’ op systeem ‘y’. Dit samenvoegen van vergelijkbare gebeurtenissen tot één gebeurtenis wordt aggregeren genoemd.

Het zojuist beschreven voorbeeld gaat nog steeds uit van loginformatie van één bronsysteem. De ware kracht van een SIEM-voorziening zit in het combineren van loginformatie uit verschillende bronsystemen. Stel dat tijdens een scan een kwetsbaarheid is gevonden op de e-mailserver (beveiligingsmelding 1), dat een IDS een bekende aanval detecteert op de e-mailserver (beveiligingsmelding 2) en dat daarna e-mails van diverse accounts worden doorgestuurd (beveiligingsmelding 3). De drie verschillende beveiligingsmeldingen zijn afkomstig uit verschillende systemen, maar zijn allemaal gerelateerd aan een succesvolle aanval. Het combineren van voornoemde beveiligingsinformatie afkomstig uit loginformatie van verschillende bronsystemen wordt correleren genoemd.

Tabel 1 geeft een overzicht van organisatierisico’s met daarbij een mogelijke monitoringregel die dit risico kan beperken. Daarnaast zijn de IT-lagen opgenomen die informatie moeten aanleveren aan de SIEM-voorziening om een juiste analyse te kunnen maken. De monitoringregels kunnen gericht zijn op één laag of systeem uit het IT-landschap, maar ook op een combinatie van lagen en systemen.

C-2011-2-Boer-t01

Tabel 1. Overzicht met enkele mogelijke organisatierisico’s en hoe SIEM deze helpt te beperken.[Klik hier voor grotere afbeelding]

Voorgaande beschrijving en tabel tonen al aan dat een SIEM-voorziening de loginformatie uit verschillende bronsystemen analyseert en filtert. Een goede filtering bevordert dat er weinig irrelevante meldingen (valse positieven) zijn, wat een te grote werklast zou betekenen voor de analisten van de SIEM-voorziening. Tegelijkertijd wil men ook geen relevante beveiligingsmeldingen (‘valse negatieven’) missen.

Het voorbeeld in het kader illustreert hoe een monitoringsysteem gericht op een specifieke component uit het IT-landschap, gebruikt kan worden binnen een SIEM-implementatie.

Een SIEM-voorziening verschaft organisaties meer inzicht in de risico’s van het steeds complexer wordende IT-landschap, maar een volwaardige SIEM-voorziening kan meer. SIEM-voorzieningen stellen organisaties in staat op elk gewenst moment analyses uit te voeren op de grote hoeveelheid verzamelde loginformatie. De meeste SIEM-voorzieningen hebben standaardrapportages gedefinieerd die voldoen aan de informatievereisten vanuit SOx of PCI DSS. Deze informatie stelt de organisatie en de auditor in staat zich niet alleen een tijdiger, maar ook een vollediger beeld te vormen van de compliancestatus van het IT-landschap van de organisatie.

Het monitoren van databases binnen de ‘middleware en database’-laag

Veel applicaties slaan hun gegevens op in databases. Het is daarom niet vreemd dat tot 92 procent van de gelekte data afkomstig is van databases ([Veri10]).

Aangezien databases veel gebruikt worden binnen organisaties, is het (handmatig) monitoren van elke individuele database lastig en tijdrovend. Om deze uitdaging te verhelpen zijn er databasemonitoringsystemen op de markt. Deze systemen bieden SIEM-functionaliteit, maar dan specifiek voor databases. Databasemonitoringsystemen stellen organisaties in staat centraal log- en monitoringregels vast te stellen die voor alle gekoppelde databases gelden.

Om deze centrale log- en monitoringregels te kunnen valideren, zal een koppeling moeten worden gemaakt met elke database. Dit is mogelijk door het installeren van een softwarekoppeling en het aanmaken van een account op de databaseserver. Het databasemonitoringsysteem controleert aan de hand van de ingestelde regels op onjuiste configuraties en op activiteiten die mogelijk ongeautoriseerd zijn.

Bij koppeling met een SIEM-voorziening kan ervoor gekozen worden alle informatie uit het databasemonitoringsysteem beschikbaar te stellen aan de SIEM-voorziening, of slechts een relevant deel daarvan. Voor beide mogelijkheden zijn valide argumenten te geven. Wanneer alle database-informatie doorgestuurd wordt naar de SIEM-voorziening, dan wordt deze mogelijk overbelast. Mogelijke gevolgen zijn traagheid en ontoereikende opslagruimte.

Wanneer slechts het relevante deel naar een SIEM-voorziening wordt gevoerd, worden mogelijk relevante gebeurtenissen gemist. Immers, wanneer de SIEM-voorziening bepaalde data niet ontvangt, kan zij deze ook niet analyseren en correleren. Het is daarom van belang om tijdens het ontwerp en de inrichting van de SIEM-voorziening een informatieanalyse uit te voeren, die ingaat op dit soort aspecten. Dit voorkomt het achteraf moeten doorvoeren van (kostbare) wijzigingen.

Welke leerervaringen kennen we uit de praktijk?

De recente geschiedenis leert dat IT-implementatietrajecten een vrij hoge faalkans kennen ([Else08]). SIEM-implementaties kennen een sterke technische component: een SIEM-voorziening moet immers gekoppeld worden aan een diversiteit van systemen. Toch is de technische component niet de grootste uitdaging voor een succesvolle implementatie. Waarop moeten bedrijven dan anticiperen om tot succesvolle SIEM-implementatie te komen?

Vijf belangrijke succesfactoren voor een SIEM-implementatie zijn ‘focus’, ‘analyseprocessen voor beveiligingsmeldingen’, ‘organisatie’, ‘fasering’ en ‘onderhoud’.

Hieronder gaan we in op deze succesfactoren.

Focus

Alle beschikbare loginformatie voor analyse naar de SIEM-voorziening sturen, kan verleidelijk zijn. Echter, dit stelt niet alleen hoge eisen aan het systeem, ook is de kans groot dat dit een enorme hoeveelheid beveiligingsmeldingen oplevert. Deze hoeveelheid beveiligingsmeldingen kan de analisten overspoelen. Als gevolg daarvan onderzoeken de analisten mogelijk willekeurige meldingen in plaats van alleen de belangrijke meldingen. Het is daarom essentieel focus aan te brengen. Het gebruik van onderstaande doelen kan helpen focus aan te brengen in de gewenste informatie:

Compliance. Welke informatie wil de organisatie inzichtelijk hebben om aantoonbaar te voldoen aan de interne compliancevereisten, maar ook aan de extern opgelegde compliancevereisten vanuit bijvoorbeeld SOx, PCI DSS (voor creditcardgegevens) of HIPAA (voor medische gegevens)?
Risicobeheer. In welke beveiligingsinformatie is de organisatie geïnteresseerd om zowel interne als externe dreigingen en fraude te identificeren? Enkele voorbeelden zijn het saboteren van systemen, het lekken van (gevoelige) informatie, een Denial of Service-aanval of het aanmaken van nieuwe gebruikers met gevoelige autorisaties.
Netwerkbeheer. Monitoring van de beschikbaarheid en belasting van kritieke systemen ter voorkoming van een beschikbaarheidsincident.

Naast het in kaart brengen van de gewenste informatie, dient bepaald te worden welke systemen te monitoren. Een aanpak die vaak goed werkt is om eerst te bepalen welke gebeurtenissen het hoogste organisatierisico opleveren (bijvoorbeeld de top 20 van organisatierisico’s). Vervolgens kan bepaald worden welke systemen hier een rol in spelen. Dit zijn systemen met een hoog risicoprofiel, waardoor het nuttig is om deze systemen aan te sluiten op de SIEM-voorziening. Zo kan de SIEM-voorziening het risicoprofiel van een organisatie concreet helpen verlagen.

Ook compliancevereisten kunnen de focus bepalen. Bij een dergelijke focus ligt de nadruk op de bewaking van systemen die vanuit wet- en regelgeving speciale aandacht vragen. Zo is PCI DSS-compliance-informatie alleen relevant voor systemen die creditcardgegevens verwerken en zijn SOx-vereisten alleen relevant voor systemen die belangrijk zijn voor de jaarrekeningcontrole.

Analyse van de beveiligingsmeldingen

Een SIEM-voorziening kent een sterke procescomponent. Dit betreft met name de analyse en afhandeling van beveiligingsmeldingen. Voor de introductie van een SIEM-product zullen deze processen vormgegeven moeten worden. Veelal vereisen de diverse typen beveiligingsmeldingen verschillende afhandelprocessen. De analyse en vervolgstappen bij een serie ongeautoriseerde handelingen zullen anders zijn dan bij een foutieve configuratie. Voor elk van de processen dient te worden bepaald wie verantwoordelijk is voor de verschillende (sub)stappen. Als onderdeel hiervan dient een escalatieprocedure te worden ingericht. Het vaststellen van verantwoordelijkheden en escalatieprocedures is extra belangrijk wanneer derde partijen ook IT-diensten leveren.

Veel organisaties die een SIEM-voorziening implementeren, stappen over van een meer reactieve manier van reageren op beveiligings- of compliance-incidenten naar de proactieve vorm. Deze overstap kan bijvoorbeeld ingegeven zijn door auditbevindingen of recente beveiligingsmeldingen. De kans is dan groot dat er niet alleen nieuwe processen moeten worden opgesteld voor het analyseren van beveiligingsincidenten, maar dat ook huidige incidentmanagementprocessen moeten worden aangepast. De proactieve aanpak van SIEM zal immers meer input voor de bestaande IT-beheerprocessen genereren, aangezien op basis van de beveiligingsmeldingen corrigerende maatregelen getroffen zullen worden.

Organisatie

Gerelateerd aan de voorgaande stap is een derde belangrijk aspect het vormgeven van een opvolgingsteam dat de beveiligingsmeldingen zal gaan verwerken. Binnen veel grotere organisaties is al een afdeling rondom beveiliging ingericht. Mogelijk kan het opvolgingsteam binnen deze afdeling worden ingepast. Dit heeft als voordeel dat weinig wijzigingen noodzakelijk zijn op organisatorisch vlak.

Vaak blijkt dat deze afdeling rondom beveiliging meer met beleid en controle bezig is dan met operationaliteit. Deze afdeling zal daardoor geen beveiligingsmeldingen van de SIEM-voorziening onderzoeken. Dit wetende kunnen verschillende oplossingsrichtingen worden gekozen.

Ten eerste kan worden gekozen voor een compact intern opvolgingsteam, of een wat uitgebreidere inrichting in de vorm van een Security Operations Centre (SOC), een extern opvolgingsteam. Daarnaast kan gebruik worden gemaakt van een SOC van een grote IT-dienstverlener waarvan al een dienst wordt afgenomen. Door voor deze weg te kiezen kan op de kosten bespaard worden en daarnaast zijn vaak verschillende soorten serviceniveaus mogelijk waarmee beter afgestemd kan worden op de specifieke behoeften. Nadeel is het risico van belangenverstrengeling wanneer beveiligingsmeldingen worden veroorzaakt door de IT-dienstverlener zelf. Een derde mogelijkheid is daarom om een onafhankelijke externe leverancier in te huren. Nadeel hiervan is dat vertrouwelijke gegevens zullen worden verstuurd aan een extra externe partij. Hierover zullen dus aanvullende afspraken moeten worden gemaakt en op de naleving hiervan zal moeten worden toegezien.

Belangrijke randvoorwaarde is in ieder geval dat goede contractuele afspraken worden gemaakt. Hierin moeten in ieder geval afspraken worden gemaakt over beschikbaarheid, reactiesnelheid (ook buiten kantooruren), de rapportagelijnen, het mandaat en hoe de mankracht het meest adequaat ingezet kan worden.

De introductie van een SIEM-voorziening zal meer beveiligingsmeldingen opleveren die allemaal moeten worden geanalyseerd en waarvan een groot deel opvolging vereist. De implementatie van een SIEM-voorziening zal dus ook invloed hebben op bestaande IT-afdelingen binnen de organisatie.

Fasering

Zoals hierboven geschetst, kennen SIEM-implementatietrajecten een sterke IT-component, maar ook een sterke organisatie- en procescomponent. Dit maakt dergelijke trajecten tot een interessante uitdaging. Een goede manier om hiermee om te gaan is het opstellen van een gefaseerd implementatieplan.

Aandachtspunten bij deze fasering zijn om op relatief korte termijn de toegevoegde waarde van SIEM aan te kunnen tonen, terwijl het traject tegelijkertijd beheersbaar blijft. Een goede aanpak maakt gebruik van de vastgestelde focus. De implementatie kan beginnen met een beperkt aantal doelsystemen en activiteiten die een groot deel van het risicoprofiel van een organisatie vormen. Deze aanpak omvat de organisatie, techniek en processen. Hierdoor worden op deze vlakken parallel verbeteringen doorgevoerd en is de toegevoegde waarde van de SIEM-voorziening snel zichtbaar.

Het is goed om tijdens de implementatie rekening te houden met bekende valkuilen. Zo zal geen enkele SIEM-voorziening exact alle regels kunnen configureren waar een organisatie behoefte aan heeft. Dit heeft te maken met zowel technische beperkingen als het ontbreken van logginginformatie op het juiste detailniveau. Daarnaast zullen veel (risicovolle) handelingen op het IT-landschap zijn toegestaan, maar hoe kan de SIEM-voorziening geautomatiseerd vaststellen of een risicovolle handeling is toegestaan?

De in de SIEM-voorziening geconfigureerde regel zal lang niet altijd de doelstelling van deze regel geheel afdekken. Dit kan zowel valse positieve meldingen opleveren, als valse negatieve meldingen. Een valse positieve melding krijg je als een regel te soepel is gedefinieerd. De SIEM-voorziening genereert daardoor meer meldingen dan nodig is. Die meldingen moeten in principe allemaal onderzocht worden. Een valse negatieve melding is een melding die ten onrechte niet wordt gegenereerd omdat een regel te strak is gedefinieerd.

Het is zaak het aantal meldingen te stabiliseren tot een acceptabel niveau alvorens de functionaliteit uit te breiden of nieuwe systemen aan te sluiten. Dit voorkomt dat de organisatie overstelpt wordt met beveiligingsmeldingen. Aan de andere kant voorkomt deze aanpak het bieden van schijnveiligheid.

Onderhoud

De wereld is continu in beweging en daarmee verandert het risicoprofiel waarmee organisaties te maken hebben. Tevens kan de risicotolerantie van organisaties veranderen. Daarom is het van belang periodiek te evalueren of de SIEM-voorziening aanpassing behoeft. Tijdens de evaluatie kan aan bod komen of:

de organisatierisico’s zijn veranderd;
de doelstelling van de SIEM-voorziening moet veranderen (bijvoorbeeld aanvullende aandacht voor beveiligingsincidenten ten opzichte van compliance);
de relatie tussen de doelstelling en de bewaakte IT-middelen juist is;
de diepgang van de bewaking juist is;
de bewaakte systemen zijn aangepast, vervangen of worden uitgefaseerd en daarmee of de aggregatie en correlatie van logging nog adequaat verloopt;
de beveiligingsmeldingen en rapportages nog voldoen aan de doelstellingen en wensen;
aan de organisatie- of proceskant wijzigingen moeten worden doorgevoerd om te waarborgen dat aan de kwaliteitseisen die van toepassing zijn op de SIEM-voorziening voldaan wordt;
de bescherming van het SIEM-product zelf nog adequaat is, zodat hierin geen beveiligingslekken ontstaan. Dit betreft zowel het doorvoeren van patches als het controleren of de logische toegangsbeveiliging adequaat is ingericht.

Deze periodieke evaluatie waarborgt dat de effectiviteit van de SIEM-voorziening niet wegebt in de loop der tijd.

Conclusie

De ontwikkelingen rondom beveiligingsoplossingen zoals SIEM gaan in rap tempo. Dit is mede ingegeven door een sterke managementbehoefte aan een tijdig inzicht in het risicoprofiel van het IT-landschap en aan snelheid van handelen bij incidenten. Hierdoor kunnen SIEM-systemen zich verheugen in een toenemende aandacht van organisaties. Interessant hierbij is dat SIEM-voorzieningen in grote mate kunnen worden aangepast naar de focus die een organisatie heeft. Dit kan resulteren in kleinschalige SIEM-voorzieningen, maar ook in SIEM-voorzieningen die hun nut bewijzen als onderdeel van brede beveiligingsprogramma’s.

Echter, het implementeren van een SIEM-voorziening is niet eenvoudig. Dit is mede te verklaren doordat een dergelijke voorziening raakt aan de organisatie, beveiligingsprocessen, IT-beheerprocessen en natuurlijk aan techniek. Dit vraagt om een gebalanceerde en weloverwogen implementatieaanpak. Het is daarom van belang om de leerervaringen uit de praktijk in acht te nemen. Dit stelt organisaties in staat SIEM-voorzieningen goed in te passen in hun initiatieven ten aanzien van risicobeheer en de krachtige mogelijkheden van SIEM volledig te benutten.

Literatuur

[Else08] Elsevier, ‘Geen Rolls-Royces meer’, 13 september 2008.

[Gart10] Gartner, Magic Quadrant for Security Information and Event Management, May 2010.

[KPMG10] KPMG, Data Loss Barometer, november 2010, http://www.datalossbarometer.com.

[McAf11] McAfee Foundstone Professional Services and McAfee Labs, Global Energy Cyberattacks: Night Dragon, 10 February 2011.

[Veri10] Verizon Risk Team in cooperation with the United States Secret Service, 2010 Data Breach Investigations Report, 2010.

Privacy by Design: From privacy policy to privacy-enhancing technologies

Privacy protection in organizations is often a matter of legal and organizational procedural measures. However, privacy legislation is also concerned with the use of IT to improve the reliability and efficiency of compliance with privacy requirements. In this way, IT is not merely the primary cause of privacy issues, but also at least a part of the solution. This article discusses a number of relevant developments affecting privacy and the role of what is known as “Privacy by Design.”

Introduction

After a brief introduction about privacy legislation, a number of privacy issues will be discussed. This discussion will explore organizational positioning and privacy awareness, as well as social and IT developments that affect both the perception of privacy and compliance with privacy requirements. The similarities and differences between privacy and security will be briefly considered. Next, a description will follow of the ways in which organizations have dealt with privacy issues since the introduction of legislation in this area, an overview that will be supported by recent KPMG research. This essentially involves a gradual but discernible development towards greater use of IT, culminating in the deployment of privacy-enhancing technologies. Finally, the main financial and implementation factors will be considered.

Development of privacy legislation

Privacy protection and privacy invasions have been around forever. Legislation existed to govern certain areas of privacy even in the Middle Ages, but the protection of privacy only really picked up steam after the second world war (for related and apparent reasons). The 1948 Universal Declaration of Human Rights states that territorial and communications privacy are considered fundamental rights.

The introduction and proliferation of IT in public and private organizations, and the privacy implications of its use and misuse, have provided a major impetus for further privacy legislation. The introduction of a privacy law in the German State of Hesse (1970) was followed by national laws in Sweden (1973), the United States (1974, applying exclusively to government), Germany (1977) and France (1978). This provided the basis for the OECD’s[OECD: Organization for Economic Cooperation and Development.] Guidelines Governing the Protection of Privacy and Transborder Data Flows of Personal Data (1980) and the Council of Europe’s Convention for the Protection of Individuals with Regard to the Automatic Processing of Personal Data (1981).

The Council of Europe convention has been adopted by more than twenty countries, while the OECD Guidelines have also been incorporated in various national laws. As is generally well known, the European Union has been giving privacy great priority since the early nineties, culminating in the Data Protection Directive[European Directive EC95/46, also known as the European Data Protection Directive.] of 1995. This Privacy Directive came into force in various EU member states between 1995 and 2002, hence later than the deadline of October 1998 in most cases. Further background about the development of privacy laws is provided in [Koor01] and [EPIC06]. The rest of this article will focus solely on privacy of information and communications; physical and territorial privacy falls outside its scope.

Data protection requirements and responsibility

Assignment of responsibility for privacy within organizations can vary considerably. Usually, the task falls to a lawyer in the Legal Department, but it may also be assigned to the Security Officer, Risk Manager, or sometimes even a marketing expert or IT auditor who takes care of privacy “on the side.” In more mature organizations, privacy is often handled by a Privacy or Compliance Officer or department (when customer data is involved) or the HR department (when employee data is involved). Such organizations are also attentive to privacy governance.

The Privacy Officer role, once a part-time position, has in recent years undergone extensive professionalization in response to the full-time concern for privacy management.

In organizations where privacy is properly entrenched, privacy governance affects how these issues are handled. Practices may vary from a strong legalistic approach with stringent regulations and procedures to a balanced approach with emphasis on both organizational and IT measures. At the same time, communication between lawyers, process/system/data owners, project managers, IT professionals, marketeers and users remains a major obstacle to the proper design, implementation and enforcement of privacy protection. These individuals use different terminology and do not always appreciate each other’s point of view. Based on our experience, we dare to say that fewer than 10% of complex organizations operate in full compliance with privacy legislation.

Awareness

Increased privacy awareness usually correlates with legislative surges. Although there is limited research on the awareness of and compliance with privacy requirements, surveys have nevertheless revealed that the level of awareness also vacillates. Surrounding the introduction of privacy legislation in the eighties and early nineties, privacy issues were not only receiving attention from governments but from the business community as well. Under the pressure of these new laws, most large organizations developed privacy policies and sector regulations, in most case subsequently implementing only a part of them. Other major incentives arose that were not directly connected with new legislation but were instead due to external factors and IT developments.

Use of the internet for personal data exchange: Sites requiring on-line accumulation of personal and credit card data were initially met with skepticism from users due to uncertainty about the consequences for privacy and security. As the popularity of social networks like Facebook, Friendster, MySpace, etc. has increased exponentially, they are eagerly being used to provide and disseminate a great deal of personal data. In response, privacy and security statements have been posted on some websites and self-regulating programs have been used to instill trust in others (TRUSTe, WebTrust, Europrise, etc.).
Outsourcing and offshoring: The transfer of business processes and IT systems to third parties that may be located abroad and often outside the EU (e.g. Asian countries) is a trend that has increased privacy awareness. In practice, the privacy protection of these service providers is sometimes even more rigorously scrutinized than the privacy practices within the outsourcing organization. The result is the formulation of processor agreements and the inclusion of security and privacy clauses in contracts and service level agreements (SLAs).
Global information systems, data center consolidation and shared service centers: Multinationals are increasingly being involved in global exchanges of personal data. Especially in situations where the central HR or CRM system is situated outside the EU (e.g. in the US), employees, works councils, and data protection authorities require additional privacy safeguards, such as (model) contracts and explicit consent.
New technology: Various technical developments make it possible for personal data to be exchanged more intensively through still more channels, thus increasing privacy risks. Examples include cloud computing ([KPMG10a]), electronic patient records, RFID, smart cards for various applications (e.g. public transport), biometrics, telemedicine, DNA databases, online profiling ([KPMG10b]), smart energy meters, etc.
Audits by data protection authorities: Privacy regulators have been conducting privacy audits in various sectors since the mid nineties, partly on their own initiative and partly in response to complaints. Fines have also been issued, but penalties in the EU still remain relatively modest, even if considerable sums are now being assessed in Spain and, since mid 2010, in the UK (up to £500,000). This enforcement activity has had a strong role in promoting awareness in such organizations as health-care institutions, police, commercial information agencies, financial institutions, municipal administrations, etc. Supervisory authorities in other sectors (e.g. finance and medicine) are showing increasing interest in including privacy in their inspections and reviews.
Fraud and abuse of social service: Completely different concerns are raised by the legally expanded use made of public service databases to combat fraud. The parties involved only began to appreciate the privacy issues involved when such practices actually began to occur. In some instances, extensive database matching is being used to create an indiscriminate “digital dragnet” to catch illegal activity.
Threat of terrorism: The terrorist threat has resulted in police and intelligence agencies acquiring increased powers that potentially compromise the privacy of suspects. Unfortunately, innocent civilians are also being affected, as demonstrated when the CIA obtained access to all the payment transactions routed through the SWIFT inter-banking network. To some extent, this access to sensitive personal data may be acceptable as it serves a higher purpose. At the same time, there is the danger that it creates a “Big Brother”-like situation. Insofar as direct conflict arises on this subject, politics and views about national security prevail over any individual privacy concerns.
Media attention to privacy incidents (see Box 1 for some examples): The unlawful collection and misuse of personal data, otherwise known as identity theft, has become one of the biggest causes of fraud in the US, victimizing several hundred thousand Americans and involving losses in the billions of dollars annually.

Box 1: Examples of published privacy incidents

Role of public privacy incidents

Incidents of privacy breaches have undeniably had a large influence on privacy awareness. Examples of such incidents are everywhere. Due to lapses in privacy protection and inadequate security measures, extremely sensitive personal data has been published. The number of personal records subject to privacy breaches has now reached 500 million (see privacy incidents since 2005 at http://www.privacyrights.org/data-breach).

The best known case in recent years was the loss of a CD containing data on 25 million British taxpayers.
The data for over 100 million credit and debit cards was stolen through large-scale cyber fraud, resulting in numerous settlements already costing in excess of $200 million (involving TJX, Visa, Fifth Third Bancorp).
In many countries, there are ongoing debates and court cases on whether the activities of Google StreetView are invasions of privacy.
One prosecutor sent a computer with sensitive court case data out with the trash.
The problems with Microsoft’s Hotmail, Live! and Passport have become well known.
Members of an association of single women were stalked online.
The British Home Office lost a USB stick with data on more than 250,000 participants in a major drug rehab project.
Brothel visitors were filmed and then sent letters.
At the British Department of Defence, a laptop went missing that contained unencrypted data on approximately 100,000 Army, Navy and Air Force personnel, including their partner data.
The Netherlands Solicitor General used personal information obtained illegally by a credit bureau.
At HSBC, unencrypted disks with millions of customer records were lost, and appropriate staff training was lacking (the result was a fine of over €3 million).
An employee at T-mobile sold customer and contract data to a competitor.
Deutsche Bahn illegally monitored its employees, leading to the highest breach of privacy fine in Germany (more than €1 million).
The loss of backup tapes with the records of millions of policyholders resulted in a multi-million pound fine by the British regulator.
The University of Berkeley was hacked, resulting in the data of 1.4 million Americans as well as the 160,000 students who used the medical facilities being “borrowed.”
The FIFA database of British football fans who attended the World Cup in South Africa was sold.
A video was placed on YouTube in which a disabled person appeared without his consent.
Personal data about online customers is solicited for spam purposes.
Customers are approached by banks with offers of lower mortgages after these banks have run analyses of the customer’s monthly mortgage interest payments at other banks.
A free credit scoring was awarded to 17 million customers, along with a $50,000 compensation payment for each customer, due to ID theft at Countrywide Financial Corp.
A multi-million dollar fine was levied for unsafe storage or deletion of medical data by a number of hospitals and drug-store chains in the US.
Etc., etc.

Box 2

Security vs. privacy

A widespread misconception, especially among IT professionals and various security officers, is to equate security with privacy. It is often assumed that “if we have security measures in line with the Information Security Standard (e.g. ISO 27001/2), then we have also taken care of privacy.” This is a misconception because security only satisfies one of seven key privacy principles (see overlap in Figure 1).

C-2011-0-Koorn-01

Figure 1: Similarities and differences between security and privacy

The legal and procedural factors concerning privacy have little or nothing to do with security. Figure 1 indicates the common factors and the distinguishing features that need to be emphasized. As suggested in this article, the challenge posed by privacy issues is applying privacy enhancing technologies that do more than improve security measures.

In addition, security and privacy require different approaches: security still focuses predominantly on building walls around large personal information databases. In contrast, privacy protection is aimed at minimizing the personal data collected and processed, while ensuring that this data is handled carefully through its lifecycle, wherever it flows or resides.

There are also situations where improving security could affect privacy. Such practices relate to the application of additional identification data, the use of biometrics and the performance of detailed background checks. The same applies to some anti-fraud and anti-terrorism measures. For this reason, there must be a new balance between security and privacy.

Evolution in approaches to privacy

After the introduction of privacy legislation, the approach to privacy issues initially focused on policy, procedural and legal factors and the adoption of traditional security measures. This consisted of the following generic steps:

Appointment of a privacy officer for the entire organization or for each domain (HR and customer information)
Development of a privacy policy or sometimes a privacy manual
Inventory of personal data processing (mostly this was narrowed down to listing the personal data stored on central systems, followed by subsequent high-level clarification of the objectives and processes of these systems)
After the enactment of privacy legislation, reporting of these systems to the appropriate data protection authorities
Formulation and implementation of guidelines and procedures for personal data disclosure and correction, etc. (e.g. “scripts” for use in all channels of customer interaction, such as the internet, call center or reception desk)
Inclusion of security provisions in contracts and SLAs with business partners and service providers
Implementation of traditional security measures such as logical access and the construction of “Fort Knox walls” to protect personal data.

There are under-appreciated issues with promoting privacy awareness and with the ongoing organizational and technical challenges of implementing a privacy policy – including issues in development projects for new services and/or systems. The use of privacy procedures has gradually expanded, and it has become necessary to introduce technical measures to enforce better compliance with privacy policies. As part of this technical implementation, organizations undergoing such a transition are adding enhanced authentication procedures (based on ownership attributes), differential screening with authorization profiles, programmed inspections and integrity testing with fictitious information. Personal data sent over public networks is also increasingly being encrypted.

Current status of privacy measures

Do we now have it all together? No, since a number of privacy principles are still not organizationally or technically guaranteed. They involve issues such as:

Execution of a Privacy Impact Assessment to indicate the effects that new services, partnerships and systems have on privacy, as well as the privacy risks that should be mitigated or reduced
Improving the quality of personal data (partly due to data duplication and poor design of master data management)
Integration of privacy safeguards into the information and IT architectures
Avoidance of excessive collection or combination of data due to such factors as increased computerization and interlinking of information systems throughout organizations
Incorporation of strict privacy clauses in IT outsourcing contracts
Secure communication with various types of third parties (e.g. e-mails with attachments containing personal data)
Constant testing with anonymous personal data without loss of representativeness
Flexibility to cope with situations, such as some active online internet users (“digital natives”) wishing to share more personal information than the rather ossified privacy legislation allows, as others paradoxically desire more (online) privacy protection while offering personal data to companies in exchange for economic benefits ([KPMG10c])
Assigning access to data groups and individual fields containing sensitive personal data based on business roles or even on a dynamic need-to-know basis
Logging which employees have accessed which personal data (especially of colleagues and celebrities)
Processing of sensitive personal data either anonymously or by using pseudonyms
Maintaining retention schedules and ensuring secure deletion and shredding of personal data (i.e. for eDiscovery)
Requiring approval and records where data is provided to third parties, domestically or abroad (i.e. outside EU).

Previous findings and the results of our privacy survey (see Box 4) show that there is still a great deal to be done. This section will provide further detail on a number of measures, along with a set of ingredients for an improvement plan.

In this respect, it is important to tailor all activities to the specific organization. A limited application of measures guaranteeing privacy is not necessarily bad. The measures taken must be based on a deliberate consideration of costs and benefits (economically and socially). Of course, laws and regulations should always be considered. Having insufficient measures to ensure compliance with legislation is punishable by law. It is also important to realize that managing privacy risks, like all risk management processes, is a continuous and cyclical process.

An effective risk management program for privacy should provide a mechanism by which an organization can manage privacy risks in a manner consistent with its business goals and needs, legal obligations and expectations from the market. An effective approach starts with recognizing that privacy is not only a technical issue but also a strategic PR and HR issue, involving personal data in hard-copy format (e.g. HR files, print-outs, audio recordings, video tapes or even biometric data).

A program of privacy risk management requires combined expertise from a variety of departments and specialists (such as Legal, IT, Line Management, Security, Compliance, Marketing/Sales and Audit), and also requires professionals with experience in information risk management, business processes and privacy legislation.

It seems that external pressure in the form of stricter enforcement, higher fines and/or a publicized incident involving a privacy breach (e.g. large-scale identity theft) is necessary in order to place privacy on the management agenda. Pressures like these are the reasons why privacy issues have already been addressed in countries like the UK, Germany and the US. When will other countries experience similar urgency? That’s what it seems to take before the public will support a powerful privacy program.

Need for privacy-enhancing technologies

In answer to most of the above issues, technical measures can be applied to limit dependence on organizational procedures and privacy awareness, while ensuring consistency. The term “privacy-enhancing technologies” (PET) is used to identify all the IT resources that can be used to protect personal data. The section entitled “Forms of PET” provides further detail about the possible PET measures that can be applied.

The application and development of “Privacy by Design” and PET is a recognizable trend. As indicated above, the technique was initially used mainly to protect previously collected personal data. Nowadays PET is also being used by a limited number of organizations to implement technical measures close to the data source and to keep the quantity of identifying data to an absolute minimum. Wherever it is not necessary, identity is not established or is disconnected from other personal information. An important essential step involves organizations becoming critically selective of the personal details that they require to provide their services. Often, more data is accumulated out of mere habit and kept much longer than is necessary or allowed. This excess data must be managed and protected, while having no use and being therefore merely a source of costs and risks. The easiest way to avoid either is to limit data collection and processing to only what is strictly required for the business purposes for which the processing is taking place. No more and no less. An important issue in this respect concerns determining if the processing of personal data ([PKIO02]):

is necessary (“identity rich”)
is necessary to a limited extent (“identity poor”), or
is avoidable or maintains anonymity (“identity free”).

Types of privacy technologies

Well-known and widely used elementary forms of PET are logical access security and encryption. Within logical access security, it is especially important to properly manage uniquely identifying personal information and corresponding authorization data. An important type of PET involves the segregation of data into multiple domains. One domain contains the identifying data, the other the remaining personal information. Financial, legal or medical data may be recorded in one or more domains – separate from the domain with the identity data. The data in each domain is not privacy-sensitive because it is not traceable to an individual. In this type of PET, identity-protection software ensures that only authorized system users can access or interlink the various data domains. A variant of data segregation involves a system function verifying the details that are stored in the database, without releasing these details. The function only responds to a query by answering yes/no or indicating a specific category. Figure 2 is a simplified graphic representation of the segregation of data into multiple domains.

C-2011-0-Koorn-02

Figure 2: Segregation of data into multiple domains with identity-protection software

Further integration of data and software is produced by a type of PET in which data can be accessed by means of specific software – the so-called privacy management system. In it, the translation of regulatory policy requirements is automated. For each data element and each system function, there is an immediate check verifying whether an activity is in accordance with the policy regulations. The ultimate type of PET involves anonymizing personal data. It includes software that does not collect the identifying personal data at all, or deletes IDs when the data is no longer required – preferably immediately after collection and initial processing. Ideally, this data does not even have to be saved. Anonymization is the strongest form of personal privacy protection, which by default meets all legal requirements. Anonymization is not always applicable in situations requiring personal data, which are better served by using one of the previously mentioned forms of PET.

Figure 3 shows a PET “stairs” diagram in which the effectiveness of the protection of personal data is governed by the applied PET type. The PET stairs do not represent a growth model and need not proceed to the “overflow point.” When an organization has implemented general PET measures, this does not mean that the organization must grow into “higher” levels of PET. The suitability of various types of PET is mainly dependent on the type and complexity of the information system, the desired ambition level and the sensitivity of personal data.

C-2011-0-Koorn-03

Figure 3: PET stairs

Broadly speaking, general PET measures are currently the most commonly applied, followed by separation of data and anonymization. The implementation of privacy management is in its infancy and is limited in scale.

Box 3

“Privacy by Design” in Canada: IT may not just cause privacy problems but also resolve them!

Research conducted by the Alberta government demonstrated that 57% of the content in its databases consists of personal information that may directly or indirectly identify individuals. As a consequence, constructing privacy architecture within the Provincial Government of Alberta (Canada) was seen as a logical step. This constituted an extension of the existing IT infrastructure and the Government of Alberta Enterprise Architecture (GAEA). The Alberta government used this privacy architecture to achieve its privacy policy for IT and ensure that the use of advanced technology meets legal privacy requirements.

The requirements for the privacy architecture were defined in detail in meetings with the relevant policy officials responsible for IT infrastructure and industry representatives, which were organized government-wide. The results of these workshops led to a list of twelve requirements, which were defined in detail in the policy paper on GAEA privacy architecture requirements. Not only was there an agreement about common privacy terminology, the necessary user interfaces and the use of technology to enforce the privacy policy, but also about an identity system based on meaningless but unique numbers (these numbers not being based on already existing identification numbers). These numbers reference deliberately separated personal domains that are, thus, only approachable in parts. The concept of key identification numbers is based on the deployment of identity protectors and layered identity domains. After specifying the requirements for the privacy architecture, a test model was developed that was then reviewed by the same work group. The information obtained was finally consolidated in a privacy management system, which received the HP Privacy Innovation Award.

PET costs

Is PET too expensive for your organization? No, there are several possible types of PET, ranging in cost. It is important to determine whether the costs associated with the solution are in proportion to the risks. Simple but powerful PET measures may bring about substantial improvement in data protection at little cost. To investigate whether a positive business case exists in your organization for the application of PET, three key questions must be answered. They are:

Will PET provide a significant contribution to the objectives of the organization?
What qualitative and quantitative benefits will PET provide in the organization?
What one-time and ongoing costs are required by PET?

The costs of PET can be significantly limited by taking account of privacy issues during the design stage. The quantitative and qualitative benefits of PET for the organization, society and the registered public or customers are substantial. The costs of including PET in the designs of most projects amount, on average, to only a few percent of the total budget and are therefore rapidly recovered. This relatively modest expense distinguishes them from other privacy measures that need to be incorporated into information systems after the design or development phase has been completed.

Cost levels are also affected by whether or not PET is being implemented in existing or newly developed systems. When PET is applied to existing systems, the costs are obviously higher than the costs involving new systems. The reason is that most of the costs of PET are one-off, and the one-time activities are part of the entire system development process. When PET-specific activities are retrofitted to existing systems, the latter must be adapted. As a result, certain activities are carried out twice, causing the costs of introducing PET to rise.

Implementing Privacy by Design

An important lesson from previous PET projects is that it is critical to consider the requirements for collecting personal data at a very early stage in the project. Such analysis involves determining the manner of data protection, the potential solutions and the associated costs and benefits. The subsequent conclusions will ensure that personal data collection is simply formulated as one of the essential (non-functional) requirements and is therefore naturally integrated into system design and development. Practical experience has certainly demonstrated that the later addition of PET into an information system is possible, but this upgrade runs sometimes deeper into the information system and underlying database than expected. In general, greater effort and higher costs are involved. And the same holds true when upgrading to advanced PET-related types and measures.

Table 1 represents the various stages that must be completed in order to successfully implement PET. PET-specific issues relating to each stage are indicated in the stage when they have to be addressed.

C-2011-0-Koorn-t01

Table 1: Stages in the PET implementation plan

For an application of the Privacy by Design principle to the smart energy grid in Canada, see [IPCO10].

Future

We expect privacy and privacy-enhancing technologies to become an integral part of system development. The general public and consumers in particular demand that organizations handle personal data with great care and efficiency. Care and efficiency requires single registration at source and confidential usage throughout all the data processing stages in the system and any associated links in the information supply chain. To meet these demands and to guarantee the quality of data, organizations must make increasing use of IT solutions. In our view, the majority of governmental organizations will be the first to adopt privacy-enhancing technologies in one form or another, followed by companies that process sensitive personal data or that must comply with strict legislative and regulatory requirements (e.g. medical, pharmaceutical and financial sectors). The supply and demand of PET solutions will have to keep pace with these developments.

Conclusion

It seems that external pressure in the form of stricter enforcement, higher fines and/or a widely publicized incident of privacy breach, such as large-scale identity theft, has to come about before privacy is placed on the management agenda. Reasons like these have led to privacy issues being addressed in countries like the UK, Germany and the US. When will other countries suffer the same compulsion? Only then does it seem that there is enough support to execute a powerful privacy program.

Our privacy survey (see Box 4) indicates that organizations in both the public and private sectors experience substantial difficulties in implementing privacy measures and complying with legal provisions, even after 20 years of legislation. Nevertheless, these organizations have a positive opinion about the quality of their privacy protection. They primarily base this view on the fact that they have implemented a number of procedural and technical measures, mainly on the operational level. Framework and preparatory measures at the strategic or tactical levels are, however, often lacking.

Privacy protection is still predominantly being approached in response to compliance requirements; the positive economic effects are barely acknowledged. Furthermore, the adequacy of implemented measures are seldom evaluated. Despite many organizations believing that they are privacy compliant, it is hoped that future organizations will be able to back up such optimistic claims with privacy audits or certificates and the absence of major privacy incidents.

Implementing technical measures not only enables more effective and efficient data protection; the use of technical measures specifically requires a critical examination of personal data collection, its necessity and the need for its protection. This approach increases the integrity and confidentiality of the data and enables a more effective and efficient processing of personal data. Privacy-enhancing technologies need to become less a series of measures intended to ensure compliance with procedures and more a set of privacy provisions directly incorporated in the design of IT systems and infrastructure.

We therefore wish to conclude this article with the following high-level business case for Privacy by Design.

Privacy by Design is more than a manner of protecting personal data:

Wanting Privacy by Design:
- PET improves the quality of data processing.
- Dependence on appropriate compliance with processes and procedures is reduced by automatic enforcement of privacy rules.
- Implementation of PET can be a means of allowing the general public and customers to have better access to and control over their personal data.
- Use of PET creates a positive image for the organization.
Needing Privacy by Design:
- PET can simplify compliance with privacy legislation.
- PET creates the conditions under which the general public can trust an organization’s operations.
- PET makes it possible to process (sensitive) personal data and provide services that would not be permissible otherwise.
Implementing Privacy by Design:
- PET has already been frequently implemented (see sample cases in [BZK04]).
- PET only has a limited effect on the development costs of new information systems, given that the technologies are already present. In general, it primarily “costs” the work required to conceive and design privacy-proof architectures.
- The inclusion of PET in your information (system) architecture provides a basis for efficient application of PET to your various information systems.

Box 4

KPMG Privacy Survey

In collaboration with TNS-Nipo, KPMG conducted a survey of nearly 300 organizations in the public and private sectors on privacy awareness and their approaches to privacy protection. The survey questions probed the extent to which privacy was an important concern for organizations and the manner in which they were dealing with the protection of privacy.

The most important results were:

Organizations do not have a firm grip on the term “privacy” and do not sufficiently understand what it means to their business. This lack of understanding is caused by the complex legislation involved, the lack of time/priority and the complexity of IT. In addition, privacy and data security were often improperly regarded by respondents as synonymous (almost half of the respondents considered their information security measures as sufficient for full privacy compliance).
Organizations are therefore particularly geared to compliance and, in general, give the impression of being mature insofar as the implementation of operational privacy measures are concerned.
The final responsibility for privacy and activities safeguarding privacy is still greatly fragmented.
The number of privacy incidents remains relatively high, especially in the financial and public sectors where approximately 15% of organizations suffered an identified privacy incident in the last three years. The KPMG Data Loss Barometer exhibits a similar view of data loss and identity theft ([KPMG09]).
More than of half of the surveyed organizations are monitoring employee e-mail or internet traffic.
The potential “economic value” of privacy (e.g. the benefits that the creation of customer profiles can have) is insufficiently explained. This means that organizations are likely still missing the opportunities that the adequate handling of personal data could deliver (see [KPMG01]).
Two thirds of the surveyed organizations believe that they are currently in compliance with privacy laws, although they scarcely assess the extent to which they have implemented privacy safeguards and measures.

The survey results are reported in detail in [KPMG10d].

Box 5

Sample step-by-step privacy plan

As noted earlier, it is important to recognize that the management of privacy risks is a continuous and cyclical process. An effective approach starts with recognizing that privacy protection is not an IT issue but that it also has strategic and tactical importance for all customer and HR data in electronic and paper format.

The following steps can help to safeguard privacy within an organization. They need not be implemented in the indicated order, as the sequence depends on the existing level of information governance and privacy maturity.

Step 1: Ensure that sponsorship and leadership involves senior management. Though a standard recommendation, privacy will remain condemned to being a merely legal or IT security project unless it garners support from senior (line) management. Sufficient support will ensure adequate funding and continuity. In many cases, this means that a General Counsel or Compliance Officer will have to stimulate management to act. In other cases, the introduction and implementation of a substantial transformation (e.g. a system consolidation involving several countries and business domains) will provide a stimulus for investment in privacy.

Step 2: Appoint a project manager (preferably not a lawyer!). Provide this project with sufficient resources and accumulated expertise. Identify key personnel and data owners in various areas of the organization (Line Management, HR, Marketing/Sales, Legal Office, Information Security, Audit) who will participate in the project. The selected groups should consist of professionals with experience in business processes, customer service, information/IT risk management and privacy laws.

Step 3: List and classify the personal data that is currently being collected. Fully understand why the organization is collecting, using and/or transferring various types of personal data. All these activities must be part of the organization-wide information lifecycle management processes. Other important questions are: Does the current personal data collection satisfy the current need, or is more personal data accumulated and retained than is actually required? How do we handle private employee data in the work environment (e.g. social networking, private e-mail, telephone / PDA use, etc.)?

Step 4: Identify and analyze the methods used to collect personal data. This step may be executed simultaneously with the previous one, and entails analyzing websites, applications, registrations, marketing campaigns, acquisition of marketing databases containing personal information, etc. Identify how and with which means the members of the general public, customers or employees have been informed and have granted consent for processing.

Step 5: Perform a Privacy Impact Assessment. After analyzing the data being collected, data flows and data management processes, a Privacy Impact Assessment can be performed to identify privacy risks. The process involves the following assessments.

What precisely is meant by privacy and privacy protection, and what do the context, legal privacy requirements and privacy demands from internal and external stakeholders mean to the organization?
What are the threats and opportunities (what it could cost the organization and what benefits it might provide); see [KPMG01] for a discussion about the upside of privacy, the opportunities?
How can all these issues be translated into a concrete approach encompassing strategic, tactical and operational levels?

Various governmental bodies, boards of standards and data protection authorities are currently developing or even imposing Privacy Impact Assessments (including several agencies in Canada, Australia, Hong Kong, New Zealand and the UK, see for instance [ICO09] and [ISOT08]).[Some privacy impact assessments are merely compliance assessments concerned with meeting the requirements stipulated in privacy legislation. A proper privacy impact assessment should also consider the privacy effects of new services and systems on customers, employees and the general public.]

Step 6: Appoint a privacy officer, and an organization-wide privacy governance having enough authority to address privacy issues throughout the organization.

Step 7: Develop an organization-wide privacy policy and translate it into organizational, procedural and technical measures (a “Privacy Control Framework”). Ensure that employees and customers are aware of this policy and the procedures involved, and that they understand their implications. Decide whether model contracts, safe harbor or binding corporate rules are preferred solutions for global data exchange. Embed privacy into regular governance and compliance (reporting) processes.

Step 8: Train employees, including management. Train both current and new employees, without neglecting contracted personnel. Pay specific attention to individuals who have frequent contact with customers and access to sensitive data.

Step 9: Make sure that personal data is secure. Personal information stored electronically, filed as paperwork or involved in internal and external communications must be secured to a technically sophisticated extent, and protected against unauthorized or unwanted access (in line with classification from step 3).

Step 10: Ensure that third parties and suppliers are also privacy compliant. Ascertain that they provide at least the same level of protection and can provide material evidence or independent assurance of this fact.

Step 11: Review and improve privacy protection, use privacy audits to ascertain the level of protection, raise awareness, further strengthen the privacy control framework implemented, and communicate a privacy certificate externally.

Literatuur

[BZK04] Netherlands Ministry of External Affairs, Privacy Enhancing Technologies for Decision-makers, 2004 (http://www.dutchdpa.nl/downloads_overig/PET_whitebook.pdf).

[EPIC06] EPIC/Global Internet Liberty Campaign/Privacy International, Privacy and Human Rights: An international survey of privacy laws and practices, 2006 (http://www.privacyinternational.org/article.shtml?cmd[347]=x-347-559458).

[ICO09] ICO (Information Commissioner’s Office), Privacy Impact Assessment Handbook, 2009 (http://www.ico.gov.uk/upload/documents/pia_handbook_html_v2/index.html).

[IPCO10] Information and Privacy Commissioner of Ontario, Hydro One and Toronto Hydro Corporation, Privacy by Design – The Gold Standard Best Practices for the Smart Grid, June 2010 (http://www.ipc.on.ca/site_documents/achieve-goldstnd_execsumm.pdf).

[ISOT08] ISO TC68/SC7, ISO 22307:2008 Financial Services – Privacy impact assessment, 2008.

[Koor01] Koorn, R.F. and M. Dontje, Internationale privacyaspecten en de Wbp, Compact 2001/4 (publication in Dutch).

[KPMG01] KPMG, A New Covenant with Stakeholders: Privacy as a competitive advantage, 2001 (http://aci.kpmg.com.hk/docs/evolving%20issues/managing%20privacy.pdf).

[KPMG09] KPMG, Data Loss Barometer, Insights into Lost and Stolen Information, Issue 2, 2009 (http://www.datalossbarometer.com).

[KPMG10a] KPMG 2010 Cloud Computing survey: From Hype to Future, 2010 (http://www.kpmg.com/NL/nl/IssuesAndInsights/ArticlesPublications/Pages/FromHypetoFuture.aspx).

[KPMG10b] KPMG, Data Protection and Privacy Issues in Online Advertising, Issues Brief, 2010 (http://www.kpmg.com/US/en/IssuesAndInsights/ArticlesPublications/Documents/flashpoint-data-protection-privacy-brief.pdf).

[KPMG10c] KPMG, Consumers-Convergence-IV , July 2010 (http://www.kpmg.com/BE/en/IssuesAndInsights/ArticlesPublications/Documents/Consumers-Convergence-IV-july-2010.pdf).

[KPMG10d] KPMG, Privacy Protection: unconscious incompetence, white paper, 2010.

[PKIO02] Logius/PKIoverheid, PET en de PKI voor de overheid, November 2002 (publication in Dutch).

Digitaal sporen

KPMG Forensic is gespecialiseerd in het onderzoeken van mogelijke integriteitsschendingen. In dit artikel schetsen de auteurs vanuit hun ervaring hoe en onder welke voorwaarden digitaal materiaal ingezet kan worden in forensische onderzoeken. Daarbij geven ze aan welke voorzorgen in acht genomen moeten worden voor een correcte behandeling van potentieel bewijsmateriaal.

Inleiding

Bijna dagelijks staan op de voorpagina’s van de kranten berichten over fraudegevallen. Zowel (semi-)overheidsorganisaties, banken als andere bedrijven blijken betrokken te zijn bij fraude. Soms in de rol van slachtoffer doordat een eigen medewerker of een leverancier de organisatie benadeeld heeft, in andere gevallen blijken organisaties zelf structureel wet- en regelgeving te ontduiken of bewust onjuiste financiële gegevens naar buiten te brengen. Slechts weinig verbeeldingskracht is nodig om te bedenken dat de zaken die de kranten halen alleen een topje van de ijsberg vormen. Dagelijks worden vele bedrijven en overheden geconfronteerd met integriteitsschendingen zoals fraude maar ook vertrouwelijke informatie die aan derden is doorgespeeld, schendingen van het intellectueel eigendomsrecht of onderzoeken ingesteld door justitie, toezichthouder of mededingingsautoriteit naar eventuele onregelmatigheden.

In veel organisaties die geconfronteerd worden met signalen met betrekking tot dergelijke schendingen slaat de schrik hevig toe. De signalen kunnen vanuit de interne organisatie naar boven komen maar ook via externe partijen zoals een bank, subsidieverstrekker, toezichthouder, openbaar ministerie, accountant of een in- of externe klokkenluider. Van de verantwoordelijke functionarissen binnen een organisatie, meestal directieleden of compliance officers, worden op korte termijn adequate maatregelen verwacht. Daarbij moet een aantal belangrijke beslissingen in een kort tijdsbestek worden genomen om de ontstane ‘crisis’ te managen. Slechts bij een beperkt aantal organisaties ligt hiervoor een draaiboek klaar in de vorm van een ‘fraud risk reaction plan’.

Een adequaat en snel optreden is gewenst maar wordt bemoeilijkt doordat de aard en de omvang van de zaak veelal onduidelijk zullen zijn en de relevante feiten en omstandigheden onbekend. Daarom wordt in veel situaties besloten om een (intern) onderzoek in te stellen dat zo snel mogelijk meer duidelijkheid verschaft. Afhankelijk van de bron van informatie zal een organisatie eerst, voor zover mogelijk, de herkomst en de betrouwbaarheid van de signalen willen verifiëren. Indien de signalen betrouwbaar lijken te zijn dan zal de organisatie snel een beeld willen verkrijgen van de aard en omvang van de mogelijke schending en de betrokken personen of partijen. Op basis van die informatie kunnen vervolgens passende maatregelen worden genomen.

In dit artikel wordt ingegaan op de belangrijke rol die digitale gegevens en informatie over het gebruik van computersystemen in een forensisch onderzoek spelen. De auteurs beschrijven vanuit hun ervaring binnen KPMG Forensic de belangrijkste risico’s rondom het betrekken van digitale gegevens in forensische onderzoeken. Vervolgens gaan zij in op de belangrijkste uitgangspunten voor het gebruik van digitale gegevens in een forensisch onderzoek om de risico’s te mitigeren.

Voorbereiding intern onderzoek

Ondanks het feit dat een snelle reactie zeer gewenst is, is het van groot belang dat in de aanloop naar een dergelijk onderzoek zeer zorgvuldig wordt gehandeld. Daarbij moet in ieder geval rekening worden gehouden met de wettelijke bescherming van de privacy van individuele werknemers. Ook spelen vragen zoals welke medewerkers moeten worden ingelicht (zoals het wel/niet inlichten van de direct leidinggevende) en welke verplichtingen gelden ten aanzien van het inlichten van externe organen zoals justitie of toezichthouders. Tegelijkertijd zal de organisatie veelal acties willen ondernemen om de onregelmatigheden te stoppen en/of de schade te beperken (bijvoorbeeld beslagleggingen of het intrekken van autorisaties). Indien reeds concrete personen in beeld zijn van wie de organisatie het handelen of juist het nalaten daarvan wil onderzoeken, kan gekozen worden voor een persoonsgericht onderzoek.

Bij de grote banken en sommige andere grote organisaties bestaat een eigen afdeling gericht op het onderzoeken van potentiële integriteitsschendingen, veelal gepositioneerd onder de Interne Audit Dienst (IAD). Als een organisatie niet over een dergelijke afdeling beschikt zijn er verschillende gespecialiseerde bedrijven om eventueel in combinatie met een juridische adviseur te ondersteunen bij een onderzoek.

Rol van digitale gegevens

Voor het bepalen van de aard en omvang van de eventuele fraude of andere integriteitsschendingen zal een onderzoek zich in eerste instantie richten op het reconstrueren van de relevante gebeurtenissen. Om die gebeurtenissen in kaart te kunnen brengen zal vaak gestart worden met het achterhalen van relevante documenten en correspondentie zowel op papier als digitaal.

Dit artikel is specifiek gericht op het doen van onderzoek naar digitaal aanwezige gegevens omdat deze vaak een cruciale rol spelen en een speciale aanpak vergen. Het type informatie waarnaar gezocht wordt, kan grofweg worden verdeeld in twee categorieën. De eerste categorie bestaat uit documenten en e-mails waarvan de inhoud inzicht verschaft in de gebeurtenissen (e-discovery). De crux van het digitaal onderzoek is hierbij het selecteren van relevante documenten. De tweede categorie bestaat uit het zoeken naar de aanwezigheid van specifieke sporen in computersystemen (computer forensics). Hierbij gaat het om vragen als ‘Heeft de heer X het vertrouwelijke document abc in zijn bezit?’, ‘Heeft mevrouw Y document abc gekopieerd naar een USB-stick?’ of ‘Door wie is document abc opgesteld?’.

Onderzoeken van digitale gegevens

Als documenten zijn opgeslagen op een algemeen toegankelijke locatie, fysiek of binnen een computersysteem, en niet duidelijk als persoonlijk eigendom gemarkeerd zijn, dan kan een organisatie de inhoud van die documenten zonder veel problemen gebruiken in een forensisch onderzoek. Het ligt echter voor de hand dat de meeste relevante informatie niet op dergelijke openbare plaatsen wordt opgeslagen maar op een afgeschermde locatie.

In hoeverre een organisatie bevoegd is om afgeschermde locaties te doorzoeken hangt af van verschillende factoren. Privé-eigendommen van de werknemer kunnen in ieder geval niet door de werkgever doorzocht worden, daartoe is alleen justitie bevoegd. Het feit dat een tas of een USB-stick wordt aangetroffen op de werklocatie doet daar geen afbreuk aan.

Artikelen die eigendom zijn van de werkgever mogen onder bepaalde voorwaarden wel doorzocht worden mits aantoonbaar is dat de werknemer vooraf van die mogelijkheid op de hoogte is gebracht. In veel organisaties hebben medewerkers een verklaring omtrent het gebruik van IT-middelen ondertekend, daarin is vaak de mogelijkheid opgenomen om bij vermoedens van ontoelaatbare handelingen de computer of andere apparatuur te onderzoeken. Een dergelijke regeling moet overigens worden voorgelegd aan en goedgekeurd door de ondernemingsraad. Als een dergelijke regeling ontbreekt, is het alternatief de betreffende medewerker actief om toestemming te vragen.

Het raadplegen van persoonlijke documenten en correspondentie van een individuele medewerker zal bovendien in verhouding moeten staan tot het onderzoeksdoel (beginsel van proportionaliteit). Het mag verder niet zo zijn dat gewenste informatie ook op een andere, minder belastende, manier te verkrijgen is (beginsel van subsidiariteit).

Als aan de bovenstaande voorwaarden wordt voldaan en geen nodeloze inbreuk op de privacy wordt gedaan, dan is in Nederland een organisatie bevoegd om indien zij daartoe gegronde redenen heeft, de e-mail en andere bestanden van een werknemer te bekijken voor zover deze via een bedrijfsaccount verstuurd of ontvangen zijn. Daarbij mag de privacy niet meer aangetast worden dan noodzakelijk is voor het onderzoek.

Uitvoering onderzoek digitaal materiaal

Het onderzoeken van de digitale gegevens in een organisatie kan zeer relevante informatie opleveren over de mogelijke integriteitsschending. Als een dergelijk onderzoek echter onjuist wordt opgezet, bestaat er een aanzienlijke kans op het aanbrengen van onherstelbare schade. De risico’s bestaan voornamelijk uit de vernietiging of beschadiging van bewijsmateriaal, een zodanige behandeling van bewijsmateriaal dat de authenticiteit niet meer vast te stellen is of het onrechtmatig verkrijgen van bewijsmateriaal waardoor de latere bruikbaarheid in onder andere gerechtelijke procedures op losse schroeven komt te staan.

Een goed en bruikbaar onderzoek naar digitale gegevens zal in ieder geval moeten voldoen aan de onderstaande voorwaarden:

informeren van de betrokkenen over het onderzoek;
behoud van de integriteit van de digitale gegevens;
reproduceerbaarheid van bevindingen;
vermijden van disproportionele schending van de privacy van betrokkenen en van derden;
toepassing van hoor- en wederhoor;
naleving van wet- en regelgeving.

Deze voorwaarden worden hieronder nader toegelicht inclusief een korte beschrijving van de wijze waarop deze in de praktijk vorm worden gegeven.

Informeren betrokkenen

Als een onderzoek wordt uitgevoerd onder de accountantsrichtlijnen en gericht is op het (nalaten van) handelen door specifieke personen, dan dienen de richtlijnen van het persoonsgericht onderzoek aangehouden te worden. Eén van die richtlijnen is het zo spoedig mogelijk informeren van de betrokkenen over het uit te voeren onderzoek. Indien er een zwaarwegend onderzoeksbelang is, kan dit informeren tijdelijk worden uitgesteld. Dit uitstel dient wel zo veel mogelijk beperkt te worden.

Indien een betrokkene geïnformeerd wordt over het onderzoek bestaat de kans dat deze vervolgens belastend materiaal probeert te wijzigen of te verwijderen. Bestaat hierop een reële kans, dan kan onder bepaalde omstandigheden worden besloten om digitale informatie eerst veilig te stellen alvorens de betrokkene op de hoogte te stellen van het onderzoek. Als de informatie wordt veiliggesteld door een exacte kopie (een image) te maken dan hoeft de betrokkene hier niet eerder iets van te merken dan op het moment dat dit door de onderzoekers aan de betrokkene wordt gemeld.

Behouden integriteit gegevens

Moderne computers hebben de vanuit onderzoeksoogpunt lastige eigenschap dat onder invloed van tal van processen die automatisch gestart worden, de opgeslagen gegevens kunnen muteren en geactualiseerd worden. Een deel van die processen gaat al van start zodra het besturingssysteem opgestart wordt. Andere processen zorgen voor wijzigingen in de computer zodra een verbinding met het netwerk of het internet tot stand is gekomen of zodra een applicatie of een document geopend wordt. Herkenbare voorbeelden van dat laatste zijn de laatst geopende documenten in Windows en in Office-applicaties zoals Excel en Word. Theoretisch kan het zelfs zo zijn dat de inhoud van een computer vernietigd wordt zodra een ‘onbevoegde’ toegang probeert te krijgen.

Bij een politieonderzoek direct na een ernstig misdrijf wordt de ‘plaats delict’ onmiddellijk hermetisch afgegrendeld totdat de technische recherche haar werk heeft kunnen doen. Analoog daaraan dienen computers, smartphones en vergelijkbare apparatuur die onderzocht worden in het kader van een fraudeonderzoek zo identiek mogelijk te zijn aan de situatie waarin een betrokkene deze achtergelaten heeft. De eerste stap in de feitelijke uitvoering van een computerforensisch onderzoek is daarom, indien mogelijk, het maken van een volledige en letterlijke kopie van de originele gegevens. Daarbij gaat het vrijwel altijd om minimaal één harde schijf, eventueel aangevuld met een andere gegevensdrager zoals een ISB-stick. Dit proces wordt ‘imagen’ genoemd. Het verschil met een normale kopieeractie is dat (verborgen) systeeminformatie en gewiste bestanden behouden blijven in de image. Indien het origineel niet in de oorspronkelijke staat bewaard kan worden door de onderzoekers, wordt ook een tweede image gemaakt voor het verrichten van de feitelijke onderzoekswerkzaamheden.

Reproduceerbaarheid bevindingen

Indien in een onderzoek belastend materiaal wordt gevonden in de computer van een betrokkene, dan zou deze kunnen beweren dat het niet een originele versie betreft maar een versie die gemanipuleerd is door de onderzoekers of door collega’s.

Tegen een dergelijke bewering is uitsluitend verweer mogelijk als een nieuw onderzoek op basis van (dezelfde) authentieke gegevens tot dezelfde bevindingen leidt. Dit betekent in ieder geval dat vast moet staan waar en onder welke omstandigheden het bewijsmateriaal is aangetroffen en hoe dit bewijsmateriaal vervolgens is behandeld. Daarbij hoort ook een zorgvuldige vastlegging van de verrichte werkzaamheden. Op basis van deze vastlegging moet het mogelijk zijn de werkzaamheden volledig opnieuw uit te voeren waarbij dezelfde bevindingen naar voren komen.

In een computer-forensisch onderzoek zijn er vaak technische hobbels die genomen moeten worden. Het systeem dat door een betrokkene gebruikt is kan niet altijd gebruikt worden voor het onderzoek (bijvoorbeeld een server), waardoor een onderzoeker noodgedwongen een ander systeem zal moeten gebruiken voor het onderzoekswerk. Ook kan een onderzoeker oplopen tegen beveiligingsmaatregelen zoals wachtwoorden of encryptietechnieken waardoor de gegevens niet of moeilijker toegankelijk zijn. Als een organisatie haar ICT uitbesteed heeft, zorgt dit ook vaak voor complicaties, zeker als de digitale gegevens fysiek buiten Nederland worden opgeslagen. Het is belangrijk dat de wijze waarop met de hier genoemde zaken is omgegaan, ook vastgelegd wordt.

Vermijden van disproportionele schending privacy van betrokkenen en derden

Computers bevatten zeer veel informatie waaronder vaak ook heel persoonlijke informatie. Een groot deel van die informatie heeft geen betrekking op het onderzoek. Dit legt een grote verantwoordelijkheid bij de forensische onderzoeker om zich te beperken tot die informatie die relevant is, in het bijzonder als een computer ook bestanden van of over anderen bevat. Hier treedt echter een variant van het de-kip-of-het-ei-verhaal op. De relevantie van een document is pas te beoordelen nadat het document gelezen is. Maar alleen die documenten die relevant zijn mogen gelezen worden.

Op basis van het subsidiariteitsbeginsel is door Asscher en Steenbruggen (1996) de privacypiramide ontwikkeld. Zij hebben de onderstaande hiërarchie opgesteld in de mate waarin het doorzoeken van e-mail de privacy aantast. Met enige aanpassing kan een vergelijkbare indeling bij het doorzoeken van de persoonlijke bestanden van medewerkers worden gehanteerd. De piramide omvat de volgende zes niveaus (van hoog naar laag):

Inhoud
Scan op taal (d.w.z. het invoeren van zoektermen)
Scan op plaatjes (gericht op o.a. het wegfilteren van spam of pornografie)
Onderwerpregel
Attachments
Volume

Op basis van het subsidiariteitsbeginsel zal de onderzoeker moeten zoeken op een zo laag mogelijk niveau in de piramide om de privacy daarmee zo minimaal mogelijk te schaden. Als het volume van het aantal e-mails of de namen van de verzonden attachments voldoende informatie bieden, voor het doel van het onderzoek, is het niet noodzakelijk dat de onderzoeker naar een meer gedetailleerd niveau gaat en daarbij ook kennis van de onderwerpen van de e-mails of zelfs van de inhoud neemt.

Als e-mail en documenten doorzocht worden om de relevante gebeurtenissen in kaart te brengen, zal de onderzoeker zich waarschijnlijk door het ingeven van zoekwoorden op niveau 2 bevinden. In een onderzoek naar het lekken van informatie kan wellicht volstaan worden met zoekacties op niveau 5.

Toepassing van hoor- en wederhoor

Als het onderzoek uitgevoerd wordt als een persoonsgericht onderzoek geldt in ieder geval dat de betrokkene de mogelijkheid moet krijgen om op de inhoud van de bevindingen te reageren. Ook in andere gevallen verdient het aanbeveling om bevindingen door betrokkenen te laten verifiëren.

Hiermee wordt het risico op foutieve bevindingen beperkt. Het is bijvoorbeeld niet onaannemelijk dat in een computer-forensisch onderzoek blijkt dat met de account van gebruiker X bepaalde handelingen zijn verricht. Het is evenwel mogelijk dat zijn wachtwoord bij een collega bekend is en dat niet gebruiker X maar een collega de betreffende handeling heeft verricht. Als de betrokkene niet zelf bevestigt dat hij de handelingen heeft uitgevoerd, dan dient de betreffende handeling niet aan de gebruiker te worden toegeschreven maar aan zijn gebruikersaccount. Zelfs bij het toeschrijven aan een bepaalde account zal bekeken moeten worden of dit het gevolg kan zijn van manipulatie door iemand anders dan de betrokkene.

Naleving van wet- en regelgeving

Gedurende de opzet en de uitvoering van een computer-forensisch onderzoek zijn er nog diverse andere wetten die van toepassing kunnen zijn. Het is onmogelijk om hier een volledig overzicht van te geven maar hieronder volgen enkele aanvullende wetten en regels die bij een computer-forensisch onderzoek een rol kunnen spelen. Een aantal landen kent wetgeving die het uitvoeren van bepaalde gegevens naar het buitenland belemmert. Ook in Nederland is dit van toepassing op sommige financiële gegevens.

Het in bezit hebben van kinderpornografisch materiaal is expliciet strafbaar gesteld in Nederland. Bij het maken van een image worden alle gegevens op een informatiedrager overgenomen zonder dat vooraf bekend is welke gegevens hierop staan. Indien later zou blijken dat een gemaakte image kinderpornografisch materiaal bevat, dan is de onderzoeker feitelijk in het bezit van dat materiaal. In een voorkomend geval zal de onderzoeker daarom dan ook aangifte bij de politie moeten doen en met haar in overleg treden over wat met de gemaakte image moet gebeuren.

Conclusie

In dit artikel is een aantal risico’s beschreven met betrekking tot het onderzoeken van digitale informatie in het kader van een potentiële integriteitsschending. Daarnaast zijn uitgangspunten benoemd waaraan een computer-forensisch onderzoek in ieder geval moet voldoen. Twee specifieke aandachtspunten zijn daarbij van belang. Ten eerste dient het onderzoeksmateriaal technisch correct behandeld te worden en ten tweede dient de onderzoeker zich bewust te zijn van zijn bevoegdheden.

Voor organisaties die beschikken over een eigen afdeling voor het onderzoeken van integriteitsschendingen is het nuttig om medewerkers opgeleid en voorbereid te hebben in het omgaan met digitaal bewijsmateriaal. Indien specifieke en/of specialistische kennis niet aanwezig is om het gehele onderzoek zelfstandig te voltooien is het belangrijk de regiefunctie te behouden en toezicht te hebben op de in dit artikel genoemde aandachtspunten.

Voor organisaties waarbij het onderzoeken van digitale gegevens nog niet is geborgd in de interne regelingen verdient het aanbeveling dit onderwerp te inventariseren en er proactief beleid op te ontwikkelen. Indien een mogelijke integriteitsschending zich openbaart en verschillende informatiebronnen zijn formeel niet bruikbaar voor het onderzoek, dan kan dit de uitkomsten van het onderzoek ernstig schaden.

Literatuur

Mr. L.F. Asscher en mr. W.A.M. Steenbruggen, Het e-mailgeheim op de werkplek, NJB 2001 / 37.

P. van den Heuvel, E-mail op het werk, afstudeerscriptie Universiteit Utrecht, 2002.

Federated Identity Management, het perspectief van de IT-auditor

Identity & Access Management (IAM) is een vakgebied dat steeds professioneler wordt benaderd in de meeste moderne organisaties. Terwijl de volwassenheid van IAM-strategieën toeneemt, heeft zich een nieuwe grens afgetekend: Federated Identity Management of FIM. FIM definieert de verzameling overeenkomsten, standaarden en technologieën die het mogelijk maken identiteitsgegevens uit te wisselen over autonome domeinen. Naarmate de voordelen van FIM duidelijk worden, neemt de interesse toe in de vraag hoe FIM geïmplementeerd zou moeten worden en wat hierbij de belangrijkste aandachtspunten zijn. Door de belangrijkste aandachtspunten of ‘kenmerken’ van een FIM-implementatie in ogenschouw te nemen kunnen organisaties hun FIM op een betrouwbare wijze inrichten zodat IT-auditors dat op een effectieve wijze kunnen beoordelen.

Inleiding

In een wereld die steeds internationaler wordt, hebben steeds meer organisaties te maken met het immer toenemende tempo waarmee informatie met partners wordt uitgewisseld. Het effectief en efficiënt kunnen samenwerken met leveranciers en klanten, en tegelijkertijd ‘in control’ zijn over de informatiestromen, is één van de critical success factors geworden voor hedendaagse organisaties. Ook het beveiligen van toegang tot informatie is een belangrijk aandachtspunt voor moderne organisaties. Vanuit dit aandachtspunt zijn strategieën ontwikkeld voor het beheer van identiteiten en logische toegangsbeveiliging (Engels: Identity & Access Management, IAM) die van oorsprong gebaseerd zijn op een lokaal en afgeschermd beveiligingsdomein. Door het landschap van informatiebronnen te ‘verdelen’ in lokale domeinen, werd het mogelijk een nauwkeurig gedefinieerde groep gebruikers toegang te verlenen tot een nauwkeurig gedefinieerde groep bronnen. Echter, de toegang tot deze groep bronnen moet in de wereld van nu worden uitgebreid naar externe werknemers of vestigingen, autonome delen van de organisatie, externe partners en veel meer buitenstaanders. Zonder adequate beheersingsmaatregelen is te verwachten dat de risico’s voor veiligheid toenemen. De concepten, technische oplossingen en standaarden zijn inmiddels dermate ontwikkeld dat veilige en gecontroleerde uitwisseling van informatie tussen autonome entiteiten mogelijk is. Onder de noemer Federated Identity Management stelt dit organisaties in staat de toegang van partners tot hun bronnen te beheersen en om de bronnen van die partners te gebruiken.

Terwijl FIM sinds de introductie begin 2000 ([Norl02]) steeds meer wordt toegepast, zien IT-auditors en organisaties zich genoodzaakt een antwoord te vinden op de uitdagingen die dit nieuwe concept met zich meebrengt. Zowel de gebruikers als de organisaties kunnen significante voordelen behalen, gegeven dat de overeenkomstige risico’s adequaat worden beheerst. Dit artikel biedt een high-level handvat door inzicht in de belangrijkste kenmerken van een FIM-implementatie te geven. Deze kenmerken kunnen organisaties helpen bij het implementeren van een betrouwbare FIM-omgeving en IT-auditors bij het uitvoeren van een adequate audit op deze FIM-omgeving. Hierbij benadert dit artikel FIM vanuit het perspectief van de dienstverleners.

Wat is Federated Identity Management?

Beheer van identiteiten

Een identiteit is een ‘representatie van een entiteit in een specifiek applicatiedomein’ ([Jøsa05]). In een typische werkelijke situatie vertegenwoordigen entiteiten gewoonlijk juridische entiteiten (bijvoorbeeld natuurlijke personen of organisaties). Voorbeeld van een identiteit zouden de geregistreerde persoonlijke gegevens van een werknemer kunnen zijn, mogelijk aangevuld met enkele fysieke karakteristieken van die persoon, alle binnen het applicatiedomein van de werkgever. Een identiteit kan ook een systeem representeren. Identiteiten zijn opgemaakt uit een verzameling karakteristieken, identificators genaamd (zoals de accountID, naam en geboortedatum van een persoon). Binnen het beheer van identiteiten (Engels: Identity Management) nemen dienstverleners ofwel serviceproviders een belangrijke positie in. Een serviceprovider is ‘een entiteit die diensten verleent aan andere entiteiten. Voorbeelden van dit soort diensten zijn onder andere internettoegang, aanbieders van mobiele telefonie en hostingbedrijven voor webapplicaties.’ ([Wiki09])

Zoals Jøsang en Pope ([Jøsa05]) beschrijven is het toegestaan een entiteit te koppelen aan nul of meer identiteiten binnen een gegeven domein. Het is bijvoorbeeld mogelijk dat een natuurlijk persoon zowel geregistreerd is als een werknemer van een productiebedrijf, als dat deze persoon klant is van datzelfde bedrijf. Hoewel het noodzakelijk is dat er een unieke identificator bestaat die gebruikt kan worden om de entiteit te herkennen (gedeelde identiteiten mogen niet bestaan als auditability vereist is), is het natuurlijk wel toegestaan dat een entiteit meerdere identiteiten heeft verspreid over meerdere domeinen. FIM biedt de mogelijkheid diensten te verlenen aan een enkele entiteit die meerdere identiteiten kent. Figuur 1 illustreert hoe een entiteit gekoppeld kan zijn aan meerdere identiteiten en hoe iedere identiteit op haar beurt opgemaakt kan zijn uit meerdere unieke of niet-unieke identificators.

C-2010-1-Guensberg-01

Figuur 1. De relatie tussen entiteiten (entities), identiteiten (identities) en identificators (identifiers).

Identity & Access Management

Identity and Access Management (IAM) definieert de processen en technologie voor het creëren, beheren van de levenscyclus (Engels: life cycle management), propageren (Engels: provisioning) en monitoren van digitale identiteitsgegevens teneinde conform het beleid van de organisatie toegang te verlenen tot informatie. Hermans ([Herm05]) definieert IAM als: ‘Het beleid, de processen en de onderliggende technologie voor het effectief en efficiënt beheren en beheersen van wie toegang heeft tot wat binnen een organisatie’. Met andere woorden, IAM definieert wie je bent, beheerst wat je kunt doen en wat niet, en faciliteert het monitoren van compliance en audits op basis van deze informatie; alle binnen de context van het lokale beveiligingsdomein (dus de diensten die in scope zijn verklaard). Merk op dat IAM niet noodzakelijk beperkt is tot informatiesystemen. Integendeel: bijna alle IAM-oplossingen kunnen even gemakkelijk toegang beheersen tot logische als tot fysieke diensten.

Op dit moment zijn er twee overheersende IAM-modellen ([Jøsa05]):

Het model van de geïsoleerde gebruikersidentiteit (momenteel het meestgebruikte IAM-model) vereist dat iedere dienst een identificator en inlogcombinatie (gebruikersnaam en wachtwoord) hanteert voor de gebruikers van die dienst. De serviceprovider beheerst de naamgevingen binnen een lokaal beveiligingsdomein en wijst identificators toe aan gebruikers. Gebruikers zijn aan een unieke identificator gekoppeld (bijvoorbeeld het accountnummer) voor iedere logische of fysieke dienst waarvan zij gebruikmaken. Aparte inlogcombinaties worden gehanteerd voor de unieke identificators. Het voordeel van dit model is dat het een relatief eenvoudige benadering biedt tot IAM omdat het beheer van identiteiten per serviceprovider in de meeste gevallen overzichtelijk is. Het nadeel echter is dat gebruikers zelf moeten bijhouden van welke verschillende diensten zij gebruikmaken en wat de identificators en inlogcombinaties zijn die daarbij horen.
Het model van de gecentraliseerde gebruikersidentiteit maakt gebruik van één aanbieder van identificators en de bijbehorende inlogcombinaties. Deze dienst kan vervolgens gebruikt worden door alle andere dienstverleners in het domein; ofwel als een extra aanbieder van identificators en/of inlogcombinaties, ofwel exclusief door de serviceprovider. Een uitbreiding van het model van de gecentraliseerde gebruikersidentiteit wordt bereikt door een gebruiker die door een vertrouwde serviceprovider is gecontroleerd ook voor andere serviceproviders als geauthenticeerd te beschouwen. Dit wordt gewoonlijk een Single Sign-On (SSO)-oplossing genoemd, omdat de gebruiker zich slechts eenmalig hoeft te authenticeren (één enkele inlogactie is vereist) om alle diensten te gebruiken.

Om het gecentraliseerde model te kunnen gebruiken, is het nodig de informatie over identiteiten onderling te delen in een federatie. FIM, een optionele component in een IAM-raamwerk, maakt dat mogelijk. Federated Identity Management bestaat uit de verzameling overeenkomsten, standaarden en technologieën die het mogelijk maken identiteitsgegevens uit te wisselen over autonome domeinen en op een veilige en beheerste wijze. De volgende onderdelen van een FIM vallen op:

Overeenkomsten, standaarden en technologieën. Alhoewel de technische voorzieningen belangrijk zijn, is FIM met nadruk afhankelijk van samenwerking op basis van vertrouwensrelaties.
Identiteitsgegevens. De uitwisseling van identiteiten en inlogcombinaties staat samenwerking met partners toe, terwijl de partners ‘in control’ kunnen blijven ten aanzien van de autorisaties en de toegang van gebruikers tot informatie.
Over autonome domeinen. Deze domeinen kunnen zich buiten de grenzen van de organisatie bevinden (externe partijen), maar zij kunnen zich ook bevinden binnen de grenzen van de organisatie (bijvoorbeeld in de keten van dienstverlening binnen de organisatie zelf). Implementatie van FIM binnen de organisatie zelf is een recente ontwikkeling die in het bijzonder van belang is binnen overheidsomgevingen (dit wordt in dit artikel verder niet uitgediept).

Federated Identity Management

In een FIM-raamwerk maken overeenkomsten tussen verschillende serviceproviders het mogelijk dat identiteiten die niet door de serviceprovider maar door afzonderlijke identiteitsverleners ofwel identityproviders worden beheerd, worden herkend over alle domeinen die onderdeel zijn van het FIM-raamwerk. Zulke overeenkomsten omvatten het beleid en de standaarden die gebruikt dienen te worden. Een identityprovider is de dienst of organisatie die verantwoordelijk is voor het vaststellen (authenticeren) van de identiteit van een gebruiker ten behoeve van zowel de lokale diensten als de diensten van externe partijen. Een serviceprovider verleent een dienst aan gebruikers en maakt daarbij gebruik van een identityprovider die, namens de serviceprovider, de authenticatie en het verzamelen van gebruikersattributen verzorgt. Hoewel autorisatie niet bij de identityprovider plaatsvindt maar bij de serviceprovider, levert de identityprovider in veel gevallen de voor autorisatie vereiste informatie die door de serviceprovider wordt gebruikt bij het wel of niet verlenen van toegang tot bepaalde informatie.

C-2010-1-Guensberg-02

Figuur 2. Conceptueel overzicht van het FIM-concept en de vertrouwensrelaties tussen gebruiker, identityprovider en serviceprovider.

Figuur 2 toont een conceptueel overzicht van het FIM-concept. De figuur illustreert ook hoe de vertrouwensrelaties zijn opgebouwd tussen de gebruiker en de identityprovider, respectievelijk de identityprovider en de serviceprovider. FIM maakt het mogelijk dat beide vertrouwensrelaties worden getransporteerd naar een vertrouwensrelatie tussen de dienstverlener en de gebruiker. Nadat de gebruiker een bewijs van authenticiteit heeft overgelegd aan de identityprovider, bepaalt de identityprovider dat de gebruiker inderdaad geauthenticeerd is. Vervolgens wordt door de identityprovider een verklaring (Engels: assertion) afgegeven aan de serviceprovider die de informatie uit die verklaring kan gebruiken om de gebruiker verder te autoriseren. De dienst kan vervolgens verleend worden conform afspraak.

Aandachtsgebieden binnen een FIM-omgeving

Organisaties zetten FIM-oplossingen vandaag de dag steeds vaker in voor het op een beheerste wijze uitwisselen van informatie over autonome domeinen. Zo ook wordt steeds meer praktijkervaring opgedaan met de voor- en nadelen van FIM-oplossingen. Op basis van deze ervaring kan een aantal ‘good practices’ worden onderkend. Zoals reeds aangegeven omvat een FIM-omgeving de organisatorische, procesmatige en technologische aspecten. In deze paragraaf zijn de ‘good practices’ per aspect inzichtelijk gemaakt.

Organisatorische kwaliteiten

Een FIM-omgeving heeft idealiter de volgende organisatorische kwaliteiten ([Comp09] [Praa04] [Auth09]):

De eerste stap richting FIM is de definitie van de FIM-businesscase. Alleen als er een businesscase is gedefinieerd, zullen de belanghebbenden de mogelijke voor- en nadelen kunnen inschatten en kunnen bepalen wat de kosten zijn die zij bereid zijn te nemen om die voordelen te behalen en de risico’s adequaat te beheersen. De betrokken organisaties moeten tot de conclusie komen dat het loont om samen te werken, waarna zij de obstakels één voor één in overleg moeten adresseren. Aansprakelijkheid moet duidelijk gedefinieerd zijn in overeenkomsten tussen de federatiepartners, inclusief aansprakelijkheidslimieten als gevolg van veiligheidsincidenten, fouten, etc.
Er moet een solide vertrouwensbasis bestaan die wordt ondersteund door ondubbelzinnige toewijzing van rollen en verantwoordelijkheden (bijvoorbeeld in een RACI-matrix). De partijen in de federatie moeten audits toestaan van hun respectievelijke FIM-domeinen op basis van vooraf afgesproken beheersingsmaatregelen en uniforme auditprocedures. Net zoals dat bij outsourcing gebeurt, kunnen SAS 70-rapporten of Third-Party Mededelingen (TPM’s) worden gebruikt om de vertrouwensrelatie te waarborgen. Eigenaarschap van processen en objecten moet duidelijk gedefinieerd zijn en door de federatiepartners worden onderschreven.
Het is belangrijk dat er een beveiligingsraamwerk bestaat om de high-level beveiligingsvereisten te definiëren waar gebruikers en beheerders aan moeten voldoen. Een FIM-beveiligingsbeleid is idealiter onderdeel van het generieke (informatie)beveiligingsbeleid van de organisatie. Het beleidsdocument moet op basis van de ontwikkelingen in IT worden bijgehouden en van toepassing zijn op de federatie en de federatiepartners. Het stimuleert het verbeteren van de bekendheid met het beleid zelf (awareness) en beschrijft de vereisten voor het voldoen aan de wet- en regelgeving die van toepassing zijn binnen de federatie. Beveiligingsproblemen in de federatie kunnen de risico’s van fraude, (identiteits)diefstal en interpretatiefouten doen toenemen als partijen foutieve informatie aan elkaar doorgeven en op die informatie vertrouwen.
Problemen in het partnerschap kunnen alleen voorkomen worden als de organisaties investeren in het ondubbelzinnig vastleggen van rollen en verantwoordelijkheden in gemeenschappelijk geaccordeerde en geaccepteerde overeenkomsten. Dergelijke overeenkomsten bevatten afspraken die bepalen wie wat mag of moet doen, wie waarvoor betaalt en wie waarvan profiteert. Overeenkomsten moeten op zijn minst adresseren wat het bereik is van het vertrouwde domein (de overkoepelende doelstellingen, belanghebbenden, procesvereisten per partner), wat de expliciete overeenkomsten zijn voor auditing en op welke wijze de afspraken gewijzigd kunnen worden (meta-overeenkomsten).
De FIM-omgeving moet voldoen aan de relevante in- en externe privacywet- en regelgeving. Idealiter ligt de controle over het gebruik van eigen gegevens bij de gebruiker zelf.
Toewijding van het management moet waarborgen dat de beveiliging van FIM adequaat wordt geadresseerd in het FIM-businessplan en dat overeenstemming wordt bereikt over de toewijzingen van taken en verantwoordelijkheden in FIM-beveiliging. Dit geldt voor de organisatorische, procesmatige en technologische beheersingsmaatregelen en de wijze waarop FIM-beveiligingsinitiatieven worden ondersteund.

Procesmatige kwaliteiten

Een FIM-omgeving heeft idealiter de volgende procesmatige kwaliteiten ([Praa04]):

Gebruikers moeten uniek identificeerbaar zijn binnen de federatie om auditability van gebruikersactiviteit te kunnen waarborgen. De levenscyclus van de gebruiker moet conform afgesproken tijdigheid in de identity repository worden gereflecteerd, inclusief het deactiveren of verwijderen van identificators als een gebruiker definitief of tijdelijk uit dienst gaat.
Adequate maatregelen moeten waarborgen dat de sterkte van authenticatie binnen de federatie geïmplementeerd is conform de afspraken die daarover bestaan; alle partners hanteren een equivalent wachtwoordbeleid dat ten minste het volgende omvat: wachtwoordcomplexiteit en update regels, lockout na herhaaldelijk foutief inloggen en beveiligde opslag van wachtwoorden. Gemeenschappelijke overeenkomsten moeten bestaan zodat ondubbelzinnige classificatie van authenticatievereisten en -maatregelen wordt bereikt, inclusief de diensten die mogen worden verleend op basis van een bepaald authenticatieniveau van de gebruiker. Auditing van de authenticatiemiddelen moet zodanig frequent plaatsvinden dat technologische ontwikkelingen worden gereflecteerd in de sterkte van de gebruikte middelen. Audits moeten ten minste gericht zijn op het productieproces, de aanvraagprocedure, het uitgifteproces en het beheer van de authenticatiemiddelen die de partners gebruiken.
De functionaris die verantwoordelijk is voor het aanmaken, wijzigen en intrekken van autorisaties moet alle autorisaties documenteren die direct of indirect (bijvoorbeeld via rollen) aan gebruikers zijn toegewezen in een autorisatiematrix of vergelijkbare administratie. Procedures moeten bestaan om de administratieve processen rondom het aanmaken, wijzigen en verwijderen van autorisaties te beheersen inclusief vereiste accordering. De autorisatiematrix (SOLL) moet periodiek worden vergeleken met de werkelijke autorisaties (IST) in een representatieve steekproef van de beschikbare diensten. Het resultaat daarvan dient periodiek door het hogere management te worden geaccordeerd.
Op basis van een risicoanalyse moeten gevoelige wijzigingen in de identificatie- en authenticatiegegevens worden gemonitord en opgeslagen (bijvoorbeeld het aanmaken, uitlezen, wijzigen of verwijderen van gebruikers met bijzondere rechten). De monitoringinstellingen moeten periodiek gecontroleerd worden door het management van de informatiebeveiligingsafdeling. Monitoringrapportages moeten op een beveiligde locatie worden opgeslagen welke het onmogelijk maakt voor ongeautoriseerde gebruikers om deze rapportages aan te passen. Verantwoordelijkheden moeten zijn toegewezen voor het controleren van monitoringalarmsignalen en -rapportages, en voor het nemen van adequate actie in geval aan de daarvoor gedefinieerde condities wordt voldaan (als bijvoorbeeld sprake is van een daadwerkelijke inbraak).
In federaties hebben de partners relatief veel controle over de verleende toegang tot de objecten van de auditee. Wegens de belangrijke functie van monitoring en audit bij het bereiken en handhaven van de wederzijdse vertrouwensrelatie, die voor een goed functionerende federatie vereist is, moeten er periodiek onafhankelijke audits plaatsvinden. Deze audits moeten worden uitgevoerd conform de daarover door middel van de FIM-overeenkomst gemaakte afspraken. Auditing biedt de mogelijkheid voor federatiepartners om de kwaliteit te controleren van de toegangsprocessen van hun gelijken. Dit is essentieel voor het bereiken van het vertrouwen dat de partners hun medewerking verlenen aan dergelijke audits. De IT-auditor dient bij het beoordelen van de federatie rekening te houden met de (on)volwassenheid van de federatiepartners en eventuele compenserende maatregelen.
Adequate functiescheiding (Engels: Segregation of Duties, SoD) moet bestaan om te voorkomen dat gebruikers waarde aan de organisatie kunnen onttrekken zonder dat dit wordt opgemerkt. Op basis van een risicoanalyse moet worden voorkomen dat bijzondere rechten als gevolg van onbedoelde combinaties in de verdeling van rechten een beveiligingsrisico opleveren. De functionaris die verantwoordelijk is voor het aanmaken, wijzigen en intrekken van autorisaties mag niet in staat zijn aanpassingen te doen zonder dat het management daarvan voor- of achteraf op de hoogte wordt gesteld.

Technologische kwaliteiten

Een FIM-omgeving heeft idealiter de volgende technologische kwaliteiten ([Kuip08] [Blak08] [Davi07] [Ping09]):

Een federatie zou moeten bestaan uit partijen die zo los mogelijk verbonden zijn (Engels: loosely coupled): actueel decentraal beheer van identiteiten verdient de voorkeur boven gedeelde verouderde identity repositories. Het gebruik van gemeenschappelijk afgesproken technologie is cruciaal voor het bereiken van FIM, maar de uitwisselbaarheid van de door de IAM-tooling geboden functionaliteit is dat evenzeer.
Omdat standaardisatie van technologie essentieel is voor federaties, moet de auditee continu de laatst beschikbare technologische standaarden blijven overwegen, zoals SAML 2.0 (identiteitsattributen), XACML (interpretatie van uitgewisselde (SAML-) gegevens), SPML (uitwisseling van gebruiker, object en service-provisioninginformatie) en SOAP (transport van op XML gebaseerde berichten). Hoewel het voorbereid zijn op meerdere standaarden de interoperabiliteit van een organisatie zal vergroten, zullen de kosten en complexiteit waarschijnlijk ook toenemen.
Er moet een technische federatieovereenkomst gehanteerd worden, waarin ten minste het volgende is gedefinieerd: gebruik, opslag en definitie van identiteitsattributen, de gebruikte risiconiveaus, sterkte van authenticatie en toegestane identityproviders per dienst, het verwerken van autorisaties door de serviceprovider (bijvoorbeeld individuele versus functionele accounts), vereisten aan de veiligheid van opgeslagen, verwerkte of verzonden gegevens, de te gebruiken standaarden en de vereisten aan certificering van alle partners (bijvoorbeeld het gebruik van PKI of een vergelijkbaar mechanisme voor veilige communicatie).
Er moet een gemeenschappelijk change-managementbeleid inzake FIM worden gebruikt door alle partners in de federatie, waarin ten minste het volgende wordt geadresseerd: de documentatie, autorisatie en uitvoering van (nood)wijzigingen, het proces van testen en aftekenen inclusief testdocumentatie en het scheiden van ontwikkel-, test-, acceptatie- en productieomgevingen inclusief eventuele uitzonderingsprocedures voor directe wijzigingen in de productieomgeving.
Er moet een definitie zijn van voor de federatie gekozen topologie. Mogelijke federatietopologieën zijn: point-to-point (ofwel: ‘één-op-één’), mesh (ofwel: ‘verbonden’), star (ofwel: ‘as en spaak’) en gecentraliseerd. Hoewel partnerships in een federatie gewoonlijk niet op een hiërarchische wijze zijn opgebouwd, is een verzameling van federaties (een confederatie) dat vaak wel.
Er moet een definitie zijn van de voor de federatie gekozen implementatie. Mogelijke implementatieopties zijn: proprietary (het ontwikkelen van een eigen oplossing), open source, een op standaarden gebaseerde federatieserver of uitbreiding van een bestaande IAM-suite.

FIM is gebaseerd op gedeeld vertrouwen, niet noodzakelijkerwijs op gedeelde technologieën. De FIM-technologieën hebben een ondersteunende functie ten opzichte van de vertrouwensrelatie in de federatie.

Conclusies en slotnotitie

Dit artikel laat zien dat het concept van FIM een waardevolle oplossing kan bieden voor een scala aan uitdagingen voor moderne organisaties die op een beheerste wijze informatie willen delen met externe partners buiten hun beveiligingsdomein. De volgende conclusies kunnen worden getrokken uit het in dit artikel gepresenteerde onderzoek.

De stand van zaken

Wat betekent FIM voor moderne organisaties? Wordt het gebruikt? Hoe?

Het concept van FIM heeft op dit moment een behoorlijk definitief stadium bereikt en het samensmelten van standaarden heeft met SAML 2.0 plaatsgevonden. De businesscase voor federatie wordt in toenemende mate gebaseerd op gebruikersgemak, efficiency en effectiviteit, doordat de externe processen van organisaties duidelijk ondersteund worden door deelname aan een federatie.

Voorbeelden van FIM-implementaties zijn momenteel gemakkelijker te vinden in de onderwijs- en overheidsomgevingen dan in de commerciële bedrijfsmatige omgeving. Volwassenheid zou een voorwaarde kunnen worden als de organisaties betrokken zijn in fusies en overnames; niet alleen de volwassenheid van FIM zal in dat geval een rol spelen, ook de algemene IAM-volwassenheid van de andere partijen.

De meeste auditkantoren bemerken een langzame toename van FIM-gerelateerde opdrachten in het internationale speelveld. Het nadeel van de eerste oplossingen voor logische identificatie was vaak dat de hele ‘portemonnee’ moest worden gepresenteerd, waardoor de serviceprovider irrelevante attributen moest verwerken en de gebruiker zich onnodig gedwongen zag persoonlijke informatie kenbaar te maken. FIM biedt hier in potentie oplossingen voor. Het IAM-onderzoek dat in 2008 door KPMG is uitgevoerd, vermeldt ([KPMG08]): ‘In de meeste organisaties van de respondenten zijn IAM-projecten gericht op het beheer en beheersen van toegang door werknemers en externen tot interne systemen en informatie. Federated Identity Management, de grensoverschrijdende verbinding van IAM-omgevingen, wordt in de meerderheid van de organisaties van respondenten nog niet in brede zin gebruikt.’

In tegenstelling tot de meeste bedrijven is de overheid een organisatie die bestaat uit een groot aantal redelijk autonome suborganisaties. De IT-omgevingen van de overheid bevatten tegelijkertijd een groot aantal legacy systemen en state-of-the-arttechnologie zoals webportals op het intranet en, in toenemende mate, ook op het internet. De overheid ziet in dat er een behoefte zal bestaan aan samenwerking via FIM als de decentrale IAM-initiatieven volwassen zijn geworden.

Auditaandachtspunten

Wat zijn de belangrijkste aandachtspunten voor de IT-auditor en auditee in FIM-gerelateerde audits?

De belangrijkste aandachtspunten voor de IT-auditor en auditee betrokken bij FIM-audits zijn afgeleid van de eerder beschreven good practices rondom FIM. De aandachtspunten kunnen gegroepeerd worden in clusters die betrekking hebben op de organisatie, processen en technologie van een organisatie.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de organisatie hebben te maken met de vertrouwensrelatie en het gegeven dat deze door een heldere businesscase moet worden ondersteund, met de wederzijds aangenomen en gehandhaafde beveiligingsraamwerken en met de toewijzing van verantwoordelijkheden en betrokkenheid van het management. FIM-overeenkomsten moeten bestaan en compliance met de relevante in- en externe wet- en regelgevingen moet worden bewaakt (bijvoorbeeld door de eindgebruiker de controle te laten voeren over eigen gegevens). Commitment van het management zorgt ervoor dat de beveiliging van FIM voldoende wordt geadresseerd.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de processen hebben te maken met de unieke identificatie van gebruikers en de eenduidige implementatie van de authenticatie- en autorisatieprocessen. Auditen van de authenticatiemiddelen en IST/SOLL-vergelijkingen moeten op voldoende regelmatige basis plaatsvinden en worden opgevolgd. Wijzigingen in de identificatie en authenticatiegegevens moeten worden gemonitord en adequate functiescheiding moet van kracht zijn.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de technologie hebben te maken met het los verbinden van federatiepartners (loose coupling) en het gebruik van passende technologische standaarden. Een technische federatieovereenkomst moet bestaan, evenals een change-managementbeleid inzake FIM en een definitie van de federatietopologie en de gekozen aanpak voor implementatie.

FIM-gerelateerde audits moeten, zo nodig periodiek, plaatsvinden op basis van een vooraf gedefinieerde frequentie. Auditinspanningen moeten altijd worden ontplooid op basis van een risicoanalyse om de juiste inzet van middelen te bepalen.

De belangrijkste kwaliteiten van een FIM-raamwerk

Dit artikel biedt een praktisch high-level handvat voor zowel de organisaties die hun FIM-raamwerken geaudit weten als de IT-auditors die een dergelijke audit uitvoeren.

Een goed FIM-ontwerp en een goede FIM-implementatie kunnen door de auditee worden bereikt door de hier volgende kwaliteiten te waarborgen. Overeenkomstig hiermee zou een IT-auditor de volgende belangrijkste aandachtspunten in een FIM-audit moeten betrekken om tot een gedegen audit te komen.

Een FIM-omgeving heeft idealiter de volgende organisatorische kwaliteiten:
- De FIM-businesscase is helder gedefinieerd voorafgaand aan implementatie.
- Er bestaat een solide vertrouwensrelatie tussen de federatiepartners.
- Er is een beveiligingsraamwerk van kracht om de high-level vereisten aan beveiliging te beheersen.
- De federatiepartners hebben op ondubbelzinnige wijze de vereiste rollen en verantwoordelijkheden vastgelegd in wederzijds geaccordeerde en aangenomen overeenkomsten.
- De auditee voldoet aan de relevante in- en externe (privacy) wet- en regelgeving. Idealiter heeft de gebruiker zelf de controle over de informatie die over hem of haar wordt gebruikt.
- Betrokkenheid van het management waarborgt een adequate aanpak voor FIM-beveiliging.
Een FIM-omgeving heeft idealiter de volgende procesmatige kwaliteiten:
- Gebruikers zijn overal in de federatie altijd uniek identificeerbaar.
- Sterkte van authenticatie is op eenduidige wijze geïmplementeerd in de federatie.
- De autorisatiematrix (SOLL) wordt periodiek vergeleken met de werkelijke autorisaties (IST).
- Wijzigingen in gevoelige identificatie- en authenticatiegegevens worden gemonitord en opgeslagen.
- Er vinden periodieke onafhankelijke audits plaats.
- Er bestaat adequate functiescheiding.
Een FIM-omgeving heeft idealiter de volgende technologische kwaliteiten:
- De federatie bestaat uit partijen die zo los mogelijk verbonden zijn (loose coupling).
- De laatst beschikbare technologische standaarden worden gebruikt.
- Een technische federatieovereenkomst wordt gehanteerd.
- Er is een gemeenschappelijk change-managementbeleid inzake FIM aangenomen door de federatiepartners.
- De federatietopologie is gedefinieerd.
- De gekozen federatie-implementatie is gedefinieerd.

Merk op dat zowel het adresseren van de belangrijkste kwaliteiten door de auditee als de beoordeling daarvan door de IT-auditor zou moeten plaatsvinden op basis van een voorafgaande risicoanalyse en een afweging van de voor- en nadelen van de kwaliteiten.

Slotnotitie

Hoewel FIM slechts gericht is op een beperkt onderdeel van de complete uitdaging, namelijk de uitwisseling van identiteitsgegevens tussen autonome domeinen, zijn de mogelijkheden op zijn minst veelbelovend te noemen. Echter, voordat organisaties FIM gaan implementeren zouden zij de in dit artikel genoemde belangrijkste kwaliteiten in ogenschouw moeten nemen. Hierbij kunnen de hier gepresenteerde high-level handvatten worden uitgewerkt naar de specifieke situatie van de auditee; concepten zoals ‘voldoende frequent’ worden dan vertaald naar een concrete meetbare indicator.

[Auth09] http://www.authenticationworld.com/Authentication-Federation/CreatingAFederatedAuthenticationTrust.pdf (laatst bezocht september 2009).

[Blak08] Bob Blakley, Dan Blum en Gerry Gebel, Federated Identity – Reference Architecture Technical Position, Burton Group, 2008.

[Comp09] http://www.computerworld.com.au/index.php/id;162794021;fp;2;fpid;2 (laatst bezocht september 2009).

[Davi07] Claire Davies en Matt Shreeve, Federated access management: international aspects, Curtis+Cartwright Consulting Limited, 7 juni 2007.

[Herm05] Ing. J.A.M. Hermans RE en drs. J. ter Hart, Identity & Access Management: operational excellence of ‘in control’?, Compact 2005/3.

[Jøsa05] A. Jøsang en S. Pope, User-Centric Identity Management, Proceedings of AusCERT mei 2005, Brisbane, Australia.

[KPMG08] KPMG, 2008 European Identity & Access Management Survey, KPMG, 2008.

[Kuip08] Jaap Kuipers, eID Convergence challenges (slide 8), SURFnet/ECP.NL, 2008.

[Norl02] Eric Norlin en Andre Durand, Federated Identity Management, Whitepaper, PingID Network, 2002.

[Ping09] http://www.pingidentity.com/information-library/Federated-Identity-Management-Tutorial.cfm (laatst bezocht september 2009).

[Praa04] Jan van Praat en Hans Suerink, Inleiding EDP-auditing, Ten Hagen & Stam uitgevers, 2004.

[Wiki09] http://en.wikipedia.org/wiki/Service_provider (laatst bezocht september 2009).

Onlinebronnen

Ten slotte wordt hier een aantal websites opgesomd die aanknopingspunten vormen voor vervolgonderzoek en praktische toepassing van de theoretische concepten uit dit artikel:

http://openid.net/what/ – Deze website presenteert het OpenID-concept dat besproken wordt in dit artikel en dat een lezer een eerste aanraking biedt met de mogelijke voordelen van deze techniek.
http://www.inames.net/ – Deze website presenteert het i-name-concept van identificators die voor mensen gemakkelijk te onthouden zijn. Ze zijn ontworpen om het probleem van permanente adressering op te lossen; hoe kan een onlineadres worden gecreëerd dat niet onderhouden hoeft te worden en dat nooit verandert ongeacht hoe vaak de contactgegevens van de eigenaar veranderen.
http://identity20.com/media/OSCON2005/ – Dick Hardt’s OSCON 2005 Keynote getiteld Identity 2.0: dit is een inspirerende en dynamische introductie van Identity 2.0 en laat zien hoe het concept van digitale identiteiten zich aan het ontwikkelen is.
http://www.identityblog.com/?p=352 – Kim Cameron’s whitepaper getiteld The Laws of Identity: een verzameling ‘wetten’ die zouden moeten gelden voor de personen die werken met identiteiten. Door deze wetten te respecteren, zo beargumenteert Cameron, is het mogelijk een verenigd systeem te creëren dat universeel geaccepteerd wordt en duurzaam is.

Data Leakage Prevention

De hoeveelheid digitale informatie binnen bedrijven, die ook in toenemende mate gevoelige informatie bevat, neemt dagelijks toe. Aangezien het lekken van gevoelige informatie, een data leakage incident, een grote impact kan hebben op zowel het bedrijf als de getroffen personen, is het belangrijk de juiste preventieve en recessieve maatregelen te nemen. Het nemen van maatregelen wordt meer en meer vanuit wet- en regelgeving afgedwongen. Om een data leakage incident te voorkomen is het belangrijk organisatorische maatregelen te nemen zoals het opstellen en implementeren van een informatiebeveiligingsbeleid en het classificeren van informatie. Naast het uitvoeren van de organisatorische maatregelen kan een Data Leakage Prevention (DLP)-softwarepakket helpen het risico van lekken te verkleinen.

Inleiding

De steeds grotere hoeveelheden digitaal opgeslagen (gevoelige) informatie in combinatie met een transparantere manier van werken binnen organisaties brengt een verhoogd risico tot lekken van deze informatie met zich mee. Het is immers steeds gemakkelijker om allerlei informatie te raadplegen en moderne communicatiemiddelen maken ook het uitwisselen steeds eenvoudiger. De gevolgen van data leakage kunnen enorm zijn. Stel, de gevolgen voor zowel het bedrijf als de getroffen personen eens voor wanneer creditkaartgegevens op straat komen te liggen. Het lekken van informatie gaat gepaard met flinke imagoschade en er kunnen aanzienlijke financiële gevolgen mee gemoeid zijn. Onderzoek heeft uitgewezen dat niet alleen het aantal incidenten toeneemt, maar dat ook de financiële gevolgen steeds groter worden. Het is dan ook niet verrassend dat ander onderzoek uitwijst dat databescherming één van de belangrijkste drijfveren is voor informatiebeveiliging.

In dit artikel wordt eerst een overzicht gegeven van de risico’s en gevolgen die gepaard gaan met het lekken van gevoelige informatie. Er zal onderscheid worden gemaakt tussen de oorzaken van het lekken en de gevolgen daarvan. Het belang om maatregelen te treffen zal worden geïllustreerd met gegevens uit relevant onderzoek en met praktijkvoorbeelden. In toenemende mate worden maatregelen ook afgedwongen vanuit wet- en regelgeving, en daarvan zal een kort overzicht worden gegeven. Daarna wordt ingegaan op de werking en het nut van Data Leakage Prevention (DLP)-softwarepakketten.

Risico’s, gevolgen en oorzaken

De meeste data leakage incidenten worden pas opgemerkt wanneer negatieve gevolgen optreden. Dit is precies de reden waarom het onmogelijk is de exacte omvang van het aantal data leakage incidenten te bepalen. Uit recentelijk door KPMG uitgevoerd onderzoek ([Mars09]) bleek dat alleen al in de laatste drie maanden van 2008 de persoonlijke gegevens van 47,8 miljoen mensen op straat waren komen te liggen in een totaal van 404 waargenomen incidenten.

Bij de term data leakage wordt vaak ten onrechte alleen aan hackers gedacht die (digitaal) inbreken om zo toegang tot gevoelige informatie te verkrijgen. Een minstens even belangrijke oorzaak van data leakage zijn de eigen medewerkers en zakenpartners. Bij het lekken van gevoelige informatie kunnen we onderscheid maken tussen de volgende vormen:

Onbewust lekken. Lekken als gevolg van een fout, bijvoorbeeld met e-mail waarbij de verkeerde bijlage of de verkeerde ontvanger wordt geselecteerd.
Bewust lekken. Werknemers die de regels kennen maar deze toch overtreden zonder dat ze uit zijn op persoonlijk gewin, bijvoorbeeld door gevoelige informatie naar een privéaccount te mailen met het oog op thuis werken.
Kwaadaardig lekken. Zowel een medewerker als een extern persoon kan hieraan ten grondslag liggen. Met voorbedachten rade informatie langs de beveiliging smokkelen met als doel persoonlijk gewin.

Het is niet altijd duidelijk wat allemaal als gevoelige informatie beschouwd kan worden. Erg breed uitgezet kan hierbij gedacht worden aan alle informatie die door een andere partij misbruikt kan worden voor persoonlijk of bedrijfsmatig gewin of waardoor het betreffende bedrijf er nadeel van kan ondervinden. In tabel 1 wordt onderscheid gemaakt tussen een aantal verschillende vormen van gevoelige informatie ([Herm09]).

C-2009-4-Vliet-t01

Tabel 1. Verschillende vormen van gevoelige informatie.

De gevolgen van een data leakage incident hangen af van het type data dat gelekt is, maar kan onderverdeeld worden tussen de gevolgen voor personen en de gevolgen voor bedrijven. Bij het lekken van persoonsgegevens kunnen de betreffende personen slachtoffer worden van identiteitsdiefstal. Bij identiteitsdiefstal is men uit op persoonlijk gewin door zich voor te doen als iemand anders. Het slachtoffer kan dan geassocieerd worden met acties welke hij of zij nooit heeft uitgevoerd. Voor bedrijven is het scala aan mogelijke gevolgen veel groter:

verlies van uitstraling en reputatieschade;
verlies van concurrentievoordeel;
vertrouwensverlies bij huidige en toekomstige klanten;
verlies in marktwaarde door vermindert aandeelhoudersvertrouwen;
boetes van privacyregulerende instanties;
compensatiekosten voor slachtoffers.

Buiten de directe gevolgen zijn er indirecte gevolgen. Door de opgelopen imagoschade hebben mensen minder vertrouwen in het bedrijf en zal het moeilijker zijn om nieuwe klanten te binden, hetgeen gepaard gaat met hogere marketingkosten. Het Ponemon Institute heeft in Amerika onderzoek gedaan naar de kosten per incident en kwam uit op een gemiddelde van $ 202 per gelekt record, waarvan $ 152 betrekking had op indirecte kosten ([Pone09b]).

Vanwege de wetgeving binnen de Verenigde Staten die het verplicht stelt om alle gevallen van data leakage waarbij persoonsgebonden informatie is gemoeid te melden, is het eenvoudig met voorbeelden uit Amerika te komen. Toch heeft ook een aantal incidenten in Nederland het nieuws weten te halen ([Spai08]).

C-2009-4-Vliet-t02

Tabel 2. Enkele voorbeelden van onbewuste data leakage incidenten binnen Nederland.

Uit de voorbeelden in tabel 2 valt op dat veel incidenten te maken hebben met persoonsgegevens of dat personen last van het lekken hebben ondervonden. Tevens valt het op dat enorme hoeveelheden gevoelige data onbewust worden gelekt en dat veel zaken aan het licht komen door goed oplettende burgers. In veel gevallen is het echter niet meer te achterhalen of er eerder al meer gegevens zijn gelekt.

Impact van de huidige economische crisis

Door het huidige economische klimaat waarbij meer mensen op straat komen te staan is de verwachting dat het aantal data leakage incidenten alleen maar verder zal toenemen. Onderzoek heeft uitgewezen dat ongeveer 59 procent van de vertrekkende werknemers bedrijfsdata steelt ([Pone09a]). Uit hetzelfde in de Verenigde Staten uitgevoerde onderzoek is gebleken dat slechts vijftien procent van de bedrijven een controle uitvoert op meegenomen papieren en elektronische documenten. De e-mailgeschiedenis en hardcopybestanden zijn het meest populair. Tevens wordt het risico tot lekken vergroot door bezuiniging op IT-kosten en IT-personeel ([OEDL09]).

Wetgeving en regulering

Ook wet- en regelgeving proberen meer grip te krijgen op het alsmaar groeiende probleem van data leakage. Het meest volwassen is de wet- en regelgeving in de Verenigde Staten. De belangrijkste regelgeving is gericht op incidenten waar persoonsgegevens mee gemoeid zijn of op bedrijven die werken met financiële of medische gegevens.

Hieronder is de belangrijkste wet- en regelgeving inclusief reguleringen vanuit de industrie zelf opgesomd.

Health Information Portability and Accountability Act (HIPAA). Wetgeving voor alle bedrijven die met medische gegevens te maken hebben, en die ook eisen aan de beveiliging van Protected Health Information (PHI) beschrijft.
Gramm Leach Bliley Act (GLBA). Wetgeving voor alle financiële organisaties inclusief bedrijven die financiële informatie ontvangen.
Data Breach Notification Laws. Wetgeving die het melden van data leakage incidenten waar persoonsgegevens mee gemoeid zijn, verplicht stelt. Momenteel van toepassing in 38 Amerikaanse staten.
Payment Card Industry Data Security Standard (PCI DSS). Wetgeving voor alle bedrijven die met creditcardgegevens werken of deze verwerken.

Op het gebied van de integriteit speelt ook de Sarbanes Oxley (SOx)-wetgeving, die deugdelijk bestuur van beursgenoteerde ondernemingen vereist, een rol. De SOx-wetgeving vereist onder andere een verantwoordelijke voor alle beschikbare informatie.

In Nederland is momenteel alleen de Wet bescherming persoonsgegevens (Wbp) ingevoerd, die omschrijft hoe organisaties moeten omgaan met persoonsgegevens en welke rechten de burgers hebben. Deze wet voorziet echter niet in het verplicht melden na het lekken van persoonsgegevens.

Onlangs is in de Europese Unie een voorstel gedaan om het melden van data leakage incidenten te verplichten. Dit voorstel, bekend onder de naam ‘the ePrivacy Directive’, is echter alleen van toepassing op elektronische communicatiediensten in publieke netwerken. Om deze reden heeft de Europese databeschermingstoezichthouder (EDPS) in een reactie laten weten de voorstellen niet ver genoeg te vinden gaan.

Hoe voorkom ik een data leakage incident?

Om het risico van het optreden van een data leakage incident te verkleinen dienen in eerste instantie organisatorische aanpassingen te worden gemaakt. De eerste stappen zijn het inventariseren welke data beschermd moeten worden, te bepalen hoe strikt het beleid moet worden en het beleggen van verantwoordelijkheden. Tevens is het van belang het beleid naar werknemers uit te dragen en werknemers te trainen om zo het informatiebeveiligingsbewustzijn te verhogen.

Naast het nemen van de juiste organisatorische maatregelen kunnen technische maatregelen zoals het aanschaffen en implementeren van een DLP-softwarepakket helpen bij het verkleinen van het risico tot het lekken van informatie.

De werking van een DLP-softwarepakket

Om het lekken van gevoelige informatie tegen te gaan richten DLP-softwarepakketten zich op data in drie verschillende stadia:

Data ‘in motion’. Alle data die zich over het netwerk verplaatsen, die ‘in beweging zijn’ zoals webverkeer, e-mail en Instant Messaging (IM)-berichten. De focus ligt hierbij op data die het bedrijfsnetwerk verlaten.
Data ‘at rest’. Alle data binnen het bedrijfsnetwerk die zijn opgeslagen op eindpunten, zoals op laptops, servers en databases.
Data ‘in use’. Alle data die in gebruik zijn, zoals het bewerken van een document of het kopiëren van een bestand naar een USB-stick.

De geanalyseerde data kunnen grofweg in twee categorieën worden ingedeeld. In het ideale geval betreft het ‘structured data’, data in een vooraf bekend formaat, zoals geboortedatum, creditkaartnummers en burgerservicenummers. Deze informatie kan met eenvoudige patroonherkenningstechnieken worden gedetecteerd. De meeste data zijn echter ongestructureerd, ‘unstructured data’, en zorgen voor een grotere uitdaging. Voor een stuk tekst in bijvoorbeeld een e-mail worden geavanceerdere technieken gebruikt, zoals conceptuele en taalanalyses, om de strekking van de tekst te achterhalen.

De meerwaarde van een DLP-softwarepakket

Er kunnen verschillende motieven ten grondslag liggen aan het besluit een DLP-softwarepakket aan te schaffen. De meest voor de hand liggende is het verlagen van het risico tot het openbaren van gevoelige informatie, maar ook op het gebied van kostenbesparing en het voldoen aan wet- en regelgeving kan een DLP-softwarepakket aanzienlijke meerwaarde leveren. Tevens kan het helpen bij meer zijdelingse aspecten zoals het ‘opvoeden’ van werknemers in het gebruik van en de omgang met (gevoelige) informatie. De belangrijkste gebieden waarop een DLP-softwarepakket meerwaarde aan een organisatie kan leveren zijn:

Compliancy met wet- en regelgeving. De meeste DLP-softwarepakketten bieden standaard de mogelijkheid templates (een set regels) te activeren die in lijn zijn met verschillende vanuit wet- en regelgeving gestelde eisen. Tevens kunnen er rapporten worden gegenereerd om de compliancy met de betreffende wet- of regelgeving aan te tonen.
Verhogen van het beveiligingsbewustzijn (trainen van medewerkers). Wanneer medewerkers het beveiligingsbeleid overtreden of dreigen te overtreden wordt de actie geblokkeerd en krijgt de medewerker hier melding van met uitleg van reden. Ook is het mogelijk een keuzemelding te genereren; medewerkers krijgen dan een waarschuwing waarna ze de betreffende actie kunnen annuleren of een keuze kunnen maken voor een vervolgactie zoals het versleutelen van het e-mailbericht of de bijlage. Op deze manier wordt het beveiligingsbeleid afgedwongen, leren werknemers van hun fouten en wordt beveiligingsbewustzijn onder werknemers verhoogd.
Kostenbesparing. Door de centrale managementinterface waar alle informatie wordt verzameld, is het veel gemakkelijker om het beleid af te dwingen en eventuele incidenten te analyseren. Tevens wordt het eenvoudiger om compliancy met wet- en regelgeving aan te tonen doordat compliancyrapporten eenvoudig gegenereerd kunnen worden.

DLP-softwarepakketten kunnen aanzienlijke meerwaarde bieden voor de informatiebeveiliging, maar kunnen niet alle incidenten voorkomen. Dergelijke softwarepakketten richten zich over het algemeen niet op aanvallen van hackers en bieden alleen bescherming tegen lekken van elektronische informatie.

Het implementeren van een DLP-softwarepakket

Het implementeren van een DLP-softwarepakket kan alleen succesvol worden wanneer eerst de noodzakelijke organisatorische aanpassingen worden doorgevoerd en wanneer realistische doelstellingen aan het DLP-product worden gesteld.

Op organisatorisch gebied dient begonnen te worden met het opstellen van een breed informatiebeveiligingsbeleid om dat vervolgens binnen de organisatie door te voeren. Bij het doorvoeren van het informatiebeveiligingsbeleid is het belangrijk de werknemers op de hoogte te brengen van het beleid, en nut en noodzaak om bewust met (gevoelige) informatie om te gaan kenbaar te maken. Binnen het informatiebeveiligingsbeleid dient te worden nagedacht over de waarde van verschillende typen informatie voor het bedrijf. Aan de hand van deze analyse kan dataclassificatie worden uitgevoerd en kunnen verschillende classificatieniveaus en overeenkomstige beveiligingsniveaus worden gedefinieerd. Per classificatie en beveiligingsniveau dienen autorisaties te worden gedefinieerd en autorisatietabellen te worden opgesteld. Belangrijk aspect hierbij is om niet alleen generieke autorisaties op te stellen; zo zullen de autorisaties op het bekijken en versturen (e-mailen) van contracten van werknemers binnen de afdeling Personeelszaken anders zijn dan op andere afdelingen. Na het in kaart brengen van het volledige informatiebeveiligingsbeleid en het definiëren van alle autorisaties kan worden begonnen met de implementatiefase.

Gedurende de implementatiefase van het DLP-product is de eerste stap het product te configureren aan de hand van het gedefinieerde beleid en de opgestelde autorisaties. Nadat het product enige tijd heeft gedraaid moet de werking worden geëvalueerd en waar nodig de configuratie worden bijgesteld. Dit proces wordt herhaald totdat het DLP-product naar wens werkt. Tevens is belangrijk ook bij de implementatiefase de medewerkers die mogelijk met meldingen van het DLP-product geconfronteerd worden, hiervan op de hoogte te stellen.

C-2009-4-Vliet-t03

Tabel 3. Overzicht van enkele DLP-softwarepakketproducenten.

Conclusie

De alsmaar groeiende hoeveelheid digitale informatie binnen bedrijven en tegelijkertijd de toename van (moderne) digitale communicatiemedia stelt bedrijven voor een grote uitdaging gevoelige informatie binnen hun grenzen te houden. Het nemen van maatregelen wordt enerzijds afgedwongen door de afschrikkende werking van de enorme (financiële) gevolgen die data leakage incidenten met zich mee kunnen brengen en anderzijds door toenemende wet- en regelgeving op het gebied van data retention en privacy.

Het huidige economische klimaat heeft de noodzaak tot het nemen van effectieve maatregelen alleen maar vergroot. Veel medewerkers die bedrijven verlaten nemen gevoelige informatie mee, en nu door de economische crisis meer medewerkers bedrijven verlaten is het risico tot het lekken van gevoelige informatie groter geworden. Tevens drukt de economische crisis op de beschikbare IT-budgetten en het IT-personeel.

De aanschaf van een DLP-softwarepakket kan een effectief middel zijn ter voorkoming van een data leakage incident. Deze softwarepakketten bieden bescherming door zich te richten op data die zich verplaatsen, opgeslagen zijn of in gebruik zijn. Deze data worden vervolgens met geavanceerde technieken geanalyseerd op overeenstemming met de vooraf ingestelde regels. Buiten het beschermen tegen data leakage incidenten bieden DLP-softwarepakketten tevens voordelen bij het voldoen aan wet- en regelgeving, het aantonen van compliancy en het verhogen van het informatiebeveiligingsbewustzijn onder de werknemers.

Ondanks alle voordelen dient men zich te realiseren dat ook DLP-softwarepakketten hun beperkingen hebben. Zij richten zich niet op kwaadaardige aanvallen van hackers en bieden alleen bescherming tegen het lekken van elektronische informatie. Desondanks kan een DLP-softwarepakket een effectief middel zijn tegen het ongewenst naar buiten komen van gevoelige informatie.

Literatuur

[EGDL09] The Executive Guide to Data Loss Prevention, Securosis LLC, March 2009.

[Herm09] Ing. J.A.M. Hermans en drs. J.W. de Jong, Information Leakage Prevention – Putting your information first, KPMG IT Advisory, 2009.

[Mars08] M. Marshall, M. Martindale, R. Leaning en D. Das, Data Loss Barometer, KPMG, September 2008.

[Mars09] M. Marshall, M. Martindale en R. Leaning, Data Loss Barometer; Review of 2008 and Predictions for 2009, KPMG, 2009.

[OEDL09] Outbound Email and Data Loss Prevention in Today’s Enterprise, Proofpoint, 2009.

[Oule09] E. Ouellet en P.E. Proctor, Magic Quadrant for Content-Aware Data Loss Prevention, Gartner, 2009.

[Pone09a] Dr. L. Ponemon, Data Loss Risks During Downsizing; As Employees Exit, so does Corporate Data, Ponemon Institute LLC, 2009.

[Pone09b] Dr. L. Ponemon, Fourth Annual US Cost of Data Breach Study; Benchmark Study of Companies, Ponemon Institute LLC, 2009.

[Spai08] K. Spaink, Dutch Data Breaches, http://www.spaink.net/dutch-data-breaches/, 2009.

[Vlie08] A.H.P. van Vliet, Data Leakage and It’s Prevention, TU Delft, September 2008.

Invoering van één toegangspas

In 2008 is binnen KPMG Nederland een nieuwe identiteitspas ingevoerd voor de fysieke toegangscontrole. Na de invoering van persoonsgebonden certificaten op de contactchip van de pas, de corporate identiteitspas, zijn daar begin 2009 IT-beveiligingstoepassingen aan toegevoegd.

De invoering van de kaart is nagenoeg uniek door de landelijke invoering voor alle medewerkers en voor alle kantoren. De leermomenten uit de praktijk bij invoering van deze hybride corporate identiteitspas met persoonsgebonden certificaten en met gebruikmaking van een Managed PKI, worden in dit artikel met u gedeeld.

Inleiding

In dit artikel wordt ingegaan op de invoering van de corporate identiteitspas binnen KPMG Nederland. Deze kaart is voor medewerkers zowel de fysieke toegangspas tot gebouwen en ruimten alsook de elektronische identiteitspas voor gebruik van IT-beveiligingsfuncties.

Voor de IT-beveiligingsfuncties is de kaart voorzien van een contactchip met certificaten en is een Managed Public Key Infrastructuur gerealiseerd ([Getr05]). Vanuit de IT Security dienstverlening van KPMG is dit artikel deels een voorbeeld van ‘Drinking Your Own Champagne’ ([KPMG07]).

Ten aanzien van de corporate identiteitspas verschilt KPMG niet van andere organisaties, met dezelfde interne issues bij het streven naar en de realisatie van verbeteringen in de interne bedrijfsvoering door inzet van informatietechnologie en door integratie van processen en diensten.

De interne beschikbaarheid van de juiste kennis en ervaring op dit gebied heeft de afgelopen jaren bijgedragen aan het huidige succesvolle resultaat, een geïntegreerde aanpak voor één identiteitspas voor fysieke én IT-beveiligingstoepassingen.

Allereerst wordt in dit artikel kort de voorgeschiedenis geschetst die leidde tot de uiteindelijke ontwikkeling en realisatie van de Public Key Infrastructuur (PKI) met de corporate identiteitspas als drager. Daarna wordt de ontwikkeling beschreven, eerst door kenmerkende werkwijzen en achtereenvolgens aan de hand van het invoeringstraject, de processen en de technologie. Enkele belangrijke leermomenten uit het interne ontwikkelingstraject volgen dan onder de kop ‘Lessons learned’. Afgesloten wordt met conclusies voor ontwikkelingen van vergelijkbare corporate identiteitspassen.

Historie en uiteindelijke business case

In het begin van dit millennium werd binnen KPMG al gewerkt aan de opzet van een eigen PKI. Net als de jaren daaropvolgend waren echter de business cases ieder afzonderlijk te klein om de noodzakelijke investering te rechtvaardigen en konden verschillende potentiële PKI-toepassingen – zoals de interne verwerking van gevoelige (HR-) gegevens, communicatie met externe partijen waaronder banken en de AFM en gebruik van extranetten – onvoldoende worden samengevoegd tot één sluitende overall business case.

Behalve de kosten beperkte ook het geringe aantal toepassingen waarbinnen gebruik kon worden gemaakt van certificaten de invoering. Ook de PKI-technieken en -diensten waren minder uitontwikkeld dan tegenwoordig, waardoor te veel specifieke aanpassingen nodig waren om applicaties eenvoudig geschikt te maken voor eindgebruikers.

Vanaf 2005/2006 werd één toepassing, beveiligd e-mailen, in toenemende mate een drijfveer voor ontwikkeling van de certificaatinfrastructuur binnen KPMG Nederland ([Meen01]). Deeloplossingen voor beveiligd e-mailen waren wel al voorhanden, maar aspecten als gebruiksgemak, digitale ondertekening en beveiliging tot en met de mailbox werden hiermee onvoldoende ingevuld.

In verschillende achtereenvolgende pilots is vervolgens kennis en ervaring opgebouwd over beveiligd e-mailen met verschillende technieken, wijzen van implementeren en het gebruik van certificaatdiensten binnen de eigen IT-omgeving. Daarbij werden behalve ondersteuning van de gebruikers voor naleving van het e-mailbeleid ook andere toepassingen bekeken, met name het ondertekenen van (pdf-)documenten en verbetering van interne processen waarbinnen strikt vertrouwelijke informatie wordt verwerkt.

IT-ontwikkelingen

Verschillende IT-ontwikkelingen vormden uiteindelijk – gecombineerd met beveiligde e-mail – de aanzet tot de finale ontwikkeling, de realisatie van de Managed PKI-dienstverlening met gebruikmaking van de toegangspas als drager voor de certificaten.

Belangrijke ontwikkelingen waren de invoering van draadloze netwerken en de uitvoering van het ICT/communicatiebeleid. Voor het gebruik van draadloze netwerken binnen kantoren is het gebruik van certificaten een vereiste vanuit dit beleid. Uitvoering van het communicatiebeleid – connectivity at any place, any where en Single Sign-On voor de werkplek – resulteerde in de wens tot één uniform authenticatiemiddel.

Door de toegenomen kennis van en ervaring met andere Managed PKI-diensten, zoals voor SSL/TLS-servicecertificaten voor beveiliging van e-mail tussen organisaties, was de jaren daarvoor ook de kennis en ervaring in de organisatie over PKI in de breedte toegenomen.

Een overkoepelend programma ter algehele verbetering van de IT-infrastructuur vormde tenslotte het organisatorische en financiële vehikel waarbinnen de plannen uiteindelijk werden uitgevoerd. Binnen dit programma werd de samenwerking tussen facilitaire dienst en de IT-organisatie verankerd binnen verschillende deelprojecten. De nieuwe dienst is duidelijk neergezet als onderdeel en uitbreiding van de basis IT-infrastructuur.

Als laatste, maar zeker niet de minst belangrijke reden voor de uiteindelijke ontwikkeling van de dienstverlening moeten de acceptabele prijsstelling voor de certificaten en de daling van de kosten voor realisatie worden genoemd. Dit laatste in het bijzonder door gebruik van zo veel mogelijk standaardsystemen en outsourced en/of managed services. In figuur 1 zijn de interne en uitbestede systeemcomponenten aangegeven.

C-2009-4-Veltmeijer-01

Figuur 1. Belangrijkste systemen voor productie van certificaten op de corporate identiteitspas.

Ontwikkeling

Zowel voor de ontwikkeling van een bedrijfsbrede PKI alsook voor de ontwikkeling van een identiteitspas waren de risico’s bekend ([Naza01], [Velt01]). Om bekende risico’s bij de ontwikkeling zoveel mogelijk te vermijden werden eerst de ervaringen uit voorgaande pilots vastgelegd in uitgangspunten, randvoorwaarden en verdere afbakening van de scope.

Deze werden vooraf besproken met de potentiële leverancier van de certificaatdiensten. Daarbij werden ook de visie en te volgen werkwijze definitief afgestemd. Hierdoor kon worden gewerkt met een ambitieuze tijdsplanning. Kernpunten van de gevolgde werkwijze daarbij zijn:

De toepassingen waarbinnen certificaten de eerste twee jaar zouden (kunnen) worden ingezet, werden expliciet benoemd. Tijdens de gehele ontwikkeling werd rekening gehouden met het (toekomstige) gebruik binnen deze toepassingen. Elk ander mogelijk gebruik werd resoluut buiten het project geparkeerd.
Enkel het volledige gebruik en beheer voor de eerste toepassing, beveiliging van e-mail, werd volledig uitgewerkt in het project. Ten aanzien van andere initieel bepaalde toepassingen werd in zoverre gekeken naar het gebruik en beheer dat de tijdens de ontwikkeling te maken keuzen daar geen negatieve invloed op zouden hebben.
Er werd een strakke fasering aangehouden waarin na realisatie van het ontwerp snel een basisinfrastructuur aanwezig moest zijn om certificaten op de identiteitspas geplaatst te hebben. Dit diende gerealiseerd te zijn voordat de nieuwe pas ten behoeve van de fysieke toegangscontrole aan gebruikers zou worden verstrekt.
Ten aanzien van het waarborgen van het betrouwbaarheidsniveau van de gehele PKI is het altijd bepalend geweest dat de uit te geven certificaten eenvoudig zouden moeten zijn op te waarderen tot gekwalificeerde certificaten (certificaten die voldoen aan eisen die vanuit de Wet Elektronische Handtekening worden gesteld om een elektronische handtekening te kunnen plaatsen die dezelfde rechtsgevolgen heeft als een handgeschreven handtekening).

Duidelijk was dat een definitieve keuze voor gekwalificeerde certificaten financieel niet haalbaar zou zijn voor de beoogde brede uitrol. Afhankelijk van andere externe ontwikkelingen zouden gekwalificeerde certificaten in de toekomst wel een eis kunnen zijn voor bepaalde doelgroepen en nog te realiseren gebruik.

Voorbeelden van keuzen die hieruit voortkomen zijn de keuze van de smartcard als SSCD (Secure Signature Creation Device) en de keuze van een provider die tevens gekwalificeerde certificaten kan leveren conform de eisen van de PKI-Overheid ([Wals02]).

Invoering

Toegangspas

Binnen het programma ter verbetering van de IT-infrastructuur waren onder andere de volgende twee deelprojecten gedefinieerd: 1. invoering van een nieuw toegangscontrolesysteem met de nieuwe toegangspas, en 2. invoering van de elektronische identiteitspas. Hierdoor konden op het juiste moment de eisen en wensen binnen de separate ontwikkelingstrajecten worden afgestemd. Voorbeelden waarbij de afstemming essentieel was zijn: de keuze om alle medewerkers te voorzien van de nieuwe kaart, de keuze voor embedding van de contactchip op de kaart en de initieel batchgewijze productie van de kaart en de certificaten.

Gedurende 2008 werd de nieuwe toegangspas per locatie uitgerold. De basisinfrastructuur was nog niet gereed op het moment dat de passen voor de eerste drie locaties werden uitgerold. Hierdoor waren separate terugroepacties nodig om de passen te voorzien van certificaten en sleutels.

Elektronische corporate identiteitspas

Op grond van eerdere ervaringen bij invoering van PKI voor beveiliging van e-mail, is er veel aandacht besteed aan de invoering bij de eindgebruikers. Voor gebruikers diende de invoering van de beveiligingsfuncties zo transparant mogelijk plaats te vinden, met een absoluut minimum aan verstoring van werkzaamheden en zo gebruiksvriendelijk mogelijk.

Zo is al in een zeer vroeg stadium een smartcardlezer toegevoegd aan de eisen voor nieuwe laptops. Hierdoor waren ruim voor de invoering de meeste gebruikers in stilte – via reguliere vervangingen van laptops – voorzien van een kaartlezer. Overige pc’s werden naderhand voorzien van losse smartcardlezers.

Bij de uitrol van de fysieke toegangspas – eventueel via separate terugroepacties – was deze pas (de nieuwe corporate identiteitspas) voorzien van persoonlijke certificaten. Pas nadat alle gebruikers waren voorzien van de nieuwe elektronische identiteitspas en nadat de laatste aanpassingen in de infrastructuur hadden plaatsgevonden, werden de pincodes verstuurd en werd breed gecommuniceerd over de ‘Corporate ID-Smartcard’ en de eerste toepassing, het beveiligen van e-mail.

Toepassingen

De uitrol vond plaats in het kader van de nieuwe functionaliteit, het beveiligd e-mailen met gebruikmaking van de certificaten op de corporate identiteitspas. De overige geplande toepassingen werden daarbij enkel kort benoemd.

De beveiligde e-mailapplicatie bepaalde het gezicht, en daarmee voor een groot deel de acceptatie, van de identiteitspas bij de gebruikers. Om een zo breed mogelijke acceptatie te realiseren is bij invoering veel aandacht uitgegaan naar ondersteuning van het gebruik voor de applicatie. Aspecten die daartoe bijdroegen waren:

Vrijwillig gebruik van de pas bij invoering en gebruik voor de eerste applicatie. Het accent lag op het ondersteunen van gebruikers bij invulling van het beleid ten aanzien van het beveiligd versturen van e-mail.
Gerichte communicatie over de nieuwe mogelijkheden met doelgroepen waarvan bekend was dat ze er veel voordeel bij konden hebben in hun dagelijkse werkzaamheden en voor verbetering van de interne processen.
Ondersteuning door het hoogste management in de vorm van een voortrekkersrol bij daadwerkelijk brede verspreiding van beveiligde interne e-mail.
Verbeterde communicatie over de verschillende mogelijkheden om e-mail te beveiligen. De pas is niet in alle situaties de optimale oplossing voor beveiliging van e-mail. Door per situatie alternatieven aan te reiken wordt voorkomen dat de pas als het nieuwe verplichte IT-middel of ‘speeltje’ van de IT-organisatie wordt gezien.

Door de wijze van geleidelijke invoering van de kaart is deze invoering in zekere zin pas afgerond als er binnen alle geplande toepassingen gebruik van kan worden gemaakt. Het begeleiden en stimuleren van gebruik binnen processen en toepassingen gaat tot die tijd door.

Processen

Het tijdspad bij invoering van de persoonlijke certificaten werd in grote mate bepaald door de invoering van de fysieke toegangspas. Dit was weliswaar voortgekomen uit de noodzaak om tot één identiteitspas te komen, maar bood in praktijk het voordeel van de juiste tijdsdruk om op tijd de basisinfrastructuur gereed te hebben (zie ook ‘Lessons learned’).

Daardoor was er onvoldoende tijd om de processen in detail uit te werken en te integreren in bestaande levenscyclusprocessen van de toegangspas. De processen voor de certificaatdiensten werden separaat opgezet – met kennis over de bestaande smartcard levenscyclusprocessen – en naderhand gecombineerd met de reeds bestaande processen binnen de facilitaire dienst. Door de centrale benadering van beide processen en fysiek nabije huisvesting van beide organisatieonderdelen verliep dit zonder al te veel problemen. Hierdoor is wel – uit noodzaak – een gescheiden ontwikkeling van de productie en processen voor de fysieke toegangspas en voor de certificaten ontstaan. In de praktijk is dit een succesfactor gebleken voor een efficiënte en effectieve opzet, realisatie en invoering van de gecombineerde CID-Smartcard. Voor regulier beheer van de gecombineerde kaart is dit echter geen wenselijke situatie.

Met de toename van de kennis en ervaring van de processen en systemen bij beide organisatieonderdelen wordt daarom voorzien dat de reguliere kaartprocessen geheel door één dienst (facilitair) zullen worden uitgevoerd. Door de benodigde specialistische kennis van informatiesystemen en certificaatdiensten zal voor de tweedelijnsondersteuning de IT-organisatie verantwoordelijk blijven. Gepland staat dan ook een uitvoering van het gehele productieproces onder één verantwoordelijk organisatieonderdeel. Op termijn zal de volgende integratiestap, combinatie van de twee verschillende productiesystemen in één systeem, eenvoudig te realiseren zijn door de opgedane ervaring.

De afstemming binnen het gehele proces tussen alle betrokken partijen, intern en extern, zal de komende periode vooralsnog een belangrijk aandachtspunt blijven om het proces verder te verbeteren.

Technologie

In deze paragraaf worden de belangrijkste technische kenmerken van de geïmplementeerde corporate identiteitspas opgesomd. Enige basiskennis van PKI is daarbij handig maar niet noodzakelijk voor begrip van het gehele artikel.

De identiteitspas is voorzien van twee antennes ter ondersteuning van diverse systemen voor fysieke toegangscontrole en een contactchip voor de IT-beveiligingsfuncties. De pas is verder voorzien van een pasfoto, de naam van de pashouder en een holografische laag.
Op de contactchip van de identiteitspas bevinden zich drie certificaat/private key paren: voor digitaal ondertekenen (signing), voor versleutelen (encryption) en voor authenticatie (client authentication / smartcard-logon). In figuur 2 is de PKI-hiërarchie weergegeven.
De signing- en encryptioncertificaten worden uitgegeven binnen één publieke PKI (Getronics/Verisign). Doordat de root Certificate Authorities (CA’s) van deze PKI door de meeste systemen als trusted worden aangemerkt, is daarmee geborgd dat er voor externe uitwisseling van beveiligde e-mail en documenten geen extra trustrelaties hoeven te worden gerealiseerd. Het wel of niet functioneren van de externe uitwisseling wordt verder bepaald door de ondersteuning van (persoonlijke) certificaten binnen de specifieke toepassing in de externe IT-omgeving.
Het authenticatiecertificaat wordt uitgegeven binnen een private PKI. Aanloggen met de corporate identiteitspas op willekeurige informatiesystemen is immers enkel wenselijk indien de trust expliciet is aangebracht. Publicatie van revocations (intrekking of herroeping van de geldigheid van een certificaat) voor externe partijen is ook niet noodzakelijk, in tegenstelling tot de onder een publieke PKI uitgegeven certificaten.
De certificaat/sleutelparen worden alle drie in alle lifecycle- en beheerprocessen als één geheel verwerkt. Zo worden ze alle drie bij productie gelijk op de kaart geplaatst en heeft een intrekking van de kaart een revocation van alle drie de certificaten tot gevolg. Het enige punt waarbij een certificaat individueel wordt verwerkt, is de recovery van het encryptiecertificaat. Voor specifieke recoveryverzoeken kan het encryptiecertificaat op een blanco kaart worden geplaatst volgens strikte procedures.
Bij vervanging van de pas worden de certificaten automatisch vernieuwd en worden oude encryptiecertificaten op de pas bijgeplaatst.
De geldigheidstermijn van de certificaten is gelijkgesteld aan de vervangingsperiode van de fysieke pas om de overlast van extra verwerkingen voor gebruikers te minimaliseren.
De essentiële PKI-componenten zoals alle CA’s en het certificaatbeheersysteem worden gehost en beheerd door Getronics. KPMG heeft een Registration Authority (RA)-deelrol die technisch wordt ingevuld met een dedicated werkstation voor het certificaatbeheersysteem. Dit werkstation is verder voorzien van de nodige kaartlezers, een kaartprinter voor productie van de certificaten en een printer voor de pinmailers.
Binnen het Certificaat Management Systeem zijn naast de gebruikersrol – voor productie van de certificaten – onder andere rollen gedefinieerd voor het resetten van pincodes door de helpdesk en rollen voor het verwerken van vertrouwelijke informatie en het uitvoeren van specifieke beheerhandelingen.

C-2009-4-Veltmeijer-02

Figuur 2. De PKI-hiërarchie met signing- en encryptioncertificaten uitgegeven onder een public PKI en authentication/smart card-logoncertificaten uitgegeven onder een private PKI.

Lessons learned

Hieronder worden enkele leermomenten aangegeven uit het ontwikkelings- en invoeringstraject van de corporate identiteitspas bij KPMG.

Het feit dat op veel deelgebieden de kennis en ervaring binnen de organisatie aanwezig is betekent niet automatisch dat genoemde punten en gerelateerde risico’s konden worden voorzien of konden worden voorkomen. Daarvoor zijn er te veel omgevingsfactoren en relaties met andere (interne) ontwikkelingen die niet konden worden beïnvloed, zoals het ontstaan van een economische crisis gedurende het project.

De totale opzet en invoering van de elektronische identiteitspas had uiteindelijk een doorlooptijd van ruim één jaar. Met de juiste aandacht voor de hieronder opgesomde punten is het zeker mogelijk om binnen één jaar tijd, vanaf scratch, een volledige public key infrastructuur – gecombineerd met een smartcard als drager van de certificaten – op te zetten en in gebruik te nemen.

Scoping

Definieer vooraf een duidelijke scope en baken deze verder af met duidelijke uitgangspunten en randvoorwaarden. Definieer ook de voorwaarden waaronder hiervan mag worden afgeweken. Dit punt is een grote open deur maar des te belangrijker gebleken door de wijze waarop het project voordeel heeft gehad bij de gezamenlijke visieontwikkeling met de leverancier, de duidelijke afspraken vooraf en de daardoor vliegende start.

Projectfasering, projectteam en samenwerking

Breng een projectfasering aan waarin eerst de basis-PKI wordt gerealiseerd waarin wel in grote lijnen de processen en toepassingen worden bepaald, maar waarin deze nog niet in detail worden uitgewerkt.

Voorwaarde voor succes hierbij is wel dat in het projectteam de juiste expertise – technisch, organisatorisch, en processen – aanwezig is om de (nadelige) gevolgen van keuzen in deze fase voor latere fasen te kunnen inschatten. Tevens dient het projectteam de juiste beslissingsbevoegdheid te hebben om snel adequate keuzen te kunnen maken.

Beschikbaarheid van de basisinfrastructuur was een noodzaak om de certificaten te kunnen produceren voordat deze werden verstrekt aan de gebruikers. Deze tijdsafhankelijkheid noodzaakte het project geheel te focussen op de technische realisatie en om op tal van punten snel keuzen te maken met de in het project beschikbare kennis.

Hierdoor werden discussies over onderling afhankelijke infrastructurele, proces- en applicatie-issues beperkt tot de essentie. In daaropvolgende fasen werden vervolgens de processen en het gebruik binnen de applicaties gedetailleerd ingevuld en geïmplementeerd.

De standaardisatie, en daarmee de koppeling van verschillende PKI-technieken is de laatste jaren sterk toegenomen. Desondanks vergde de ontwikkeling van de interfaces naar de verschillende componenten op het laatst – vlak voor uitrol – meer tijd dan gepland. Korte beslissingslijnen waren daarbij essentieel voor goede communicatie naar het project, de beheerorganisatie en de gebruikers.

Uitbesteding / Managed dienstverlening

In de aanloop van het project in 2007 werd in andere internationale onderdelen van de organisatie gewerkt aan een interne PKI, voornamelijk voor gebruik binnen de eigen IT-infrastructuur. Met name door de bredere toepasbaarheid van de certificaten en snellere implementatiemogelijkheden is toch gekozen voor het uitbesteden van de PKI-diensten. Deze keuze, en de keuze voor de aanbieder van Managed PKI-diensten is essentieel geweest voor het succesvolle resultaat ([Getr05]).

Het binnen het project samenvoegen van de ervaring, expertise en kunde van eigen medewerkers en die van de leverancier in het project heeft geleid tot een managed service die met de beschikbare middelen niet binnen de eigen organisatie gerealiseerd en beheerd had kunnen worden. Net als bij outsourcing van andere IT-diensten dient de eigen organisatie wel over de juiste kennis te beschikken om de regie te blijven voeren tijdens de ontwikkeling en om in control te blijven over de beheerdiensten.

Behalve de voordelen van tijdwinst en kosten zijn de mogelijkheden voor aanpassingen en uitbreiding van de PKI-diensten, met behoud van betrouwbaarheidsniveau van certificaten, een voordeel gebleken van de uitbestede dienst.

Aanvraag-, uitgifte- en beheerprocessen

Niet nieuw, maar toch zinvol om hierbij te benoemen zijn de volgende, meest opvallende leermomenten:

Blijf altijd streven naar een eenvoudig en uniform aanvraag- en distributieproces, ook als dit tijdelijk, tijdens ontwikkeling, niet zo kan worden opgezet.
Ga ervan uit dat wat er in het gehele proces van aanleveren van kaarten en productie van kaart en certificaat mis kan gaan, ook een keer mis gaat.
Blijf de kaart- en applicatieprocessen conceptueel altijd als separate processen beschouwen en breng scheiding en controles aan daar waar dat mogelijk is. Hoezeer de fysieke toegangscontrole ook is gekoppeld aan de identiteitspas, het blijft een applicatie net als bijvoorbeeld het beveiligen van e-mail.
Richt de productie van de kaart en die van de certificaten in binnen één proces. Gescheiden opzet kan wenselijk zijn bij ontwikkeling maar voor het reguliere beheer is het inefficiënt en een bron van verstoringen.
Doe de initiële uitrol en/of invoering in één keer. Eventueel noodzakelijke uitzonderingen blijven de beheerorganisatie zeer lange tijd achtervolgen, zijn een bron van verstoringen en een groot acceptatierisico.

Conclusies

Gerelateerd aan de in dit artikel genoemde aspecten en onze interne projectervaringen kunnen de volgende conclusies worden getrokken ten aanzien van de opzet, realisatie en invoering van een corporate identiteitspas en managed PKI voor persoonsgebonden certificaten op die kaart:

In een samenwerkingsverband met een Managed PKI-leverancier en met de juiste aandacht voor scoping en gefaseerde realisatie is het mogelijk binnen één jaar tijd, vanaf scratch, een volledige public key infrastructuur – gecombineerd met een smartcard als drager van de certificaten – op te zetten en in gebruik te nemen.

Door geleidelijke invoering van de elektronische corporate identiteitspas – geleidelijk in de zin van niet direct noodzakelijk voor gebruik van de IT-infrastructuur en niet direct toepasbaar voor alle uiteindelijk te ondersteunen toepassingen – is invoering mogelijk met een sterk beperkt budget.

Om tegen acceptabele kosten beveiligde uitwisseling van elektronische gegevens tussen organisaties op grote schaal mogelijk te maken, is er behoefte aan een ‘sub-qualified’ en/of de-facto PKI-standaard. Met deze standaard moet het voor organisaties eenvoudig zijn om bilateraal afspraken te maken over wat en hoe er informatie wordt uitgewisseld en met welke juridische betekenis.

Literatuur

[Getr05] Getronics PinkRoccade Nederland BV, Managed PKI Service; Introduction, 2005.

[KPMG07] KPMG IT Advisory, Public Key Infrastructure Implementatie en Audit; Betrouwbare en veilige elektronische communicatie, 2007.

[Meen01] Drs. W.J.P. van de Meent, Het ontwikkelen van e-mailconventies, Compact 2001/5.

[Naza01] Noel Nazario en Martijn van Oosten, Real-world Application of Public Key Infrastructures Deployment Methodology, Compact 2001/1.

[Velt01] Ir. A.J.M. Veltmeijer, Beheeraspecten van technisch complexe omgevingen, Compact 2001/2.

[Wals02] Drs. P.A. van Walsem en ir. A. van Zanten CISA, Is ETSI TS 101456 geschikt voor gebruik bij een certificeringsonderzoek?, Compact 2002/4.

Hacken met pdf-files

Waar een aanval van hackers zich in het verleden met name richtte op de kritieke serversystemen van een bedrijf, ontwikkelt zich een trend waarin aanvallen zich meer en meer ook richten op eindgebruikerssystemen ([Thom01], [Micr08], [Govc08]). Het ontvangen van phishing mails en spyware is een toenemend verschijnsel ([Hill04]). Niet alleen is er meer aandacht voor aanvallen op werkplekken, ook komen exploits[Code die misbruik maakt van een kwetsbaarheid in bepaalde software, veelal met het doel om toegang te krijgen tot een systeem, verkrijgen van meer rechten of uitvoeren van een zogenaamde Denial-of-Service-aanval. Het Metasploit framework is een bekende tool voor het ontwikkelen en uitvoeren van exploits.], code die misbruik maakt van zwakheden in applicaties, in toenemende mate publiek beschikbaar. Een voorbeeld hiervan zijn de recente zwakheden in Adobe Reader. Met enige regelmaat worden nieuwe kwetsbaarheden in Adobe Reader vastgesteld en gepubliceerd. Maar hoe erg is dit nu eigenlijk? En in welke mate beschermen de aanwezige maatregelen als regelmatige updates, virusscanners en firewalls tegen deze bedreigingen? Wat bereikt een aanvaller met een dergelijke aanval en kan dit mogelijk impact hebben op de gewenste werkwijze tijdens een audit of accountantscontrole? In dit artikel zullen deze vragen beantwoord worden.

Inleiding

Al in 2005 werd een trend waargenomen van aanvallen waarbij de focus op eindgebruikers lag ([Mill05]). Een aspect hiervan is het snel in aantal toenemen van het aantal spyware- en phishingincidenten ([Hill04]). De aanvallen verschuiven hierbij volgens CERT ([Mill05]) veelal van een IT-infrastructuurgerichte aanval naar een applicatiegerichte aanval. In een dergelijke aanval stuurt een aanvaller een gebruiker een geïnfecteerd bestand dat vervolgens door de gebruiker in een kwetsbare applicatie wordt geopend. Bij openen van de file wordt vervolgens een door de aanvaller geprogrammeerde actie uitgevoerd. Vanuit het perspectief van een aanvaller zijn er legio mogelijkheden om een geïnfecteerd bestand bij gebruikers te krijgen, denk aan:

webbrowsers (forums, gratis downloads);
instant messenger clients;
e-mail (phishing mails) met een vervalst (gespoofed) afzenderadres. In geval van een bedrijf kan hier mogelijk een andere medewerker van het bedrijf als afzender worden gebruikt, denk aan een ‘belangrijke mededeling van de raad van bestuur’;
peer-to-peer netwerken of torrents;
andere gebruikersapplicaties ([Cisc08]).

Een trend die zich naar verwachting in 2010 verder zal doorzetten, is de aanval via social networking sites als Myspace, Facebook, Hyves en andere ([Malw09]).

Eindgebruikerssystemen hebben veelal toegang tot het internet. Met andere woorden, het is mogelijk een verbinding op te zetten door de firewall heen vanaf deze systemen, bijvoorbeeld met een webbrowser. Serversystemen daarentegen zijn veelal niet direct vanaf het internet bereikbaar. Verkeer dat servers vanaf het internet probeert te benaderen wordt dan door een firewall geblokkeerd (zie figuur 1).

C-2009-4-Pacques-01

Figuur 1. Verkeer door de firewall.

Wanneer een eindgebruikerssysteem wordt gecompromitteerd (overgenomen door een hacker) kan dit worden gebruikt als stepping-stone (uitgangspunt) voor verdere aanvallen op het netwerk. Om kritieke serversystemen te bereiken voert een hacker een dergelijke aanval in twee stappen uit. In de eerste stap wordt een eindgebruikerssysteem overgenomen, waarna vanaf het overgenomen systeem – zonder gehinderd te worden door maatregelen als de externe firewall – een aanval op kritieke systemen wordt uitgevoerd. Hiernaast is een aanvaller in staat data van het overgenomen eindgebruikerssysteem te kopiëren of aan te passen of het systeem op te nemen in een zogenaamd ‘botnet’.[Een leger van computers die, vaak zonder dat de eigenaars dit weten, worden ingezet voor Denial-of-Service (DoS)-aanvallen.]

Aanvallen langs vele wegen

Aanvallen op gebruikerssystemen door middel van kwetsbaarheden in applicaties

Een gemiddelde gebruiker heeft bij benadering zo’n tachtig applicaties geïnstalleerd staan ([Ball08], [Ball09]). Uit statistieken blijkt dat gemiddeld 85 procent van deze applicaties is gepatcht tegen securitybedreigingen, wat neerkomt op gemiddeld twaalf niet-gepatchte applicaties per gebruiker (zowel wereldwijd als in Nederland). In 2008 bleek uit onderzoek op 20.000 gebruikerssystemen dan 89,09 procent hiervan minimaal één ‘onveilige’ applicatie bevatte.

C-2009-4-Pacques-t01

Bron: [Ball08]

Met ‘onveilige’ applicatie wordt hier een applicatie bedoeld waarvan de producent een nieuwere versie heeft uitgegeven waarin één of meer kwetsbaarheden zijn opgelost, maar de gebruiker deze nog niet heeft geïnstalleerd. Merk op dat geïdentificeerde kwetsbaarheden waar nog geen patch voor beschikbaar is, maar mogelijk wel exploits voor bestaan, niet in deze statistieken zijn meegenomen.

Veelgebruikte applicaties op eindgebruikerssystemen waar virussen en exploits misbruik van maken zijn onder andere:

Word, PowerPoint, Excel;
Adobe Reader, Flash Player;
Mozilla Firefox, Internet Explorer.

Omzeilen van firewalls

C-2009-4-Pacques-02

Figuur 2. Maatregelen tegen aanvallen van buitenaf. (Bron: http://www.networksurety.com/solutions/firewall.php.)

Beschermende maatregelen binnen een organisatie zijn in de praktijk veelal gericht tegen aanvallen van buitenaf. In een externe firewall kan daartoe al het verkeer dat van buiten een verbinding tot stand probeert te brengen met een intern systeem, worden geblokkeerd. Vaak is het echter wel mogelijk om vanuit een ‘vertrouwd’ intern systeem een verbinding met een extern systeem op te zetten en daarmee verkeer door de firewall te laten sturen. Juist dit laatste kan in een aanval gebruikt worden door een gebruiker een geïnfecteerd pdf-bestand te sturen waarbij vanaf de werkplek een verbinding wordt opgezet naar buiten, waar de aanvaller zich bevindt.

Aanvallen vanuit het interne netwerk

Wanneer een penetratietest vanuit het interne netwerk wordt uitgevoerd (bijvoorbeeld op serversystemen die relevant zijn voor de financiële verslaggeving), blijkt dat in ruim 90 procent[Dit percentage is gebaseerd op de resultaten van een groot aantal interne penetratietesten uitgevoerd door KPMG.] van de gevallen dat kwetsbaarheden aanwezig zijn die vanuit het gebruikerssegment misbruikt kunnen worden. Dit in tegenstelling tot externe penetratietesten vanaf het internet waar dit percentage aanvallen, waarbij daadwerkelijk de achterliggende systemen geraakt worden, beduidend lager ligt. Wanneer een aanvaller van buitenaf dus in staat is – bijvoorbeeld door middel van een pdf-exploit – een gebruikerssysteem op het interne netwerk te compromitteren, kan hiervandaan een verdere aanval op het interne netwerk worden uitgevoerd.

Kwetsbaarheden op eindgebruikerssystemen kunnen aldus indirect leiden tot het compromitteren van voor de jaarrekeningcontrole relevante systemen.

Aanvallen door middel van pdf-bestanden

Recente versies van Adobe Reader bevatten kwetsbaarheden die kunnen leiden tot volledige (externe) toegang tot het systeem ([Good07], [Lau07], [MacA08], [Naza08], [Trus08], [Mill05]). Zelfs wanneer een gebruiker Adobe Reader direct vanaf de officiële site van Adobe downloadt bestaat de kans dat dit een kwetsbare versie betreft. Op het moment van schrijven (8 augustus 2009) wordt bij installatie vanaf de Adobe website (http://get.adobe.com/reader/) versie 9.1.0 geïnstalleerd, als stand-alone programma en als browser-plugin. Deze versie staat bekend als kwetsbaar voor verschillende zogenaamde ‘code execution’ kwetsbaarheden. De patches die in mei 2009 (één kwetsbaarheid) en juni (negen kwetsbaarheden) zijn uitgegeven, zijn niet aan de aangeboden versie toegevoegd. Het wordt aan de gebruiker overgelaten om de zojuist gedownloade versie direct weer te updaten.

Analyse van een pdf-bestand

Een pdf-document bestaat uit alleen ASCII-karakters en kan daarom met een eenvoudige editor als Notepad worden gelezen ([Stev09]). Hiernaast bevat een pdf-document veel whitespaces en wordt er geen gebruik gemaakt van compressie, wat de leesbaarheid vergroot. In figuur 3 wordt de code van een eenvoudige pdf-file getoond die alleen de tekst ‘PDF test’ bevat.

C-2009-4-Pacques-03

Figuur 3. Opbouw van een pdf-bestand.

Hieronder worden de basiscomponenten van een eenvoudige pdf beschreven. Voor meer gedetailleerde informatie, zie [PDFD].

Header

In de header wordt de pdf-versie gespecificeerd.

C-2009-4-Pacques-list01

Objecten

Objecten bepalen de structuur en inhoud van het pdf-document. Objecten beginnen met een uniek referentienummer gevolgd door een versienummer. In het voorbeeld pdf-document wordt een zestal objecten gedefinieerd. In het eerste plaatje wordt een object gedefinieerd met referentienummer 1 en versienummer 0. Tevens wordt het type (catalog) aangegeven. De regels 4 en 5 in dit voorbeeld bevatten een referentie naar indirecte objecten 2 en 3 die later in de code beschreven zijn.

C-2009-4-Pacques-list02

Object 2 beschrijft de outline voor het document. Die is in dit geval gelijk aan 0. De pagina’s in het document worden beschreven in object 3. Het /Kids-element verwijst hierin naar de inhoud van de pagina’s. Het /Count-element definieert het aantal pagina’s (1) van het document.

C-2009-4-Pacques-list03

Object 4 beschrijft de afmeting van de pagina (Mediabox) en bevat referenties naar de inhoud van de pagina (object 6) en het gebruikte font in de pagina (object 5). De definitie van het font is weergegeven in deze afbeelding.

C-2009-4-Pacques-list04

De inhoud van de pagina (object 6) wordt beschreven in een zogenaamde ‘stream’. Een stream kan verschillende encodings bevatten. In dit geval bevat de stream de tekst ‘PDF test’ in font F1 en lettergrootte 18. De tekst wordt geprint op locatie 100.700 van de pagina.

C-2009-4-Pacques-list05

Xref en trailer

Tot slot worden de Xrefs gedefinieerd. De Xrefs zijn een index voor de pdf-applicatie en bevatten de absolute offsets (verwijzing) naar de aanwezige objecten (het aantal karakters vanaf het begin van de file tot aan het object). Deze index begint met een offset naar het zogenaamde ‘0-object’ gevolgd door de offsets naar de andere zes objecten in het document. Het eerste object heeft dus een offset van 12, met andere woorden object 1 start 12 bytes na het begin van de file. De trailer geeft aan met welk object de pdf-applicatie dient te beginnen met lezen, in dit geval dus object 1. De startxref bevat een verwijzing (offset) naar de absolute locatie van de xrefs in de file.

C-2009-4-Pacques-list06

Toevoegen van JavaScript in pdf

Het pdf-formaat ondersteunt interactieve content als JavaScript. Ingevoegd JavaScript kan bijvoorbeeld worden uitgevoerd wanneer het document wordt geopend (via /Openaction) of wanneer een specifieke pagina in het document wordt benaderd. In de bovenstaande voorbeeld-pdf kunnen we JavaScript laten uitvoeren bij het openen van het document door het toevoegen van het volgende object (object 7):

C-2009-4-Pacques-list07

Tevens voegen we vanuit het root object een referentie toe (/OpenAction), zodat het object wordt gestart wanneer de file wordt geopend:

C-2009-4-Pacques-list08

Bij het openen van het document wordt het script uitgevoerd en (in dit geval) een pop-up getoond (zie figuur 4).

C-2009-4-Pacques-04

Figuur 4. JavaScript uitvoeren vanuit een pdf-file.

De JavaScript engine voor pdf is erg beperkt. Echter, door gebruik te maken van kwetsbaarheden in Adobe Reader is het mogelijk meer functionaliteit toe te voegen.

Misbruik van kwetsbaarheden in Adobe Reader

In Adobe Reader worden in toenemende mate kwetsbaarheden gemeld. Een voorbeeld is de Util.printf kwetsbaarheid die in het kader hierna in meer detail wordt toegelicht. Enkele andere kwetsbaarheden waar kant-en-klare exploits voor beschikbaar zijn, zijn weergegeven in figuur 5.

C-2009-4-Pacques-05

Figuur 5. Beschikbare pdf-exploits.

Util.printf() buffer overflow (Adobe Reader 8.1.2)

Een van de kwetsbaarheden waar eind vorig jaar veel exploits misbruik van maakten, betreft een buffer overflow[Een buffer overflow is een foutief gedrag van software die probeert data te schrijven in een tijdelijke gegevensruimte maar buiten de grenzen van deze buffer schrijft. Dit veroorzaakt in de meeste gevallen een stopzetting van het programma. Fouten in applicaties, maar nog meer in het geval van besturingssystemen, worden soms misbruikt door wormen, virussen en hackers om ongeoorloofde toegang te krijgen tot computersystemen.] in Adobe Reader. Deze kwetsbaarheid wordt veroorzaakt door een fout in de util.printf() JavaScript-functie. Om deze kwetsbaarheid te misbruiken dient een aanvaller een hiertoe geprepareerde pdf-file door een reguliere gebruiker op een doelsysteem te laten openen. Wanneer de pdf-file wordt geopend, wordt de hierin door de aanvaller verborgen code uitgevoerd onder de rechten van de reguliere gebruiker.

Onderstaande Python-code (volledige toelichting op: http://www.coresecurity.com/content/adobe-reader-buffer-overflow) maakt gebruik van deze buffer overflow. Deze code genereert JavaScript-code die, wanneer uitgevoerd vanuit een pdf, probeert code op geheugenadres 0x30303030 uit te voeren. Wanneer we een string toewijzen in JavaScript wordt deze op een willekeurige plaats in het geheugen geschreven. Om shellcode op adres 0x30303030 te krijgen kan een groot aantal strings naar het geheugen worden geschreven om daarmee de kans te vergroten dat één van deze strings op adres 0x30303030 wordt geplaatst. Deze techniek wordt ook wel heap-spraying genoemd.

C-2009-4-Pacques-list09

De shellcode dient gestart te worden vanaf de eerste instructie. In het ideale geval zou de eerste instructie van het programma dus precies op geheugenadres 0x30303030 terechtkomen. Omdat niet vastgesteld kan worden op welk punt van de stack de huidige code zich bevindt en na hoeveel strings geheugenadres 0x30303030 is bereikt, laten we de shelllcode voorafgaan door een lange zogenaamde NOP-sled.

Een NOP-instructie (No OPeration) bestaat uit slechts één byte en voert geen actie uit, maar vervolgt met de volgende NOP-instructie. Op deze manier kan een groot aantal NOP-instructies doorlopen worden totdat de shellcode bereikt en uitgevoerd wordt. Voor de shellcode maakt het niet uit met welke NOP-instructie er gestart wordt. De hierop gebaseerde exploit ([Mill05]) is op deze wijze opgebouwd. De payload bevat de uit te voeren code.

Tools voor het automatisch creëren van kwaadaardige pdf-bestanden

Online zijn verschillende zogenaamde ‘toolkits’ beschikbaar die een grote hoeveelheid exploitcode bevatten. Met een dergelijke toolkit kan op eenvoudige wijze een geïnfecteerd bestand worden gemaakt. Eén van de bekendere toolkits is het Metasploit framework. De Util.printf exploit is inmiddels als Mixin (plugin) voor het Metasploit framework beschikbaar. Via Metasploit kan eenvoudig de Util.printf() payload[Shellcode (ook wel payload): code die wordt uitgevoerd door de exploit. Bevat de opdracht die op de doelmachine wordt uitgevoerd, veelal het opstarten van een command Shell.] worden geselecteerd die deze vervolgens automatisch in een pdf injecteert. Metasploit is vrij online beschikbaar.

In figuur 6 wordt weergegeven hoe met behulp van Metasploit een pdf kan worden gecreëerd die geïnfecteerd is met de genoemde Util.printf() exploit.

C-2009-4-Pacques-06

Figuur 6. Het creëren van een kwaadaardige pdf.

Nadat de gebruiker de pdf heeft geopend, wordt automatisch een verbinding gemaakt met de aanvaller en een zogenaamde ‘shell’ gecreëerd. De aanvaller kan vervolgens het gecompromitteerde systeem bedienen alsof hij fysiek op het systeem werkt met de rechten van de ingelogde gebruiker. In figuur 7 is te zien hoe de aanvaller een overzicht opvraagt van de op het gecompromitteerde systeem actieve processen. Andere mogelijkheden zijn het bekijken of wijzigen van alle gegevens op het systeem zoals alle wachtwoordhashes van gebruikers.

C-2009-4-Pacques-07

Figuur 7. Opvragen van op het gecompromitteerde systeem actieve processen.

Een alternatief voor het creëren van een shell is het injecteren van een VNC-server. Hiermee kan de aanvaller grafisch meekijken op het scherm van het geïnfecteerde systeem en desgewenst de (muis en toetsenbord) besturing overnemen. Een voorbeeld hiervan is te zien in figuur 8. De aanvaller kan hier precies zien wat er op de desktop van de gebruiker gebeurt en ‘live’ op het scherm meekijken.

C-2009-4-Pacques-08

Figuur 8. Overnemen van het scherm door middel van VNC.

Geautomatiseerd verspreiden van malware (onder andere pdf)

Verspreiden van malware kan, zoals eerder opgemerkt, op verschillende manieren plaatsvinden: via e-mail, peer-to-peer netwerken of websites. Voor verspreiding van exploits via het web zijn op de zwarte markt verschillende zogenaamde ‘exploit packs’ te verkrijgen. Eén van deze exploit packs is El Fiesta, dat voor rond de $ 800 wordt aangeboden op Russische fora. Dit exploits pack bevat een vijfentwintigtal exploits (afhankelijk van de versie), waaronder de eerder beschreven pdf-exploit.

C-2009-4-Pacques-09

Figuur 9. Overzicht van geïnfecteerde systemen in El Fiesta.

Een dergelijk exploit pack bevat hiernaast over het algemeen een webpagina die de aanvaller online kan plaatsen. Wanneer deze wordt bezocht door een bezoeker doorloopt het exploit pack alle aanwezige exploits om vast te stellen of het systeem van de bezoeker kwetsbaar is voor één van deze. Wanneer het systeem van de bezoeker kwetsbaar is wordt dit automatisch geïnfecteerd met een van tevoren bepaalde payload en worden zijn gegevens (IP-adres) naar een database geschreven. De beheerder van de exploitpagina kan rustig afwachten en in een overzicht zien hoeveel gebruikers reeds geïnfecteerd zijn en – in geval van een botnet – de geïnfecteerde clients (bots) opdrachten geven.

Beheersingsmaatregelen en mogelijke gevolgen voor de financiële controle

De hierboven geproduceerde pdf is getest op een systeem met Windows XP SP2 en verschillende Adobe Reader-versies. De pdf kan op alle kwetsbare pdf-versies succesvol worden uitgevoerd.

Het merendeel van de virusscanners herkent de geproduceerde pdf-file nog niet als kwaadaardig. In figuur 10 staan de resultaten van Virustotal, waar het bestand door veertig verschillende virusscanners is onderzocht. Slechts zeven van deze scanners gaven aan dat het bestand kwaadaardige code bevatte.

C-2009-4-Pacques-10

Figuur 10. Resultaten van Virustotal.

Naast het gebruik van een virusscanner is het mogelijk om handmatig een pdf te bekijken met een teksteditor. Verdachte strings zijn /JS en /JavaScript die een indicatie zijn voor JavaScript in de pdf-file. Praktisch alle kwaadaardige pdf-bestanden die ik ben tegengekomen bevatten JavaScript. Vanzelfsprekend betekent het aantreffen van JavaScript niet per definitie dat het een kwaadaardig pdf-bestand betreft.

Naast het bijwerken van antivirusdefinities zijn er verschillende aanvullende maatregelen die genomen kunnen worden om risico’s van applicatiegerichte aanvallen tegen te gaan, waaronder:

het beperken van rechten van lokale gebruikers. Lokale gebruikers dienen op basis van het ‘need to have’-principe ingericht te zijn, en niet de mogelijkheid te hebben zelf applicaties te installeren;
het filteren van outboundconnecties in de firewall om ongewenste verbindingen naar buiten tegen te gaan;
het inrichten van adequate patch-managementprocessen, voor zowel besturingssystemen als applicaties. Er zijn verschillende applicaties die checken of de meest recente versies van applicaties geïnstalleerd zijn, zoals Updatestar, Updatechecker en de PSI-scanner van Secunia;
het inrichten van monitoring om afwijkingen van het toegangsbeleid te detecteren en de te controleren gebeurtenissen te registreren, als bewijs bij beveiligingsincidenten. Systeemmonitoring maakt het mogelijk zeker te stellen dat gebruikers uitsluitend processen uitvoeren waarvoor zij expliciet zijn gemachtigd;
in het incident-managementproces aandacht besteden aan de opvolging van (mogelijk) geïnfecteerde eindgebruikerssystemen;
het inrichten van adequate netwerkscheiding tussen eindgebruikerssystemen en servers (gelaagd netwerkbeveiligingsmodel);
aandacht besteden aan security (awareness) training. Gebruikers dienen te worden getraind in het omgaan met de beveiligingsprocedures en het correcte gebruik van IT-voorzieningen, om eventuele beveiligingsrisico’s te minimaliseren.

Een accountant kan vaststellen in welke mate deze maatregelen zijn ingericht om de noodzaak van het controleren van de veiligheid van werkplekken op te nemen in het controleprogramma.

Conclusie

Sinds een aantal jaren vindt een ontwikkeling plaats waarbij aanvallen zich in toenemende mate op gebruikerssystemen richten. Gebruikers worden hiertoe via allerlei verschillende kanalen benaderd.

Wanneer op werkplekken kwetsbare applicaties aanwezig zijn, zoals een kwetsbare versie van Adobe Reader, bestaat de kans dat een aanvaller die hier misbruik van maakt volledige controle krijgt over de betreffende desktop. Indien een aanvaller in staat is een werkpleksysteem op het interne netwerk te compromitteren (bijvoorbeeld door kwetsbaarheden in het besturingssysteem of applicaties) vergroot deze hiermee de mogelijkheden om een server die relevant is voor de jaarrekeningcontrole tevens te compromitteren aanzienlijk. Dit kan grote impact hebben op de integriteit van daarop aanwezige financiële gegevens en daaraan gerelateerde controles. In een veelvoud van praktijksituaties van de auteur is gebleken dat toegang tot een eindgebruikerssysteem voldoende is om serversystemen te compromitteren en de financiële verslaggeving of andere data in te zien dan wel aan te passen.

Maatregelen als firewalls, virusscanner en updates van besturingssystemen hebben slechts beperkte invloed op het tegengaan van deze bedreiging. Hoewel voor kwetsbaarheden in de applicaties regelmatig patches uitkomen, blijven er ook nieuwe kwetsbaarheden ontdekt worden.

Om vast te stellen of werkplekken gedurende een onderzoeksperiode kwetsbaar zijn geweest, is het van belang de aanwezigheid van beperkende maatregelen zoals deze in voorgaande paragraaf zijn toegelicht, gedurende deze periode te kunnen vaststellen.

[Ball08] Jakob Balle, 1.91% of all PCs are fully patched!, http://secunia.com/blog/37/ 3rd December 2008

[Ball09] Jakob Balle, http://secunia.com/blog/56/, 25th June 2009

[Cisc08] Targeted Internet attacks will increase in 2009, December 19, 2008, Cisco http://www.internet-security.ca/internet-security-news-020/cisco-report-targeted-internet-attacks-will-increase-in-2009.html

[Fies] Fiesta 2.4 – Monitoring ITW exploit, http://www.prevx.com/blog/107/Fiesta—Monitoring-ITW-exploit.html

[Good07] D. Goodin, Nasty PDF exploit runs wild, October 2007, http://www.theregister.co.uk/2007/10/24/pdf_exploit_in_the_wild/

[Govc08] Govcert , juli 2008, Trendrapport 2008: cybercrime in trends en cijfers, http://itknowledgebase.computable.nl/rapport-detailpagina.183112.lynkx?rapportPointer=9-212545-212547-212551&filterValue=tactieken&filterType=&pageStart=

[Hill04] Gijs Hillenius, 25 maart 2004, Code van virussen, spam en spyware versmelt, http://www.computable.nl/artikel/ict_topics/security/258697/1276896/code-van-virussen-spam-en-spyware-versmelt.html

[Lau07] H. Lau, When PDF’s Attack… Again!, October 2007, https://forums.symantec.com/t5/Vulnerabilities-Exploits/When-PDF-s-Attack-Again/ba-p/305545#A125

[MacA08] MacAfee, Exploit-PDF.a, October 2008, http://vil.nai.com/vil/content/v_139103.htm

[Malw09] http://www.h-desk.com/articles/Malware_Trends__What_Will_Attack_Us_in_2009__a45_f1.html

[Micr08] Microsoft Security Intelligence Report volume 6 (July – December 2008), http://www.microsoft.com/downloads/details.aspx?FamilyID=aa6e0660-dc24-4930-affd-e33572ccb91f&displaylang=en

[Mill05] Jason Milletary, October 4, 2005, Trends in Internet Attack, Technology and the Role of Artifact Analysis, http://www.arcert.gob.ar/tc/presentaciones/martes/TendenciasEnCodigoMalicioco-CERTcc.pdf

[Milw] Util.printf exploit http://www.milw0rm.com/exploits/7006

[Naza08] J. Nazario, PDF Exploit – In the wild, and how to decode, November 2008, http://asert.arbornetworks.com/2008/11/pdf-exploit-in-the-wild-and-how-to-decode/

[PDFD] PDF Dictionary, http://1t3xt.info/api//com/lowagie/text/pdf/PdfDictionary.html

[Stev09] Didier Stevens, Hakin9 3/2009 Anatomy of malicious PDF Documents

[Thom01] Ian Thomson, Users left open to attack by failure to patch third-party apps, 21 Apr 2009, http://www.v3.co.uk/vnunet/news/2240702/users-patching-third-party-apps

[Trus08] Trustedsource Anti-Malware Team, Rise Of The PDF Exploits, September 2008, http://www.trustedsource.org/blog/153/Rise-Of-The-PDF-Exploits

Tools

Updatestar: http://www.updatestar.com/

Metasploit 3.3: http://www.metasploit.com/framework/download/

Adobe Acrobat Reader 7, 8.1.1, 8.1.2, 9: http://www.oldversion.com/download_Acrobat_Reader_7.05.html

Updatechecker: http://www.filehippo.com/updatechecker/

Secunia: http://secunia.com/vulnerability_scanning/

IT-beveiligingstesten als onderdeel in IT-audits

Voor beveiligingsonderzoeken worden naast audits steeds vaker beveiligingstesten ingezet. Bij het uitvoeren van beveiligingstesten wordt de effectiviteit van beheersings- en beveiligingsmaatregelen getest. Vreemd genoeg worden audits en beveiligingstesten niet vaak gecombineerd, terwijl zij elkaar een meerwaarde kunnen bieden. Sterker nog, mogelijk dienen beveiligingsonderzoeken gezamenlijk te worden uitgevoerd om de vraag van de klant goed te kunnen beantwoorden.

Inleiding

IT-auditors voeren onderzoeken uit naar IT-omgevingen. Vaak wordt bij een dergelijk onderzoek gekozen voor het uitvoeren van een formele audit. Met een audit is op voorhand een duidelijke structuur van werkzaamheden voorhanden. Bijvoorbeeld is het helder hoe het feitenonderzoek plaatsvindt en op welke wijze conclusies worden getrokken.

In toenemende mate zien wij dat cliënten vragen hebben over de IT-beheersing in combinatie met de aanverwante informatiebeveiliging. Vaak wordt dan gekozen voor een IT-audit van IT-beveiligingsprocessen. Dan kunnen onderwerpen worden geadresseerd zoals het verkrijgen van toegang van gebruikers tot de data en het monitoren van beveiliging.

Naast audits vinden beveiligingstesten plaats. Dit zijn zogenaamde overeengekomen specifieke werkzaamheden waarbij een feitenonderzoek naar beveiligingsmaatregelen plaatsvindt. Feitenonderzoek richt zich niet op getroffen maatregelen, maar op de effectiviteit van een stelsel van maatregelen. Een beveiligingstest maakt dan ook gebruik van een andere aanpak, met andere resultaten.

De reguliere IT-audit heeft een meer procesgerichte aanpak, terwijl de IT-beveiligingstest een meer gegevensgericht onderzoek is. Maar beide onderzoeken worden uitgevoerd om eenzelfde onderzoeksgebied te analyseren. Zouden we de twee onderzoeken dan juist goed kunnen combineren? Hebben beide onderzoeken een grote overlap, of vullen zij elkaar juist aan? Om antwoord te geven op deze vragen is het interessant de beide soorten onderzoeken nader te beschouwen. Vervolgens behandelen we de aanwezige onderlinge versterking om te komen tot inzicht in de synergie.

IT-auditing

IT-auditing is een feitenonderzoek met een vaste structuur en een duidelijke onderzoeksaanpak. Voor het vergaren van de feiten worden de volgende technieken toegepast:

interview van het management en personeel;
inspecteren en beoordelen van documentatie omtrent proces en organisatie;
observatie van getroffen maatregelen;
her-uitvoeren van maatregelen.

Tijdens de interviews met management en personeel wordt beoogd helder te krijgen welke processen plaatshebben binnen de organisatie. Binnen de processen wordt beoordeeld of de procedures worden gevolgd zoals in opzet vastgelegd. Dit heeft tot doel om te beoordelen of afdoende maatregelen zijn geïmplementeerd binnen de procedures (in opzet) en of deze ook daadwerkelijk zijn geïmplementeerd en worden uitgevoerd (bestaan). Als laatste kan ook worden gecontroleerd of de maatregelen gedurende een bepaalde periode actief waren (werking). De maatregelen zijn binnen het toetsingskader gevangen in zogeheten controls. De controls tezamen dienen een integraal en afdoend complex van maatregelen te vormen teneinde in control te zijn van de processen en de organisatie. Een IT-audit heeft hierbij een sterke nadruk op de IT.

Door het inspecteren van de documentatie wordt een beeld verkregen van de opzet van processen, controls, evenals van configuratie-instellingen in de IT-omgeving. Door de opzet te toetsen aan het bestaan en vice versa wordt de werkelijke effectiviteit van de geïmplementeerde controls duidelijk.

Ter aanvulling op interviews en het inspecteren van documentatie wordt gebruikgemaakt van observatie en het her-uitvoeren van controls. In beide gevallen test een IT-auditor als het ware zelf de aanwezigheid, en dus de effectiviteit, van de control. Een passend voorbeeld is te zien binnen het onderwerp van de fysieke beveiligingsmaatregelen. Fysieke beveiligingsmaatregelen worden geïmplementeerd om de toegang tot ruimten binnen bijvoorbeeld een datacenter te controleren. Zo dienen bezoekers met een bezoekerspas niet in staat te zijn bepaalde delen van een datacenter te betreden. Wanneer de IT-auditor een bezoekerspas aanvraagt en deze bij een paslezer houdt, kan hij observeren of hem de toegang wordt geweigerd daar waar in opzet bedoeld. Op basis van de uitkomst van deze test stelt de IT-auditor vast of deze control daadwerkelijk effectief is (de toegang wordt geweigerd).

Naast het bevragen van management en personeel om vast te stellen of geïmplementeerde maatregelen overeenkomen met in opzet vastgelegde procedures, is het noodzakelijk om de IT-systemen ook te toetsen. Deze systemen vormen de basis van de geautomatiseerde processen en procedures. De IT-systemen ondersteunen de processen in een bedrijf en dienen dus ook controlemaatregelen geïmplementeerd te hebben. Een deel van de controls is dus geautomatiseerd. Het betrekken van de IT-systemen binnen het onderzoek naar de beheersing van IT is noodzakelijk.

Het onderzoeken van de IT-systemen en de onderlinge samenhang van geïmplementeerde controls als onderdeel van het feitenonderzoek kost veel tijd (en vraagt dus een groot budget). Het onderzoeken van tientallen applicaties, databases, honderden servers en netwerkapparatuur is een noodzaak, echter niet praktisch haalbaar. Om toch een integrale en correcte uitspraak te doen over het bestaan van controlemaatregelen binnen de IT-infrastructuur, wordt een aantal technieken toegepast: scoping en sampling.

Scoping wordt gebruikt om slechts de relevante IT-infrastructuur in het onderzoek te betrekken. Bij een onderzoek naar bijvoorbeeld de informatiebeveiliging van de financiële gegevens worden alleen de financiële systemen meegenomen; andere systemen dus niet.

Sampling wordt gebruikt om binnen de geselecteerde systemen, specifieke systemen en configuraties te bekijken. Sampling wordt zodanig intelligent uitgevoerd dat een uitspraak over de sample iets zegt over de verzameling waaruit deze voortkomt. Zo wordt een sample genomen uit een groep van gelijksoortig ingerichte systemen, bijvoorbeeld fileservers. Door het onderzoeken van de inrichting van één van de file servers is de inrichting van de overige gelijksoortig ingerichte fileservers onderzocht.

Deze aanpak lijkt solide om te komen tot een onderbouwde uitspraak. Echter, deze aanpak introduceert een drietal problemen:

Niet alle systemen worden onderworpen aan een onderzoek.
De systemen worden vervolgens niet in detail onderzocht.

Naast een beperkt feitenonderzoek op systeemniveau speelt nog een ander probleem: de integrale beoordeling van de geautomatiseerde controls. Hoe beoordeelt men de invloed van een netwerkconfiguratie op een geautomatiseerde controlemaatregel in een server of een database?

Een juiste integrale beoordeling van de IT-omgeving is praktisch niet haalbaar door de complexiteit van de IT-omgeving en de onderlinge dynamiek van de geïmplementeerde controlemaatregelen.

De huidige IT-auditaanpak voor het beoordelen van het bestaan van controlemaatregelen binnen de IT-infrastructuur is niet efficiënt en slechts beperkt effectief. Doordat de systemen technisch gezien slechts beperkt worden bekeken, neemt het risico van een foute uitspraak door de IT-auditor toe. Zo kan een IT-auditor ten onrechte claimen dat het IT-beheer op orde is en de informatiebeveiliging op niveau, terwijl het ondersteunende feitenonderzoek beperkt is geweest.

C-2009-4-Kornelisse-01

Figuur 1. Samenhang en complexiteit van IT-omgevingen vormen een uitdaging binnen een IT-audit voor een juiste uitspraak.

Beveiligingstesten

Auditors voeren al lange tijd beveiligingstesten uit. Een beveiligingstest is een technisch onderzoek naar de effectiviteit van de beveiligingsmaatregelen inzake IT-objecten. Deze effectiviteit wordt vastgesteld door te zoeken naar zwakheden en door die zwakheden eventueel uit te buiten. Een dergelijk onderzoek dient te worden uitgevoerd door iemand die kundig is op het gebied van technische IT-beveiliging. Tevens dient deze persoon de gevonden kwetsbaarheden te kunnen vertalen naar bedrijfsrisico’s. Deze vertaling naar bedrijfsrisico’s is cruciaal om een uitspraak te kunnen doen over de effectiviteit van de IT-beveiliging.

De reden van uitvoeren

De klanten die deze dienst afnemen hebben vaak duidelijke vragen, zoals: is mijn IT-omgeving bestand tegen cyberaanvallen? En als men slaagt in een succesvolle aanval, welke bedrijfsgegevens worden gecompromitteerd? Hoe kan de IT-beveiliging van de omgeving verder worden verbeterd? Allemaal valide vragen, temeer omdat IT-objecten continu staan blootgesteld aan hackers en kwaadwillend personeel. De klant heeft behoefte te weten welke risico’s er zijn, wat de kans van optreden van die risico’s is, wat de impact is, en hoe deze risico’s verlaagd kunnen worden.

Maar waarom beantwoorden we deze vragen door middel van een IT-beveiligingstest en niet door middel van een reguliere IT-audit? Het antwoord daarop is goed uit te leggen door een zijstap te maken naar de wereld van brandoefeningen.

Een brandoefening wordt binnen gebouwen met regelmaat uitgevoerd. Een brandoefening wordt voornamelijk uitgevoerd om een ontruiming wegens brand in het gebouw zo echt mogelijk te simuleren. De brandoefening staat niet op zichzelf. Diverse plannen, overleggen en trainingen voor personeel zijn hieraan voorafgegaan. Daarnaast zijn brandvoorzieningen in de gebouwen aanwezig. Echter, de brandoefening is de ultieme test of al het voorbereidende werk ook effectief is. Door alle maatregelen te testen weet men of deze maatregelen in de praktijk echt werken, of dat er toch een en ander misgaat. Meer dan eens komt door de brandoefening naar voren dat er toch nog zaken over het hoofd zijn gezien. Denk hierbij aan elektrische deuren die (toch) niet opengaan, knelpunten van mensenstromen of brandmelders die dienst weigeren.

Een IT-beveiligingstest kan hiermee worden vergeleken. Het is de test of de beveiliging afdoende effectief is door het uitvoeren van een simulatie, of dat toch nog wat zaken over het hoofd zijn gezien.

Soorten van beveiligingstesten

Beveiligingstesten bestaan in vele smaken. Dergelijke testen kunnen als volgt worden gerubriceerd:

Black box. De aanvaller heeft geen enkele informatie over de objecten in scope.
Grey box. De aanvaller heeft beknopte informatie over het object. Denk hierbij aan een netwerkarchitectuur met verkeersstromen of afgeleide informatie zoals de opzet van een gebruikersnaam.
White box. De aanvaller heeft veel informatie over het object en zelfs een bepaalde vorm van toegang. Denk hierbij aan een webapplicatie waar de aanvaller inloggegevens voor heeft. Het doel is om meer rechten te krijgen binnen de applicatie.

Een term die vaker wordt gebruikt is ‘double’. Een double black box-test betekent dat de aanvaller geen enkele informatie heeft over de objecten in scope. Daarnaast is de IT-organisatie niet op de hoogte van de beveiligingstest. Daardoor wordt de effectiviteit van de beheerorganisatie inzake het herkennen, lokaliseren en mitigeren van een aanval ook getest. Deze test simuleert het best een werkelijke aanvalssituatie.

Mogelijke objecten van onderzoek

Beveiligingstesten kunnen zich richten op een veelheid van objecten. Denk bijvoorbeeld aan:

externe website;
aanwezigheid op het internet (alle systemen aan het internet maar ook de publieke informatie zoals Google en RIPE);
het interne netwerk voor kantoorautomatisering;
applicaties zoals een intranet of een CRM-systeem;
databases;
mobiele apparatuur (bijvoorbeeld een telefoon of PDA);
personeel.

Hoewel het personeel strikt genomen geen IT-object is, kan het personeel wel object van onderzoek zijn. Om maatregelen op het niveau van het personeel te testen, wordt een zogeheten social engineering test uitgevoerd. Met een dergelijke test wordt onderzocht of het personeel zich houdt aan het beveiligingsbeleid van het bedrijf. Denk hierbij aan het doorlaten van personen zonder pasje bij een elektronisch beveiligde deur, het niet afsluiten van ongebruikte computers, het opschrijven van wachtwoorden bij de computer of het communiceren van wachtwoorden via de telefoon.

Wijze van onderzoek

Beveiligingstesten zijn, op social engineering tests na, technische onderzoeken. Hierbij wordt direct met de techniek gecommuniceerd. Het gebruik van programmatuur ter ondersteuning van het onderzoek is dan ook een logisch gevolg. Dit kan veel tijdwinst opleveren. Bijvoorbeeld: het proberen van een aantal wachtwoorden vindt geautomatiseerd sneller plaats dan met de hand. Tevens kan de tester ondertussen zijn aandacht dan ergens op richten. Maar let op, de programmatuur ten behoeve van IT-beveiligingstesten dient louter ter ondersteuning, want zij kan slechts simpele taken automatiseren. De resultaten van de programmatuur dienen altijd gevalideerd te worden door de tester. Vanwege de complexiteit kan nooit op de pure uitkomst van de programmatuur worden vertrouwd, omdat de programmatuur vaak zogenaamde false-positives (niet bestaande zwakheden) rapporteert. Het bekende credo ‘a fool with a tool is still a fool‘ gaat hier dan ook zeker op.

Het uitvoeringsproces van een IT-beveiligingstest is terug te brengen tot de volgende stappen: mapping, scanning en exploiting. De keuze van deze stappen, samen met de objecten, bepaalt de mate van intrusie. We herkennen hierbij de volgende onderverdeling: vulnerability assessment, penetration testing en red teaming. Het verschil hiertussen is het beste uit te leggen aan de hand van figuur 2.

C-2009-4-Kornelisse-02

Figuur 2. Overzicht van soorten IT-beveiligingstesten.

In de mappingfase wordt gekeken welke systemen überhaupt aanwezig zijn in het netwerk en welke services actief zijn op die systemen. Tevens worden metadata uit zoekmachines of andere publieke bronnen geraadpleegd. In de scanningfase worden versies van software herkend en worden de objecten onderworpen aan scans op zoek naar zwakheden. Deze twee fasen samen zijn onderdeel van een ‘vulnerability scan’. In deze twee stappen wordt veel gebruikgemaakt van geautomatiseerde tools.

Een volledige penetration test omvat ook de derde stap: exploiting. In deze stap worden gevonden zwakheden uitgebuit om zo in de systemen te kunnen inbreken. Dat kan door middel van een exploit, stukken programmacode die een kwetsbaarheid uitbuiten. De aanvaller laat het object in kwestie acties uitvoeren die de aanvaller toegang verschaffen. Na een succesvolle exploitingfase heeft de aanvaller toegang verkregen tot het object met bijbehorende gegevens.

De term red teaming is een uitbreiding op penetration testing en is afkomstig uit de militaire wereld waar het in gevechtsimulaties wordt gebruikt. Bij red teaming is het doel het belangrijkste. De trukendoos mag volledig open; alle acties die men kent mogen worden gebruikt. Bij IT-beveiligingstesting kan men hierbij denken aan een bedrijf dat louter is geïnteresseerd of inbreken mogelijk is, in de brede zin van het woord. Een combinatie van social engineering (manipuleren van mensen), phishing (ontlokken van gevoelige informatie, zoals gebruikersnaam en wachtwoord) en war driving (zoeken naar en toegang verkrijgen tot het draadloos netwerk van het bedrijf) met interne en externe penetratietesten kan dan bijvoorbeeld worden gebruikt om het doel te bereiken.

Wijze van rapporteren

Een beveiligingstest is, net als een IT-audit, een feitenonderzoek. Echter, bij een beveiligingstest worden alleen negatieve feiten gerapporteerd, bijvoorbeeld: ‘De gebruikte wachtwoorden voor het systeemaccount zijn gelijk aan de standaardwachtwoorden van de fabrikant, en daardoor gemakkelijk te raden‘.

Door een zwakheid te vinden of door in te breken op een systeem kan worden aangetoond dat de beveiliging niet afdoende is. Andersom kan niet worden geredeneerd. Als het niet lukt zwakheden te vinden of in te breken, dan betekent dat niet dat deze zwakheden er niet zijn. Een hacker met ongelimiteerde tijd of budget zal vrijwel altijd kunnen inbreken. Immers, een hacker hoeft zich niet te houden aan gemaakte afspraken over de toegestane aanvallen!

Het eindresultaat van een IT-beveiligingstest is een rapport of presentatie met negatieve bevindingen en aanbevelingen ter verbetering.

Overeenkomsten en verschillen van IT-audit en IT-beveiligingstest

Om een beeld te krijgen van de overeenkomsten en verschillen tussen werkzaamheden inzake IT-audits en -beveiligingstesten hebben wij deze uitgezet op basis van een aantal aspecten.

1. Soorten onderzoeken

De soorten IT-audits zijn in te delen op basis van de hoeveelheid assurance: redelijke mate van zekerheid, beperkte mate van zekerheid en feitelijke bevindingen. Daarbij zijn de eerste twee soorten vaak van toepassing als de uitkomst van het onderzoek niet alleen voor de opdrachtgever maar ook voor derden toegankelijk is. Denk bijvoorbeeld aan een SAS70, TPM of jaarrekeningcontrole. De laatste soort (feitelijke bevindingen) wordt vaak gebruikt door bedrijven om een nulmeting uit te voeren of om zichzelf te verbeteren. Deze informatie is niet bedoeld voor derden, omdat er geen conclusie is verbonden aan de feitelijke bevindingen.

De soorten IT-beveiligingstesten zijn terug te brengen tot: vulnerability assessment, penetratietest en red teaming. De eerste test gaat in op het in kaart brengen van geverifieerde zwakheden. De tweede en derde test gaan een stap verder door de gevonden zwakheden daadwerkelijk uit te buiten. Bij red teaming is het arsenaal aan toegestane middelen onbeperkt, terwijl dit bij een penetratietest zich beperkt tot een bepaalde scope. De IT-beveiligingstest lijkt qua soort sterk op het onderzoek van feitelijke bevindingen bij de IT-audit.

2. Publiek

Het publiek van een IT-audit en een IT-beveiligingstest is verschillend. Zoals gezegd kan een rapport van een IT-audit ook voor derden zijn. Bij IT-beveiligingstesting is dit niet het geval. Immers, alle gevonden kwetsbaarheden zijn dan beschikbaar voor de buitenwereld. Dit is niet wenselijk. Een ander verschil is dat het publiek van een IT-beveiligingstest vaak sterke affiniteit heeft met IT (bijvoorbeeld een IT-manager) en niet zozeer met bedrijfsprocessen. Bij een IT-audit bestaat het publiek naast de opdrachtgever soms uit derden en heeft het publiek vaak meer affiniteit met bedrijfsprocessen en risico’s dan met de techniek. Een voorbeeld hiervan zijn CEO’s, CFO’s en CIO’s als opdrachtgever. Derden zijn bijvoorbeeld toezichthouders of (in het geval van outsourcing) de demandorganisatie.

3. Toetsingsnormen van een IT-audit en een IT-beveiligingstest

IT-audits worden uitgevoerd op basis van verschillende toetsingsnormen. Dit is afhankelijk van het precieze doel van het onderzoek en de omgeving waarin het onderzoek plaatsvindt. Op het gebied van IT-beheer en informatiebeveiliging zijn de toetsingsnormen bijvoorbeeld Cobit, ITIL en ISO 27001.

Voor IT-beveiligingstesting echter zijn geen algemeen en internationaal geaccepteerde toetsingsnormen voorhanden. Wel zijn er initiatieven om te komen tot dergelijke toetsingsnormen. Een voorbeeld hiervan is OWASP: Open Web Application Security Project. OWASP is een verzameling toetsingsnormen voor webapplicaties.

4. Uitvoering van een IT-audit en een IT-beveiligingstest

Het onderzoek van een IT-audit vindt plaats op basis van documentatiestudie, interviews en observaties. Er wordt uitgegaan van de bekende maatregelen binnen het bedrijf, waarvan opzet, bestaan en werking van deze maatregelen worden getoetst. De nadruk ligt op de opzet, het bestaan en de werking van het beleid en de procedures. De techniek krijgt slechts beperkte aandacht.

Een IT-beveiligingstest heeft juist de focus op de techniek. Deze vindt plaats op basis van een black box-benadering. Dit betekent dat er wordt uitgegaan van het onbekende in plaats van het bekende: de tester weet niet welke maatregelen er zijn getroffen. De focus ligt op de daadwerkelijke effectiviteit van de maatregelen die in de techniek zijn geïmplementeerd. Deze maatregelen worden getest door te bekijken of deze omzeild kunnen worden.

5. Kwaliteitsaspecten van een IT-audit en een IT-beveiligingstest

Een IT-audit kan zich richten op een groot aantal kwaliteitsaspecten. Denk hierbij aan performance, toekomstvastheid, (beheer)kosten, projectplanning, etc. Daarbinnen wordt een IT-audit ook vaak gebruikt voor beveiligingsonderzoeken. De kwaliteitsaspecten komen precies overeen met die van een IT-beveiligingstest:

Beschikbaarheid

Kernvraag: zijn de systemen altijd beschikbaar? Onderwerpen die aan bod komen zijn bijvoorbeeld het gecontroleerd laten verlopen van wijzigingen in de IT-omgeving, redundantie van IT-systemen en reservekopieën van gegevens.

Bij een IT-audit worden voor dit aspect vaak het beleid en de procedures rondom change management, redundantie en back-up & recovery bekeken.

Bij een IT-beveiligingstest wordt getracht om IT-objecten onbeschikbaar te maken in de omgeving, door deze bijvoorbeeld te overstelpen met bevragingen of juist gegevens toe te sturen.

Vertrouwelijkheid

Kernvraag: kan iemand bij gegevens die hij/zij niet mag zien? Hierbij wordt vaak gekeken naar de autorisaties die gebruikers hebben op de gegevens. Zo zouden de medewerkers van een verkoopafdeling geen inzicht moeten hebben in de gegevens van de HR-afdeling.

Bij een IT-audit ligt de nadruk op de procedures rond het aanmaken, wijzigen en verwijderen van gebruikersaccounts en de autorisaties die bij de gebruikersaccounts horen. Ook wordt aandacht besteed aan de periodieke controle van die accounts en autorisaties. Tevens is er aandacht voor de opzet en het bestaan van beveiligingsinstellingen in de IT-omgeving.

Bij een IT-beveiligingstest wordt getracht die geïmplementeerde maatregelen te testen en waar mogelijk te omzeilen.

Integriteit

Kernvraag: kan iemand gegevens zonder toestemming aanpassen? Ook hierbij wordt vaak gekeken naar de autorisaties die gebruikers hebben op de gegevens.

Voor zowel een IT-audit als een IT-beveiligingstest gelden dezelfde aandachtsgebieden als bij vertrouwelijkheid. Echter, hier wordt ook gekeken naar de daadwerkelijke mogelijkheid voor gebruikers om gegevens te manipuleren.

6. Onderzoeksobjecten van een IT-audit en een IT-beveiligingstest

De onderzoeksobjecten bij een IT-audit bestaan in hoofdzaak uit mensen, processen en (zij het beperkt) IT-systemen. Hierbij ligt de focus op de samenhang van deze drie objecten.

Bij een IT-beveiligingstest is het accent juist omgekeerd. De onderzoeksobjecten bij een IT-beveiligingstest zijn de IT-systemen. Soms zijn dit ook mensen (bijvoorbeeld bij een social engineering test), waarmee er dus een overlap is met een IT-audit, zij het met een andere invalshoek.

7. Reikwijdte van een IT-audit en een IT-beveiligingstest

De reikwijdtes van een IT-audit en een IT-beveiligingstest verschillen onderling. Onder reikwijdte wordt hier verstaan: de objecten die bekeken worden en de mate van detail waarin dit gebeurt.

Een IT-audit dekt voornamelijk het gebied af van beleid en procedures. Er wordt gekeken naar de volledige opzet van het beleid en de procedures. Ook wordt er gekeken naar enkele samples van het bestaan. Tot slot wordt die bestaanscontrole toegepast op gegevens die over een periode zijn verzameld. Hieruit blijkt de werking. De onderliggende techniek krijgt beperkte aandacht en wordt niet in (individueel) detail bekeken.

Een IT-beveiligingstest dekt zoals gezegd andere zaken af. De focus ligt juist niet op het voorgenomen beleid en de procedures, maar op de implementatie van de maatregelen in de techniek. De techniek krijgt veel aandacht. Verder wordt zoveel mogelijk getracht om de techniek tot in individueel detail te bekijken. De geïdentificeerde problemen worden vertaald naar bedrijfsrisico’s en mogelijke root causes. Een harde relatie tussen de geïdentificeerde problemen en het beleid en procedures is niet te geven, zonder het beleid en de procedures onderzocht te hebben.

C-2009-4-Kornelisse-t01

Tabel 1. Aspecten van IT-audit en IT-beveiligingstest vergeleken.

Voordelen van een beveiligingstest als onderdeel van een IT-audit

Uit tabel 1 kunnen we concluderen dat IT-beveiligingstesting voordelen heeft ten opzichte IT-auditing. Een aantal daarvan is goed toepasbaar tijdens IT-audits en levert direct voordelen op voor IT-audits.

Snelheid

Het uitvoeren van een vulnerability scan of een penetratietest gaat relatief snel. Binnen enkele uren ontstaat een eerste beeld. Bijvoorbeeld: is het updaten van software consequent uitgevoerd? Het grote aantal objecten dat tegelijk kan worden bekeken (geautomatiseerd) biedt ook snelheidsvoordeel. Dit heeft als bijkomend voordeel dat men zou kunnen kiezen om periodiek een, deels geautomatiseerde, test uit te voeren. Hierdoor ontstaat een beeld over een langere periode en kan mogelijk meer gezegd worden over de werking van de maatregelen in de loop van de tijd.

Controle van bestaan van objecten

Bij een IT-securityscan wordt begonnen met te onderzoeken welke objecten daadwerkelijk aanwezig zijn op een netwerk, in tegenstelling tot het vertrouwen op de lijst van systemen aangereikt door de klant. Hierdoor kan het voorkomen dat objecten worden (her)ontdekt. Denk bijvoorbeeld aan een systeem dat men vorig jaar al dacht te hebben uitgefaseerd of aan een niet-geautoriseerde netwerkkoppeling naar internet of een ander bedrijf.

Scopingondersteuning

Een IT-beveiligingstest kan een IT-audit helpen bij het maken van de juiste keuzen omtrent scoping, sampling en de onderwerpen die extra aandacht behoeven binnen de IT-audit. Als uit de IT-beveiligingstest blijkt dat veel Windows systemen niet geüpdatet zijn, is dit voor een IT-audit een goed startpunt om het updatebeleid onder de loep te nemen en daarnaast de Windows beheerorganisatie extra aandacht te geven.

Verminderde complexiteit

IT-omgevingen groeien en zullen vooral nog meer blijven groeien. Tevens worden systemen steeds afhankelijker van de invoer vanuit andere systemen. Deze samenhang en complexiteit van de verschillende maatregelen binnen de IT-omgevingen kunnen verstrekkende gevolgen hebben die op het eerste gezicht niet altijd even duidelijk zijn. Een IT-beveiligingstest kan deze samenhang van technische componenten duidelijk aantonen door te zoeken naar de zwakste schakel in het beveiligingsmodel. Op basis van een dergelijk onderzoek kan blijken dat de functiescheiding in een applicatie niet gewaarborgd is door kwetsbaarheden in onderliggende databases, besturingssystemen of netwerk.

Duidelijke impact

Het resultaat van een IT-beveiligingstest maakt de impact van een kwetsbaarheid heel duidelijk. ‘Wij waren in staat ongeautoriseerde betalingen te verrichten’ is immers duidelijker dan ‘De autorisaties van het betaalsysteem en het controlesysteem zijn onvoldoende gewaarborgd. Dit kan leiden tot ongeautoriseerde betalingen’. Het risico is in beide gevallen gelijk, maar de impact is duidelijker doordat de eerste formulering veel concreter is.

C-2009-4-Kornelisse-03

Figuur 3. IT-beveiligingsonderzoek ondersteunt IT-audit door het versterken van de breedte en diepte van het onderzoek.

Voordelen IT-audit bij een IT-beveiligingstest

IT-auditing heeft ook een aantal voordelen ten opzichte van beveiligingstesten. Deze zijn samen te vatten tot onderstaande punten:

Root cause analyse

Techniek wordt ingericht en bestuurd door mensen. Mensen kunnen fouten maken. Deze fouten komen tot uiting in de implementatie van de techniek. Maar het hoeft niet zo te zijn dat de fout alleen daar ligt. Doordat een IT-audit ook kijkt naar het beleid en naar procedures kan het een grondigere root cause analyse maken.

C-2009-4-Kornelisse-04

Figuur 4. Synergie tussen IT-audit en IT-beveiligingstesting.

Toekomstvastheid

Daar waar een IT-beveiligingstest een momentopname is kan een IT-audit een periode van tijd onderzoeken. Dit heeft tot gevolg dat een IT-audit ook een betere uitspraak kan doen over een toekomstige tijd. Als procedures worden gevolgd en periodieke controles plaatsvinden geeft dat meer waarborgen voor de toekomst dan dat een object op een bepaald moment veilig is ingericht.

Conclusie

Nu we de twee verschillende onderzoeken besproken hebben, is duidelijk dat ze elkaar aanvullen juist op de plekken waar zij zwaktes vertonen. Wanneer we de combinatie van IT-audit en IT-beveiligingstesting gebruiken ontstaan er twee voordelen:

Efficiëntie (budget). Door de juiste onderzoeksaanpak te kiezen voor de verschillende onderzoeksobjecten kan het onderzoek veel efficiënter worden uitgevoerd.
Verlaging audit risk. Door de juiste onderzoeksaanpak te kiezen voor de verschillende onderzoeksobjecten kan het onderzoek veel meer in de diepte en breedte worden uitgevoerd en wordt de IT integraler getoetst.

Bovenstaande voordelen tonen aan dat een technische IT-audit dan ook veel baat heeft bij een IT-beveiligingstest.

De Payment Card Industry – Data Security Standard

Berichten over grote aantallen gecompromitteerde creditcardgegevens komen regelmatig in het nieuws. Indien met deze gestolen gegevens vervolgens ook fraude wordt gepleegd, kan dit invloed hebben op het vertrouwen dat gebruikers in het gebruik van creditcards hebben en dus uiteindelijk resulteren in mogelijk lagere opbrengsten voor creditcardmaatschappijen door het verminderde gebruik. Daarom is al enige tijd geleden de Payment Card Industry – Data Security Standard in het leven geroepen die moet voorkomen, dan wel tijdig detecteren, dat creditcardgegevens worden gecompromitteerd. In dit artikel wordt beschreven wat deze standaard inhoudt, welke problemen er kunnen optreden bij de implementatie en hoe deze kunnen worden aangepakt en wat de gevolgen kunnen zijn als men niet compliant is.

Inleiding

De leden van de Payment Card Industry (PCI) Security Standards Council (American Express, Discover, JCB, MasterCard en Visa) monitoren continu gevallen van het compromitteren van creditcardgegevens. Een beveiligingsincident en vervolgens het compromitteren van creditcardgegevens kan verstrekkende gevolgen hebben voor de betrokken organisaties, inclusief mogelijke notificatievereisten ten aanzien van het incident (in bijvoorbeeld de Verenigde Staten[Hoewel in Europa ook wordt gesproken over zogenaamde ‘security breach notification’, wil men op dit moment dat zo’n notificatie alleen van toepassing zal zijn op telecomproviders en niet op bijvoorbeeld online banking.]), reputatierisico, verlies van klanten, mogelijke financiële verplichtingen en rechtszaken.

Uit analyse achteraf is gebleken dat veelvoorkomende beveiligingszwakheden die door de Payment Card Industry Data Security Standard (PCI DSS) worden geadresseerd, niet waren geïmplementeerd door organisaties ten tijde van het beveiligingsincident. De PCI DSS werd opgezet en bevat gedetailleerde vereisten om exact deze reden – om de kans op en de gevolgen van een beveiligingsincident te minimaliseren. De PCI DSS is opgezet door de oprichters van de PCI Security Standards Council (PCI SSC) om de brede globale acceptatie van consistente databeveiligingsmaatregelen te bewerkstelligen. De standaard bevat onder andere vereisten voor security management, policies, procedures, netwerkarchitectuur en softwareontwikkeling.

Heartland Payment Systems processes payments for over 250,000 mostly small and mid-size businesses and merchants in the U.S. and is considered to be the sixth-largest payment processor in the country. On 20 January 2009, the company announced that, during an internal audit prompted by a Visa warning, it had discovered that transaction data passing through its network had been intercepted and a significant number of credit cards had been compromised.

RBS WorldPay offers payment-processing solutions that cover credit, debit, Electronic Bank Transfers, gift cards, customer loyalty cards, checks, ATM, and tailored solutions for retail, restaurant, petroleum, convenience stores, grocery, hospitality, transport, and cardholders not present in these sectors. On 23 December 2008, the company announced that, at the beginning of November, unidentified parties had illegally obtained access to its computer systems and potentially compromised the personal information of 1.5 million customers.

RBS also noted that 100 payroll cards had been fraudulently used and had, subsequently, been disabled. It was later revealed that these cards had been employed in one of the most complex and well-coordinated fraud schemes to have ever been instrumented. Over 130 different ATM machines in 49 cities worldwide were hit in a 30-minute period, the crooks successfully withdrawing a whooping $9 million.

(Bron: news.softpedia.com)

PCI DSS

Welke data moet worden beschermd?

Creditcardgegevens kunnen worden gedefinieerd als het zogenaamde Primary Account Number (PAN) en andere gegevens die worden verkregen als onderdeel van een betaaltransactie, waaronder de volgende gegevens vallen:

naam van kaarthouder;
vervaldatum;
servicecode;
gevoelige authenticatie-informatie, zoals:
- de volledige ‘magnetic stripe’-gegevens (op magnetische strip, op een chip of elders opgeslagen);
- zogenaamde card validation codes;
- pingegevens.

Het PAN is de factor die bepaalt of de PCI DSS en de PA DSS (Payment Application Data Security Standard) van toepassing zijn. Indien het PAN niet wordt opgeslagen, verwerkt of verstuurd, dan zijn de PCI DSS en de PA DSS ook niet van toepassing.

In dit artikel zal overigens verder niet worden ingegaan op de PA DSS. Het is wel goed om te weten dat de standaard bestaat om de beveiliging van third party payment applicaties te beoordelen. De beveiliging van zelfontwikkelde applicaties wordt door de PCI DSS afgedekt. Een lijst van gecertificeerde applicaties is beschikbaar via de PCI SSC.

Naam van kaarthouder, vervaldatum en servicecode moeten beschermd worden indien deze worden opgeslagen samen met het PAN, conform de PCI DSS. Tevens zouden op deze gegevens nog additionele (wettelijke) regels van toepassing kunnen zijn, zoals privacyregels.

De gevoelige authenticatie-informatie mag volgens de PCI-standaard nooit worden opgeslagen nadat autorisatie voor een betaling al is verkregen.

C-2009-4-IJkel-t01

Tabel 1. Overzicht creditcardgegevens en vereisten ten aanzien van opslag en beveiliging (ofwel versleuteling).

Zoals boven vermeld is het niet toegestaan gevoelige authenticatie-informatie op te slaan. Dit is om de eenvoudige reden dat indien deze gegevens samen met het PAN kunnen worden verkregen, er grote risico’s ontstaan dat deze gegevens worden misbruikt voor het uitvoeren van frauduleuze transacties.

C-2009-4-IJkel-01

Figuur 1. Visuele weergave elementen creditcardgegevens, voor- en achterzijde.

Indien een crimineel de ‘magnetic stripe’-gegevens in handen zou krijgen, dan zou er zelfs een volledige kopie van de creditcard gemaakt kunnen worden. De figuren 2 en 3 laten zien welke informatie op de magnetic strip van een creditcard staat.

C-2009-4-IJkel-02

Figuur 2. Visuele weergave gegevens op track 1 van de magnetic stripe.

C-2009-4-IJkel-03

Figuur 3. Visuele weergave gegevens op track 2 van de magnetic stripe.

Voor wie en waarop is de PCI DSS van toepassing?

In principe dient eenieder (met uitzondering van de eindgebruiker) die creditcardgegevens opslaat, verwerkt of verstuurt te voldoen aan de PCI DSS. Dit geldt dus voor zowel grote partijen, bijvoorbeeld Equens, als kleine partijen, zoals een webwinkel met maar enkele creditcardtransacties per jaar. De wijze waarop compliance moet worden aangetoond verschilt echter, enerzijds op basis van de rol die men heeft (serviceprovider of merchant) en anderzijds op basis van het volume van transacties per jaar.

C-2009-4-IJkel-t02

Tabel 2. Merchantniveaus en compliance-validatievereisten Visa; andere creditcardmaatschappijen hanteren een gelijksoortige indeling.

C-2009-4-IJkel-t02

Tabel 3. Serviceproviderniveaus en compliance-validatievereisten Visa.

De scope waarvoor compliance moet worden aangetoond, wordt in de PCI DSS gedefinieerd als alle systeemcomponenten die onderdeel zijn van of een connectie hebben met de zogenaamde ‘cardholder data’-omgeving. De ‘cardholder data’-omgeving is dat gedeelte van het netwerk waar cardholder data of gevoelige authenticatiegegevens zich bevinden, inclusief netwerkcomponenten, servers en applicaties. Uiteindelijk zou deze regel vanuit de PCI DSS kunnen resulteren in het toepasbaar zijn van de PCI DSS op het gehele interne netwerk van een bedrijf en niet alleen de ‘cardholder data’-omgeving zelf!

Hoe moet de data worden beschermd?

De PCI DSS bevat min of meer 6 onderwerpen, 12 gebieden en 62 hoofdvereisten. Deze 62 hoofdvereisten bestaan op hun beurt weer uit een aantal meer gedetailleerde vereisten waaraan men moet voldoen om aan de hoofdvereisten te kunnen voldoen. In tabel 4 zijn de onderwerpen en gebieden weergegeven, inclusief een korte uitleg over wat deze betekenen.

C-2009-4-IJkel-t04

Tabel. 4. Onderwerpen en gebieden van de PCI DSS, met korte toelichting.

In principe moet men aan alle vereisten voldoen om PCI-compliant te worden. Hoewel veel van deze vereisten kunnen worden gezien als normale good practices om een IT-omgeving te beveiligen en te beheren, is er toch een aantal gebieden die het moeilijk (kunnen) maken om compliant te geraken.

Wat zijn veelvoorkomende problemen bij implementatie?

Op basis van de ervaringen die zijn voortgekomen uit het recente verleden bij bedrijven die reeds de PCI DSS hebben geïmplementeerd en ook zoals KPMG deze is tegengekomen bij haar klanten, kan een aantal implementatieproblemen worden gedefinieerd. Inmiddels is het ook tot creditcardmaatschappijen doorgedrongen dat compliancy niet altijd binnen korte tijd is te realiseren en daarom is het van belang om constant in contact te blijven met deze maatschappijen om afspraken te maken over het pad om uiteindelijk wel volledige compliancy te bereiken.

Locatie van cardholder data

Aan het begin van een PCI DSS-traject is vaak niet exact bekend waar cardholder data precies is opgeslagen en of deze opslag ook werkelijk noodzakelijk is. Een inventarisatie zal dus moeten worden gemaakt van alle systemen (inclusief eindgebruikersystemen) en er zal moeten worden bepaald of het aantal locaties waar data wordt opgeslagen niet kan worden teruggebracht.

Zonder inventarisatie kan ook niet worden vastgesteld of men PCI-compliant is, aangezien er geen informatie beschikbaar is over de scope. Het niet terugdringen van het aantal locaties waar cardholder data zich bevindt kan mogelijk resulteren in kostbare maatregelen die op meer systemen moeten worden geïmplementeerd (zoals de versleutelingseisen).

Scoping

De PCI DSS schrijft voor dat alle systeemcomponenten die onderdeel zijn van of een connectie hebben met de ‘cardholder data’-omgeving compliant moeten worden gemaakt. Indien geen netwerkscheiding wordt aangebracht tussen de ‘cardholder data’-omgeving en de rest van het interne netwerk van een bedrijf, dient het gehele interne netwerk PCI-compliant te worden gemaakt, wat een onmogelijke, dan wel zeer tijdrovende en kostbare taak kan blijken te zijn.

Het is daarom van het grootste belang om te trachten de ‘cardholder data’-omgeving af te scheiden van het interne netwerk via interne firewalls. Hierdoor kan de scope worden beperkt en dus ook de inspanning om de PCI DSS te implementeren.

Veranderingen in bedrijfsprocessen

Het invoeren van de PCI DSS, inclusief het beperken van de locaties waar cardholder data zich bevindt en overige pogingen om de scope te beperken, kan tevens resulteren in de noodzaak om bepaalde bedrijfsprocessen dan wel IT-beheerprocessen te wijzigen.

Organisatorische veranderingen kunnen soms rekenen op weerstand en tevens hebben nieuwe processen vaak een aanlooptijd nodig voordat deze volledig werken zoals voorzien.

Monitoring

De PCI DSS bevat aanzienlijk uitgebreide vereisten ten aanzien van logging en monitoring. Ten eerste moet worden nagegaan in hoeverre bestaande applicaties en systemen wel voldoende mogelijkheden bieden om aan de vereisten te voldoen en wat er exact zou moeten worden gemonitord binnen de applicaties en systemen. Voorts dient mogelijk nieuwe software te worden geïmplementeerd en personeel te worden aangenomen om ook de monitoring goed te kunnen uitvoeren.

Versleuteling cardholder data

Het voldoen aan de vereisten van versleuteling van cardholder data is soms moeilijk te implementeren, bijvoorbeeld:

omdat gebruik wordt gemaakt van legacy draadloze netwerken (met zwakke of geen versleuteling) in bijvoorbeeld winkels waar creditcardgegevens van ‘point of sale’-systemen naar centrale systemen worden verstuurd;
omdat er sprake is van legacy applicaties waarin het niet mogelijk is zodanige veranderingen in de software door te voeren dat de software versleuteling van en naar de database met de cardholder data ondersteunt.

Voortdurende compliance

Nadat de initiële PCI-compliance is gerealiseerd, is het noodzakelijk dat aandacht wordt besteed aan het compliant blijven. Nieuwe systemen en applicaties die worden geïntroduceerd zullen aan dezelfde eisen moeten voldoen als de initiële omgeving, daarnaast kunnen er ook updates plaatsvinden op de PCI DSS-vereisten die moeten worden opgevolgd. Tot slot zijn er ook bepaalde eisen in de PCI DSS die een bedrijf waarschijnlijk niet zelf kan en/of mag uitvoeren. Een voorbeeld hiervan zijn de vereisten in tabel 4 onder punt 11, die het minimaal jaarlijks uitvoeren van interne en externe penetratietests verplicht stellen en daarbij een mate van onafhankelijkheid eisen van degene die de penetratietest uitvoert ten opzichte van de organisatie die het beheer van de PCI-omgeving uitvoert.

Samenvatting en conclusie

De PCI DSS dient de kans op beveiligingsincidenten in de ‘cardholder data’-omgeving te verkleinen en de detectie van (mogelijke) incidenten te verhogen, om uiteindelijk fraude met creditcardgegevens te voorkomen. Indien bedrijven die in principe verplicht zijn de PCI DSS te implementeren dit niet (goed) doen, kan dat tot onder andere boetes en het verlies van klanten leiden en dus negatieve financiële consequenties hebben of misschien zelfs wel de continuïteit schaden. In de Verenigde Staten zijn er zelfs staten (Minnesota) die compliance met de PCI DSS wettelijk verplicht hebben gesteld).

Het is dus van belang dat bedrijven zorgen dat ze compliant zijn. Hiertoe dient wel een aanpak te worden gehanteerd die efficiënt en effectief is en dus te hoge compliancekosten vermijdt. Hiervoor is het vooral van belang dat rekening wordt gehouden met de scope waarop de PCI DSS van toepassing is en die trachten zo klein mogelijk te maken. Tevens dient open communicatie plaats te vinden met de creditcardmaatschappijen, of de partij waaraan compliance moet worden aangetoond, om de voortgang van compliance te bespreken en eventueel te kunnen uitleggen waarom het voldoen aan bepaalde eisen meer tijd vergt.

Literatuur

https://www.pcisecuritystandards.org/, PCI DSS 1.2, oktober 2008.

https://www.pcisecuritystandards.org/, PCI DSS 1.2, ‘Navigating PCI DSS’, oktober 2008.

http://boonbox.net/resources.htm, Managers’ Cheat Sheet for PCI DSS, december 2008.

http://www.pcicomplianceguide.org/

http://news.softpedia.com/news/Heartland-and-RBS-WorldPay-No-Longer-PCI-Compliant-106826.shtml, 16 maart 2009.

http://usa.visa.com/merchants/risk_management/cisp_merchants.html

http://www.out-law.com/page-9841, ‘EU nations oppose extension of data breach notification law’, 3 maart 2009.

https://www.revisor.leg.state.mn.us/bin/bldbill.php?bill=S1574.2.html&session=ls85

Informatiebeveiliging versus open source software

Open source software is volwaardige software. De tijd is voorbij dat open source software het exclusieve domein was van enkele gedreven techneuten, academici en activisten. Steeds meer commerciële ondernemingen en publieke instellingen overwegen om over te stappen van hun vertrouwde Microsoft-, SAP- en Oracle-omgevingen naar open source alternatieven. De vraag die hierbij wordt gesteld door menig CIO en CISO luidt: ‘Is het gebruik van open source software veilig?’ In dit artikel geeft de kritische IT-auditor zijn antwoord op deze vraag.

Inleiding

Open source software groeit gestaag. Wat voorheen door het bedrijfsleven werd afgedaan als vrijblijvende initiatieven van hobbyisten is uitgegroeid tot een volwaardige tegenhanger van commerciële closed source software.[Dikwijls wordt ook de term proprietary (‘eigendoms-‘) software gebruikt. Aangezien ook open source software deels in eigendom kan zijn, wordt in dit artikel de term closed source software gehanteerd.] Inmiddels besturen verschillende soorten Linux gigantische serverparken van multinationale concerns, OpenOffice wedijvert steeds serieuzer met Microsoft Office, terwijl het merendeel van de websites op het internet gebruikmaakt van Apache Webserver.

Ogenschijnlijk lage investeringen die open source software vergt en krachtige stimulans vanuit de overheid effenen de weg voor de opmars. Waar veel organisaties al jaar en dag klagen over vendor lock-in, hoge licentiekosten en inflexibele software, lijkt open source software dé oplossing te bieden voor al deze problemen. Zowel analisten als IT-integrators zien open source software samen met SaaS/cloud computing als de belangrijkste trends voor de komende tijd. Forrester ziet zelfs open source software, mede door zijn lage aanschafkosten, als hét wondermiddel om de pijn van de financiële crisis bij de IT-afdeling te verzachten ([Hamm09]).

Met alle mogelijkheden die open source software biedt, kent open source software ook de nodige aandachtspunten ten aanzien van informatiebeveiliging. Ofschoon de discussie hierover in alle hevigheid woedt tussen ‘open source evangelisten’ en al dan niet partijdige ‘open source sceptici’, zal dit artikel een beeld geven van de risico’s van open source software.

Definitie van ‘open’

Wat is ‘open’ nu precies? Open source software wordt vaak in verband gebracht met open standaarden en open access. Ofschoon de term ‘open’ in dit geval openbaar of vrije toegang betekent, staan deze zaken grotendeels los van elkaar.

Open source software

Onder open source software wordt software verstaan die ontwikkeld is door een al dan niet op professionele basis opererende gemeenschap (open source community) waarvan de broncode openbaar is gesteld. Dit in tegenstelling tot closed source software waarvan de broncode geheim wordt gehouden en vrijwel altijd in beheer blijft van een commerciële softwareleverancier/softwareproducent. Bekende voorbeelden van open source software zijn de besturingssystemen Linux[Linux is een verzamelnaam voor verschillende Linux-distributies. Bekende distributies zijn RedHat, Suse, Ubuntu en Debian.] en Open Solaris, de veelgebruikte webserver Apache, het applicatieplatform JBoss, en OpenOffice, één van de open source tegenhangers van de Office-suite van Microsoft. Gewoonlijk wordt de software ontwikkeld in het kader van een zogenoemd open source project.

C-2009-4-Chung-t01

Tabel 1. Closed source versus open source.

Open standaarden

Open standaarden zijn door de ICT-markt algemeen geaccepteerde standaarden voor hard- en software. Deze kunnen door verschillende leveranciers en gebruikers worden ingezet en gebruikt. Bekende voorbeelden van open standaarden zijn ISA, TCP/IP, PDF en ODF.

Open access

Onder open access wordt vrije toegang tot (academische) publicaties op het internet verstaan. Voorbeelden van open access zijn Directory of Open Access Journals en BMC Journals.

Doorgaans maakt open source software gebruik van open standaarden en worden publicaties die door open source communities worden geproduceerd via het open access principe vrijelijk beschikbaar gesteld. Ook closed source software maakt in toenemende mate gebruik van open standaarden, al zijn sommige van deze standaarden zoals .Net sterk gelinkt aan bepaalde commerciële producten.

Ten aanzien van open source software moet echter worden opgemerkt dat open source software niet synoniem is aan freeware (gratis software). Weliswaar zijn veel open source producten kosteloos verkrijgbaar als downloads voor particuliere gebruikers, maar voor sommige open source software dient gewoon te worden betaald. Daarnaast wordt ook closed source software soms als freeware aangeboden.

Het gebruik van open source software

Buiten het terrein van enthousiaste computergebruikers en de academische wereld waar open source software reeds gemeengoed is, neemt het gebruik van open source software significant toe binnen de commerciële sector. Verschillende recente onderzoeken van Forrester en Gartner wijzen uit dat meer dan de helft van alle grote Amerikaanse en Europese ondernemingen gebruikmaakt van open source software voor één of meer toepassingen. Een aanzienlijk deel van deze ondernemingen geeft ook aan dat zij open source software willen inzetten voor bedrijfskritieke toepassingen zoals CRM, ERP en e-mail. Hierbij worden wel zorgen geuit over de eventuele risico’s van open source software ten aanzien van informatiebeveiliging ([Schi08], [Hamm09]).

In Nederland stimuleert de overheid sinds enkele jaren het gebruik van open source software binnen de (semi)publieke sector. Hiertoe is het Actieplan Nederland Open in Verbinding gepresenteerd waarbij de (semi)publieke sector wordt opgeroepen om indien mogelijk voor open source software en open standaarden te kiezen. Ook de Europese Unie heeft bij monde van Europees Commissaris Neelie Kroes bepaald dat open source software bij gelijke geschiktheid voorrang moet krijgen op closed source software ([Noiv07]).

Ondanks de interesse vanuit het bedrijfsleven en de krachtige aanzet vanuit de overheid bedraagt het aandeel van open source software in het totale softwareportfolio minder dan vijf procent. Wel wordt bij vervanging van oude, veelal closed source software, steeds vaker gekozen voor open source alternatieven. Dit percentage bedraagt volgens Forrester bijna vijfentwintig ([Hamm09]).

Twee aanvullende complicerende factoren zijn voorts van belang:

Steeds meer commerciële closed source software bevat onderdelen van open source software.
Op bescheiden schaal besluiten leveranciers van closed source software om delen van hun catalogus als open source software aan te bieden. Hierdoor is een strikte scheiding tussen open en closed source software in enkele gevallen lastig aan te geven.

Succes van open source software

De toenemende populariteit van open source software is met name te danken aan de volgende factoren:

Lagere aanschafkosten

Een zeer groot deel van open source software is gratis dan wel tegen geringe kosten verkrijgbaar. Veelal kunnen open source producten door individuele (thuis)gebruikers en non-profitorganisaties kosteloos worden gedownload van het internet. Zelfs voor de betaalde open source producten zijn de aanschafkosten fors lager dan voor closed source producten. Ter vergelijking: de licentiekosten voor functioneel volwaardige open source ERP-oplossingen (Compiere, PostBooks, Openbravo) bedragen minder één procent van de licentiekosten die betaald moeten worden voor bekende closed source ERP-oplossingen zoals SAP en PeopleSoft. Hierbij moet wel worden aangetekend dat de licentiekosten voor ondernemingen liggen tussen de vijf en tien procent van de totale ICT-kosten ([Meek08]).

Transparantie en aanpasbaarheid van de software

Niet alleen is de broncode van de open source software openbaar, in veel gevallen kan de gebruiker ook de code naar eigen inzichten en toepassingsdoeleinden wijzigen zonder tussenkomst van en/of financiële verplichtingen aan de softwareleverancier. Een voorwaarde is natuurlijk dat de kennis van de programmatuur beschikbaar is.[Veelgebruikte programmeertalen zijn C, C++, Java en PHP; Visual Basic en C# die veel worden gebruikt voor closed source producten zijn ondervertegenwoordigd.]

Onafhankelijkheid ten opzichte van de leverancier

De openheid van open source software zorgt in principe voor minder vendor lock-in. Verregaande onwenselijke afhankelijkheid van één leverancier en/of technologie is gemeengoed in de IT-wereld: veel ondernemingen zijn voor hun bedrijfsvoering volkomen hulpbehoevend geworden van de grillen van grote softwareleveranciers. Open source software daarentegen kent in de regel een grote mate van vrijheid – er zijn immers geen of nauwelijks licenties of langlopende contracten – en biedt door zijn gebruik van open standaarden diverse alternatieven voor specifieke toepassingen. Een migratie tussen open source databasesystemen zoals MySQL en PostgreSQL verloopt meestal soepeler dan tussen Oracle en IBM DB2.

Beveiligingsrisico’s van open source software

Open source in vergelijking tot closed source

Over de mate van beveiliging van open source software worden heftige debatten gevoerd door verstokte aanhangers en sceptici van het open source concept. Veelal worden hun stellingen gekleurd door ideologische en commerciële belangen. Waar menig open source adept wijst naar de talloze zwakheden en beveiligingslekken in de producten van Microsoft en Oracle, hekelen veel commerciële softwarebedrijven de vermeend amateuristische ontwikkel- en testpraktijken bij veel open source projecten.

In ieder geval geven veel potentiële klanten van open source software aan dat de beveiligingsrisico’s van open source software en de onbekendheid met dit onderwerp één van de belangrijkste barrières vormen tot het adopteren van (meer) open source software ([Suto08], [Schi08]).

Open source software is uiteraard niet vrij van zwakheden zoals beveiligingslekken, race conditions en bugs. Er bestaan specifieke wormen en exploits voor veelgebruikte systemen zoals Linux, Apache en Tomcat; sommige malwares zijn zelfs cross-platform waardoor zij zowel Windows als Linux kunnen besmetten. En net als closed source software kent open source software de nodige patches die deze zwakheden moeten verhelpen.

Het identificeren van de beveiligingsrisico’s van open source software zal in relatie moeten staan tot de beveiligingsrisico’s van de bestaande, veelal closed source software. Een eerlijke vergelijking tussen die twee is evenwel een lastige zaak aangezien het aandeel van open source software in het totale softwareportfolio van organisaties, ondanks de recente stijging van de populariteit, nog steeds zeer laag is ten opzichte van closed source software (minder dan vijf procent). Met name voor financiële toepassingen waar veel cybercriminelen hun aanvallen op richten, is het aandeel van open source software marginaal. Dit heeft tot gevolg dat het absolute én relatieve aantal inbraakpogingen op open source onevenredig laag is ([Hamm09]).

Hierbij moet wel worden opgemerkt dat het aantal malware dat misbruikt maakt van de zwakheden in de software voor Linux (enkele honderden), ook met het marktaandeel in ogenschouw genomen, in geen verhouding staat tot het aantal malware dat inmiddels voor Windows XP of Windows 2003 beschikbaar is (enkele tienduizenden). Ook is de populaire open source Apache Webserver beslist niet onveiliger dan een minder gebruikt closed source alternatief als IIS.

Vrije toegang tot de broncode

Een belangrijk theoretisch voordeel van open source software is de vrije toegang tot de broncode. In principe kunnen alle gebruikers en geïnteresseerden de broncode van de software op beveiliging controleren en eventuele beveiligingsissues oplossen of mitigeren. Ook kan de software zonder tussenkomst van de softwareleverancier naar eigen inzichten en noden van de organisatie worden aangepast. Waar gebruikers van closed source software zijn overgeleverd aan het beveiligingsbeleid van leveranciers, hebben gebruikers van open source software de vrijheid om hun eigen beleid hierop te voeren.

De meningen op dit vlak zijn echter verdeeld. Terwijl sceptici erop wijzen dat ook cybercriminelen en hackers de zwakheden in de open source software, zonder deze buiten eigen kring bekend te maken, ongehinderd kunnen exploiteren, onderstrepen gezaghebbende experts zoals Bruce Schneier en Eric Raymond dat juist openheid leidt tot beter beveiligde software. Helaas worden beide stellingen slechts sporadisch ondersteund met concrete cijfers. De praktijk van KPMG leert evenwel dat veel toegepaste open source producten zoals Apache en JBoss enerzijds bewijzen dat open source software niet is gevrijwaard van zwakheden, maar dat anderzijds de voortdurende open controle de software zeer solide heeft gemaakt ten opzichte van vergelijkbare alternatieven uit de closed source hoek. De realiteit leert ook dat zwakheden in closed source software via reverse engineering ontdekt kunnen worden. De vele aanvallen die Windows in haar bestaan hebben geteisterd, leveren hiervoor het bewijs ([Schn09], [Chun09]).

Daarentegen creëert die openheid van open source software ook een schijnveiligheid. Slechts een marginaal percentage van de gebruikers en softwarespecialisten van buiten het project levert daadwerkelijke bijdragen en patches aan. De beveiliging is dus hoofdzakelijk, net als bij closed source software, het domein van een select groepje ontwikkelaars ([Moha08]).

C-2009-4-Chung-t02

Tabel 2. Argumenten voor en tegen ten aanzien van beveiliging.

Aandacht voor informatiebeveiliging

In de regel is aandacht voor informatiebeveiliging bij softwareontwikkeling geen vanzelfsprekendheid. Vrijwel alle ontwikkelaars willen in de eerste plaats een goed werkend product opleveren, en hierbij is beveiliging eerder een hindernis dan een baat. Goede beveiliging verlengt immers de doorlooptijd van de ontwikkeling en kan bepaalde functionaliteiten in de software beperken.

Door de toegenomen aandacht voor cybercriminaliteit is informatiebeveiliging de laatste jaren nadrukkelijker op de kalender komen te staan bij de grote (closed source) softwareleveranciers. Er wordt een beroep gedaan op beveiligingsexpertise: beveiligingsprocessen worden geïmplementeerd ten aanzien van softwareontwikkeling en beheer, en gebruikers worden aangespoord om eventuele zwakheden te rapporteren. Deze maatregelen hebben ertoe geleid dat het aantal kritieke lekken in Windows, Oracle en SAP met de opeenvolgende releases (iets) is afgenomen.

Dezelfde trend lijkt niet te gelden voor open source projecten. Een onderzoek wijst uit dat het aantal zwakheden in de software voor enkele open source producten per release gelijk is gebleven of zelfs is toegenomen. Voorbeelden hiervan zijn Geronimo applicatieserver en Hipergate websuite. Bovendien was de aandacht voor informatiebeveiliging vrijwel afwezig bij deze projecten. Er werd geen beroep gedaan op beveiligingsexpertise, er was geen sprake van coherente ontwikkelprocessen en eventuele zwakheden konden niet via een specifiek adres worden gerapporteerd. Daarnaast werd de kennis van beveiliging slechts marginaal binnen de community geborgd ([Suto08]).

Een belangrijk punt in dit opzicht is het release-managementproces. Waar grote softwareleveranciers zoals Microsoft en Oracle zich bedienen van strakke releaseplanningen die centraal worden gecoördineerd, hebben veel open source projecten nog niet die mate van volwassenheid bereikt. Dit heeft uiteraard tot gevolg dat het aantal zwakheden bij de betreffende open source producten niet afneemt. De ontwikkeling van open source software mag dan wel ‘open’ zijn, in de praktijk blijft de ontwikkeling voorbehouden aan een select groepje ontwikkelaars dat zich nauwelijks gebonden voelt tot strakke processen. Het probleem doet zich ook voor dat verschillende patches en aanpassingen in de broncode door het ontbreken van een strakke releaseplanning en hiërarchie binnen de groep ongecontroleerd worden aangebracht. Hierdoor kunnen verschillende versies in omloop komen en goede patches onbedoeld door slechte aanpassingen worden overschreven. Release management blijft een issue in open source communities ([Meek08], [Moha08]).

Er blijkt tevens weinig gebruik te worden gemaakt van technologieën om softwarebugs en andere zwakheden in de software te detecteren. Veel bekende zwakheden zoals Cross-Site Scripting (XSS) en SQL-injecties die eenvoudig kunnen worden voorkomen, komen relatief vaak voor in open source software ([Suto08]).

Kennis van open source

Open source software vergt specifieke (programmeer) kennis en ervaring. Aangezien het gros van de open source software is ontworpen en gebouwd door techneuten, vergt het beheer beduidend meer technische kennis in vergelijking tot closed source software. Daarbij is de beschikbare expertise op open source software relatief schaars en losser georganiseerd.

Gezien het feit dat de sterkte van informatiebeveiliging in belangrijke mate wordt bepaald door het kennisniveau van applicatie- en systeembeheerders, kan zelfs een goed ontwikkeld open source product door onbekwame beheerders onveilig worden gebruikt. Relatief veilige Linux-systemen kunnen door slecht beheer vol met ongepatchte lekken en onveilige settings zitten, waardoor het voordeel inzake informatiebeveiliging ten opzichte van Windows volledig teniet wordt gedaan.[Enkele voorbeelden zijn SNMP met default community strings, onbeveiligde Samba-shares en anonieme FTP met toegang tot alle files.] Bovendien vergen populaire open source producten dikwijls een hoog aantal patches doordat veel, vaak kleine, verbeteringen worden aangebracht. Het is dan ook van belang om deze patches goed te testen en te installeren.

C-2009-4-Chung-t03

Tabel 3. Risicodiagram open source en closed source.

Mitigerende maatregelen

Gelet op de genoemde risico’s en aandachtspunten kunnen de volgende mitigerende maatregelen worden genomen:

Stel beveiligingsrichtlijnen op voor open source systemen en applicaties

Linux kent andere zwakheden dan Windows, en systemen en applicaties kennen hun eigen instellingen die bepalend zijn voor het beveiligingsniveau.

Het opstellen van beveiligingsrichtlijnen/standaarden voor open source software vergt evenwel specialistische technische kennis van de betreffende pakketten en is een zaak voor beveiligingsprofessionals.

Onderzoek de volwassenheid van de betreffende open source community en het project

Indien de community en het project kleinschalig en/of onbekend zijn, is het raadzaam om deze te (laten) onderzoeken. Hierbij dient in ieder geval te worden gekeken naar de volgende elementen:

Gehanteerde ontwikkelmethodiek. Worden gestructureerde, gecontroleerde ontwikkelmethodieken ingezet met voortdurende aandacht voor informatiebeveiliging?
Verbeterproces. Kunnen zwakheden in de software worden aangemeld? Onderneemt de community actie voor verbeteringen? Is er voldoende kennis aanwezig? Staat de community open voor adviezen?
Release management. Worden patches en upgrades periodiek en gecontroleerd uitgebracht? Doet de community aan versiebeheer?
Inzet van geautomatiseerde tools. Worden tools gebruikt voor broncode checks?

Voer een broncodereview uit

Waar closed source softwareleveranciers zich kunnen verschuilen achter juridische procedures, kan open source software door de openbaarheid van de broncode relatief eenvoudig door specialisten worden onderzocht op zwakheden en fouten.

Zorg voor gekwalificeerde beheerders

Systeem- en applicatiebeheerders dienen voldoende gekwalificeerd en ervaren te zijn. Inmiddels kennen grote open source oplossingen zoals Linux, JBoss, Geronimo en Apache hun eigen opleidingstrajecten voor beheerders. Het is van belang dat de benodigde kennis wordt gewaarborgd binnen de organisatie.

Conclusie

Net als closed source software kent open source software zwakheden in de programmatuur en is de ontwikkeling afhankelijk van de beschikbare kennis, aandacht en ervaring.

Open source software kent evenwel door zijn openheid en betrekkelijke onafhankelijkheid van commerciële partijen enkele specifieke aandachtspunten ten aanzien van informatiebeveiliging. Openheid betekent dat meerdere ogen naar de broncode kunnen kijken en sneller de zwakheden worden opgespoord en opgelost. Dit kan ook betekenen dat criminelen en hackers de zwakheden kunnen exploiteren voordat de benodigde patches beschikbaar zijn. Daarnaast kampen met name kleinere open source projecten met onvolwassen processen voor beveiliging waardoor zwakheden in hun software niet methodisch en gecontroleerd worden aangepakt.

Desalniettemin wijzen beschikbare cijfers uit dat bekende open source producten zoals Linux en Apache wat betreft beveiliging verrassend goed scoren in vergelijking tot de closed source tegenhangers. Dit geeft aan dat er serieus moet worden gekeken naar open source oplossingen om het niveau van informatiebeveiliging te verhogen.

Een groot voordeel van open source software vanuit auditperspectief is dat de broncode eenvoudiger door specialisten, zonder omslachtige juridische procedures, kan worden beoordeeld. Voor auditors is open source software een godsgeschenk!

Literatuur

[Beav09] Kevin Beaver, Five common Linux security vulnerabilities you may be overlooking; A look at real-world exploits of Linux security vulnerabilities, Searchenterpriselinux.com, 2009.

[Chun09] Mike Chung, Open Source, mogelijkheden en aandachtspunten van open source, KPMG ITA ISC, april 2009.

[Gart08] Hype Cycle for Open Source Software, Gartner, 2008.

[Gruh08] Martin Gruhn, Security Engineering and Open Source Software Development, Freie Universität Berlin, 2008.

[Hamm09] Jeffrey S. Hammond, Open Source Software Goes Mainstream, Forrester, 2009.

[Hein05] Gary Hein, Open Source Software: Risks and Rewards, Burton Group, 2005.

[Meek08] Heather Meeker, The Open Source Alternative: Understanding Risks and Leveraging Opportunities, 2008.

[Moha08] Arif Mohamed, Open Source Software Security, Computerweekly.com, 2008.

[Noiv07] NOiV, Actieplan Nederland Open in Verbinding, Ministerie van Economische Zaken, 2007.

[Schi08] Esther Schindler, Survey: Open Source is Entering the Enterprise Mainstream, Network World, 2008.

[Schn09] Bruce Schneier, Schneier on Security, 2009.

[Suto08] Larry Suto, Open Source Security Study, How are Open Source Development Communities Embracing Security Best Practices?, Fortify Security Research Group, 2008.

[Webe05] Steven Weber, The Success of Open Source, 2005.

Waarom vraagt LinkedIn je Google-wachtwoord?

Met de opkomst van softwarediensten over het internet (SaaS) spelen er diverse nieuwe uitdagingen op het gebied van informatiebeveiliging. In [Chun08] werd al beschreven dat SaaS-architecturen nieuwe beveiligingsrisico’s creëren door de complexiteit van diensten en integratie van softwarediensten.

Indien men SaaS- en Web 2.0-concepten gaat toepassen, worden de beperkingen van de huidige internetinfrastructuur op het gebied van Identity & Access Management zichtbaar.

In dit artikel wordt een aantal opties voor de integratie van webdiensten bekeken, en worden de eraan gerelateerde beveiligingsrisico’s besproken. Zowel huidige technieken als toekomstige ontwikkelingen op dit gebied passeren de revue.

Het delen van informatie tussen websites is slecht geregeld

Vanuit LinkedIn kun je contacten vanuit een webmailomgeving (bijvoorbeeld Gmail) importeren. Echter, om deze contactgegevens te delen tussen Gmail en LinkedIn moet je de Gmail-gebruikersnaam en het wachtwoord in een LinkedIn-pagina invoeren. Als je iets langer stilstaat bij dit fenomeen, komen er allerlei vragen naar boven: Waarom is dit nodig? Wat gebeurt er met dit wachtwoord? Leest LinkedIn ook mijn e-mail en Gmail calendar? Is het invoeren van dit wachtwoord veilig? Kan dit niet anders?

C-2009-4-Ceelen-01

Figuur 1. Screenshot van LinkedIn.

Dit voorbeeld laat zien dat er de noodzaak is om informatie te delen tussen verschillende webapplicaties. Applicatieontwikkelaars en site-eigenaren willen zoveel mogelijk informatie verzamelen zodat de applicaties zich zo intelligent mogelijk gedragen. Ook voor gebruikers zijn er voordelen, data-uitwisseling tussen websites maakt het mogelijk om informatie op één plek te beheren.

Indien in LinkedIn je Gmail-account gekoppeld wordt, dan krijg je de mogelijkheid om je contacten op één plek te beheren. De gekozen oplossing heeft één groot nadeel: gebruikers worden geacht inloggegevens van bijvoorbeeld Gmail niet af te staan aan andere websites. Indien gebruikers gewend raken aan het afgeven van de inloggegevens, dan kunnen criminelen dit gedrag misbruiken en wachtwoorden achterhalen door nep-websites op te zetten.

Vanuit het feit dat twee grote spelers op het internet (LinkedIn en Google) deze oplossing gekozen hebben, kunnen we concluderen dat de huidige beveiligingsmechanismen ontoereikend zijn voor het delen van informatie. Met ontwikkelingen zoals SaaS en Web 2.0 zal de noodzaak informatie te delen tussen internetdiensten alleen maar toenemen. Deze zogenaamde ‘mashups’ maken het mogelijk om informatie en diensten naar eigen inzicht te combineren. Ook in zakelijke toepassingen zal dit probleem zich steeds vaker gaan voordoen. In de toekomst moet een SaaS-oplossing voor CRM (Customer Relationship Management) integreren en communiceren met je e-mail en je kalender.

Wat is SaaS en Web 2.0?

Web 2.0 is de trend dat websites interactiever worden en steeds meer worden gemaakt van door gebruikers aangeleverde content. Door de toepassing van Ajax (asynchronous JavaScript en XML) hoeft een webpagina niet ververst te worden om nieuwe data in te laden. Typische voorbeelden zijn social-networking websites en bijvoorbeeld de interface van Gmail.

SaaS staat voor Software as a Service. Dit is een softwaredistributiemodel waarbij de software als een onlinedienst wordt geleverd. Gebruik van de software vereist alleen een internetverbinding, de SaaS-provider zorgt voor onderhoud en beheer van de dienst.

Uit het LinkedIn-voorbeeld komt ook naar voren dat gebruikers meer controle willen hebben over de data die zij delen tussen verschillende webdiensten. Als gebruiker wil ik alleen mijn contacten delen en niet mijn e-mail en kalender.

In dit artikel zal geanalyseerd worden welke risico’s en problemen spelen bij het toestaan van communicatie tussen websites. Daarnaast worden de huidige technische mogelijkheden en toekomstige ontwikkelingen behandeld.

Communicatie tussen websites levert beveiligingsrisico’s op

Eén van de meest fundamentele beveiligingsmaatregelen op het internet is de scheiding tussen websites van verschillende domeinen. Een domein is een deel van een internetadres, bij het adres ‘http://bank.nl/internetbankieren’ hoort het domein ‘bank.nl’.

Beveiligingsmaatregelen in je browser zorgen ervoor dat elke website JavaScript-code mag uitvoeren, maar deze scripts zijn zodanig beperkt dat ze geen data mogen benaderen van een ander domein. Ter illustratie, als gebruiker wil je niet dat een script van een website met het domein ‘kpmg.nl’ toegang heeft tot data van je internetbankierenomgeving op het domein ‘bank.nl’.

De scheiding tussen deze domeinen is in webbrowsers geïmplementeerd door middel van de zogenaamde Same-Origin Policy. De Same-Origin Policy zorgt ervoor dat data van een website beschermd worden. Data kunnen alleen worden uitgewisseld tussen websites indien zij dezelfde domeinnaam hebben en aan een aantal aanvullende technische voorwaarden voldoen. De Same-Origin Policy regelt dat een script op http://www.LinkedIn.com geen data kan benaderen van http://Gmail.com en dat een script van http://Gmail.com/contacts wel verbinding mag maken met http://Gmail.com/mail.

Ontwikkelaars van webapplicaties kunnen gebruikmaken van de Same-Origin Policy door data te plaatsen op verschillende domeinen. Een voorbeeld hiervan is het gebruik van http://maps.google.com en http://mail.google.com; doordat Google gekozen heeft voor gescheiden domeinen zal de browser geen communicatie toestaan tussen deze applicaties. Indien er gekozen was voor http://www.google.com/maps en http://www.google.com/mail, dan zou dit wel mogen. Het risico van de laatstgenoemde optie is dat een zwakheid (bijvoorbeeld een cross-site scripting aanval) in de maps-applicatie gevolgen heeft voor vertrouwelijkheid en integriteit van je mail.

Met de opkomst van mashups werd duidelijk dat het noodzakelijk is om deze scheiding tussen domeinnamen te omzeilen ([Bhol07]). Ontwikkelaars hebben een aantal oplossingen bedacht, die hierna besproken worden.

Proxy

In het voorbeeld van LinkedIn en Gmail wordt er gebruikgemaakt van een zogenaamde Proxy-oplossing. Figuur 2 bevat een schematische beschrijving van de Proxy-oplossing. In dit voorbeeld kan Gmail worden beschouwd als een resourceprovider; Gmail levert contactdata. LinkedIn is in het genoemde scenario de serviceprovider, LinkedIn levert de uiteindelijke dienst aan de eindgebruiker. Onderdeel van de service die geleverd wordt is ‘resource consumption’, waarbij data van een resourceprovider worden ingebed in de service.

In figuur 2 zijn vier fasen te onderscheiden:

In fase 1 authenticeert de gebruiker zich met de dienst waarvan hij gebruik wil gaan maken. Hij gebruikt de inloggegevens van de serviceprovider (LinkedIn).
Tijdens fase 2 geeft de gebruiker zijn inloggegevens van de resourceprovider (Gmail) aan de serviceprovider.
De serviceprovider logt met de verkregen inloggegevens in bij de resourceprovider.
De serviceprovider vraagt data aan de resourceprovider en stuurt deze door aan de gebruiker via de server van de serviceprovider. De data staan dus op de server van de serviceprovider (aangeduid met http://SP.com/RPdata).

C-2009-4-Ceelen-02

Figuur 2. Proxy-oplossing.

Doordat de data beschikbaar is op http://sp.com/RPDATA kunnen scripts van http://sp.com hiervan gebruikmaken.

Vanuit beveiligingsoogpunt is de Proxy-oplossing geen ideale situatie. Alhoewel gebruikers een bewuste keuze maken om wachtwoorden af te staan is het de vraag of zij zich bewust zijn van de risico’s die spelen:

Het afstaan van een wachtwoord geeft de serviceprovider volledige toegang tot het account bij de resourceprovider. De serviceprovider kan alle functionaliteit die een normale gebruiker heeft aanroepen, terwijl de gebruiker eigenlijk alleen autorisatie wil geven voor beperkte functionaliteit, zoals het toegankelijk maken van specifieke informatie.
Een ander probleem ligt in het beheren van deze inloggegevens. Serviceproviders slaan de wachtwoorden op zodat zij altijd de actuele data uit kunnen lezen. Het spreekt voor zich dat het opslaan van wachtwoorden van een externe partij de nodige risico’s met zich meebrengt.
Een derde probleem met deze oplossing is het feit dat gebruikers normaal gesproken inloggegevens alleen moeten invoeren op de website die de inloggegevens verstrekt heeft. Wat gebeurt er als LinkedIn gaat vragen om de inloggegevens van internetbankieren? Gaan gebruikers deze afstaan omdat ze dit normaal achten?

Ook voor ontwikkelaars is deze situatie niet ideaal, er moet extra software ontwikkeld worden voor de Proxy-functionaliteit en voor het authenticeren bij resourceproviders.

JSONP

Als alternatief voor de bovengenoemde Proxy-oplossing is JSONP ([Remo05]) ontwikkeld. Binnen deze oplossing wordt gebruikgemaakt van de eigenschap dat een JavaScript-bestand ook op een andere domeinnaam mag staan. Figuur 3 toont schematisch aan hoe JSONP werkt.

In fase 1 authenticeert de gebruiker zich zowel bij de resourceprovider als bij de serviceprovider. Het betreft het reguliere inlogproces op beide websites.
De serviceprovider retourneert een HTML-pagina met daarin de instructie om een JavaScript-bestand van de resourceprovider op te halen.
De browser van de gebruiker haalt de data op van de resourceprovider; deze data zijn op een speciale manier ‘ingepakt’ in JavaScript. Door middel van samenwerking van scripts van de serviceprovider en de resourceprovider worden de data in de pagina verwerkt.

C-2009-4-Ceelen-03

Figuur 3. JSONP.

Op het eerste gezicht lijkt deze oplossing erg elegant, gebruikersnamen en wachtwoorden hoeven niet te worden uitgewisseld. Het probleem met deze oplossing is dat de website van de serviceprovider het toestaat dat een JavaScript-bestand van een externe website (RP.com) wordt geladen. Dit bestand kan mogelijk kwaadaardige code bevatten.

De resourceprovider is in staat code uit te laten voeren op het domein van de serviceprovider. Indien de resourceprovider wil, kan hij bijvoorbeeld toegang krijgen tot gegevens opgeslagen bij de serviceprovider. Een mogelijke hack bij een resourceprovider kan dus direct invloed hebben op de veiligheid van serviceproviders.

Een ander probleem is dat een andere website, bijvoorbeeld evil.com, op eenzelfde manier ook deze data kan inlezen. JSONP is daarom niet geschikt voor privacygevoelige informatie.

Huidige oplossingen zijn ontoereikend

Zoals hierboven aangegeven is het technisch mogelijk om data uit te wisselen tussen websites. De huidige oplossingen creëren echter nieuwe beveiligingsrisico’s. Binnen de huidige mogelijkheden bestaat het risico dat een hacker die toegang heeft tot één website ook toegang kan krijgen tot alle verbonden websites. Zolang dit olievlekeffect niet voorkomen kan worden, zal men terughoudend zijn in het gebruik van deze oplossingen.

De toekomst: CORS

Met de ontwikkeling van een nieuwe webstandaard genaamd Cross-Origin Resource Sharing (CORS [Cros09]) worden de nadelen van de eerdergenoemde oplossingen aangepakt. CORS definieert mogelijkheden om uitzonderingen te maken op de Same-Origin Policy. Er is een mechanisme gekozen dat lijkt op JSONP, maar zonder de nadelen.

Figuur 4 bevat een schematische weergave van deze techniek.

In fase 1 authenticeert de gebruiker zich zowel bij de resourceprovider als bij de serviceprovider. Het betreft het reguliere inlogproces.
De serviceprovider retourneert een HTML-pagina met daarin de instructie om een JavaScript-bestand van de resourceprovider op te halen. Er wordt hierbij geen gebruik gemaakt van ‘inpakken’ zoals dat bij JSONP het geval is.
De resourceprovider ontvangt het request en levert de data aan. Naast de data wordt er een lijst met toegestane domeinnamen meegestuurd. De browser van de gebruiker zorgt ervoor dat alleen scripts van de domeinnamen uit het lijstje toegang krijgen tot deze data.

C-2009-4-Ceelen-04

Figuur 4. CORS.

Door gebruik te maken van deze nieuwe functionaliteit is het ‘inpakken’ door middel van JavaScript zoals in JSONP niet meer noodzakelijk. Het grote voordeel hiervan is dat een resourceprovider geen code meer kan uitvoeren op het domein van de serviceprovider.

Door de toevoeging van de lijst met toegestane domeinnamen in het antwoord van de resourceprovider wordt het tweede nadeel van JSONP opgelost zonder afbreuk te doen aan de voordelen van dit mechanisme.

Er zijn al enkele browsers verkrijgbaar die deze manier van communicatie toestaan, onder andere Internet Explorer 8 en Firefox 3.5. De verwachting is dat applicaties de mogelijkheid gaan bieden om zelf de lijsten met toegestane domeinnamen te beheren. In theorie bied CORS de mogelijkheden om als gebruiker zelf aan te geven dat je alleen je contacten wil delen met LinkedIn en dat e-mail en kalenderdata alleen gedeeld mogen worden met bijvoorbeeld een CRM-pakket.

Conclusie

Proxy

+ Geen risico’s voor serviceproviderdomein

– Geen controle over welke functionaliteit wordt ontsloten

– Serviceprovider moet accountgegevens beheren en beveiligen

– Ontwikkeling en beheer van Proxy-functionaliteit en authenticatie bij resourceproviders

JSONP

+ Transparante oplossing voor eindgebruikers

+ Weinig aanpassingen in bestaande websites

– Serviceprovider loopt risico’s indien een resourceprovider gecompromitteerd is

– Resourceprovider heeft geen invloed op welke websites de informatie gebruiken

CORS

+ Lost bovengenoemde nadelen en risico’s op

– Nog geen wijdverbreide browserondersteuning

Zoals in [Chun08] aangegeven vereist de overstap naar SaaS-oplossingen een gedegen analyse van risico’s voor de gehele dataketen. In dit artikel is ingezoomd op de technische risico’s die spelen bij de integratie van webdiensten. Het blijkt dat op dit gebied de huidige oplossingen beveiligingrisico’s introduceren die niet eenvoudig gemitigeerd kunnen worden.

De introductie van CORS biedt mogelijkheden om op een gecontroleerde manier data te delen tussen verschillende webdiensten. Het is een technologische verbetering op het gebied van access management van webdiensten. Aangezien ondersteuning voor CORS al aanwezig is in enkele browsers, is het wachten op de eerste toepassing van dit concept op grote schaal.

Literatuur

[Bhol07] S. Bhola, S. Chari en M. Steiner, Security for Web 2.0 application scenarios: Exposures, Issues and Challenges, Workshop Web 2.0 Security & Privacy, 2007.

[Chun08] Mike Chung, Informatiebeveiliging versus SaaS, Compact 2008/4.

[Cros09] Cross-Origin Resource Sharing – W3C Working Draft 17 March 2009, http://www.w3.org/TR/access-control/.

[Remo05] Remote JSON – JSONP, http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/.

Identitymanagement, ervaringen uit het onderwijs

SURFnet heeft meer dan tien jaar gewerkt aan een landelijke infrastructuur voor gemakkelijk en veilig inloggen over organisatiegrenzen heen. Dit artikel laat iets van deze geschiedenis zien. Voor het realiseren van een landelijke authenticatie-infrastructuur zijn diverse fasen doorlopen: gestart werd met chipkaarten en passwords via sms-berichten, daarna lag het accent op web single sign-on, met open source A-Select voor federatieve authenticatie (A-Select is de software onder de motorkap van DigiD). Uiteindelijk is een landelijke infrastructuur gerealiseerd gebaseerd op open source en commerciële software met nadruk op open standaarden voor identitymanagement. Identiteitenbeheer en authenticatie werden losgemaakt uit de afzonderlijke applicaties en krijgen een eigen beheersysteem dat in staat is organisatieleden ook buiten de eigen organisatie te laten inloggen.

Inleiding

De ontwikkeling naar een leven lang leren wordt op grote schaal ondersteund door ICT. Anytime, anyplace, any device, always on toegang vraagt erom dat afnemers en aanbieders van diensten met minimale hindernissen kunnen samenwerken over de grenzen van de organisaties heen. Authenticatie (bewijzen wie je claimt te zijn) en identitymanagement (beheer van gebruikersgegevens) vormen hierbij processen die steeds meer losgekoppeld worden van de individuele applicaties. Hiervoor komen systemen beschikbaar die samenwerking vergemakkelijken, met behoud van de gegevensbeveiliging. SURFnet ontwikkelde een landelijke authenticatievoorziening, in eerste instantie gebaseerd op open source-programmatuur van Alfa en Ariss. Dat is de technologie die ook door DigiD wordt gebruikt.

De ontwikkelingen gaan allang verder dan open source ter beschikking stellen: onderwijsinstellingen en dienstenleveranciers nemen deel in een landelijke SURF trustfederatie voor algemeen gebruik, waardoor werk rond identitymanagement dat de organisatiegrens overstijgt uit handen wordt genomen. Een goed voorbeeld van een trustfederatie voor specifiek gebruik bieden de banken, die het mogelijk hebben gemaakt om met de bankpas van bank A bij buitenlandse bank B contanten uit de geldautomaat op te nemen, zonder dat je eerst een rekening bij die bank B hoeft te openen.

Naadloze toegang tot een groot dienstenpalet

Door het internet is het mogelijk vanaf elke plaats op elk moment toegang te krijgen tot een scala aan diensten. Op één beeldscherm heeft de student naadloos toegang tot bijvoorbeeld:

de elektronische leeromgeving van hogeschool A;
de leeromgeving van universiteit B;
artikelen uit honderden databanken van een groot aantal uitgevers;
een landelijke beeld- en geluidbank van de omroepen;
een gezamenlijke werkomgeving in Sharepoint waarin studenten uit binnen- en buitenland samenwerken.

Hierbij willen we de toegangsvoorziening zien als een facilitator en niet als een hindernis. Een toegangsvoorziening (identificatie, authenticatie, autorisatie) moet het gemak van naadloze toegang tot een veelheid aan bronnen bieden met behoud van beveiliging en een minimum aan administratieve lasten. Het groeiende aantal user-ids en passwords vraagt al jaren om een oplossing, SURF faciliteert een beperkte digitale sleutelbos. Verbree en Van der Hulst hebben in Compact 2005/3 al helder uiteengezet wat er technisch komt kijken bij het beperken van digitale sleutelbossen.

C-2009-1-Kuipers-01

Figuur 1. SURFfederatie: één sleutel voor veel diensten.

Historisch perspectief

Het onderwijs is niet uniek, de overheid streefde ernaar om in 2007 65% van de diensten te ontsluiten via het internet. De Belastingdienst werkt eraan om aangiftes online via het internet te kunnen laten plaatsvinden. Dit vroeg om één aanlogcode voor burgers. De vraag van de overheid naar een authenticatievoorziening in het kader van het programma ‘Andere Overheid’ en het aanbod van A-Select hebben elkaar via de Manifestgroep ontmoet in 2003. Dit heeft ertoe geleid dat A-Select opgenomen is als technologie onder de motorkap van DigiD. Een voorwaarde daarbij was dat de programmatuur als open source beschikbaar werd gesteld. De samenwerking met de overheid leidde tot een robuust en betrouwbaar systeem dat in april 2006 door 1,1 miljoen Nederlanders werd gebruikt en in 2008 door 7 miljoen gebruikers.

DigiD is nu de nationale authenticatievoorziening voor Nederland, alle overheidsdiensten kunnen voor de authenticatie (verificatie van de identiteit, bewijzen wie je claimt te zijn) een beroep doen op DigiD. DigiD geeft de aangesloten website of dienst het burgerservicenummer (BSN) van diegene die aanlogt. Wat de website of dienst vervolgens met het BSN doet hangt af van het achterliggende proces. De eerste onderwijsdienst die aansloot op DigiD was MijnIBGroep met circa 400.000 studenten. Aansluiting van Studielink op DigiD maakt het mogelijk dat aankomende studenten (die dus nog niet bekend zijn in de administratie van een universiteit of hogeschool) zich via het Internet voor het hoger onderwijs inschrijven. Het federatieve karakter van A-Select maakt het mogelijk om naast DigiD ook gebruik te maken van andere authenticatiebronnen. Ben je eenmaal ingeschreven in Studielink en heb je een user-id van je hogeschool ontvangen, dan kan je als student inloggen met zowel je DigiD als met een toegangscode van de universiteit of hogeschool.

De naam A-Select komt van authenticatieselectie, keuzevrijheid uit verschillende bronnen en mogelijkheden om te bewijzen wie je zegt dat je bent. Keuzevrijheid in authenticatiemiddelen voor verschillende groepen gebruikers is enorm belangrijk, heeft SURF geleerd. Voorwaarde voor de keuzevrijheid is wel dat een uniek identificerend gegeven beschikbaar is.

Het vraagstuk rond toegangsbeveiliging en authenticatie, wat nu vaak identitymanagement wordt genoemd, betekende voor het onderwijs enige tijd het realiseren van een studentenchipkaart. Ten tijde van de strijd tussen Chipper en Chipknip rond 1996 was de mening dat de introductie van een studentenchipkaart de uniforme toegang tot gegevens een stuk eenvoudiger zou maken. Dat bleek moeilijker dan toen werd gedacht. Problemen met onder andere chipkaartlezers gooiden roet in het eten. Voor SURF waren de vraagstukken rond toegangsvoorzieningen en authenticatie reden om in 2001 het programma TrustSURF te starten, dat tot doel had het bundelen en verspreiden van kennis over authenticatievraagstukken.

Het SURF Meerjarenplan 2003>6 ‘De kern van de zaak’ formuleerde onder andere de ambitie om een landelijke authenticatiedienst voor het hoger onderwijs te realiseren. Inmiddels is door de samenwerking met de Stichting Kennisnet ICT de doelstelling verbreed naar heel het onderwijs met potentieel 3,5 miljoen gebruikers. Kennisnet biedt daarvoor de dienst Entree.Kennisnet.nl.

De moeizame inzet van een studentenchipkaart leidde binnen het Gigaport-project tot de ontwikkeling van ‘pragmatische authenticatie met persoonsgebonden middelen’: de bankkaart en de mobiele telefoon. Deze aanpak heeft zich bewezen, het loont om gebruik te maken van een reeds bestaande infrastructuur. De bankkaart van de Rabobank en de ABN-AMRO bank was beschikbaar binnen het onderwijsdomein voor authenticatie met voorzieningen voor internetbankieren waarover veel, maar niet alle, studenten beschikken. Het Leids Universitair Medisch Centrum (LUMC) heeft de bankkaart gebruikt om toegang te verlenen tot medische gegevens. Het onderwijs stimuleerde dat de overheid gezamenlijk gebruik zou gaan maken van deze bankauthenticatie binnen DigiD. In het rapport voor Forum Standaardisatie ‘Verkenning authenticatie, roeien met de riemen die je hebt?'[www.forumstandaardisatie.nl/fileadmin/OVOS/Doc_authenticatie.pdf] wordt dit idee uitgewerkt.

De mobiele telefoon werd ingezet voor het ontvangen van eenmalig geldige wachtwoorden, one-time-passwords (OTP’s) via een sms. Voordeel van de mobiele telefoon als authenticatiemiddel is het intuïtieve gebruiksgemak en de combinatie van zowel het hebben van de telefoon als het weten van de pincode. Nadeel van sms-authenticatie vormen de kosten – een grote hogeschool die per dag 100.000 sms-berichten verstuurt had er een forse kostenpost bij. Een belangrijke les uit de SURF- en Gigaport-projecten was dat keuzevrijheid geboden moet worden in authenticatiemiddelen. De authenticatieselectieprogrammatuur A-Select ondersteunt verschillende authenticatievormen zoals: gebruikersnaam en wachtwoord, security tokens, authenticatie op basis van de bankkaart, sms-passwords, softwarecertificaten, hardware PKI-certificaten, authenticatie gebaseerd op het IP-adres.

Bij de keuze van een identitymanagementpakket vormt de ondersteuning van verschillende authenticatiehulpmiddelen een aandachtspunt. SURFnet maakte het mogelijk om de verschillende authenticatievormen los te koppelen van individuele applicaties. Deze ontwikkeling is vergelijkbaar met het loskoppelen van bestanden van applicaties door de komst van databasemanagementsystemen. Diverse leveranciers bieden anno 2009 pakketten voor het loskoppelen van identificatie en authenticatie.

Van open source naar open standaarden

Het buitenlandse onderwijs kende gelijksoortige ontwikkelingen als het Nederlandse onderwijs, waarbij de Angelsaksische landen zich richten op het open source-systeem Shibboleth. Shibboleth is mede ontstaan uit de eis van privacybescherming volgens de Family Educational Rights and Privacy Act (FERPA). In Europa werkt het hoger onderwijs samen in de Trans-European Research and Education Networking Association (TERENA) aan het oplossen van authenticatievraagstukken. De website van TERENA (www.terena.org) bevat nuttig materiaal op het gebied van identitymanagement.

In diverse landen is gewerkt aan open source-authenticatiesystemen. Het onderwijs liep daarbij vooruit op ontwikkelingen bij de grote softwareontwikkelaars. Na 2005 werd duidelijk dat partijen als Oracle door het opkopen van nichespelers serieus werkten aan oplossingen. De vraag van het onderwijs heeft zich mede daardoor verlegd van open source naar open standaarden. Doordat ook de markt met oplossingen kwam kon de aandacht geconcentreerd worden op de standaarden.

Als we naadloos gebruik willen kunnen maken van diensten van een groot aantal partijen dan moeten we er zeker voor zorgen dat het bij elkaar kunnen inloggen gestandaardiseerd wordt. De standaard waar het meest van verwacht wordt op dit gebied, is SAML versie 2.0 (Security Assertion Markup Language). Diverse pakketleveranciers bieden ondersteuning voor deze standaard en ook de open source-pakketten zijn overgegaan op SAML. A-Select en Shibboleth spreken SAML. En ook Microsoft heeft aangegeven ondersteuning te gaan bieden.

C-2009-1-Kuipers-02

Figuur 2. SURFfederatie ondersteunt diverse protocollen.

Het College Standaardisatie werkt in het kader van het actieplan ‘Nederland Open in Verbinding’ van Economische Zaken aan de totstandkoming van een lijst met open standaarden. Eén van de standaarden die mogelijk opgenomen wordt op de lijst is SAML 2.0. Organisaties die nog niet van SAML hebben gehoord, doen er goed aan hier kennis van te nemen.

Met het harmoniseren op een open standaard is een belangrijk punt bereikt in het realiseren van een naadloze mogelijkheid om gezamenlijk toegang te krijgen tot elkaars systemen. De implementatie van de standaard blijkt helaas niet altijd triviaal te zijn. Oplossingen worden nu weer gezocht in ‘light’ versies zoals SimpleSAMLphp die een snellere uitrol mogelijk moeten maken.

SURFnet heeft intussen meegewerkt aan diverse systeemimplementaties van open source- en commerciële pakketten. Leveranciers gebruiken SURFfederatie graag als testomgeving voor hun applicaties, SURFnet vervult een natuurlijke rol als proeffabriek voor innovaties. Het open karakter van de SURFnet-organisatie houdt in dat SURFnet de opgedane kennis eenvoudig kan delen met bedrijven en organisaties.

Inloggen via SURFfederatie

SURFnet heeft SURFfederatie ingericht, dat is de trustfederatie voor het hoger onderwijs en onderzoek. Een trustfederatie is een verzameling algemeen geldende technische, organisatorische en juridische afspraken die deelnemers vertrouwen bieden om gebruik te maken van lokale authenticatievoorzieningen van de aangesloten partijen voor het krijgen van toegang tot aangesloten diensten. De regels waaronder instellingen en dienstverleners samenwerken worden vastgelegd in federatievoorwaarden.

Een mooi voorbeeld van een trustfederatie met een specifiek doel bieden de banken die het rekeninghouders mogelijk maken om geld op te nemen bij een andere (bijvoorbeeld buitenlandse) bank waar klanten geen rekening aanhouden. Een voorbeeld hoe de federatie in het onderwijs wordt gebruikt is de wijze waarop studenten toegang krijgen tot de content van een uitgever zonder dat de user-ids en passwordbestanden bij de uitgever onderhouden dienen te worden. De uitgever en de federatie komen overeen dat als studenten en medewerkers lokaal geauthenticeerd zijn, dit voldoende is om op te vertrouwen. De instellingen zullen ervoor zorgen dat uitsluitend studenten die daadwerkelijk zijn opgenomen in de studentenadministratie en dus niet de reeds afgestudeerde studenten toegang kunnen krijgen tot databases van de uitgevers. Immers, afgestudeerde studenten hebben geen recht op vrije toegang tot de content van de uitgever. De uitgever moet erop kunnen vertrouwen dat als een student afstudeert deze tijdig verwijderd wordt uit de gebruikersadministratie.

Een belangrijk voordeel van federatief identitymanagement is dat de privacy van studenten en medewerkers verregaand kan worden beschermd. De mogelijkheid bestaat om af te spreken dat een uitgever toegang geeft tot specifieke databanken louter op basis van het feit dat de instelling verklaart dat het daadwerkelijk een student of medewerker is. De uitgever hoeft niet te weten welke individuele student een bepaalde databank raadpleegt, alleen dát het een student is van de specifieke instelling. Mogelijk kan de verklaring specifieker worden: dit is een student chemie in de laatste fase van de opleiding. Het definiëren en registreren van de attributen studierichting, studiefase stelt extra eisen aan het administratieve apparaat. De standaardisatie van attributen zal de nodige inspanning vergen, hoe kom je bijvoorbeeld internationaal tot een werkbare definitie van studierichtingen. Authenticatie op basis van attributen, de eigenschappen van een gebruiker, maakt nieuwe wijzen van zakendoen mogelijk.

Een belangrijke proef met federatief inloggen vond plaats bij de Universiteit van Tilburg in samenwerking met uitgever Elsevier. Deze universiteit host de infrastructuur inmiddels. Eind 2007 ging SURFfederatie in productie en begin 2009 zijn 53 instellingen en diensten, 410.000 studenten aangesloten op SURFfederatie. Het aantal instellingen en diensten zal in 2009 groeien naar 80, met 500.000 studenten. In 2010 zal het hoger onderwijs vrijwel geheel zijn aangesloten. Een dienst die geleid heeft tot een versnelling in het aansluiten op SURFfederatie is de videohost van SURFnet met beeldarchief van de omroepen en video-opnames van colleges. Als studenten deze dienst thuis willen gebruiken, moeten zij bijna altijd aanloggen via de federatie. Een populaire extern gehoste applicatie helpt enorm bij de adoptie van federatief identitymanagement.

C-2009-1-Kuipers-03

Figuur 3. Keuzemenu vergelijkbaar met iDeal.

In Europa en Amerika zijn diverse onderwijsfederaties ingericht en buiten het onderwijs gebeurt ook het nodige. Covisint is een mooi voorbeeld van een federatie voor bedrijven. In het kader van landelijk lenen en een landelijke bibliotheekpas werken openbare bibliotheken al geruime tijd samen. De overheid werkt aan een federatie van ministeries onder de naam Rijksweb en biedt MijnOverheid.nl. In de zorg werkt VECOZO aan een single logon-oplossing voor 90.000 zorgverleners en 20 verzekeraars. DigiNotar biedt een federatieve oplossing voor onder andere de advocatuur en accountancy en algemeen voor consumenten. Veel partijen ontmoeten elkaar via ECP.NL, het platform voor eNederland dat precompetitieve samenwerking op het gebied van identitymanagement faciliteert. ECP agendeert hierbij diverse ontwikkelingen zoals eHerkenning (authenticatie) voor bedrijven richting overheid, een OpenID-pilot en onderzoek naar identitymanagement en beveiliging binnen social networking-omgevingen.

Vertrouwen door audit van aansluitvoorwaarden

SURFfederatie biedt het gemak dat een deelnemer, bijvoorbeeld een uitgever die een vaste prijsafspraak heeft gemaakt met een aangesloten universiteit, de authenticatie voor zijn systemen uitbesteedt aan een onderwijsinstelling. De deelnemer vertrouwt dat het authenticatiesysteem van de andere deelnemers, waar hij geen zicht op heeft, in orde is. Voor een betrouwbare federatie is het uiteindelijk vereist te kunnen bouwen op een betrouwbare infrastructuur van alle aangesloten partijen. Om deze te realiseren zullen alle aangesloten onderwijsinstellingen hun beveiliging op orde moeten houden en hierbij is een rol weggelegd voor de informatiebeveiligingsfunctionarissen. In het hoger onderwijs treffen de informatiebeveiligingsfunctionarissen elkaar regelmatig in het SURF-informatiebeveiligersoverleg (IBO). SURF stimuleert dat de aansluitvoorwaarden voor SURFfederatie onderwerp van een lokale audit worden.

Voor een auditor betekent de ontwikkeling naar federatieve authenticatiestructuren meer samenwerking met derden (SAS 70, third party-mededelingen).

Conclusie

De conclusie van de ervaringen uit het onderwijs is dat het mogelijk is om een grootschalige identitymanagementfederatie in te richten waarbij derden vertrouwen op de infrastructuur van de aangesloten partijen. Hierbij is standaardisatie van het samenwerkingsprotocol en de uit te wisselen gegevens van groot belang. De regels voor samenwerking zullen in de praktijk moeten worden getoetst. SURFnet heeft veel ervaringskennis verworven en deelt deze kennis als proeffabriek voor innovatie graag met derden.

Informatiebeveiliging versus SaaS

Bedrijfssoftware over het internet wordt steeds populairder. Vrijwel alle grote softwareleveranciers en IT-integrators bieden steeds uitgebreidere en professionelere onlinediensten aan onder de noemer SaaS. Maar ook hier gaan kansen vergezeld met gevaren. Met name op het gebied van informatiebeveiliging biedt SaaS de nodige uitdagingen die nochtans zijn onderbelicht. Hoog tijd voor de kritische IT-auditor om weerwoord te geven aan dit fenomeen.

Inleiding

Software-as-a-Service (SaaS) heeft zich de laatste jaren gestaag ontwikkeld van een eenvoudig ‘software-over-het-internet’-concept tot een volwaardig sourcingmodel voor uitgebreide, bedrijfsbrede softwarediensten. Hoewel het oorspronkelijke ASP-model (Application Service Provider) uit de jaren negentig mede door zijn beperkte reikwijdte van diensten en gebrekkige integratie nooit kon bogen op enig commercieel succes, is SaaS anno 2008 één van de snelst groeiende IT-modellen. Alleen al in Nederland nemen meer dan duizend organisaties softwarediensten af via het internet volgens het principe van SaaS, waarbij de groei voor zowel het MKB als voor beursgenoteerde ondernemingen meer dan twintig procent per jaar bedraagt ([Aspf08]). Onderzoeksbureau Gartner voorspelt dat ruim tien miljoen bedrijven binnen tien jaar zullen overstappen op SaaS ([Desi07]); ook IDC en Burton verwachten dat lokaal geïnstalleerde ‘on-premise’ software binnen afzienbare tijd wordt verdrongen door ‘on-demand’ oplossingen, waarvan SaaS de hoofdmoot vormt ([Kouw07], [Maiw07]).

C-2009-0-Chung-f1

Nu de inmiddels gevestigde SaaS-pioniers, waarvan Salesforce.com de bekendste is, hun dienstenportfolio gestaag uitbreiden, storten vrijwel alle grote softwarebedrijven zich in het ‘ver-SaaSen’ van hun pakketten. Microsoft (met een mix van on-premise en on-demand software), Cisco en Oracle bieden, al dan niet in samenwerking met andere softwarebedrijven en IT-integrators, steeds meer SaaS-oplossingen aan voor complete bedrijfsprocessen. Andere grote spelers zoals SAP, IBM en Software AG investeren in middlewareproducten die toekomstige on-demand diensten zullen faciliteren.

Terwijl het succes van SaaS geen grenzen lijkt te kennen dringt slechts langzaam het besef door dat SaaS met al zijn voordelen ook serieuze uitdagingen kent op het vlak van informatiebeveiliging. Zoals zo vaak bij nieuwe IT-modellen blijkt informatiebeveiliging ook bij SaaS een sluitpost van de begroting. Dit artikel zal als tegenwicht voor de euforie rond SaaS nader ingaan op de specifieke risico’s van SaaS betreffende de informatiebeveiliging vanuit het perspectief van de afnemer (klant). Alvorens de risico’s in kaart zijn gebracht, zullen de baten van SaaS worden beschreven zodat we aan het eind van het verhaal een balans kunnen opmaken.

Wat is SaaS? ‘On-premise’ versus ‘On-demand’

Het principe van on-demand software waaronder SaaS luidt dat het bezit en eigenaarschap van software wordt gescheiden van het gebruik. De software blijft bij on-demand oplossingen eigendom van de leverancier; de afnemer betaalt dus alleen voor het gebruik van de software en heeft geen lokale installatie van de software, dit in tegenstelling tot het traditionele ‘on-premise’ model. SaaS voorziet er bovendien in dat de bedrijfsdata die door de software wordt gebruikt eveneens wordt opgeslagen bij de leverancier. De afnemer heeft dus met SaaS geen lokale servers meer nodig; een pc met toegang tot het internet is voldoende (zie figuur 1).

C-2009-0-Chung-01

Figuur 1. ‘On-premise’ versus ‘on-demand’.

Zo bezien verschilt SaaS niet fundamenteel van het aloude ASP-concept. Het uitgangspunt van beide modellen is immers het aanbieden en gebruiken van software over het internet. Echter, waar de ASP doorgaans beperkte dienstverlening leverde van één applicatie voor één enkel proces, omvatten SaaS-oplossingen meerdere applicaties of zelfs volledige, geïntegreerde software suites voor meerdere bedrijfsprocessen. In principe kan SaaS de volledige kantoorautomatisering omvatten waarbij alle standaardfunctionaliteiten zoals tekstverwerking, spreadsheets en e-mail als webdienst kunnen worden aangeboden. Gmail, Google Documenten en Microsoft Online Services (Exchange Online, SharePoint Online) zijn enkele bekende voorbeelden hiervan; steeds meer open source-varianten komen tevens beschikbaar zoals Ulteo Online Desktop.

Architectuur van SaaS

Logische architectuur

SaaS kent meerdere logische architectuurmodellen, maar de basis van SaaS vormt de ‘multi-tenant’-architectuur. Bij het ‘multi-tenant’-model zijn de IT-componenten opgebouwd om meerdere afnemers (‘tenants’) te bedienen (zie figuur 2). Dit is de eenvoudigste SaaS-architectuur.

C-2009-0-Chung-02

Figuur 2. ‘Multi-tenant’-architectuur.

De leverancier (SaaS-vendor) heeft alle software en bedrijfsdata van de afnemers op een centrale locatie opgeslagen. Via gescheiden kanalen kunnen de afnemers de gewenste softwarefunctionaliteit en bedrijfsdata gebruiken. De SaaS-leverancier zorgt hierbij voor het correct aanleveren en transporteren van de diensten, waarop de klant in staat wordt gesteld deze diensten als webdiensten af te nemen. De vroegere ASP-diensten werkten doorgaans volgens dit model.

Aangezien de kans klein is dat één leverancier in staat is alle bedrijfssoftware aan te bieden, zijn veel ondernemingen genoodzaakt om van meerdere SaaS-leveranciers diensten af te nemen voor een volledige applicatieportfolio. Dit vindt dan plaats volgens het ‘multi-vendor’-model (zie figuur 3).

C-2009-0-Chung-03

Figuur 3. ‘Multi-vendor’-architectuur.

De afnemer heeft zijn bedrijfsdata verspreid over meerdere SaaS-leveranciers en locaties. Via al dan niet geïntegreerde kanalen neemt de afnemer verschillende softwarediensten af.

Steeds meer IT-integrators/resellers, grote softwarebedrijven en brancheorganisaties integreren diensten van verschillende partijen tot grotere SaaS-pakketten. Zij fungeren hierbij als SaaS-integrators – ook wel SaaS-aggregators of brokers genoemd – en vormen het contactpunt voor hun klanten. Soms hebben de partijen die de software leveren op hun beurt weer onderaannemers die specifieke diensten zoals dataopslag of CPU-power leveren. Dit wordt het ‘multi-instance’-model genoemd (zie figuur 4).

C-2009-0-Chung-04

Figuur 4. ‘Multi-instance’-architectuur.

Hoewel de afnemer één contactpunt heeft voor de SaaS-oplossing, namelijk de SaaS-integrator, worden de softwarefunctionaliteiten in feite door meerdere partijen geleverd. Ook de bedrijfsdata zijn verspreid over meerdere locaties waarbij de data niet noodzakelijkerwijs is opgeslagen bij de betreffende softwareleverancier. Steeds meer grote IT-bedrijven bieden tegenwoordig SaaS-diensten aan in de vorm van een ‘multi-instance’-architectuur.

In de praktijk zullen grote, internationale ondernemingen evenwel door meerdere SaaS-integrators worden bediend. Bovendien zal een deel van de software, vanwege technische eisen of contractuele verplichtingen, alleen door lokale installaties te gebruiken zijn. Daarom zal een ‘multi-integration’-architectuur voor die gevallen van toepassing zijn (zie figuur 5).

C-2009-0-Chung-05

Figuur 5. ‘Multi-integration’-architectuur.

Bij dit model leveren meerdere SaaS-integrators met verschillende onderaannemers een deel van de softwarediensten aan. Een deel van de diensten blijft intern. De bedrijfsdata is derhalve verspreid over meerdere externe en interne locaties.

Data-architectuur

In principe wordt met gebruik van SaaS de data die hoort bij de software extern bij de SaaS-leverancier opgeslagen en beheerd. Interne opslag is technisch mogelijk, maar in de praktijk veelal omslachtig. Het is als een lokale opslag van je e-mails met een Gmail-account.

Betreffende de architectuur van de externe opslag van data zijn voor SaaS de volgende drie modellen de meest voorkomende (zie ook figuur 6):

Geïsoleerde databases, waarbij elke afnemer zijn eigen database bij de leverancier heeft. Andere klanten van de leverancier hebben geen toegang tot deze database.
Geïsoleerde schema’s, waarbij de afnemers de database delen, maar ieder zijn eigen schema in de database heeft.
Gedeelde schema’s, waarbij de afnemers niet alleen de database, maar ook de schema’s delen. De klant heeft zijn eigen klant-ID in de database.

C-2009-0-Chung-06

Figuur 6. Verschillende data-architecturen van SaaS.

Succes van SaaS

Het succes van SaaS hangt samen met het feit dat de bestaande toepassingen waarbij IT-diensten intern worden aangeboden, tegen steeds meer integratie- en beveiligingsproblemen aanlopen terwijl de kosten nauwelijks meer in de hand te houden zijn. Outsourcing en offshoring hebben de problematiek slechts ten dele opgelost en de beloofde kostenbesparing bleek in de praktijk zelden haalbaar. SaaS biedt in dit perspectief dé ideale oplossing: de hele IT inclusief alle hard- en software kan de deur uit, het beheer wordt opgeheven, alle benodigde softwarediensten worden afgenomen via het internet en de kosten zijn transparant en relatief eenvoudig te beheersen.

Naast de kostenfactor kent SaaS het theoretisch voordeel dat de onderneming zich echt kan richten op haar kerntaken zonder te worden gehinderd of geremd door de interne IT-afdeling. Bovendien is de verwachting dat de SaaS-leverancier door het verkregen schaalvoordeel beter in staat zal zijn de nieuwste technologieën en beheerprocessen toe te passen teneinde de efficiëntie en effectiviteit van de dienstverlening te verhogen.

Kostenbesparing

Operationele IT-kosten kunnen met SaaS significant worden verlaagd aangezien SaaS geen grootschalige, kostbare en risicovolle implementaties van bedrijfssoftware kent aan de kant van de afnemer – alle installaties staan immers op de servers van de leverancier. Daarbij komen ook alle beheerkosten om de diensten continu beschikbaar te stellen voor de rekening van de leverancier. Bovendien kan er flink worden bespaard op hardware en de kostbare benodigdheden zoals serverruimten, koelinstallaties en elektriciteit aangezien SaaS nauwelijks (server) hardware behoeft aan de kant van de afnemer. Het enige wat de afnemer nodig heeft is een pc met (veilige) toegang tot het internet. De kosten die aan de klanten worden doorberekend, zijn relatief laag dankzij het verkregen schaalvoordeel en centralisatie van (beheer)kennis en ervaring.

SaaS kent ook het voordeel dat softwareontwikkeling en -aanpassing grotendeels uit het zicht van de afnemer blijft. Idealiter levert de klant alleen de specificaties en eisen aan waarna de SaaS-leverancier de vernieuwingen/veranderingen doorvoert op zijn eigen IT-omgeving. De enige verplichtingen van de afnemer zijn functionele tests en acceptatie. Hinderlijke updates op pc’s behoren daarmee tot het verleden.

Lagere kosten voor softwaregebruik kunnen tot stand komen doordat er niet meer wordt gewerkt met vaste licentiekosten bij aanschaf gevolgd door jaarlijkse gebruikskosten, die meestal tien tot vijftien procent van de aanschafprijs bedragen. Bij SaaS wordt namelijk alleen het gebruik van de software in rekening gebracht aangezien de software in het bezit blijft van de SaaS-leverancier. Gebruiksabonnementen zijn nog steeds de regel al raakt ‘pay-as-you-go’ de laatste jaren in zwang, waarbij de klant betaalt per keer dat de softwaredienst wordt aangeroepen. Ofschoon afhankelijk van de tarieven is het voordeel van ‘pay-as-you-go’ dat er alleen wordt betaald voor software die daadwerkelijk wordt gebruikt en onnodige licentiekosten worden voorkomen. Zie tabel 1 voor een vergelijking.

C-2009-0-Chung-t01

Tabel 1. Kostenmatrix van on-premise versus SaaS.

Wel moet worden opgemerkt dat ofschoon de initiële kosten van SaaS aanmerkelijk lager zijn dan bij on-premise software, de kosten van SaaS door de hele software life cycle constant blijven terwijl de kosten bij lokale installaties geleidelijk zullen afnemen. Kostenbesparing met SaaS is dus sterk afhankelijk van de duur van de software life cycle en uiteraard van de tarieven. Hoe langer een softwarepakket wordt gebruikt, hoe lager het relatieve voordeel van SaaS is ten opzichte van on-premise software ([Dube07]).

Businessfocus

Theoretisch gezien is het gebruik van elektronische data bij SaaS transparant, eenvoudig te automatiseren en schaalbaar. Het gebruik van data kan simpel worden bijgehouden aan de hand van gecentraliseerde monitoring en logging aan de kant van de leverancier. Regelmatig terugkerende, manuele taken kunnen eveneens centraal worden geautomatiseerd door middel van job scheduling. Bovendien heeft de afnemer met SaaS de mogelijkheid om het datagebruik uit te breiden of te verminderen zonder aanschaf of afschrijving van databases, hardware en ruimte.

Kortere implementaties van softwarediensten en veranderingen met minimale onderbrekingen alsook een eenduidige toegang tot de applicaties – namelijk via het internet – zorgen voor hogere productiviteit en tevredenheid bij de eindgebruikers. In plaats van verschillende applicatie-interfaces heeft SaaS namelijk maar één front-end: de webbrowser.

Geavanceerde technologie

Minimale opslag van lokale data en centraal geïnstalleerde software kunnen leiden tot een aanzienlijke verbetering van de informatiebeveiliging. De data kan door de SaaS-leverancier centraal worden beveiligd met inzet van de meest geavanceerde technologieën, waarbij de datastromen en sessies real-time worden gemonitord. Bovendien zijn ook uitwijkmogelijkheden en noodvoorzieningen bij de leverancier geregeld. De afnemer profiteert op deze manier van de hoge(re) beveiligingsniveaus met gecentraliseerde expertise en ervaring bij de leverancier ([Dube07]).

‘State-of-the-art’ technologieën kunnen ook worden toegepast aan de kant van de SaaS-leverancier. Te denken valt aan energiebesparende datacenters, virtualisatie, cloud storage en ESB-technologieën (Enterprise Service Bus). Veelal zijn deze technologieën te duur voor kleinere ondernemingen, terwijl de SaaS-leverancier door zijn schaalgrootte de benodigde investeringen wel kan doen.

Beveiligingsrisico’s van SaaS

De voornaamste beveiligingsrisico’s van SaaS zijn terug te voeren op drie risicogebieden van SaaS:

de externe opslag en verwerking van data;
de afhankelijkheid van het (publieke) internet; en
de complexiteit van diensten en integratie.

Externe opslag van data

De opslag en verwerking van bedrijfsdata bij de SaaS-leverancier betekent in de eerste plaats dat de potentieel zeer gevoelige en waardevolle data buiten de gecontroleerde zone van de afnemer wordt geplaatst, soms zelfs buiten de landsgrenzen. De data staat dus op een plek die niet door interne beveiligingsmaatregelen kan worden beschermd. Ten tweede staat de data bij een leverancier die meerdere klanten bedient en in principe één beveiligingsstrategie hanteert voor data met verschillende eigenaren.

De grootste risico’s van externe opslag zijn derhalve:

verlies van bedrijfsdata als gevolg van incompetente operationele IT-afdelingen van de leverancier of onderaannemers zoals gebrekkige en/of falende back-ups, dataopslag, redundantie en slecht datamanagement;
misbruik of diefstal van bedrijfsdata als gevolg van onvoldoende beveiligingsmaatregelen inclusief Identity & Access Management[Identity & Access Management (IAM) is het complex van systemen en processen die ervoor zorg dragen dat op een efficiënte en betrouwbare wijze toegang tot de (IT-)objecten wordt beheerd. Gebruikersbeheer, authenticatiebeheer en autorisatiebeheer vormen onder meer de hoofdcomponenten van IAM.], zoals:
- misbruik/diefstal van bedrijfsdata door het personeel van de leverancier of onderaannemers als gevolg van zwakke authenticaties en/of gebrekkige autorisaties;
- misbruik/diefstal van bedrijfsdata door ongeautoriseerde externe partijen zoals andere afnemers, criminelen of hackers als gevolg van zwakke authenticaties en/of gebrekkige autorisaties;
- misbruik/diefstal van bedrijfsdata door interne medewerkers als gevolg van gebrekkige functiescheidingen;
inbreuk op vertrouwelijkheid van bedrijfsdata door fouten in de beveiliging en/of gebrekkige demarcaties (scheidingen) tussen verschillende afnemers;
non-compliance en andere audit-findings als gevolg van slechte auditabiliteit;
non-compliance als gevolg van gebrekkige functiescheidingen;
ongecontroleerd dataverkeer als gevolg van slechte scheidingen van data tussen verschillende SaaS-afnemers en tussen de leverancier en onderaannemers;
privacy issues als gevolg van onvoldoende assurance om vertrouwelijke en/of persoonsgegevens te beschermen;
non-repudiation issues als gevolg van onvoldoende authenticatie- en verificatiemechanismen;
juridische issues indien de data buiten de landsgrenzen komen.

C-2009-0-Chung-f2

Tijdens de terugkoppeling benadrukt Mike Chung dat informatiebeveiliging in relatie tot SaaS bijzondere aandacht behoeft.

De genoemde risico’s zijn evenwel sterk afhankelijk van de SaaS-architectuur en de data-architectuur tussen de afnemer en de leverancier. Wat betreft de SaaS-architectuur zijn het aantal verschillende leveranciers en de complexiteit de belangrijkste factoren. Meer leveranciers betekent meer interfaces tussen de afnemer en de SaaS-leveranciers waardoor de kans op gebreken toeneemt. Daarnaast zal een eenvoudige ‘multi-tenant’-architectuur doorgaans beter te controleren zijn en derhalve minder risico’s met zich meebrengen dan een complexe ‘multi-integration’-architectuur. In tabel 2 staan de veelvoorkomende gebreken die relevant zijn voor alle SaaS-architecturen beschreven met het bijbehorend risiconiveau voor de betreffende architectuur. Hoe complexer de architectuur is vanuit het perspectief van de klant, hoe hoger het risiconiveau wordt (zie tabel 2).

C-2009-0-Chung-t02

Tabel 2. Veelvoorkomende gebreken en risiconiveaus per architectuurmodel.

Wat betreft de data-architectuur zijn de relatief dure maar veiliger geïsoleerde databases minder riskant dan de goedkopere modellen waarbij de database of zelfs de schema’s worden gedeeld. Ook hierbij gaat de regel op dat hogere efficiëntie ten koste gaat van informatiebeveiliging (zie tabel 3).

C-2009-0-Chung-t03

Tabel 3. Efficiëntie en risico’s van data-architecturen.

Als de besproken SaaS-architecturen en data-architecturen betreffende de efficiëntie en risico’s worden gemapped krijgen we de matrix in tabel 4.

C-2009-0-Chung-t04

Tabel 4. Efficiëntie en risico’s van verschillende architecturen.

Afhankelijkheid van het internet

De continuïteit en beschikbaarheid van SaaS steunt voor een belangrijk deel op de beschikbaarheid en performance van het (publieke) internet. Deze afhankelijkheid kan ertoe leiden dat een storing of defect aan het internet de hele bedrijfsvoering stillegt. Recente storingen op het internet zoals die bij het webknooppunt AMS-IX en de beruchte kabelbreuk in de Middellandse Zee hadden tot gevolg dat bedrijven die afhankelijk waren van SaaS in enkele gevallen dagenlang geen productie konden draaien. Er bestaan weliswaar technische mogelijkheden om (korte) onderbrekingen in de connectie te overbruggen of om sessies periodiek te laten synchroniseren, maar een langdurige storing van het internet betekent geen software en, veel ernstiger, geen toegang tot de bedrijfsdata!

Een bijkomend punt is dat niemand het internet ‘bezit’ waardoor het buitengewoon moeilijk is om verantwoordelijke/aansprakelijke partijen aan te wijzen in geval van storingen.

De fysieke afstand tussen de gebruiker en de IT-afdeling over het internet kan nadelig zijn voor de performance. Vaste bandbreedtes zijn meestal wel te regelen, maar ook dan is de afnemer afhankelijk van de vele knooppunten op het internet en de snelheid van het netwerk bij de leverancier.

Daarnaast is het (publieke) internet het domein van iedereen inclusief degenen met kwade bedoelingen. Niet alleen het onderscheppen of omleiden van het dataverkeer is relatief eenvoudig, de gebruikte protocollen zijn in veel gevallen slecht beveiligd. Denial of Service-aanvallen, data ransoming en malware-installaties komen steeds vaker voor en zijn uiteraard niet exclusief voorbehouden aan on-demand diensten. Het probleem is wel dat de constante dienstverlening met de bijbehorende data over het publieke internet het risico op aanvallen en misbruik vanuit het internet aanzienlijk vergroot ([Zant07]). Ook de actuele problematiek van zwakheden in de DNS-structuur is mogelijk van invloed op SaaS aangezien de SaaS-gebruikers door criminelen eenvoudig kunnen worden omgeleid naar clandestiene en/of vervalste websites. Eventuele zwakheden in de wereldwijde architectuur van het internet kunnen daardoor verregaande gevolgen hebben voor online diensten, zeker als patches laat worden uitgebracht of niet worden geïnstalleerd.

Dit in ogenschouw nemend, kunnen de volgende beveiligingsrisico’s worden geïdentificeerd:

discontinuïteit/onbereikbaarheid van diensten en data in geval dat er geen verbinding is tot het internet;
slechte beschikbaarheid van softwarediensten als gevolg van storingen op het internet;
verlies van data als gevolg van storingen op het internet;
slechte beschikbaarheid van softwarediensten over het internet als gevolg van geografische beperkingen;
verlies/misbruik/diefstal van data als gevolg van inadequate (netwerk)beveiliging door onder meer:
- onderschepping van dataverkeer,
- Denial of Service-aanvallen,
- data ransoming,
- malware-installaties;
verlies/misbruik/diefstal van data als gevolg van zwakheden in de architectuur van het internet.

C-2009-0-Chung-t05

Tabel 5. Bedreigingen van het internet.

Complexiteit van diensten en integratie

Integratie met bestaande, interne IT-diensten evenals tussen verschillende SaaS-leveranciers en integrators kan grote integratieproblemen met zich meebrengen en de complexiteit vergroten.

Deze complexiteit geldt ook voor de beveiligingsmechanismen en -strategieën. Niet alleen zal er sprake zijn van meerdere oplossingen waarvoor geldt dat de keten net zo sterk is als de zwakste schakel, de integratie van beveiliging leidt vaak tot compatibiliteitsissues en onduidelijke verantwoordelijkheden. SaaS-leveranciers hebben meestal hun eigen methoden om het dataverkeer en data te beveiligen welke vooralsnog niet zijn gebonden aan algemeen geaccepteerde normen. Hierdoor is integratie zowel voor de integrator als voor de afnemer bij een ‘multi-integration’-architectuur een complicerende factor.

Open standaarden inzake informatiebeveiliging zoals SAML, XML Encryption en WS-Security worden steeds vaker toegepast, maar deze standaarden zijn nog lang niet uitgekristalliseerd. Integratie tussen verschillende softwarepakketten binnen SaaS en tussen verschillende leveranciers komt steeds vaker conform de principes van SOA (Service Oriented Architecture) tot stand. Hierbij worden de verschillende diensten (services) aan elkaar gekoppeld en aangeboden via een ESB (Enterprise Service Bus) (zie figuur 7). Helaas is het beveiligingsmodel voor SOA nog net zo onvolwassen als dat van SaaS en kent het model grote beveiligingsrisico’s met name op het gebied van authenticatie en autorisatie tot de softwarediensten ([Chun07]).

C-2009-0-Chung-07

Figuur 7. SaaS op basis van SOA.

Aangaande de complexiteit kunnen derhalve de volgende risico’s worden geïdentificeerd (zie ook figuur 8):

verlies of verzwakking van beveiligingsmechanismen als gevolg van beperkingen in de integratie tussen verschillende SaaS-oplossingen en/of tussen de nieuwe SaaS-oplossing en de bestaande IT-omgeving;
slechte aansluiting van de gestandaardiseerde beveiligingsprocessen van de integrator op de bedrijfsspecifieke processen van de afnemer;
complexiteit van de IT-omgeving als gevolg van vele en/of aangepaste interfaces, connecties, koppelingen en (meta) directories:
- moeilijkheden bij het uitvoeren van security changes;
- complexe root-cause analyses bij beveiligingsincidenten;
beveiligingslekken en onduidelijke verdeling van verantwoordelijkheden inzake informatiebeveiliging als gevolg van deze complexiteit.

C-2009-0-Chung-08

Figuur 8. Potentiële kwetsbaarheden van SaaS in de praktijk.

Mitigerende maatregelen

Externe opslag van data

Om de risico’s inzake vertrouwelijkheid en integriteit van data te kunnen mitigeren dient te allen tijde duidelijk te zijn waar de data zich bevindt, wie de data beheert en hoe de datastromen precies lopen. Het in kaart brengen van deze informatie blijkt in de praktijk een zeer ingewikkelde onderneming voor de afnemers én de leveranciers. In veel gevallen weten de leveranciers zelf nauwelijks hoe het dataverkeer loopt tussen hen en hun onderaannemers ([Thoo07]). Bovendien moet een dergelijk overzicht voortdurend worden bijgewerkt waarbij de vraag rijst wie het eigenaarschap van dit overzicht op zich moet nemen, de service manager aan de kant van de afnemer of de SaaS-leverancier(s)?

In ieder geval vergen de volgende drie zaken de hoogste aandacht van de afnemer opdat de vertrouwelijkheid en integriteit van bedrijfsdata is gewaarborgd:

Eisen en standaarden inzake bedrijfsdata (data policy) dienen voor de gehele dataketen in en buiten de organisatie te gelden. De SaaS-leverancier/integrator dient zich te committeren aan deze eisen en standaarden evenals zijn onderaannemers.
Verantwoordelijkheden en aansprakelijkheden dienen duidelijk te worden gedefinieerd en belegd. Hierbij moeten alle actoren van de dataketen betrokken worden.
Er dienen periodieke controles plaats te vinden om het beveiligingsniveau te beoordelen voor de gehele dataketen.

De belangrijkste bedrijfsdata zou in ieder geval altijd bereikbaar moeten zijn voor de afnemer. Een kopie van deze data zou dan lokaal opgeslagen moeten worden waarmee eigenlijk één van de uitgangspunten en voordelen van SaaS, namelijk dat alle data bij de externe leverancier wordt opgeslagen, teniet wordt gedaan. Bovendien zal dit het netwerkverkeer negatief beïnvloeden. Duidelijke criteria ten aanzien van de waarde van de bedrijfsdata waarbij een klein deel van de data lokaal wordt bewaard, is daarom een goed uitgangspunt.

Beveiliging dient over de gehele dataketen aan de eisen van de afnemer te voldoen. Ook hierbij is de vraag relevant of de leverancier moet voldoen aan de (verschillende) eisen en standaarden van de afnemers of zelf de eisen en standaarden moet voorleggen die acceptabel zijn voor alle afnemers.

Voor de handhaving van functiescheidingen en gecontroleerde autorisaties is een goed ingericht Identity & Access Management (IAM) van essentieel belang. Ook hierbij is de vraag waar de verantwoordelijkheden liggen en wie het beheer van de IAM-tooling op zich moet nemen, de afnemer of de leverancier? IAM aan de kant van de afnemer heeft als voordeel dat de onderneming zelf ‘in control’ blijft over toegang tot haar data, maar zal vanwege de veelheid aan software agents en connectoren op zijn systemen in de praktijk onwerkbaar zijn voor de SaaS-leverancier die meerdere klanten moet bedienen. IAM aan de kant van de leverancier heeft als voordeel dat vanaf één centraal punt alle toegang wordt geregeld voor meerdere afnemers, maar deze oplossing zal hoogstwaarschijnlijk niet voldoen aan alle klanteisen ([Cser08]).

Afhankelijkheid van het internet

Storingen op het internet zijn helaas te onvoorspelbaar voor wat betreft de impact en duur om goede preventieve maatregelen daartegen te treffen. Het is daarom verstandiger om met de leverancier duidelijke afspraken te maken over verantwoordelijkheden en taken in geval van storingen. Het is voor de leverancier van belang dat alle mogelijke knelpunten en beperkingen in kaart worden gebracht opdat bij storingen de juiste repressieve maatregelen in werking treden.

In ieder geval dient de afnemer zich te verzekeren van voldoende beveiligde webbrowsers en verbindingen; werknemers mogen alleen gebruikmaken van de SaaS-diensten vanaf beveiligde en gecontroleerde pc’s over beveiligde netwerken.

Complexiteit van diensten en integratie

Om de complexiteit van de IT-omgeving niet te vergroten met SaaS kan de afnemer een SaaS-oplossing kiezen die voldoet aan de volgende eisen:

eenvoudige integratie met de bestaande IT-omgeving;
gebaseerd op open standaarden;
transparante architectuur; en
hoog volwassenheidsniveau van IT-beheer en governance, en indien mogelijk aansluitend op de processen van de afnemer.

In gevallen dat er niet kan worden voldaan aan deze eisen dient de afnemer in ieder geval een goed overzicht te hebben van de complexiteit, de risico’s en de netwerkzones. Ook dient de SaaS-omgeving periodiek te worden gecontroleerd op beveiligingsrisico’s.

Goed opgestelde SLA’s over informatiebeveiliging zijn eveneens een voorwaarde. Voor de security officer of de betreffende service manager van de afnemer geldt dat richting de leverancier duidelijke afspraken worden gemaakt over onder meer:

standaarden en policies;
beveiligingseisen;
securityprocessen en -procedures inclusief de taken en verantwoordelijkheden;
IAM;
datamanagement;
continuïteit en uitwijk;
logging, monitoring en auditing.

De volledige aansprakelijkheid leggen bij de SaaS-integrator voor wat betreft de taken en verantwoordelijkheden van zijn onderaannemers kan het werk bij de afnemer vereenvoudigen, maar daarmee worden de risico’s niet gedekt. Proces- en governancemodellen die deze leemte in IT Service Management dekken, hebben vooralsnog hun nut niet bewezen. De praktijk leert in ieder geval dat ‘klassieke’ best practices zoals ITIL v2 en Cobit lang niet alle beveiligingsaspecten van SaaS omvatten ([Turn03]).

Als uitgangspunt voor procesinrichting kan evenwel het SaaS-referentiemodel van KPMG worden gebruikt (zie figuur 9). Dit model geeft de verantwoordelijkheden van de afnemer, de leverancier alsook de gezamenlijke verantwoordelijkheden weer. Voorts biedt dit model een indicatie van welke processen kunnen worden uitbesteed, maar ook welke beslist binnen de eigen organisatie moeten worden gehouden ([Chun08]).

C-2009-0-Chung-09

Figuur 9. KPMG’s referentiemodel voor SaaS.

Als we nu de belangrijkste mitigerende maatregelen afzetten tegen de belangrijkste risicogebieden krijgen we de matrix in tabel 6.

C-2009-0-Chung-t06

Tabel 6. Mitigerende maatregelen.

Conclusie

Waar kansen zich voordoen ontstaan ook risico’s. SaaS biedt grote kansen voor organisaties die streven naar betere kostenbeheersing, sterkere businessfocus en schaalbare IT-diensten. De aantallen leveranciers en mogelijkheden zijn inmiddels groot genoeg om een heel softwareportfolio van de onderneming als SaaS af te nemen. De praktijk leert echter dat SaaS in zijn stormachtige ontwikkeling ook de nodige beveiligingsrisico’s met zich heeft meegebracht die de verwachte baten teniet kunnen doen.

Externe dataopslag, sterke afhankelijkheid van het internet en complexiteit van diensten en integratie zijn de voornaamste risicogebieden van SaaS, waartegen met bestaande kennis en middelen voldoende te bewapenen valt. Het is dan wel van belang dat de relevante risico’s voor de gehele dataketen van de dienst in kaart worden gebracht. Juist dit punt blijkt in de praktijk bij veel afnemende organisaties én SaaS-leveranciers onvoldoende onder controle te zijn.

Terwijl de softwarediensten en operationele activiteiten verplaatst kunnen worden naar de SaaS-leverancier, zal SaaS in principe niet het risiconiveau van de afnemer verlagen. Om optimaal te kunnen profiteren van SaaS is het derhalve essentieel om de juiste mitigerende maatregelen te treffen alvorens er wordt overgegaan tot implementatie van dit veelbelovende model.

C-2009-0-Chung-f3

Fort Voordorp

Literatuur

[Aspf08] www.aspforum.nl

[Card05] Rui Cardoso and Mário Freire, Security Vulnerabilities and Exposures in Internet Systems and Services, Universidade de Beira Interior, Idea Group Inc., 2005.

[Carr08] Nicolas Carr, The Big Switch: Rewiring the World, from Edison to Google, 2008.

[Chun07] Mike Chung, De beveiligingsproblematiek rond Service Oriented Architecture, Banking & Finance, november 2007.

[Chun08] Mike Chung, Software-as-a-Service. Opportunities and Risks of SaaS, KPMG ITA ISC, mei 2008.

[Cser08] Andras Cser and Jonathan Penn, Identity Management Market Forecast: 2007 to 2014, Forrester, februari 2008.

[Desi07] Roberto Desisto and Raymond Paquet, Learn the Economic Advantages of a Pure SaaS Vendor, Gartner Research, oktober 2007.

[Dube07] Abhijit Dubey and Dilip Wagle, Delivering Software as a Service, McKinsey Quarterly, mei 2007.

[Isfd05] Disappearance of the Network Boundary, Information Security Forum, ISF Digest 2005.

[Kouw07] Fred Kouwenberg, Software-as-a-Service, Tooling event 2007.

[Maiw07] Eric Maiwald, SaaS for Collaboration and Content: A Smart Move or an Invitation to Disaster?, Burton Group, 2007.

[Thoo07] Eric Thoo, Safeguarding Information When Using SaaS, Gartner Research, november 2007.

[Turn03] Mark Turner, David Budgen and Pearl Brereton, Turning Software into a Service, IEEE Computer Society, 2003.

[Zant07] Arjen van Zanten en Ronald Heil, Het ICT-Netwerk. Waar ligt de grens?, Compact 2007/2.

Authenticatiemanagement: een procesbenadering

Authenticatiemanagement is momenteel onderbelicht binnen organisaties. Het begrip zou te veelomvattend zijn en is niet zo concreet als bijvoorbeeld autorisatiemanagement, waarvan de bekendheid van het woord functiescheiding tekenend is. Het belang is echter groot. De auteurs stellen een concrete aanpak voor om authenticatiemanagement goed in te richten (en te controleren), waarbij rekening wordt gehouden met de nieuwste ontwikkelingen binnen het vakgebied.

Inleiding

Sinds mensenheugenis is authenticatie een concept waar alledaags gebruik van wordt gemaakt, hoewel niet iedereen zich hiervan bewust is. Een voorbeeld: u gaat geld pinnen. Over het algemeen mag alleen u vanaf uw bankrekening pinnen. Maar hoe weet de bank nu met zekerheid wie er bij de automaat staat? Authenticatie draait om de vraag: hoe kan met (enige mate van) zekerheid worden bepaald dat een persoon is wie hij of zij claimt te zijn? Men kan zich voorstellen dat de noodzaak voor authenticatie en de te verkrijgen mate van zekerheid groter wordt naarmate het risicoprofiel van de aan de authenticatie gekoppelde autorisatie toeneemt (zoals het inzien van bepaalde informatie, of het verrichten van een zekere handeling zoals een pintransactie). Zie figuur 1 voor een veelgebruikt authenticatieproces in bedrijfsomgevingen.

C-2008-4-Steevens-01

Figuur 1. Schematisch overzicht van een authenticatieproces.

In het normale zakelijke verkeer is het begrip authenticatie ook van belang. Logische beveiligingsmaatregelen, zoals het inperken van autorisaties en het implementeren van functiescheidingsregels, zijn over het algemeen gebaseerd op de identiteit van een actor (wat zowel een persoon als een systeem kan zijn). Zonder juiste authenticatie verliezen de beveiligingsmaatregelen een groot deel van hun toegevoegde waarde. Daarnaast is er een juridisch aspect van belang, zodat achteraf kan worden vastgesteld dat een persoon bepaalde gevoelige informatie heeft ingezien of een bepaalde schadelijke handeling heeft verricht. Dit wordt ook wel de ‘onweerlegbaarheid’ van een transactie genoemd.

Authenticatieproces versus authenticatiemanagement

Het authenticatieproces omvat de activiteiten die uitgevoerd worden om de identiteit van een actor succesvol vast te stellen. Het betreft een operationeel proces, waarvan een mogelijke invulling is weergegeven in figuur 1.

In dit artikel omvat authenticatiemanagement het beleid, de processen en de techniek om effectief het authenticatieproces te besturen en te beheersen. De activiteiten die binnen authenticatiemanagement worden onderkend zijn:

het uitvoeren van een risicoanalyse;
het afwegen van risico’s versus bedrijfscultuur;
het opzetten van een risicogestuurd authenticatiebeleid en -ontwerp (de inrichting van het operationele authenticatieproces maakt dus deel uit van authenticatiemanagement);
de initiële identificatie en authenticatie van medewerkers (onboarding in de organisatie) én systemen;
het vormgeven van een proces voor de uitgifte, activering, ondersteuning en intrekking van authenticatiemiddelen.

Opmerkelijk genoeg lijkt de aandacht voor authenticatiemanagement en authenticatie in algemene zin achter te blijven bij de aandacht voor het reeds genoemde begrip autorisatiemanagement. De oorzaak hiervan is niet geheel duidelijk, maar mogelijk speelt het feit dat nog maar weinig harde normen op dit vlak bestaan een rol. Hierdoor hebben zowel het bedrijfsleven als IT-auditors mogelijk meer moeite met het eenduidig oordelen over authenticatiemanagement.

Is deze beperkte aandacht voor authenticatiemanagement terecht? Hoeveel organisaties hebben aandacht voor authenticatiemanagement, zelfs zonder dat de SOx-wetgeving of zelfs maar de IT-auditor hier specifiek aandacht voor heeft? Is het binnen organisaties überhaupt bekend hoe het authenticatiemanagement dient te worden ingericht? Hoe gaat uw organisatie hiermee om?

Toelichting op begrippen

Voordat we de aanpak voor het inrichten van authenticatiemanagement toelichten, schetsen we een begrippenkader. Het blijkt namelijk vaak lastig om identificatie en authenticatie van elkaar te onderscheiden.

Identificatie versus authenticatie

Identificatie is het claimen van een identiteit door het overleggen van identificatiemiddelen, bijvoorbeeld een rekeningnummer of gebruikersnaam. Authenticatie is het verifiëren van de juistheid van deze identiteit door het overleggen van authenticatiemiddelen, bijvoorbeeld een wachtwoord of pincode. Authenticatie wordt uitgevoerd door de dienstverlenende partij. Lastig hierbij is dat zowel de begrippen authenticatie(middelen) als identificatie(middelen) gemeengoed zijn geworden en vaak als synoniem worden gebruikt. Als je sec naar authenticatie als een proces kijkt is dat niet terecht. Een identificatiemiddel geeft namelijk geen zekerheid over de juistheid van de identiteit van de gebruiker. Het geeft alleen een beeld van wat hij claimt te zijn. Een authenticatiemiddel is een middel waarmee je identiteit bewezen[Met ‘bewezen’ wordt niet een 100% zekerheid bedoeld. Het gebruik van alle authenticatiemiddelen geeft een ‘bepaalde mate van zekerheid’ over de identiteit van de gebruiker.] en gecontroleerd kan worden, omdat het iets is wat je weet, bent of hebt ([Modi05]).

Relevantie van authenticatiemanagement voor IT-auditing

Tijdens IT-audits ligt de focus vaak voornamelijk op autorisaties en autorisatiemanagement. Dit valt te verklaren doordat wetgeving, zoals SOx, hier strikte eisen aan stelt. Het element dat specifiek onder authenticatiemanagement valt en vaak ook binnen de audits valt, is of de organisatie een uniform wachtwoordbeleid heeft. De reden hiervoor is mogelijk dat men overige authenticatiemiddelen simpelweg niet overweegt of te duur acht. Daarnaast is een wachtwoordbeleid relatief eenvoudig te controleren aan de hand van bestaande richtlijnen en hebben veel organisaties hiervoor beleid ingericht. Als norm wordt meestal gesteld dat een wachtwoord dat voldoet aan het beleid niet eenvoudig te kraken of te raden is.

Deze (veelvoorkomende) aanpak kent de volgende problemen, die we met enkele voorbeelden toelichten:

Een grote bank heeft een standaard-wachtwoordbeleid ingesteld (waarvan aangenomen mag worden dat het wachtwoord moeilijk te kraken of te raden is). Medewerkers lenen echter wel eens hun gebruikersaccount en wachtwoord uit aan andere interne medewerkers als zij bijvoorbeeld een korte periode op vakantie gaan. Eén van de interne medewerkers gebruikt deze accounts om zijn eigen transacties goed te laten keuren. Door enkele ongeanticipeerde afschrijvingen en verliezen gaat de bank een jaar later failliet. Heeft de bank de risico’s goed ingeschat? Was de opgelegde functiescheiding nog gewaarborgd?
Op een server voor de financiële applicatie is een sterk wachtwoordbeleid ingesteld. Op een andere locatie staat een systeem dat de financiële gegevens verwerkt voor de koppeling met het HR-systeem. Door technische problemen is de authenticatie tussen deze systemen nog niet ingericht, maar het management is blij dat de systeemkoppeling eindelijk is ingericht. Het management van de organisatie vermoedt nu dat financiële gegevens zijn gekopieerd en verkocht aan concurrenten. Door wie? Heeft de organisatie een eenduidig beleid opgesteld, zodat juridisch vastgesteld kan worden welke persoon verantwoordelijk is?
Een middelgroot persbureau heeft een ‘documentmanagementsysteem’ ingericht voor de centrale ontsluiting van nieuwsberichten en voor de centrale opslag van (concept)artikelen die mogelijk voor een publicatie gebruikt kunnen worden. Iedere medewerker krijgt bij in dienst treden een zeer sterk wachtwoord uitgereikt. Na enkele jaren succesvol dienstverband verlaten enkele medewerkers het bedrijf en gaan bij een overheidsinstantie werken. Een half jaar laten komen er zaken aan het licht waardoor enkele medewerkers van de overheidsinstantie ervan worden verdacht op de hoogte en in bezit te zijn van bepaalde gevoelige ongepubliceerde artikelen van het persbureau. Was het on- en offboardingproces bij het persbureau op orde?
Een middelgrote organisatie werkt met sterke authenticatie (in dit geval smartcards) om in te loggen op de informatiesystemen waarop de fysieke beveiliging ook is aangesloten. Zojuist heeft een grote ontslagronde plaatsgevonden in verband met bezuinigingen. De receptionist kent de medewerkers meestal persoonlijk en heeft de mogelijkheid om de eerste deur te openen. Dat gebeurt soms als iemand zijn smartcard op zijn werkplek heeft laten liggen bij het weggaan, waarna iemand voor hem de deur heeft opengehouden. ‘s Ochtend blijkt vandalisme in de serverruimte te hebben plaatsgevonden. Hoewel back-ups gemaakt zijn, is de fysieke schade enorm en kunnen de medewerkers een dag niet werken. Was het authenticatieproces berekend op de veranderde situatie? Was het authenticatieproces ingebed in de gehele organisatie?

Dit zijn slechts enkele voorbeelden uit de praktijk. In dit artikel wordt als uitgangspunt gehanteerd dat authenticatiemanagement in IT-audits altijd wordt benaderd vanuit de risico’s die een organisatie in de praktijk loopt.

Voorgestelde benadering voor het inrichten van authenticatiemanagement

Authenticatiemanagement heeft als doel de kwaliteit van het authenticatieproces te beheersen. Daarom is de benadering vormgegeven in het ‘quality control’-model Plan-Do-Check-Act[Plan-Do-Check-Act is ook bekend als de ‘Shewhart cycle of quality control’.] ([Shew39]). Als invulling van de benadering is gebruikgemaakt van het COSO-model. Het COSO-model is door auditors algemeen geaccepteerd als raamwerk voor risicobeheersing. In de voorgestelde benadering zijn alleen de relevante onderdelen meegenomen. Voor meer informatie over het COSO-model, zie [COSO04].

De volgende stappen dienen te worden uitgevoerd als onderdeel van de managementcyclus:

C-2008-4-Steevens-02

Figuur 2. Authenticatiemanagement binnen de managementcyclus.

1. Bepalen van de Internal Environment[The internal environment encompasses the tone of an organization, and sets the basis for how risk is viewed and addressed by an entity’s people, including risk management philosophy and risk appetite, integrity and ethical values, and the environment in which they operate ([COSO04]).]

Onderdeel van deze stap is het bepalen van de zogenaamde risk appetite. Dit begrip geeft aan welke risico’s geaccepteerd worden binnen de organisatie. Hierop zijn bijvoorbeeld de branche waarin de organisatie opereert van invloed, maar ook de cultuur van de organisatie (ondernemend of risicomijdend) en de manier van leidinggeven. Interessant hierbij is dat de risk appetite niet specifiek voor authenticatiemanagement hoeft te zijn, maar op de gehele organisatie (of een deel daarvan) toegepast kan worden. Enkele voorbeelden:

Sterk risiconemend. Bijvoorbeeld een beginnende internet start-up of creatieve onderneming. Het devies is vaak om de opstartkosten zo snel mogelijk terug te verdienen, waarbij het analyseren en mitigeren van risico’s ondergeschikt is.
Sterk risicomijdend. Bijvoorbeeld banken en overige financiële instellingen.
Impactmijdend. De nadruk ligt sterk op het voorkomen van risico’s met hoge impact. De kans van optreden is van ondergeschikt belang. Een voorbeeld kan een organisatie zijn met een cultuur die zich richt op de grote problemen. Kleinere problemen voorkomt men niet, maar lost men op als deze zich voordoen.

Daarnaast kunnen factoren van buitenaf van invloed zijn op de risk appetite, bijvoorbeeld wanneer klanten, toezichthouders of auditors hieraan specifieke eisen stellen. De risk appetite kan uiteindelijk worden vastgelegd in een risicomatrix, zoals weergegeven in figuur 3.

C-2008-4-Steevens-03

Figuur 3. Risicomatrix met vastgestelde risk appetite.

Het is overigens een wijdverbreid misverstand dat bij deze stap al een kostenafweging van maatregelen plaatsvindt, aangezien de maatregelen en de mogelijke risico’s voor het authenticatieproces nog niet bepaald zijn. Wanneer in een volgende stap blijkt dat de organisatie onvoldoende geld of tijd beschikbaar stelt om een maatregel te implementeren, dan dient de risk appetite te worden aangepast. Blijkbaar accepteert de organisatie een hoger risiconiveau dan aanvankelijk werd ingeschat.

Het is overigens aannemelijk dat ook de (IT-)auditor hier een mening over heeft, aangezien het mogelijk is dat de risk appetite op deze manier onverantwoord hoog komt te liggen. In de praktijk zien we dit vaak bij organisaties met een hoog risicoprofiel die de kosten voor het invoeren van fysieke beveiligingsmaatregelen dan wel sterke authenticatie te hoog vinden.

2. Uitvoeren van een risicoanalyse

Onderdeel van het bepalen van de risicoanalyse is het inzichtelijk maken van welke informatie rondgaat binnen de organisatie. Wanneer dit deels zeer vertrouwelijke gegevens betreft, dan dienen ook de systemen in kaart te worden gebracht die deze informatie opslaan, verwerken of verzenden. In een vervolgstap kan dan worden bepaald of op deze specifieke systemen aanvullende maatregelen noodzakelijk zijn.

Het is gebruikelijk om de risicoanalyse op een hoog abstractieniveau te starten om deze vervolgens gedetailleerd en concreet uit te werken. Dit heeft als gevolg dat de beheersingsmaatregelen tevens steeds concreter kunnen worden.

Enkele voorbeelden zijn opgenomen in tabel 1.

C-2008-4-Steevens-t01

Tabel 1. Enkele voorbeelden van een risicoanalyse.

Uiteraard dienen alle risico’s genummerd te worden. Voor de overzichtelijkheid zijn alleen de risico’s genummerd die van toepassing zijn op het resterende deel van het artikel.

Na het in kaart brengen van de risico’s dienen de kans en impact hiervan te worden bepaald. Uiteraard is dit voor elke organisatie specifiek. Wanneer bijvoorbeeld in het verleden regelmatig externen zijn aangetroffen die niet begeleid worden, dan is de kans groot dat dat ook in de toekomst zal voorkomen. Alle risico’s dienen vervolgens in de risicomatrix te worden geplaatst.

Voor de risico’s R1 tot en met R4 is hieronder een voorbeeld van een risicoanalyse uitgewerkt:

R1: Wanneer een dubbel uitgevoerde kaartlezer bij de ingang defect is, kunnen medewerkers het gebouw niet meer in. Dit resulteert in ongewenst productieverlies. De kans hierop is klein doordat de lezer dubbel is uitgevoerd; daarnaast kunnen medewerkers een andere ingang of poort kiezen.
R2: Vingerafdruklezers staan vaak gevoelig afgesteld waardoor de afdruk soms niet wordt herkend. Het uiteindelijke risico hiervan is vrij laag (hoe vervelend ook voor de medewerker) omdat er vrijwel geen impact is (informatie wordt niet ongeautoriseerd vrijgegeven).
R3: De organisatie wenst dat alle externen/bezoekers te allen tijde worden begeleid. In het verleden zijn regelmatig externen/bezoekers in bedrijfsruimten aangetroffen zonder begeleiding, dus de kans dat dit nogmaals gebeurt is groot. De impact is klein doordat er veel sociale controle is binnen het bedrijf.
R4: Medewerkers laten bij tijdelijke afwezigheid vaak hun wachtwoord achter bij directe collega’s. Sommigen hebben memo’s op hun monitor geplakt met de wachtwoorden die zij gebruiken. De impact op de organisatie is dat ingerichte functiescheidingen niet meer gewaarborgd zijn.

De voorbeeldrisico’s van deze organisatie zijn weergegeven in de matrix van figuur 4. De pijlen geven aan in welke richting het risico beïnvloed dient te worden om het risico binnen de risk appetite te laten vallen. Maatregelen daartoe zijn nodig om enerzijds de optredingskans te reduceren en anderzijds de impact te verkleinen.

C-2008-4-Steevens-04

Figuur 4. Risicomatrix met vastgestelde risico’s.

3. Bepalen van te nemen beheersingsmaatregelen

Voor elk risico dat is bepaald, dient te worden vastgesteld welke maatregelen de organisatie neemt om de risico’s binnen de risk appetite te brengen.

R1: Het onderhoudscontract kan vanuit authenticatieoogpunt worden versoepeld. De organisatie kiest voor de goedkoopste optie: binnen 72 uur is een monteur ter plaatse.
R2: Het risico valt binnen de risk appetite, derhalve zijn geen maatregelen noodzakelijk.
R3: Voor alle medewerkers wordt een security awareness-training verplicht gesteld. Daarnaast worden de richtlijnen ten aanzien van het begeleiden van bezoek periodiek gecommuniceerd.
R4: De organisatie besluit om periodiek te controleren op de aanwezigheid van memo’s met daarop accountgegevens. De security awareness-training zal ook ingaan op het opschrijven van deze gegevens en het delen van wachtwoorden.

4. Implementeren en uitvoeren van de gekozen beheersingsmaatregelen

Deze stap omvat het daadwerkelijk vertalen én implementeren van de ontworpen beheersingsmaatregelen in de staande organisatie.

5. Zelfcontrole van in werking genomen beheersingsmaatregelen

Door het meten van de prestatie van de risico’s kan men nagaan of de geïmplementeerde beheersingsmaatregelen effect hebben gehad. Het is niet per se nodig om direct een externe auditor in huis te halen. Belangrijk is om een plan op te stellen hoe de effectiviteit van de genomen beheersingsmaatregelen kan worden gemeten. Aan de hand van de informatie die hieruit komt kunnen bestaande beheersingsmaatregelen geoptimaliseerd worden om risico’s optimaal af te dekken. De uitvoering van deze zelfcontrole dient bij voorkeur plaats te vinden door medewerkers die onafhankelijk en objectief naar het proces kunnen kijken. Dit zou bijvoorbeeld een afdeling interne audit kunnen zijn.

R1: Het is voorgekomen dat de kaartlezer defect was. Tijdens drukke in- en uitloopuren blijkt de receptie de toegangspoort soms open te zetten om de doorstroming te bevorderen.
R2: Door een software-update van de fabrikant blijkt de vingerafdruklezer een vingerafdruk sneller te lezen. De kans op fouten neemt iets toe, maar het risico valt nog steeds binnen de risk appetite.
R3: Het is gebleken dat externen/bezoekers nu altijd begeleid worden in alle openbare ruimten.
R4: Hoewel de situatie iets verbeterd is, blijken de medewerkers vrij hardnekkig in hun gedrag. De wachtwoorden worden niet meer op monitors geplakt, maar bewaard in niet-afgesloten bureaukasten. Collega’s zijn daarvan vaak op de hoogte.

6. Optimaliseren van beheersingsmaatregelen

Na meting van de effectiviteit van de getroffen beheersingsmaatregelen is het belangrijk om te kijken of de bestaande maatregelen geoptimaliseerd kunnen worden. Op basis van de resultaten van de zelfcontrole kunnen aanpassingen op de maatregelen of geheel nieuwe maatregelen worden voorgesteld.

Per risico zouden bijvoorbeeld de volgende aanpassingen gedaan kunnen worden:

R1: Men kan de receptie instrueren dit niet meer te doen, gezien het risico dat onbevoegden op die manier het gebouw binnenkomen. Daarnaast kan men het onderhoudscontract wederom aanpassen.
R2: Geen aanpassingen noodzakelijk.
R3: Geen aanpassingen noodzakelijk.
R4: Mede gezien de bevindingen van de (IT-)auditor en druk vanuit de klantomgeving beslist het management om sterke authenticatie op basis van smartcards in te voeren binnen de gehele organisatie. Door deze verandering kan het bedrijf ook diensten aanbieden aan bepaalde veeleisende organisaties.

Vervolgens begint de managementcyclus opnieuw. Om nog even verder te gaan op het voorbeeld: een onderzoeksrapportage heeft uitgewezen dat vingerafdruklezers onvoldoende zekerheid bieden. Naast het niet authenticeren van geautoriseerde personen, blijken deze soms ook toegang te verlenen aan niet-geautoriseerde personen. Omdat het bedrijf inmiddels diensten aanbiedt met hoog geclassificeerde informatie, is zowel de kans als de impact van het risico fors toegenomen. Men besluit om de toegang tot de serverruimte ook via smartcards te laten verlopen. Bijkomend voordeel is dat de organisatie slechts één procedure hoeft te onderhouden ten behoeve van de verstrekking van authenticatiemiddelen.

Conclusie

De aandacht voor authenticatiemanagement wordt op dit moment overschaduwd door autorisatiemanagementvraagstukken. Dit terwijl is beschreven waarom authenticatie een randvoorwaarde voor gedegen autorisatiemanagement is. Gegeven de ontwikkelingen binnen authenticatie die momenteel plaatsvinden (Single Sign On / Reduced Sign On[Single Sign On (SSO) / Reduced Sign On (RSO): Het begrip SSO/RSO betekent dat gebruikers zich slechts op één plaats of een zeer beperkt aantal plaatsen behoeven te identificeren en authenticeren om toegang te verkrijgen tot systemen, applicaties of transacties.]) en ontwikkelingen die in de nabije toekomst meer gemeengoed zullen zijn (federatieve authenticatie[Federatieve authenticatie kan het best worden omschreven als een stelsel van afspraken, standaarden en technologieën die het mogelijk maken om elektronische identiteiten en bijbehorende profielen overdraagbaar en uitwisselbaar te maken tussen diverse autonome domeinen, zowel binnen één organisatie als tussen organisaties onderling ([Verb05]).]), is het risicoprofiel toegenomen. Desondanks blijft de auditaanpak en -inspanning op dit moment gelijk. Organisaties en IT-auditors dienen het belang van authenticatiemanagement te onderkennen en daaraan gestalte te geven om risico’s voldoende af te dekken. Dit artikel heeft een mogelijke aanpak beschreven om ook het authenticatieproces integraal te beheersen. Pas dan kan een organisatie werkelijk in control zijn.

Literatuur

[COSO04] http://www.coso.org/Publications/ERM/COSO_ERM_ExecutiveSummary.pdf, geraadpleegd: juni 2008.

[Modi05] Modinis, ‘Study on Identity Management in eGovernment’ for the European Commission, november 2005.

[Shew39] W.A. Shewhart, Statistical Method from the Viewpoint of Quality Control, Dover, New York, 1939.

[Verb05] Drs. M. Verbree en P.E. van der Hulst, Federated identity management: het einde van uw digitale sleutelbos?, Compact 2005/3.

SABA: IT-audit tooling 2.0

SABA is de nieuwe generatie IT-audit tooling van KPMG voor het verzamelen van systeemgegevens. SABA is beter afgestemd op de moderne eisen van de IT-auditors: automatisering is verder doorgevoerd waardoor nog meer tijdwinst kan worden gehaald en beoordelingen kunnen gemakkelijker klantspecifiek worden gemaakt door verbeterde rapportagemogelijkheden.

Inleiding

Door de jaren heen heeft KPMG IT Advisory diverse losse tools gebruikt ter ondersteuning van IT-audits. Hoewel deze tooling altijd goed heeft geholpen om snel systeeminstellingen te verzamelen, heeft deze oude tooling een aantal nadelen. Naast een uitleg over de achtergrond en de voor- en nadelen van deze tooling ter ondersteuning van IT-audit zal dit artikel verder ingaan op de kernpunten en het gebruik van de ‘next generation’ audit tooling die KPMG heeft ontwikkeld: SABA.

Achtergrond IT-audit tooling

Hoewel een IT-audit vaak over meer dan alleen IT-systemen gaat, is de component van deze IT-systemen zelf niet te onderschatten. Omdat IT-systemen nou eenmaal een belangrijk onderdeel zijn van de informatieverwerking (zie ook figuur 1), moeten deze systemen met de bijbehorende instellingen en autorisaties worden beoordeeld ([Korn07]). Door het toenemende gebruik van IT in de maatschappij, en daarmee ook in de klantenkring van KPMG, komen de auditors en adviseurs van KPMG ook steeds meer IT-systemen tegen bij klanten.

C-2008-4-Smeets-01

Figuur 1. Positie van IT-systemen in de bedrijfsvoering.

Alvorens de instellingen van IT-systemen kunnen worden beoordeeld, moeten deze eerst worden verzameld. Deze stap van verzamelen is uitermate geschikt om te automatiseren aangezien het hier puur het uitvoeren en samenvoegen van systeemcommando’s betreft. Op het vlak van verzamelen van instellingen kan dus door de IT-auditor een flinke winst in tijd worden behaald omdat niet alle instellingen uit interviews of handmatige demonstratie hoeven te blijken. Let wel, interviews zijn nog steeds noodzakelijk om de instellingen te beoordelen. Een klant kan immers altijd compenserende maatregelen hebben getroffen om bepaalde risico’s af te dekken.

In deze laatste stap van beoordelen zit dan ook meteen het risico voor de IT-auditor. Het verzamelen van de instellingen kan worden gedaan door iedereen die voldoende kennis heeft van het IT-landschap van de klant en de keuze kan maken om de juiste systemen te beoordelen (functioneel). Echter, voor het beoordelen van de uitkomst is nog steeds kennis nodig van de systemen zelf (versies van besturingssystemen en applicaties) en van de klant zelf (bijvoorbeeld voor compenserende maatregelen).

De nieuwe generatie audit tooling die door KPMG is ontwikkeld, is beter afgestemd op de moderne eisen van de IT-auditors: automatisering is verder doorgevoerd waardoor nog meer tijdwinst kan worden behaald en beoordelingen kunnen gemakkelijker klantspecifiek worden gemaakt door verbeterde rapportagemogelijkheden.

Tekortkomingen vorige versies KPMG-audit tooling

Door de jaren heen heeft KPMG diverse versies gehad van verschillende IT-audit tooling. De meeste tools waren zelf ontwikkeld, al werd en wordt nog steeds af en toe gebruikgemaakt van software van derden. Vaak is gebleken dat zelfgemaakte tooling meer flexibiliteit biedt en inzichtelijker is voor klanten. Software van derden wordt namelijk vrijwel altijd aangeboden als programma en niet als script[Een script is een aaneenschakeling van systeemcommando’s die te lezen en aan te passen is met een tekstverwerker. Een applicatie is gecompileerde programmacode die niet te lezen en niet te wijzigen is zonder de broncode. Deze broncode wordt vrijwel nooit vrijgegeven door de fabrikant.]. Hierdoor heeft zelfgemaakte tooling dan ook de voorkeur boven software van derden. Desondanks kleven er diverse nadelen aan eigen tooling, welke vaak werden opgelost in nieuwere versies. Hieronder volgt een kort overzicht van de verschillende versies die we kennen binnen KPMG en de bijbehorende nadelen.

Versie 0

Versie 0 kenmerkt zich door het ontbreken van een feitelijk script. Deze allereerste versie mag dan ook eigenlijk geen echte versie heten. De manier van informatie verzamelen was puur gebaseerd op het vertellen door systeembeheerders van welke instellingen screenshots moesten worden gemaakt, of van welke systeemcommando’s de output moest worden gekopieerd naar een tekstbestand. Dit gebeurde door middel van observaties van het ophalen van de systeeminstellingen.

De nadelen van deze methode werden al snel duidelijk en waren eindeloos: niet schaalbaar, foutgevoelig, veel specifieke kennis nodig bij auditor tijdens verzamelen, training-on-the-job kostbaar, et cetera. Al snel werd er dan ook gewerkt aan een opvolger.

Versie 1

De automatiseringsslag die volgde heeft geresulteerd in de scripts voor diverse smaken besturingssystemen en databases. De eerste generieke scripts zijn in 2002 ontwikkeld. De scripts waren een aaneenvoeging van een select aantal systeemcommando’s waarvan de output werd geëxporteerd naar een HTML-document. Het resultaat was voor de auditor gemakkelijk te bekijken met een webbrowser. Deze scripts waren een enorme verbetering en zijn lange tijd gebruikt binnen KPMG, en soms zelfs daarbuiten.

De voordelen van deze eerste echte generatie audit tooling waren groot en zorgden voor een goede verspreiding. De scripts konden worden weggezet door een auditor zonder specifieke kennis van het platform, en de klant kon het script uitvoeren zonder de overhead van een gedetailleerd interview waarbij systeeminstellingen werden bekeken. Het script kon worden uitgevoerd door de klant wanneer het uitkwam, en de resultaten ervan waren gemakkelijk terug te mailen naar de auditor. De analyse kon vervolgens op een andere locatie en een ander moment worden gedaan, eventueel door een expert op het platform.

Echter, met de voordelen kwamen ook nadelen. De voornaamste nadelen van deze generatie audit tooling zijn hieronder genoemd in willekeurige volgorde:

Gebrek aan uniformiteit. Doordat de verschillende scripts voor de diverse besturingssystemen en applicaties allemaal los van elkaar werden ontwikkeld, resulteerde dit in los van elkaar staande scripts die ieder een aparte manier van aanroepen, uitvoeren en rapporteren hadden. Bij het ene script was de output één bestand, bij andere scripts een hele directory vol met bestanden. De opzet van de rapportage was niet altijd in dezelfde volgorde, wat de vertaalslag naar de samenvattende rapportage onnodig ingewikkeld maakte.
Verschillende rapportages. De rapportages van de verschillende scripts waren net allemaal wat anders. Hoewel allemaal opgesteld in HTML, week de manier van rapporteren steeds weer in een of meer opzichten af van andere rapportages. Denk hierbij aan de volgorde van de soorten controles, wel of geen beoordeling bij de resultaten en verschillende opmaakstijlen.
Handmatig kopiëren. Doordat de rapportages niet in Microsoft Word waren opgesteld, moest de auditor vervolgens de relevante output van de scripts kopiëren en plakken naar de uiteindelijke Word-rapportage. Dit is erg tijdintensief.
Kennis in scripts. De scripts bevatten naast de feitelijk uit te voeren systeemcommando’s ook meteen het rapportagegedeelte. Hierdoor werd de kennis die erin zit (norm, systeemcommando en resultaat) ook meteen doorgegeven aan degene die de scripts ontving. Hoewel het geen ‘rocket science’-kennis betreft, bleken deze scripts toch een gewild iets gezien het grote aantal plaatsen waar we als KPMG onze eigen scripting terug hebben gezien op andere plaatsen bij dezelfde klanten, totaal andere klanten en zelfs concurrenten.

Een ander nadeel hiervan was dat mocht de output van de scripts per ongeluk in handen komen van een derde, alle (wellicht gevoelige) data over klantsystemen kant-en-klaar werd gepresenteerd, inclusief hiaten in de beveiliging van deze systemen.
Statisch. Door de manier waarop de scripts zijn opgezet, zijn ze onnodig statisch. Uitbreiding was niet altijd even snel gedaan en specifieke normen voor specifieke klanten moesten of overal worden doorgevoerd, of de rapportage moest achteraf worden aangepast.
Versiecontrole. De scripts bevatten geen enkele manier van versiecontrole. Eventuele fouten of onvolkomenheden die in oude versies konden bestaan, bleven tot in lengte van dagen bestaan omdat auditors niet werden gedwongen periodiek een update van de scripts binnen te halen.

Kernpunten versie 2.0

Na enkele jaren van intensief gebruik en gewenning aan de nieuwe scripts maakten de voordelen plaats voor de nadelen. De roep om vernieuwde versies werd steeds sterker. In 2006 is de ontwikkeling van een nieuwe generatie gestart waarbij de volgende kernpunten werden aangehangen:

Uniformiteit. Dezelfde tooling voor alle systemen en applicaties. De manier van rapporteren moet nauw aansluiten op onze manier van rapporteren naar de klant.

Bij deze uniformiteit moet ook rekening worden gehouden met mogelijkheden voor het gemakkelijk toevoegen van nieuwe platformen en nieuwe rapportagevormen (bijvoorbeeld voor specifieke klanten of voor specifieke dossiereisen).
Kennisscheiding. Scheiding tussen kennis in scripts (KPMG) en de uitkomst daarvan (klant), waardoor beide veiliger worden voor luistervinken.
Versiecontrole. Makkelijke manier van verplicht updaten van de scripts.
Procesoptimalisatie. Minder ‘dom’ werk voor de auditor en automatiseer wat je kunt. Hierdoor veel tijdwinst en verminderde foutgevoeligheid.

De nieuwe generatie: SABA

SABA is het nieuwe platform voor IT-audit tooling voor het verzamelen en analyseren van systeeminstellingen dat KPMG IT Advisory sinds enige tijd gebruikt. Hoewel de ontwikkeling door één afdeling is gedaan, is het niet zo dat alleen deze afdeling hier verder aan kan werken. Doordat het nieuwe platform modulair is opgezet, is (internationale) samenwerking met andere units, of zelfs klanten, vrij gemakkelijk te bewerkstelligen.

Kernpunten SABA

Toen met de ontwikkeling van SABA werd begonnen, is een aantal ontwerpkeuzes gemaakt. Deze keuzes zijn gemaakt om de nadelen van de vorige generatie tooling zo optimaal mogelijk weg te werken. Hieronder volgt een uitleg van de belangrijkste kernpunten van SABA:

Tooling platform. SABA moet een uniform platform worden dat gemakkelijk is uit te breiden met gewenste functionaliteit. Het toevoegen van een nieuw platform of nieuwe applicatie moet snel te doen zijn zonder dat dit consequenties heeft voor de rest van SABA. Tevens moet de manier van gebruik uniform zijn.
Spreiding van vergaren en rapporteren. De scripts die worden uitgevoerd op het systeem van de klant mogen geen hapklare rapportage opleveren. Zonder de rapportageslag, die alleen kan worden gedaan op het KPMG-netwerk, is de SABA-output vrijwel onbruikbaar.

Hiermee gaan we tegen dat de scripts gevoelige informatie kant-en-klaar presenteren aan iedereen die de output onderschept. Tevens gaan we hiermee tegen dat de scripts buiten ons medeweten worden gebruikt.
Rapportage in gewenst formaat. Rapporteren in het Word-formaat heeft grote voordelen. Niet alleen is het omzetten naar de uiteindelijke eindrapportage gemakkelijker, maar ook is het een stuk gemakkelijker om het rapport te bewerken.
Inhoud van rapportage aanpasbaar. Door gebruik te maken van rapportagetemplates kan de auditor kiezen wat er uiteindelijk wordt gerapporteerd. Dit geeft de vrijheid om voor klanten met specifieke eisen een aparte template te maken waar specifieke controles worden weggelaten of juist worden toegevoegd. Tevens is het hierdoor gemakkelijk een ‘quick-scan’ rapport te maken dat alleen de basale controles (versiecontrole en autorisaties) bevat.

Een ander voordeel is dat de taal van de rapportage kan worden aangepast. Bij het genereren van de rapportage moet de auditor de keuze hebben om het rapport in het Nederlands of Engels te genereren. In de toekomst kunnen hier gemakkelijk nieuwe talen aan worden toegevoegd.

De architectuur van SABA

In de architectuur van SABA onderscheiden we een aantal componenten. Zoals in figuur 2 te zien is kent SABA een duidelijke scheiding tussen wat bij de klant gebeurt en wat bij KPMG gebeurt. Tevens is te zien dat gebruik wordt gemaakt van drie XML-bestanden, die alle drie nodig zijn alvorens een rapport te kunnen genereren.

Het eerste XML-bestand, genaamd ‘controls XML’, bevat de definitie van de feitelijke controles die moeten worden uitgevoerd met de daarbij behorende scriptcommando’s per besturingssysteem en/of applicatie. Dit ‘controls XML’ is dan ook het bestand dat wordt gebruikt voor het maken van het script.

Het tweede XML-bestand dat we zien is genaamd ‘output XML’. Dit bestand bevat de resultaten en de uitvoer van het uitvoeren van de scripts. Hoewel een XML-bestand gewoon platte tekst is, is het niet presenteerbaar als een rapport en daardoor minder bruikbaar mocht het in de verkeerde handen vallen. Alleen de resultaten zitten in dit XML-bestand. De commando’s waar deze resultaten bij horen zijn hierin niet vermeld, wat het voor een luistervink een stuk moeilijker maakt om het bestand te interpreteren.

Het derde XML-bestand, genaamd ‘report XML’, bevat de definitie van de verschillende rapportagetemplates. Hierin staat welke hoofdstukstructuur het rapport kent en welke controles in welke volgorde terugkomen in het rapport.

Alle drie de XML-bestanden zijn nodig om het uiteindelijke rapport te kunnen genereren. Dit genereren van het rapport gebeurt op een webserver in het KPMG-netwerk. Bij het genereren van het rapport kan de auditor de taal van het rapport bepalen en welke rapportagetemplate moet worden gebruikt.

C-2008-4-Smeets-02

Figuur 2. Fasen bij gebruik van SABA.

Voordelen voor auditor en klant

De nieuwe opzet van SABA heeft een aantal voordelen voor zowel auditor als klant. Naast de eisen voor uniformiteit en kennisscheiding die als grote nadelen werden gezien bij de vorige generatie audit tooling, is er nu ook eindelijk grip op de verschillende versies die in omloop zijn. De webserver die het rapport genereert kan controleren welke versie is gebruikt en of deze nog toegestaan is. Tevens is het aantal mogelijkheden voor het genereren van rapporten flink vergroot. Zo kan bijvoorbeeld een aantal systemen in één rapport worden verwerkt.

Voor de klant is het gemakkelijker geworden om de scripts te analyseren alvorens deze uit te voeren omdat deze scripts uniform en duidelijk zijn opgezet. Tevens is het voor de klant fijner om te weten dat de uitvoer van het script niet alle gevoelige data kant-en-klaar presenteert; de rapportgenerator is daar nog voor nodig en deze staat in het KPMG-netwerk.

Als laatste grote voordeel kan het feit worden genoemd dat de ontwikkeling van de scripts (zowel inhoud van checks als uitbreidbaarheid van het aantal besturingssystemen en applicaties) veel gestructureerder kan worden aangepakt. Het SABA-platform is namelijk modulair opgezet. De reacties vanuit technische units uit andere landen zijn volmondig positief, wat veel goeds belooft voor de toekomst.

SABA gebruiken

Voor de klant verandert er weinig als SABA wordt gebruikt in plaats van oude scripts. In essentie is het nog steeds een script dat moet worden uitgevoerd. Het bestand met de uitvoer, in dit geval een XML-bestand, moet nog steeds worden teruggestuurd naar de auditor. In figuur 3 is te zien wat de klant zal zien bij het uitvoeren van de scripts.

C-2008-4-Smeets-03

Figuur 3. Schermafbeelding van succesvol uitvoeren SABA op doelsysteem.

Voor de auditor is er een klein aantal veranderingen in het gebruik van SABA ten opzichte van de oude scripts. Allereerst moet de auditor ervoor zorgen dat hij de laatste versie heeft van de scripts alvorens deze uit te sturen naar de klant. In essentie is dit niet anders dan bij de oude scripts. Echter, in tegenstelling tot bij vorige generaties tooling zijn bij SABA de gevolgen groter als de auditor niet de juiste versie stuurt; oude versies zullen niet worden geaccepteerd door de rapportgenerator waardoor er geen rapport kan worden gemaakt zonder hulp van de ontwikkelaars. De laatste versies van de scripts zijn altijd te vinden op het KPMG-netwerk.

Om een output-XML-bestand van de klant te verwerken hoeft de auditor alleen maar te surfen naar de SABA-rapportgenerator, welke is te vinden op het KPMG-netwerk. In figuur 4 is weergegeven wat de auditor krijgt te zien.

C-2008-4-Smeets-04

Figuur 4. KPMG SABA-rapportgenerator.

De auditor moet hier een aantal keuzes maken: de taal, naar wie het rapport moet worden gemaild (inclusief zoekmogelijkheid), welke output-XML-bestanden in het rapport moeten worden verwerkt (maximum van acht output-XML-bestanden) en ten slotte welke rapportagetemplate moet worden gebruikt. Vervolgens verschijnt het rapport in de e-mailbox van de auditor die is opgegeven als ontvanger.

Toekomst

De basis die met SABA is gelegd, is op dit moment al uiterst effectief voor de auditors. De reacties zijn dan ook erg positief. Maar zoals altijd zijn er punten die nog verder kunnen worden verbeterd. In de toekomst zal SABA dan ook worden verbeterd op een divers aantal punten.

Op dit moment worden de voornaamste besturingssystemen reeds ondersteund: Windows Server 2000 en 2003, HP-UX, Solaris, AIX, SUSE Linux en Red Hat Linux. Naast een uitbreiding naar Windows Server 2008 zal er ondersteuning komen voor een aantal veelgebruikte applicaties zoals webservers en DNS-servers. Voor deze applicaties zal een aantal kritieke instellingen worden gecontroleerd door SABA.

Naast een verbreding in het aantal ondersteunde platformen zal er ook een verdieping komen in de controles die worden uitgevoerd. Dit houdt concreet in dat de basiscontroles die nu door SABA worden uitgevoerd, zullen worden aangevuld met steeds gedetailleerdere controles. Tevens kan voor een aantal basale controles de uitvoer automatisch worden geëvalueerd en in het rapport worden voorzien van een beoordeling.

Om dit alles spoedig te laten verlopen zal SABA beschikbaar worden gesteld voor diverse auditteams in binnen- en buitenland. Tevens zal samenwerking worden gezocht met deze teams om de ontwikkeling gezamenlijk verder op te kunnen pakken.

Samenvatting

SABA is de nieuwe standaard-tooling van KPMG ter ondersteuning van IT-audits waarbij de configuraties van IT-systemen worden onderzocht. Door de uniforme opzet heeft SABA een groot aantal voordelen boven de oude losse scripts, voor zowel auditor als klant. De voornaamste voordelen zijn te vinden op het gebied van tijdwinst, procesoptimalisatie en uniformiteit. De nieuwe opzet van SABA zorgt er namelijk voor dat het gebruik weer voldoet aan de huidige eisen van klant en auditor en dat toekomstige uitbreidingen (zowel in de breedte als in de diepte) geen invloed hebben op de werking van oudere versies.

Literatuur

[Korn07] Ir. P. Kornelisse RE CISA, Jaarrekeningcontrole en technische IT-beveiliging, Compact 2007/3.

Alternate Data Streams

Het NTFS-bestandssysteem dat door Windows gebruikt wordt, biedt de mogelijkheid om meerdere ‘data streams’ op te nemen in één bestand. Dit concept, aangeduid met Alternate Data Streams (ADS), is relatief onbekend en biedt de mogelijkheid om data of kwaadaardige software op het systeem te verbergen zodat die zonder speciale tools haast onmogelijk gedetecteerd kunnen worden. Hackers maken op verschillende manieren dankbaar gebruik van deze feature, bijvoorbeeld om hun tools of malware ongezien op het systeem achter te laten, waardoor ze later eenvoudig op het systeem kunnen terugkeren of door met een keylogger (een vorm van spyware die alle toetsaanslagen registreert) onderschepte gebruikersinvoer (als wachtwoorden en creditcardnummers) in een ADS weg te schrijven, zodat deze onvindbaar is voor de gebruiker zelf en later door de hacker kan worden uitgelezen. In dit artikel wordt beschreven hoe ADS misbruikt kan worden en daarnaast hoe in ADS verborgen bestanden opgespoord en verwijderd kunnen worden.

Inleiding

Vanaf Windows NT maakt Microsoft Windows gebruik van het NTFS (New Technology File System), dat het oude FAT(32) filesysteem vervangt. Eén van de kenmerken van NTFS is de aanwezigheid van Alternate Data Streams. Alternate Data Streams zijn oorspronkelijk opgenomen in alle versies van NTFS om compatibiliteit met Macintosh Hierarchical File System (HFS) te verzorgen. Het Macintosh filesystem maakt gebruik van verschillende zogehete ‘forks’ voor het opslaan van data (voor de inhoud van documenten) en metadata (voor het vastleggen van het bestandstype en andere relevante details over het bestand). ADS wordt tevens door Windows gebruikt om bestandsinformatie als metadata en tijdelijke gegevens op te slaan. De applicatie WordPad gebruikt dit bijvoorbeeld om metadata over een bestand op te slaan.

Karakteristiek voor het gebruik van ADS is dat de gegevens die hierin worden weggeschreven niet in de Windows Verkenner of via bijvoorbeeld een DOS-prompt zichtbaar zijn. Bij het openen van een bestand wordt de hoofdstroom van gegevens geraadpleegd. Eventuele andere aanwezige data streams zijn onzichtbaar. Zo kan er bijvoorbeeld een .zip-bestand van 10 MB in de stream van een tekstbestand van slechts 1 kb worden opgenomen. Windows zal hierna nog steeds de bestandsgrootte van 1 kb weergeven. Deze ‘feature’ biedt hiermee vanuit het perspectief van een hacker interessante mogelijkheden om bijvoorbeeld tools (een zogenaamde ‘rootkit’) op een gecompromitteerd (reeds geïnfiltreerd) systeem te verbergen die gebruikt kunnen worden voor verdere aanvallen. Ook worden ADS gebruikt om virussen en andere malware in te verbergen (bijvoorbeeld W2k.stream, het eerste virus dat gebruikmaakt van ADS om zichzelf in te verbergen). Gelukkig, voor gebruikers van Windows, gaat een stream van een bestand verloren wanneer dit via een browser of FTP wordt binnengehaald. Dit betekent dat streams feitelijk niet gebruikt kunnen worden voor het verspreiden van malware maar slechts om bestanden te verbergen nadat malware het systeem reeds heeft gecompromitteerd.

ADS in de praktijk, een kleine workshop …

Een typisch scenario waarin een hacker gebruikmaakt van een ADS zou er als volgt uit kunnen zien:

Allereerst wordt op een gecompromitteerd systeem een ADS aangemaakt onder een bestaande file of directory, vervolgens wordt hier een executable naartoe geschreven en wordt ervoor gezorgd dat dit bestand automatisch door de gebruiker wordt opgestart bij het opstarten van Windows. Deze stappen worden in de volgende paragrafen in detail beschreven.

Het is mogelijk onderstaande voorbeelden op het eigen systeem uit te proberen. De gebruikte commando’s zijn ter verduidelijking weergegeven in kaders. Vooraf zijn de bestanden calc.exe en notepad.exe uit Windows naar de nieuwe map C:ADS gekopieerd. Tevens wordt gebruikgemaakt van de toolset Unxutils ([Unx]). De in de voorbeelden genoemde commando’s worden alle in een DOS-prompt uitgevoerd, tenzij dit anders aangegeven is.

Het aanmaken van een ADS

Een ADS wordt aangeduid met de naam van het bestand waarin de stream is ondergebracht, een dubbele punt en vervolgens naam van de ADS.

Bijvoorbeeld:

C:ADSbestandsnaam.txt:streamnaam.txt

Hierin is ‘bestandsnaam.txt‘ de naam van het ‘gastheer’bestand en ‘streamnaam.txt‘ de naam van de ADS. Het gastheerbestand kan een bestaand of een nieuw bestand zijn. Door het volgende commando in een DOS-prompt uit te voeren wordt een nieuw bestand testfile.txt aangemaakt:

echo Dit is een testfile > testfile.txt [ENTER]

Zoals door middel van een ‘dir‘-commando kan worden vastgesteld, heeft het nieuwe tekstbestand testfile.txt een bestandsgrootte van 22 bytes. (zie figuur 1). Dit bestand bevat de tekst ‘Dit is een testfile’ en kan via het DOS-commando ‘type testfile.txt‘ worden uitgelezen.

C-2008-4-Paques-01

Figuur 1. Het aanmaken van een tekstfile van 22 bytes.

Met het volgende commando wordt tekst toegevoegd aan de ADS van het bestand testfile.txt:

echo secret information > testfile.txt:datastream.txt [ENTER]

De tekst ‘secret information‘ is hiermee toegevoegd aan de ADS met de naam ‘datastream.txt‘. Merk op dat de bestandsgrootte (zie figuur 2) van het bestand testfile.txt gelijk is gebleven; deze is nog steeds 22 bytes (de tijd is echter wel veranderd). Het toevoegen van een ADS aan een bestand verandert niets aan de werking of inhoud van het oorspronkelijke bestand.

C-2008-4-Paques-02

Figuur 2. Het schrijven van data naar een ADS.

Een .jpg-bestand (plaatje) kan worden toegevoegd aan een stream met het volgende commando:

type c:windowsGreenstone.bmp > testfile.txt:Greenstone.bmp [ENTER]

Om vast te stellen of het plaatje daadwerkelijk in de stream is opgenomen, kan de stream worden geopend met het volgende commando:

mspaint testfile.txt:Greenstone.bmp [ENTER]

Gegevens benaderen in een ADS

Wanneer getracht wordt de data in de ADS te benaderen via het commando ‘type testfile.txt:datastream.txt‘, wordt een foutmelding getoond. Ditzelfde gebeurt indien via het ‘Open‘-commando in Notepad wordt geprobeerd de stream te wijzigen. Een stream kan aangepast worden door Notepad via de command-prompt aan te roepen:

notepad testfile.txt:datastream.txt [ENTER]

Nu wordt Notepad gestart en de inhoud van de ADS getoond. Wanneer er nu aanvullende tekst wordt toegevoegd aan de ADS zal de bestandsgrootte van het bestand ‘testfile.txt‘ zoals dat door Windows wordt weergegeven, niet gewijzigd zijn.

In principe kan elk type file in een ADS worden opgeslagen. In plaats van gewone tekst kan ook uitvoerbare code of een geheel programma in een ADS geplaatst worden. Zo’n programma is dan voor de gebruiker van het systeem onzichtbaar aanwezig. Een ADS kan niet alleen aan files worden toegevoegd, maar ook aan directories, bijvoorbeeld door de onderstaande commando’s uit te voeren:

mkdir ads2dir [ENTER]

type calc.exe > c:adsads2dir:calctest.exe [ENTER]

Met deze commando’s is een nieuwe directory ‘ads2dir‘ aangemaakt. Het tweede commando zorgt ervoor dat een kopie van het programma Calculator gekopieerd wordt naar de ADS ‘calctest.exe‘ van deze directory.

Indien nu in de Windows-verkenner de eigenschappen van de folder ‘C:ADS‘ worden opgevraagd, zal de Verkenner aangeven dat de folder 0 bytes groot is. De ADS van de folder bevat echter het bestand ‘calc.exe‘. De hoeveelheid data die in een ADS opgeslagen kan worden, is bijzonder groot. Tevens kan een oneindig aantal streams aan een bestand worden toegevoegd.

Het verborgen ‘calctest.exe‘-bestand kan worden uitgevoerd met het onderstaande commando. Merk op dat het volledige directory path gebruikt wordt om de locatie van het bestand aan te geven.

start c:adsads2dir:calctest.exe [ENTER]

Met dit commando wordt de Windows-rekenmachine vanuit de ADS gestart. (Dit werkt niet voor Windows Vista, daar Vista het opstarten van applicaties in streams via het ‘start’-commando niet ondersteunt.) In Windows 2000 en eerdere versies van Windows wordt een ADS-executable in proces viewers zoals Windows Task Manager weergegeven als het gastheerbestand waar deze aan gekoppeld is. Zouden we dus ‘calc.exe‘ opnemen in een ADS van ‘explorer.exe’ en vervolgens ‘calc.exe‘ uitvoeren, dan wordt ‘explorer.exe‘ in deze Windows-versies als actief proces aangegeven. Dit betekent dat naast de aanwezigheid van de file ook het uitvoeren hiervan verborgen plaatsvindt. In Windows XP is een programma dat actief is in ADS, wel in taakbeheer zichtbaar, zoals te zien is in figuur 3.

C-2008-4-Paques-03

Figuur 3. Taakbeheer in Windows XP.

Met de tool ‘cat’ (onderdeel van de toolset UnxUtils) kan een programma uit een ADS terug naar een normale file (hier ‘calcnew.exe‘) worden geschreven.

Cat c:adsads2dir:calctest.exe > calcnew.exe [ENTER]

Het bestand ‘calcnew.exe‘ bevat nu de calculator die we aan de directory hadden gekoppeld.

Misbruik maken van ADS

Zoals eerder opgemerkt kan praktisch elk type bestand in een ADS worden opgenomen. Een typisch scenario waar een virus (of ander type malware) gebruik van maakt, ziet er als volgt uit:

Scenario 1

Een hacker vervangt de originele executable met de viruscode, hernoemt het virus naar de oorspronkelijke bestandsnaam en voegt vervolgens de oorspronkelijke executable toe in de ADS. Wanneer de gebruiker het executable-bestand uitvoert wordt de viruscode gestart en start het virus vervolgens het oorspronkelijke programma dat zich in de ADS bevindt (figuur 4).

C-2008-4-Paques-04

Figuur 4. Infectie van een bestaand programma met malware.

Scenario 2

In een ander scenario wordt de viruscode zelf in de ADS verborgen. De viruscode kan nu automatisch worden uitgevoerd via bijvoorbeeld het Windows-register tijdens het opstarten van Windows of door in de oorspronkelijke executable een beperkt stuk code toe te voegen dat het virus in de ADS aanroept. Voordeel van deze aanpak is dat de bestandsgrootte van de oorspronkelijke file (nauwelijks) verandert, wat de kans op detectie verkleint.

Het volgende voorbeeld illustreert hoe een bestand in een ADS automatisch kan worden opgestart.

Let op: De volgende commando’s brengen wijzigingen aan in het register. Het is aan te raden om voor het uitvoeren van deze commando’s een back-up van het Windows-register te maken. (Voor het uitvoeren van registerwijzigingen zijn beheerdersrechten op het systeem nodig.)

reg delete HKCRtxtfileshellopencommand /f [ENTER]

reg add HKCRtxtfileshellopencommand /ve /t REG_EXPAND_SZ /d c:adsads2dir:calctest.exe /f [ENTER]

Wanneer nu een willekeurige tekstfile wordt geopend zal Windows de rekenmachine (uit de ADS) in plaats van Notepad starten. Uiteraard kunnen deze commando’s ook in een batchbestand, VB-script of andere programmeertaal worden opgenomen (om door een nietsvermoedende gebruiker te worden uitgevoerd). In dit voorbeeld wordt het onschuldige programma calculator gestart. Op dezelfde wijze kan met slechts twee regels code elke keer dat er een tekstfile wordt geopend onmerkbaar elk mogelijk bestand worden gestart.

Het register kan worden hersteld met het volgende commando:

reg add HKCRtxtfileshellopencommand /ve /t REG_EXPAND_SZ /d “%SystemRoot%system32notepad.exe %1” /f [ENTER]

Andere manieren waarop een executable in een ADS kan worden gestart, zijn onder meer:

het automatisch laten starten met Windows;
via de task scheduler;
door toevoeging aan de Windows-startup folder;
door het toevoegen van instructies in de winstart.bat file in de Windows-map;
door het plaatsen van een file explorer.exe in de map c:. Doordat de map : eerder in het zoekpad van Windows voorkomt zal indien hier een bestand explorer.exe staat, dit automatisch door Windows worden uitgevoerd in plaats van het oorspronkelijke bestand in de map c:windows.

Detecteren en verwijderen van Alternate Data Streams

Gezien de eenvoud waarmee bestanden in een stream verborgen worden is het aan te raden om kritische systemen periodiek te controleren op de aanwezigheid van deze streams. Deze controle zou bijvoorbeeld deel kunnen uitmaken van een periodieke technische audit op security-instellingen.

In Windows Vista is het ‘dir’-commando voorzien van een nieuwe optie (/r) waarmee files met verborgen streams getoond worden. Voor eerdere Windows-versies zijn er verschillende gratis tools voor het detecteren van ADS beschikbaar als ‘lads‘ ([Lad]), ‘lns‘ ([Lns]), ‘streams‘ ([Mic]) en ‘adsspy‘ ([Ads]).

Een typische output van de tool ‘lads‘ is opgenomen in figuur 5. Hier is te zien dat zowel de naam van de ADS als de afmeting van deze ADS zichtbaar kan worden gemaakt.

Voor diegenen die de voorkeur geven aan een grafische interface biedt de Tool ‘Adsspy‘ (figuur 6) uitkomst.

C-2008-4-Paques-05

Figuur 5. Het opsporen van een ADS met lads.

C-2008-4-Paques-06

Figuur 6. ADS spy: een grafische tool om ADS op te sporen.

Wanneer het bestand of de directory waaraan een ADS is gekoppeld wordt verwijderd, wordt daarmee ook de ADS verwijderd. Ook kunnen de tools ‘streams‘ en ‘ADS spy‘ worden gebruikt om de ADS uit de file te verwijderen.

Een andere wijze om de ADS te verwijderen is door de file waaraan deze is gekoppeld naar een bestandssysteem dat geen ADS ondersteunt (bijvoorbeeld FAT32) te verplaatsen en weer terug.

Een derde mogelijkheid voor het verwijderen van een ADS is om de inhoud van het oorspronkelijke bestand naar een nieuw bestand te schrijven en het nieuwe bestand te hernoemen naar de oorspronkelijke bestandsnaam. Bijvoorbeeld:

type notepad.exe>tempfile.exe [ENTER]

del notepad.exe [ENTER]

ren tempfile.exe notepad.exe [ENTER]

Aanvullend op het controleren op de aanwezigheid van een ADS op het filesysteem met bovenstaande tools kunnen we alle programma’s die automatisch met Windows worden gestart, nalopen op verdachte patronen. Een ‘:’ in het path wijst mogelijk op de aanwezigheid van een verborgen ADS.

Conclusie

De ADS-feature van NTFS geeft de mogelijkheid om files op te slaan op een manier onzichtbaar voor Windows en standaard file handling applicaties. Een hacker kan misbruik van deze eigenschap maken door virussen of malware in een ADS te verbergen. Met ADS kan data in bestaande files worden toegevoegd zonder hun afmeting of werking te beïnvloeden. Er kan een grote hoeveelheid data in een ADS worden opgenomen (ideaal voor keyloggers). Hiernaast zijn ADS eenvoudig te maken en bijzonder lastig te detecteren zonder het gebruik van speciale tools. Files in een ADS kunnen worden aangeroepen op allerlei verschillende manieren waaronder het gebruik van batch files of via het Windows-register. Met deze combinatie van eigenschappen kan ADS een serieuze bedreiging vormen voor de beveiliging van een systeem. Het is dan ook aan te raden om kritische systemen periodiek te controleren op de aanwezigheid van alternate data streams. Deze controle zou bijvoorbeeld deel kunnen uitmaken van een periodieke technische audit op security-instellingen.