Hoe verder het met AIVD BYOD-advies

Als je het onderwerp ‘bring your own device’ een beetje in de gaten houdt, kun je het niet hebben gemist. De AIVD heeft 31 juli een advies gepubliceerd over de wenselijkheid en mogelijkheid van BYOD binnen overheidsorganisaties. In hoofdlijnen komt het advies er op neer dat organisaties beter met ‘choose your own device’ aan de slag kunnen gaan. Dus, ja, ga verder met smartphones en tablets, maar, nee, de medewerkers mogen geen persoonlijke devices gebruiken. Een dergelijk scenario heb ik een tijdje geleden al beschreven op deze site en staat natuurlijk ook in het boek. Het advies van de AIVD is prima leesbaar, maar het is wel goed om het geheel in perspectief te houden. De ervaring leert, helaas, dat een rapport als dit snel misbruikt wordt door degenen die niet zitten te wachten op BYOD en zo snel mogelijk een end-to-end controle binnen het bedrijfsnetwerk willen herstellen. Daarmee doe je je collega’s en de innovatiekracht van jouw organisatie geen plezier, maar doe je ook geen recht aan het AIDV-stuk (PDF).

Het belang van dataclassificatie

De AIVD maakt helder waar haar advies betrekking op heeft. Het gaat in de eerste plaats niet om apparaten, maar om gegevens en nog specifiek om de vertrouwelijke gegevens. Op Wikipedia valt te lezen dat de overheid vier niveaus van vertrouwelijke gegevens onderscheid, in oplopende graad: departementaal vertrouwelijk, staatsgeheim confidentieel, staatsgeheim geheim, staatsgeheim zeer geheim. Waar staatsgeheim bij staat valt buiten de scope van het advies (voor wie de wet wil lezen, alhier).

Niet alle gegevens zijn even gevoelig, om maar eens een open deur in te trappen, en daarmee kan het advies mijns inziens ook niet betrekking hebben op alle medewerkers en hun apparaten. Je zal per rol moeten kijken met welke typen gegevens de medewerker in aanraking komt en daar je beleid op af moeten stemmen. Ik maak daarbij een onderscheid tussen privacygevoelige gegevens en organisatiegevoelige gegevens.

Privacygevoelige gegevens Organisatiegevoelige gegevens
Risicoklasse Risico
0 1 2 3 Openbaar Intern Vertrouwelijk … en hoger
Rol 1 x x x
Rol 2 x x
Rol 3 x x

Medewerkers die met openbare en/of interne informatie werken en geen (of slechts in zeer beperkte mate) met privacygevoelige gegevens te maken hebben, hoeven niet onder dit advies te vallen. Je moet dan wel de zaak op orde hebben en het mogelijk hebben gemaakt om aan gegevens een classificatie te hangen. Heb je dat niet gedaan dan zul je alle gegevens naar de hoogste risicoklasse moeten tillen en op basis daarvan maatregelen nemen. Oftewel, in plaats van een fatsoenlijke kluis bouw je dan een fort met meerdere grachten en muren en een beperkt aantal hele smalle toegangspoortjes. Niet handig, niet gebruiksvriendelijk en vooral erg duur.

Risicoscenario’s

Zodra je meer zicht hebt op de risico’s van de gegevens waar verschillende typen gebruikers mee te maken hebben, kun je een analyse maken van de gevolgen van een datalekkage (bewust of onbewust). Is het op zich een probleem als een medewerker, binnen zijn/haar rol, op een persoonlijke tablet vertrouwelijke stukken kan lezen? Nee, denk ik zo. Het probleem ontstaat pas wanneer iemand anders, die daartoe niet gemachtigd is, een dergelijk stuk in handen krijgt. En dan wordt het de vraag hoe groot de risico’s op verlies of diefstal zijn, dan wel het risico’s op afluisteren/meelezen. In het boek pleit ik er om die reden voor dat minimaal de toegang tot apparaten beveiligd moet zijn (wachtwoord, pincode, patroon, whatever) met een versleutelde opslag van gegevens. Mijns inziens is dat een minimale randvoorwaarde voor BYOD.

De AIVD gaat nog wat verder en wijst ook op de risico’s in de verbinding, de communicatie tussen het apparaat en de plek waar de gegevens zijn opgeslagen.

Onsluiten van de gegevens

Uiteindelijk moet er wel gewerkt worden en moeten medewerkers met gegevens aan de slag. De AIVD geeft een helder overzicht van drie scenario’s: (1) de medewerker maakt gebruik van eigen apps en haalt gegevens binnen (bijvoorbeeld e-mail); (2) bring your own display, waar op het apparaat een gevirtualiseerde applicatie of desktop wordt gepresenteerd; (3) de organisatie app dan wel een enterprise container met daarin de apps en gegevens (voorzien van extra veiligheidsmaatregelen). Mijns inziens moet je dat wel weer koppelen aan het bovenstaande schema. Je wilt niet alles aanbieden via enterprise containers. Dat wordt op termijn gewoon erg duur en beperkend. Nu zijn iOS en Android de belangrijkste mobiele platforms (met Android in meerdere smaken), wat over 1 of 2 jaar de bom zal zijn is onbekend. Hoe ga je die ontwikkelingen bij houden? Hoe snel kun je voor de verschillende platformen nieuwe containers uitrollen en beheren?

Wat ik mis in het AIVD-advies (maar corrigeer me als ik het heb gemist) is de webapp-oplossing. Ik geloof werkelijk dat webapps op termijn de meest robuuste oplossing zijn. In dat geval heb je niet meer nodig dan een browser en een internetverbinding, en dat is voor mobiele apparaten toch wel standaard. Dan hoef je alleen nog maar te richten op het realiseren van veilige toegang tot de webapp. Voordelen: nauwelijks opslag op het apparaat (want nul bestaat niet), build once, available anywhere, anytime, any device.

Het grootste risico afvangen lukt toch niet

De AIVD wijst er op dat je als organisatie in de backoffice stevige maatregelen moet nemen bij de beveiliging van de gegevens en dat die beveiliging role-based ingericht moet worden. Op het niveau van het apparaat wordt gesproken over versleuteling, beveiliging op de toegang tot het apparaat, maar dan wel van een afdoende niveau, en de mogelijkheid van een remote wipe. Voor het overige komt het neer op gedragsrichtlijnen. Een apparaat met vertrouwelijke gegevens breng je niet terug naar de winkel voor reparatie. Beveiligingsmaatregelen mogen niet worden omzeild of uitgeschakeld. Dat soort maatregelen. Maar uiteindelijk blijft de mens de zwakste schakel in het geheel. Gelukkig noemt de AIVD ook de de mogelijkheid om de gebruiker te trainen en voor te lichten.

Zelf zou ik daar niet een ‘mogelijkheid’ maar een ‘vereiste’ van hebben gemaakt. BYOD betekent een verschuiving in verantwoordelijkheden. Meer vrijheid voor de medewerker gaat gepaard met meer verantwoordelijkheid en daar mag best een stevige toets op komen. Ik vind het AIVD-advies op dit punt wat zwak.

Maar waar komt het CYOD-advies vandaan?

Zoals eerder gesteld kan ik me voorstellen dat je als organisatie niet met BYOD maar met CYOD aan de slag gaat. Maar ik zie in de argumentatie van de AIVD maar weinig dat tot de conclusie leidt dat CYOD de oplossing is voor het afvangen van de veiligheidsrisico’. De maatregelen die de dienst voorstelt zijn, mijns inziens, identiek aan wat een organisatie zou moeten doen bij een BYOD-beleid. De voorstelde technische, functionele en procesmatige oplossingen zijn intrinsiek aan ieder mobiel apparaatsbeleid, of het nu om uitgereikte apparaten dan wel persoonlijke apparaten gaat. De risico’s zijn minstens zo groot bij een CYOD-beleid en die worden niet beter afgevangen dan bij een BYOD-apparaat in dezelfde situaties.

Hoe verder met het AIVD BYOD-advies?

Als een snelle introductie in het vraagstuk van BYOD is het advies prima, maar het advies schiet op drie punten tekort:

  1. het mist een belangrijke manier om gegevens op een veilige en apparaatsonafhankelijke manier te ontsluiten en blijft daarmee in de ‘oude’ oplossing van end-to-end controle steken;
  2. het belangrijkste veiligheidsrisico (de medewerker) wordt met de maatregelen niet afgevangen;
  3. de keuze voor CYOD boven BYOD wordt nauwelijks onderbouwd.

Geplaatst op 1 augustus 2012, in Elders gelezen. Markeer de permalink als favoriet. 3 reacties.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers op de volgende wijze: