Inleiding

Voor een achtergrondonderzoek kun je kostbare recherchebureaus inhuren en ik raad je aan dat te doen als je dat nodig acht. Voor onderzoeken naar de betrouwbaarheid van de kandidaten in een sollicitatieprocedure kun je (als je geen ruim budget hebt) heel veel informatie zelf verzamelen of toetsen.

Voorwaarden

Voordat je een antecedentenonderzoek begint heb je de kandidaat expliciet toestemming gevraagd om dit onderzoek te mogen uitvoeren, of je hebt aan het begin van de procedure bekend gemaakt dat dit onderzoek deel uitmaakt van de sollicitatieprocedure. Dit maakt deel uit van de NVP sollicitatiecode.[1]

Een achtergrondonderzoek is een ander onderzoek dan een assessment waarbij wordt bekeken of iemand in een team past of voldoende (kennis)niveau heeft om een functie te kunnen vervullen. Bij een antecedentenonderzoek probeer je een beeld te vormen van de integriteit van de kandidaat om problemen in de toekomst te voorkomen. Uiteraard zul je zo’n onderzoek met de nodige zorgvuldigheid moeten uitvoeren, omdat er anders claims over discriminatie op je af kunnen komen.

Antecedentenonderzoeken voer je uit om te weten wat voor mensen je in huis haalt. Een achtergrondonderzoek hoef je niet voor alle sollicitanten uit te voeren. Je kunt je waarschijnlijk wel beperken tot de vertrouwensfuncties (systeem- en netwerkbeheer, medewerkers veiligheid en medewerkers HR), voorbeeldfuncties (management) en financiële functies (inkopers, controllers, medewerkers financiële administratie). Uitzonderingen op en toevoegingen aan dit rijtje zijn natuurlijk altijd mogelijk, maar geef jezelf er goed rekenschap van op welke gronden je besluit iemand uit dit rijtje niet aan een antecedentenonderzoek te onderwerpen.

Uitvoering

Deze onderzoeken kun je beginnen met het gebruik van zoekmachines en open bronnen (google, facebook, twitter, hyves, linkedin, e.d.). De kandidaat zal je eveneens aanknopingspunten geven voor een onderzoek, bijvoorbeeld zijn cv en andere door hemzelf aangeleverde informatie. Tot slot kun je gebruik maken van besloten bronnen, bijvoorbeeld door een recherchebureau in te huren.

Het doel van het onderzoek zou het valideren moeten zijn van de door de kandidaat aangeleverde informatie. Dat kun je doen door in het algemeen netjes en correct te handelen en bijvoorbeeld hoor en wederhoor toe te passen. In de praktijk is dat niet altijd even eenvoudig.

Een nadeel van het gebruik van social media als bron voor een antecedentenonderzoek is dat je veel meer informatie vindt dan wenselijk is in een sollicitatieprocedure. Omdat je toegang hebt tot de privésfeer van een persoon kun je kennis opdoen over de gezondheid, het seksuele leven en de geloofsovertuiging van een persoon. In relatie tot de functie waarop de kandidaat solliciteert kan het hebben van deze kennis ongewenst zijn. Een manier om dit dilemma te omzeilen is de volgende.

Laat de sollicitant een vragenformulier zo volledig mogelijk invullen (benadruk het belang van de volledigheid) en toets deze informatie. Gegevens die kunnen worden gevraagd zijn:

• Ex-werkgevers de afgelopen 7 tot 10 jaar
• Alle woonadressen de afgelopen 10 jaar
• Eventuele veroordelingen en andere relevante informatie
• Geboortedatum
• Scholen en gevolgde opleidingen
• Behaalde diploma’s
• Laat de sollicitant het ingevulde formulier “naar waarheid en volledigheid” ondertekenen en expliciet akkoord gaan met een nader onderzoek

Stel een onderzoeker aan met de opdracht de geleverde informatie te valideren. Geef deze onderzoeker de opdracht mee om expliciet te kijken naar een aantal punten die negatief zouden zijn als zij worden aangetroffen (overmatig drankgebruik voor een voorbeeld functie, blijk geven van gokschulden of (online) pokerspeler op toernooien bij een financiële functie, en dergelijke) en geef eveneens een aantal pluspunten op waarnaar gezocht moet worden. Geef daarnaast aan welke informatie niet in het rapport mag worden opgenomen als deze wordt aangetroffen tijdens het onderzoek (eventuele ziektegeschiedenis, afkomst  en dergelijke, informatie die niet relevant is voor het goed vervullen van de functie). Laat de onderzoeker de informatie van het formulier controleren bij de opgegeven referenties (zelf de contactgegevens opzoeken) en zeker stellen dat er geen sprake is van een persoonsverwisseling.

Conclusie

Het doel van het onderzoek is zekerheid te verkrijgen over de waarachtigheid van het cv van de kandidaat, niet om te roeren in het privé leven van iemand anders. Uiteindelijk zal het rapport van de onderzoeker een bevestiging van aangetroffen positieve en/of negatieve punten bevatten, samen met een conclusie over de juistheid en volledigheid van de in het cv aangeleverde informatie. Laat de kandidaat de resultaten van het onderzoek zien en vraag eventueel om opheldering van onbegrepen zaken.

Tot slot

Blijf altijd correct en ga er vanuit dat de sollicitant te goeder trouw is. Het zou jammer zijn als een geschikte kandidaat zicht terugtrekt door een negatief gevoel als gevolg van een onhandig uitgevoerd achtergrondonderzoek.

Een doorsnede van de verhalen van leveranciers afgezet tegen de praktijk van een informatiebeveiliger.

Redenen om aan DLP te doen.

Er zijn verschillende redenen om maatregelen met betrekking tot DLP te treffen, maar die hangen af  van een aantal factoren. Als je organisatie aan de beurs genoteerd is heb je te maken met specifieke regelgeving. Afhankelijk van de aard van je bedrijf heb je mogelijk bedrijfsgeheimen die je liever voor jezelf houdt. Daarnaast heb je als organisatie een bepaalde verantwoordelijkheid tegenover je klanten, je aandeelhouders en je personeel. Een mooi woord daarvoor is ‘due diligence’, goed ondernemerschap.

Dataverlies

Een organisatie kan gegevens op veel verschillende manieren verliezen. Bij de meeste daarvan merk je het op zijn best als het al te laat is. Gegevens lekken op allerlei manieren uit je bedrijfsomgeving, door pc’s, laptops en werkstations uit het bedrijfsnetwerk die zijn besmet met kwaadaardige software.

Datadragers, zoals USB apparaten, mobiele apparaten (pda’s, telefoons, tablet pc’s, etc.), CD/DVD roms, backuptapes, oude en af te voeren hardware of papier kunnen allen vertrouwelijke informatie bevatten die niet buiten de organisatie bekend mag worden.

Je business partners (software ontwikkelaars, ondersteuners, onderaannemers) kunnen je gegevens kwijtraken, bijvoorbeeld door ontevreden werknemers in hun organisatie.

Je eigen medewerkers kunnen bedrijfsgeheimen op straat leggen door (te) veel informatie te delen via social media (Facebook, Hyves, LinkedIn, Twitter, Yammer, BrightIdea, etc.). Data die onbeschermd verstuurd wordt via Internet of traditionele post kan worden onderschept en in verkeerde handen komen.

Cloud computing providers (ASP en SAAS providers) kunnen configuratie fouten maken in hun software, te laat zijn met het doorvoeren van security updates, backup en restore procedures slecht uitvoeren waardoor je gegevens verloren kunnen gaan, zelf onvoldoende uitwijkmogelijkheden hebben waardoor bij een brand jouw gegevens verloren gaan, gegevens niet goed verwijderen van defecte hardware of failliet gaan waardoor je niet meer bij je gegevens kunt.

Tot slot loop je het risico dat informatie bij onbekende derden terecht komt als je werken op afstand (telewerken, het nieuwe werken) toestaat. Al met al genoeg mogelijkheden om als organisatie dataverlies te lijden. Gelukkig is voor een groot deel van deze bedreigingen tegenmaatregelen bedenken.

Tegenmaatregelen

De meeste maatregelen kun je eenvoudig zelf bedenken. Over het algemeen komt het er op neer dat je wat sterker gaat controleren op de naleving van de maatregelen die je al hebt. Een mooi woord hiervoor is governance. Denk daarbij aan het gecontroleerd uitvoeren van changes op de firewall, alle laptops voorzien van een volledig versleutelde harde schijf , beperking van de rechten tot het versturen van gegevens, (betere) afspraken met leveranciers, et cetera.

Om een echte stap voorwaarts te maken en de kans aanzienlijk te verkleinen dat geclassificeerde gegevens de bedrijfsomgeving verlaten, zul je je aandacht moeten richten op de gebruikers. Maak duidelijk welke belangen zij en de organisatie hebben om voorzichtig met vertrouwelijke informatie om te gaan. Geef aan wat de mogelijkheden zijn, welke gereedschappen hiervoor gebruikt kunnen worden en welke consequenties er zijn verbonden aan het niet nakomen van de afspraken. Train je personeel regelmatig in het gebruik van de middelen. Een voorbeeld hiervan is het opstellen van een bedrijfspolicy hoe om te gaan met social media (Facebook, LinkedIn, Hyves, Twitter en dergelijke).  Maak duidelijk dat de organisatie achter het gebruik op de juiste wijze staat.  Bied informatie en advies hoe om te gaan met social media in relatie met het werk.

Zorg voor tools waarmee data kan worden versleuteld voordat deze wordt verzonden. Regel in de ICT infrastructuur het logmanagement grondig in. Log niet alleen de noodzakelijke handelingen, maar controleer de logging op ongewenste activiteiten en neem zonodig gepaste maatregelen. Filter email- en internetverkeer (geautomatiseerd) op inhoud, bijvoorbeeld het gebruik van tevoren vastgestelde termen of zinsneden.

Maatregelen in de praktijk

Ga na of de tegenmaatregelen in verhouding zijn met de (bedrijfs)risico’s. Schaf eventueel een integrale DLP oplossing aan. Een dergelijk pakket software is aan te sluiten op de ICT infrastructuur en dekt de technische maatregelen af. Houd in het achterhoofd dat de menselijke factor met deze oplossing niet wordt meegenomen.

Maatregelen ter verhoging van het gebruikersbewustzijn bestaan uit trainingen en voorlichting over de genomen (zichtbare) maatregelen. Bied de gebruikers gereedschappen zoals winzip of winrar om beveiligde bestanden te kunnen maken.

Pas de contracten aan voor de afvoer van hardware en archiefvernietiging. Stel eisen inzake DLP aan cloud service providers en application service providers (SAAS / ASP).

Aandachtspunten

Als organisatie moet je niet de illusie hebben dat je hiermee verlies van gegevens totaal kunt voorkomen. Het achterlaten van een tas of koffer met dossiers in de trein sluit je niet uit.

Je kunt wel je gebruikers trainen en zorgen dat zij op een bewuste wijze met de bescherming van bedrijfsgegevens omgaan. Mocht zich een incident voordoen dan kan niemand zich beroepen op zijn onwetendheid.

In dit overzicht staan de verschillende aandachtspunten rond Cloud Computing gegroepeerd rond het thema risico’s en risicoreductie. Doel van het overzicht is helderheid te verschaffen over de punten waar een organisatie aan moet denken als die structureel gebruik gaat maken van Cloud Computing.

Bronnen

Bronnen voor dit overzicht zijn onder meer informatie uit documentatie van ENISA, Berkely University en de Cloud Security Alliance.

Cloud Computing

In dit overzicht gebruik ik de volgende definitie van Cloud Computing.

De Cloud scheidt applicatie en informatiebronnen van de onderliggende structuur en de mechanismen om ze te leveren. Deze definitie beperkt zich hier tot Software as a Service (SaaS). Andere XaaS Cloud Computing vormen zijn hiermee uitgesloten van de beschouwingen in dit overzicht.

De overgang naar Cloud Computing gaat gepaard met emotie. Een organisatie geeft zijn data ‘weg’ aan een externe partij en wat overblijft is een gevoel van verlies van controle. Control wil zeggen dat er deugdelijke controles aanwezig zijn en dat hun effectiviteit bewezen is. De rationele component bij een overgang naar Cloud Computing regelt dat er contracten zijn met mantelovereenkomsten en SLA’s, dat de beveiliging ingebouwd is en dat verantwoordelijkheden worden overgedragen.

Business belangen

Cloud Computing komt niet uit de lucht vallen en het is geen IT speeltje maar de business belangen spelen een grote rol. Toch moet goed worden beoordeeld in hoeverre de business belangen niet worden belemmerd door de overgang naar de Cloud. Dat kan door de verschillende bedrijfsprocessen en de daarmee gepaard gaande informatie te beoordelen op geschiktheid voor Cloud Computing. Ruwweg zijn er drie vormen mogelijk: geschikt, na aanpassing geschikt en ongeschikt. Verder zijn er verschillende vormen van Cloud Computing mogelijk tussen de beide uitersten Private Cloud en Public Cloud, denk hierbij aan Private Cloud (intern of on site), Private Cloud (extern, inclusief dedicated of gedeelde infrastructuur), Hybride omgevingen, Community en Public Cloud. De organisatie moet eerst per bedrijfsproces of -applicatie bepalen of dit geschikt is voor de Cloud. Daarna volgt de vaststelling welk type Cloud het meest geschikt is.

Voor het bepalen in hoeverre een bedrijfsproces of –applicatie geschikt is voor de Cloud, is de beantwoording van de volgende vragen essentieel.

Per soort informatie of dienst die naar de Cloud gaat moet men zich afvragen of de organisatie schade kan oplopen:

●        Als de informatie publiekelijk bekend wordt en/of overal beschikbaar is;

●        een medewerker van de Cloud provider toegang heeft tot deze informatie of dienst;

●        het proces of de functionaliteit wordt gemanipuleerd door een (onbekende) derde;

●        het proces of de functionaliteit er niet in slaagt de verwachte resultaten te leveren;

●        de informatie of gegevens onverwacht veranderen;

●        de informatie of dienst voor een (on)bepaalde tijd niet beschikbaar is.

Met het doorlopen van deze stappen krijgt een organisatie een beeld van de risico’s die zij kan of wil lopen bij een migratie naar de Cloud. Daarbij is het van belang om een goed beeld te hebben van de positie van de markt en de spelers in de markt, kennis te hebben van de veranderingen die er zich afspelen, zoals overnames en faillisementen en eventuele aanbiedingen af te zetten tegen de marktwaarde op de lange termijn.

Risicoafwegingen

Bij het afwegen van de mogelijkheden en de risico’s mag men niet uit het oog verliezen dat de gemiddelde Cloud provider de zaken beter en professioneler voor elkaar heeft dan het gemiddelde private datacenter. Hier speelt het schaalgrootte voordeel een belangrijke rol. Wel is van belang dat een organisatie zich realiseert dat in een externe omgeving als de Cloud de ‘oude problemen’ dezelfde rol spelen als bij een eigen datacenter. Zoals beheerders met administrator rechten die ook in de Cloud een gevaar blijven voor je gegevens, applicatie management en het ontwikkelen van (on)veilige applicaties blijft een groot risico vormen, kwaadaardige insiders, het kapen van accounts, services en dataverkeer.

Dit kan omdat er in de Cloud de basisverzameling met afspraken en maatregelen nog niet volledig is ontwikkeld. Dat heeft tot gevolg dat auditing moeilijk tot onmogelijk is door de relatieve onvolwassenheid van de publieke Cloudomgeving. De meeste kwetsbaarheden manifesteren zich als gevolg van gedeelde techologie (Multi tenancy), wat leidt tot dataverlies of –lekkage. Als gevolg van de relatieve onvolwassenheid van de sector is dit nog zelden goed geregeld.

Uitgangspunten voor acceptabele risico´s

Om in control te zijn en te blijven bij het gebruik van Cloud computing formuleer ik wat uitgangspunten waarmee een organisatie handvatten heeft als die in gesprek gaat met een Cloud provider.

●        Bescherm data in de Cloud op dezelfde wijze als data in handen van de rechtmatige eigenaar.

●        Houd bij contracten rekening met (onverwachte) beëindiging van de overeenkomst. Regel de correcte teruggave of vernietiging van de informatie.

●        Weet waar de data fysiek gehuisvest is of staat. Dit is trouwens een vereiste inzake persoonsgegevens (Wbp). Alleen zo kun je naleving van relevante wet- en regelgeving borgen, ook als gegevens nationale grenzen overschrijden.

●        Maak afspraken over Recovery Time Objective en verzeker je ervan dat de plannen zodanig zijn dat de leverancier aan de eisen kan voldoen.

●        Controleer bij Amerikaanse dienstverleners of zij daadwerkelijk op de Safe Harbor lijst staan vermeld.

Operationele uitwerking

Natuurlijk kun je alles in contracten dichtregelen, maar uiteindelijk gaat het om de uitwerking ervan in de praktijk. In de SLA´s en operationele afspraken moet een organisatie daarom tenminste de volgende aandachtspunten benoemen:

●        Hoe is het patchmanagement bij de Cloud provider geregeld?

●        Wat zijn de gegarandeerde uptime en response tijden?

●        Waaruit bestaat de backup policy?

●        Hoe snel kan de Cloud provider herstellen na een catastrofe met totaal dataverlies?

●        Kun je oude backups terug laten zetten? Tot hoever terug?

●        Tot hoever terug worden gemaakte snapshots bewaard en met welke frequentie worden zij gemaakt?

●        Wat is het beleid voor data retentie?

●        Blijft jouw data op hun backupmedia  staan na het beëindigen van de overeenkomst?

●        Wat gebeurt er met de virtuele machines op de schijven bij de Cloud provider als ze niet meer nodig zijn (een voordeel van Cloud Computing is de eenvoud van op- en afschalen)? Wordt de schijf daadwerkelijk volledig gewist volgens dezelfde procedures als in het eigen rekencentrum?

●        Welk toegangsbeleid hanteert de Cloud provider, zowel voor wachtwoorden als voor sleutels?

●        Welk personeel van de Cloud provider heeft uitgebreide rechten en kan daarmee toegang krijgen tot je applicaties en data?

●        Welk governancebeleid hanteren zij hiervoor?

●        Garandeert de provider nog steeds ondersteuning bij of na onderzoek na incidenten of bij herstel van data?

Een goede manier om een zekere mate van volledigheid te krijgen (in het licht van de beschikbare raamwerken) is het gebruik van de Cloud Security Alliance (CSA) Controls Matrix. Deze matrix is gebaseerd op de gangbare raamwerken zoals Cobit, COSO, ISO27001/2, PCI-DSS en verwijst naar de relevante paragrafen uit deze raamwerken.

Tot slot

De Verenigde Staten hebben geen integrale privacy wetgeving, maar de EU stelt dat bedrijven die zich conformeren aan de Safe Harbor Act passende beveiliging bieden.

Weliswaar kan op basis van de Patriot Act toegang tot de data worden verkregen. De keren dat dit gebeurt is sinds 11 september 2001 zijn te overzien. Uit de cijfers die bekend zijn van de Nederlandse autoriteiten blijkt dat Nederland de grootste opvrager is van verkeersgegevens in Europa en daarmee de privacy veelvuldig schendt.

Veel van de punten die ik heb aangestipt zijn in te regelen met goede afspraken met de Cloud provider. Neem bijvoorbeeld in het contract op dat de provider jou terstond moet informeren dat er van overheidswege een inbreuk is gedaan op de vertrouwelijkheid van jouw gegevens. Tref maatregelen zoals Hot Backup en het toepassen van Open Cloud/Open Standaarden om het continuïteitsrisico bij exit of insolventie van de leverancier te beperken. In ieder geval verminder je hiermee de dataportabiliteits issues en bevorder je de interoperabiliteit.

Bezint eer gij begint

Naar verwachting zal Internet ´vol´ zijn in 2014. De gebruikte bandbreedte kan nog ongeveer drie maal verdubbelen, terwijl de groei 40% per jaar is. Dit wil niet zeggen dat Internet in 2014 stil staat, maar wel dat bandbreedte een schaars goed zal worden en dat de kosten zullen stijgen.

De continuïteit van Cloud providers is niet gegarandeerd, de markt is nog volop in beweging.

Standaarden voor beveiliging bestaan nog niet voor de Cloud en de bestaande standaards voldoen niet.

Het doel van een autorisatiematrix moet zijn inzicht te krijgen (en te houden) in de rollen die een medewerker heeft. Dit doe je bijvoorbeeld om mogelijke frauduleuze handelingen te voorkomen. Iemand zowel de rechten geven op het accorderen als het betalen van facturen vertoont grote gelijkenis met het verhaal van de vastgebonden kat op het spek.

In grotere organisaties geldt dat het moeilijk is om overzicht te houden over het aantal en de soort uitgegeven rechten. Door rechten aan rollen te koppelen knip je het probleem al in kleine stukken. Medewerkers kunnen een of meer rollen vervullen en hebben daardoor automatisch rechten. In de autorisatiematrix zorg je ervoor dat rollen geen conflicterende rechten hebben en dat rollen zelf niet met elkaar in conflict mogen zijn. Je houdt de autorisatiematrix alleen in stand als je er een goed beheerproces omheen bouwt.

Medewerkers veranderen van functie binnen een bedrijf, maar het komt zelden voor dat de rechten (autorisaties) van deze medewerkers worden aangepast. Een andere veel voorkomende bron van vervuiling is dat een nieuwe medewerker een kopie van het profiel van zijn voorganger krijgt. Zeker als deze voorganger een rijke historie binnen het bedrijf heeft, zal de nieuwe medewerker veel extra rechten krijgen die hij niet nodig heeft voor het uitvoeren van zijn functie.

De meest zekere methode om te voorkomen dat een medewerker teveel rechten heeft is om zijn rechten af te nemen als hij een nieuwe functie gaat vervullen. Daarna kunnen hem de rechten worden toegekend die bij zijn nieuwe functie horen.

Als je dit verder uitwerkt ben je al aardig op weg in de richting van een RBAC (Role Based Access Control) traject.

Toen de SIOD begon met het inrichten van een organisatie en het opstellen van een onderzoeksmethode om uitkeringsfraude te herkennen hebben zij het CBP hierbij betrokken. Dit wekt de indruk dat de onderzoeksmethode de initiële goedkeuring heeft van het CBP.

Het CBP heeft de uitgangpunten in de documenten van de SIOD getoetst. Daarnaast heeft het CBP een of meer huisbezoeken afgelegd en medewerkers op verschillende locaties geïnterviewd. Het conceptrapport met de bevindingen is gedeeld met het ministerie van SZW en op basis van (toelichtende) antwoorden is de definitieve versie vastgesteld. Dit lijkt mij een correcte wijze van onderzoeken, waarbij ik er gemakshalve van uit ga dat het CBP zich netjes heeft gemeld bij de SIOD met een verzoek om interviews af te mogen nemen en niet in het geniep heeft gehandeld.

Bij het lezen van het rapport vroeg ik mij meteen af wat de aanleiding is geweest voor het onderzoek. Zelfs als dit is afgesproken in het voorgaande traject, dan zou je hier nog steeds een verwijzing naar deze afspraak verwachten.

De onderzoekers zijn diep in de door de SIOD toegepaste werkwijze gedoken. Wat ik niet aantrof is een beoordeling van de mate waarin het geoorloofd is dat bestanden (van uitkeringsgerechtigden, waterverbruik en kadastergegevens) worden gekoppeld. Tevens blijkt nergens dat er toestemming is van de in deze registraties opgenomen personen, of dat zij over de koppeling geïnformeerd zijn. In het rapport staat wel een bevinding dat men over de koppeling voor het SIOD onderzoek geïnformeerd had moeten worden. Mijn punt gaat echter over de bronbestanden, vóór de koppeling. Daar heeft het CBP een kans laten liggen.

Een andere vraag waar het CBP niet over schrijft heeft betrekking op de doelbinding, proportionaliteit en subsidiariteit. Is de schending van de privacy wel voldoende beperkt en waren er geen lichtere middelen mogelijk om kennelijke frauduleuze praktijken in beeld te brengen? Zelfs als dit in orde is dan nog was het een goed punt geweest van de onderzoekers van het CBP om dit mee te nemen in de rapportage.

Ik zie nieuwe mogelijkheden (en risico’s, afhankelijk van je standpunt) voor de “slimme” elektriciteitsmeters die op afstand kunnen worden uitgelezen. Wie zegt dat big brother SIOD niet meeleest?

Enkele bedrijven hebben deze maatregel ingevoerd, waarbij je als gebruiker voor of na het inloggen akkoord moet gaan met de gedragscode op het netwerk. Dit is de digitale variant van het bordje “Verboden toegang, art. 461 W.v.Sr.”. Dat is tevens de zwakte van het systeem. Als je als organisatie hieraan begint, dan dien je er wel voor te zorgen dat je op alle digitale toegangen een dergelijk bordje zet. Anders kan iemand die zich toegang heeft verschaft via een onbekend kanaal stellen dat hij niet wist dat het niet mocht, er hing immers geen bordje.

Door aan gebruikerszijde deze melding te plaatsen laat je de gebruikers een of twee extra handelingen verrichten voordat zij op het netwerk zijn. Dit wordt al snel een routine, zonder dat de tekst wordt gelezen of begrepen. Dat komt het beveiligingsbewustzijn niet ten goede en is een verkeerde manier van toepassen van het informatiebeveiligingsbeleid.

Verder kun je je afvragen wanneer je de melding moet tonen, voor of na het inloggen. Voor het inloggen zou betekenen dat een gebruiker nog kan weigeren. Maar hij heeft een overeenkomst of opdracht, waarin al de zaken met betrekking tot beveiliging zijn geregeld. Niet accorderen is geen optie en de maatregel voegt niets toe. Na het inloggen tonen heeft evenmin een toegevoegde waarde, men is immers – logisch gezien – al binnen. Dat is het hetzelfde als een portier binnenzetten om ongewenste gasten buiten te houden.

Organisaties die iets met een akkoord verklaring willen doen kunnen dat beter regelen met algemene voorwaarden voor het gebruik van IT middelen. Door die jaarlijks te ondertekenen, bijvoorbeeld tijdens integriteitssessies of door het bij de beoordelingsgesprekken op de agenda te zetten, wordt eveneens voldaan aan het kenbaarheidsprincipe. “Ik wist het niet” is daarmee geneutraliseerd.

Gebruikers die zich regelmatig actief akkoord verklaren zijn zich daar veel meer van bewust dan degenen die dagelijks een vakje aanvinken en op OK klikken.

Logging
Een functionaliteit die veel van deze producten hebben is het loggen (registreren) van verbindingen. Dan kan zowel centraal (op de server) als lokaal (bij de client op de desktop) zijn ingesteld. Iemand die deze blog volgt voelt hem al aankomen, hier zit een privacy luchtje aan.

Van e-mail weten we dat er registratie plaatsvindt bij het verzenden en ontvangen van e-mailberichten. De mails zelf worden vastgelegd in de mailbox. Dat moet ook wel, anders heb je er niets aan. E-mail kan gebruikt worden als bewijsgevend materiaal. Voor IM, dat niet echt is ingeburgerd in het bedrijfsleven, zou je soortgelijke regels verwachten. Toch komen de meeste clients met een voorinstelling waarbij de logging uitstaat.

Accounts
Een bedrijf zal eveneens zelf het beheer van de IM accounts willen uitvoeren, om de professionele uitstraling te kunnen handhaven. Dit is natuurlijk vooral van belang bij externe contacten. Iemand met de alias ‘lekkerding88@hotmail.com’ komt net zo serieus over als ‘leethaxor@yahoo.com’. Gesteld dat een accountmanager een dergelijke IM account gebruikt bij zijn zakelijke contacten, dan zal dat de professionele uitstraling van de organisatie nadelig beïnvloeden.

Het controleren van de bedrijfspolicy met betrekking tot de naamgeving is een ding. Een organisatie zal het eveneens niet waarderen als een ex-medewerker de accountnaam ‘janssen-bedrijfsnaam@hotmail.com’ blijft hanteren na zijn vertrek. Centraal beheer van IM accounts is een belangrijk punt. Bij het selecteren van de enterprise oplossing voor IM moet beheer van accounts deel uitmaken van de oplossing.

Beleid
IM berichten zijn vaak kort en informele krabbels, waarbij vastlegging – vanuit gebruikerstandpunt bezien – niet nodig of gewenst is. Voor bedrijven kan dat anders zijn, zeker als er contacten met externe partijen worden onderhouden met behulp van IM. Centrale logging van dat IM verkeer kan dan zeker gewenst zijn, bijvoorbeeld voor bewijsvoering. Meestal gaat hierbij de voorkeur naar het vastleggen van de gegevens bij de client software. Dat levert trouwens wel problemen op bij ontslag van een medewerker.

Voor mailboxen zijn vaak protocollen ingeregeld waarbij eisen zijn geformuleerd over de omstandigheden waaronder een mailbox wordt geopend, om de privacy van de medewerker te beschermen. Bij IM moet dit eveneens geregeld worden, de werkgever kan hier een belang hebben, zoals het nakomen van afspraken met derde partijen die door betrokken medewerker zijn gemaakt. Een methode om dit te borgen is het opstellen van voorwaarden voor het gebruik van IM. Daaronder kan het vastleggen van IM conversaties horen, net als richtlijnen voor het gebruik van de account.

Als dit proces goed is ingeregeld, zal het privacy luchtje niet gaan stinken.

Een bedrijf dat besluit de draagplicht in te voeren voor toegangspassen wordt direct geconfronteerd met allerlei weerstanden. Veel mensen vinden of voelen dat zij in hun persoonlijke levenssfeer worden geraakt. Dat is een verzwarende factor bij de controle op naleving van het beleid.

De kans dat een dergelijke maatregel gaat werken is nog het grootst in een strak geleide hiërarchische organisatie waar men overwegend in bedrijfskleding loopt en werkt. Zelfs dan is zichtbaar commitment van het management nodig om van deze maatregel een succes te maken. De herkenbaarheid van bezoekers zal alleen goed werken als de draagplicht strikt gehandhaafd wordt. Natuurlijk moet bij het invoeren van deze maatregel nadrukkelijk gekeken worden naar de beoogde veiligheidsopbrengst. Het management en de afdeling informatiebeveiliging dienen goed in beeld te hebben wat er met deze zware maatregel beschermd moet worden.

Mocht een volledige draagplicht niet haalbaar zijn, dan zijn er enkele compenserende maatregelen mogelijk waardoor het vereiste beveiligingsniveau alsnog benaderd kan worden. Hierbij kun je denken aan het steeds begeleiden van bezoekers en het afschermen van ruimtes met (bijvoorbeeld) vertrouwelijke informatie. Deze ruimtes zijn dan niet te betreden met een bezoekerspas. Verder moet in alle ruimtes met vertrouwelijke informatie een cleandesk policy van kracht zijn, waardoor informatielekkage wordt bemoeilijkt. Om meelifters (piggy-backing) bij het betreden van een vertrouwelijke zone tegen te gaan kun je denken aan de invoering van mantraps of eenpersoons sluizen.

Voorkomen van misbruik van passen die toegang geven tot de vertrouwelijke zones is een ander fenomeen. Je kunt dit beheersen door aanvullende eisen te stellen aan de bezoeker. Bijvoorbeeld het vragen van een pincode of gebruikmaken van biometrische identificatie. Alweer, de kosten van de beveiliging moeten in balans zijn met de waarde van hetgeen beschermd wordt.

De sterkste maatregel die een organisatie in kan zetten wordt gevormd door het eigen personeel. Als iedereen het belang begrijpt van cleandesk, het begeleiden van bezoekers en onbekenden durft aan te spreken, dan is de kans op ongewenst bezoek het kleinst.

Daar kan geen draagplicht tegenop.

Bedrijven en organisaties die wat langer hebben nagedacht over gegevens en toegang beschikken over een autorisatiematrix. Hierin staan rollen, rechten en functies aangegeven. Uit dit schema moet blijken dat een gebruiker geen conflicterende rechten heeft, zoals zowel goedkeuringsrechten als betaalrechten voor facturen.

Het komt veel voor dat de autorisatiematrix bestaat en van origine goed is ingeregeld. Dat er later bij een audit negatieve bevindingen worden afgegeven heeft alles te maken met onvoldoende of geen beheer van de autorisatiematrix. Vaak gaat dit al fout doordat de accounts van vertrokken of overgeplaatste medewerkers niet worden verwijderd. Mensen die hun carrière binnen het bedrijf hebben gemaakt verzamelen in de loop van de tijd veel aanvullende rechten. Regelmatig komt het voor dat een nieuwe medewerker een kopie van de rechtenverzameling van zijn voorganger krijgt, zodat hij in ieder geval genoeg rechten heeft om zijn werk te kunnen doen. Nadeel van deze werkwijze is dat er binnen de kortste keren geen overzicht meer is van de rechtenstructuur. De autorisatiematrix is nutteloos geworden en de organisatie loopt risico’s bij zijn informatiebeheer.

Om de zaak weer in de hand te krijgen moet een onevenredig grote inspanning worden verricht. Eerst moet worden bepaald aan welke functies welke rollen moeten zijn gekoppeld, daarna moeten de rechten per rol worden vastgesteld en tot slot moeten de rechten en rollen door de beheerders worden toegekend. Als klap op de vuurpijl moet het beheer worden ingeregeld.

Deze werkzaamheden kan een organisatie voorkomen door een goed beheer van de autorisatiematrix, het tijdig verwijderen van overbodige accounts en het intrekken van rechten bij functiewijzigingen.

Zo gaat een organisatie met zijn informatiebeheer van nice to know naar need to know.

Je kunt als informatiebeveiliger beleid formuleren tot je een ons weegt en communiceren tot je erbij neervalt, maar hier helpen alleen technische maatregelen. Het werkt trouwens wel goed als je daar een beleid voor hebt dat helder is gecommuniceerd. Doelgroep van de communicatie wordt gevormd door de usual suspects: externe medewerkers (consultants), ontwikkelaars en technische ondersteuning (bv. printer onderhoudsmonteurs).

Voor de technische kun je denken aan NAC. Network Access Control komt in veel smaken, ik ga in het op het security model, zonder mij druk te maken over merken. Bij NAC wordt een pc aangemeld bij de Active Directory (AD) (of repository die deze beheerdienst uitvoerd). Hierna wordt eenmalig een certificaat aangemaakt op basis van de geregistreerde pc naam en het MAC adres. Bij de volgende maal aanmelden checkt het controlestation de geldigheid van het certificaat. Afhankelijk van het resultaat worden toegangsrechten uitgedeeld of de netwerktoegang geblokkeerd. Bij detectie van een pc zonder certificaat gaat er uit compliance overwegingen een melding naar de afdeling security. Zo blijf je op de hoogte van de beveiligingsopbrengst van je maatregel en kun je eventuele trends vroegtijdig detecteren.

Voordeel van preregistratie is dat iedere machine bekend is bij beheer en is opgenomen in de Configuration Management Database (CMDB). Gebruikers (of vreemden) die geen beheerrechten hebben op de AD kunnen geen pc’s registreren. Zo verklein je de kans op ongeautoriseerde apparatuur in je netwerk.

Op dit thema zijn variaties mogelijk. Want je wilt misschien wel de externe medewerkers toegang tot  Internet bieden. Een niet-geregistreerde computer (zonder certificaat) krijgt dan geen rechten op het datacenter, maar kan automatisch gerouteerd worden naar de internetzone. Verder kun je een pc die zich aanmeld bij de autorisatieserver op de aanwezigheid en status van de endpoint security software. Mocht de pc niet voldoen aan je eisen, stuur hem dan naar een sandboxomgeving en installeer (push) de updates. Daarna kan de pc zich opnieuw aanmelden en zal hij, na geslaagde authenticatie en autorisatie, toegang krijgen tot de gewenste netwerkbronnen.

Zoals je ziet kun je op relatief eenvoudige wijze snel een grote beveiligingswinst boeken en een aantal risico’s voor je omgeving verkleinen of neutraliseren. Je moet het alleen even doen.