Policies zijn een belangrijk middel waarmee je je netwerk veilig kunt houden. Maar nu blijkt dat goede informatie over de support op mobiele apparaten voor deze EAS policies niet zo makkelijk te krijgen is. Bovendien is het lang niet altijd duidelijk wat er gebeurt als een Exchange server is geconfigureerd om een policy te gebruiken, terwijl een mobiel apparaat die policy niet ondersteunt.

De feiten

Het is aan de beheerder om zeker te stellen dat er aan de policies wordt voldaan, welk apparaat er ook wordt gebruikt. Daarom hebben we de feiten even op een rij gezet.

Exchange ActiveSync 2007 kent 29 toegangs- en beveiligingspolicies die door de beheerder kunnen worden geactiveerd. (Kijk op de Technet pagina’s voor details over de policies)

Er zijn maar een paar mobiele apparaten die in ieder geval een paar van deze EAS policies ondersteunen. Dat zijn ten eerste de iPhone, natuurlijk apparaten met Windows Mobile, de E en N series en de S60 van Nokia en tot slot WebOS en Palm OS van Palm.

Windows Mobile 6.1 ondersteunt alle 29 policies, al heb je voor een aantal ervan wel een Exchange enterprise licentie nodig. Apple en Nokia hebben tot nu toe niet gereageerd op verzoeken om precies te vertellen welke policies ze ondersteunen en een woordvoerster van Palm is tot nu toe niet in staat gebleken om de bewuste informatie boven water te krijgen. Op hun websites hebben de drie bedrijven wel wat informatie staan:

• De site van Nokia zegt dat ze “alle security policies” ondersteunen, zonder erbij te vermelden welke dat precies zijn.

• Apple zegt dat de iPhone de volgende policies ondersteunt: Allow Camera, Password Enabled, Allow History, Maximum Failed Password Attemts, Minimum Password Length, Maximum Inactivity Time Lock, Policy Refresh Interval, Minimum Device Comlex Characters, Require Manual Synchronization While Roaming en – alleen in iPhone 3.1 – Require Device Encryption.

• Palm geeft aan dat WebOS 1.1 de volgende policies ondersteunt: Password Enabled, Alphanumeric Password, Password History, Maximum Failed Password Attemts, Maximum Password Length, Maximum Inactivity Lock, Minimum Device Complex Characters en Password Recovery.

Android van Google ondersteunt EAS helemaal niet en BlackBerry ondersteunt het niet direct. In plaats van EAS heb je voor de BlackBerry RIM’s eigen BlackBerry Enterprise Server, die zelf een aantal policies heeft. Vanzelfsprekend ondersteunt BlackBerry OS die allemaal.

Veel apparaten kunnen wel met Exchange verbinden via IMAP, als Exchange tenminste zo is geconfigureerd dat dit wordt toegelaten. Maar de EAS policies kunnen niet worden afgedwongen via IMAP.

Zeker stellen dat EAS niet wordt omzeild

Aan het onterecht rapporteren van on-device encryptie door iPhones werd een einde gemaakt door de update naar iPhone OS 3.1, die op 8 september werd uitgebracht. Maar doordat ze gebruikers en beheerders niet op de hoogte hadden gesteld van de fix voor apparaten die voorheen logen over hun encryptie, zorgde Apple ervoor dat gebruikers ineens geen toegang meer hadden tot Exchange nadat ze hun upgrade hadden uitgevoerd. (Overigens hebben de iPhone 3G S en het laatste model van de iPhone Touch wel de beschikking over on-device encryptie, dus die spraken de waarheid als het daar om ging)

De ongeëncrypteerde iPhones konden verbinden met Exchange waarop die encrypty-policy was ingesteld doordat Exchange servers erop moet vertrouwen dat zulke apparaten de waarheid vertellen over wat ze ondersteunen, en op de feitelijke status van het apparaat ten aanzien van de ondersteunde policy.

Als een apparaat probeert te verbinden met Exchange, dan vraagt EAS aan het apparaat welke policies het ondersteunt en of er aan wordt voldaan. Dit doet zich voor voordat de gebruiker inlogt. Vervolgens zegt het apparaat ‘ja’ op de policies die het kent en Exchange neemt dan aan dat het antwoord op de rest ‘nee’ is. De Exchange server geeft het apparaat daarna toegang of niet, dat ligt er aan of er aan de policies is voldaan die de beheerder heeft ingesteld.

Als in EAS een policy is ingesteld die niet expliciet door het apparaat wordt ondersteund, dan krijgt het apparaat dus geen toegang tot de server. Is EAS bijvoorbeeld zo ingesteld dat het wachtwoord ten minste een non-alfanumeriek karakter moet hebben, en het apparaat ondersteunt die policy niet, dan krijgt het geen toegang tot de server, ook al voldoet het wachtwoord aan de eisen die de policy stelt. Exchange laat het apparaat niet verbinden omdat het heeft verteld dat het wachtwoorden niet kan verifiëren op de juiste vereisten, en EAS neemt vervolgens het risico gewoon niet.

Het probleem is nu dat er een manier is om deze vereisten te omzeilen. EAS heeft een optie die Allow Non-Provisionable Devices heet. Is die optie geactiveerd, dan laat EAS apparaten verbinden als ze de policies niet ondersteunen die de beheerder heeft ingesteld. Met andere woorden: als een apparaat niet expliciet zegt dat het een policy niet ondersteunt, neemt EAS aan dat het die policy wel ondersteunt. Heb je dus Allow Non-Provisionable Devices ingeschakeld, dan ga je er voetstoots vanuit dat de apparaten die proberen te verbinden met de server aan de voorwaarden voldoen, en dat ze niet moeten worden buitengesloten omdat ze de EAS policies niet ondersteunen.

Het volgende voorbeeld maakt duidelijk wat dit betekent. EAS is zo gezet dat het een minimale wachtwoordlengte vereist en on-device encryptie. Maar het apparaat ondersteunt alleen de policy voor minimale wachtwoordlengte. Als de Allow Non-Provisionable Devices optie staat ingeschakeld, dan zal EAS het apparaat toelaten op de server als het wachtwoord de minimale lengte heeft. Maar of het apparaat versleuteld is of niet wordt totaal genegeerd, omdat het apparaat die policy niet ondersteunt.

Wat te doen met apparaten die niet voldoen

Als een apparaat alle EAS policies ondersteunt die je hebt ingesteld, dan is er vanuit beveiligingsoogpunt geen reden om de gebruiker niet toe te laten op de Exchange server, mits aan alle eisen is voldaan. Maar je wilt niet de kans lopen dat apparaten kunnen verbinden die niet aan jouw eisen voldoen. Dus zul je er minimaal voor moeten zorgen dat de optie Allow Non-Provisionable Devices is uitgeschakeld, ook al betekent dat dat bepaalde apparaten niet kunnen verbinden, afhankelijk van welke policies je hebt ingesteld.

Maar dat is nog niet genoeg. Want blijkbaar kun je er niet altijd zeker van zijn dat die apparaten de waarheid vertellen over welke policies ze ondersteunen. Heb je bijvoorbeeld gebruikers met een iPhone die nog iPhone OS 3.0 of eerder hebben, dan zul je meer moeten doen. Hier zijn de opties die je hebt.

Houd ze allemaal van je netwerk. De veiligste en goedkoopste optie voor apparaten die je wat dit betreft niet kunt vertrouwen is ze gewoon allemaal weren. Je kunt dat bijvoorbeeld doen door certificaten te eisen voor toegang, en die certificaten verstrek je niet aan deze apparaten, dus kunnen ze niet verbinden. Maar deze techniek vereist van je dat je certificaten uit gaat delen aan mobiele apparaten die je wel wilt ondersteunen. Maar daarmee beperk je jezelf tot BlackBerry (waar je trouwens weer de aparte BlackBerry Enterprise Server voor nodig hebt) en apparaten met Windows Mobile. De configuratietool van de iPhone laat de distributie van certificaten wel toe, maar je hebt er niet de controle over die je nodig hebt om het gebruik te beperken tot bepaalde gebruikers en zonder de automatisering die mogelijks is op de BlackBerry en Windows Mobile.

Creëer aparte policies voor de verschillende apparaten. Een meer genuanceerde optie is het creëren van aparte policies voor gebruikers van de apparaten die niet alle EAS policies ondersteunen die je vereist. Het doel van deze aparte policies is om de veiligheidsvoorwaarden aan te scherpen op de vlakken die door deze apparaten wel worden ondersteund, ter compensatie van het gebrek daaraan op andere gebieden. Heb je bijvoorbeeld de veiligheidseis dat een apparaat on-device encryptie heeft, maar je wilt wel alle iPhone-gebruikers aan laten loggen op Exchange, dan kun je voor hen een extra policy invoeren, waardoor ze een complexer wachtwoord moeten gebruiken en waardoor ze het wachtwoord regelmatig moeten veranderen. Vervolgens kun je er nog door middel van de Maximum Failed Password Attempts policy voor zorgen dat het apparaat helemaal geen toegang meer kan krijgen als er een aantal keren wordt geprobeerd in te loggen met een verkeerd wachtwoord.

Gebruik een mobile management server. Voor de derde optie die we geven moet in de buidel worden getast, maar deze geeft je wel de beste garantie dat je niet om de tuin wordt geleid. Je kunt een mobile management server gebruiken, zoals die van Good Technology of van MobileIron, samen met een mobiele client die samenwerkt met die server. Good heeft bijvoorbeeld een client die werkt op de iPhone, op Palm WebOS en op de Android systemen. Je voegt er on-device encryptie mee toe die aan alle standaarden voldoet. Het voegt ook encryptie toe aan Windows Mobile 6.0 en eerder. Het product van MobileIron weet precies welke EAS policies door een apparaat, laten we zeggen een iPhone, worden ondersteunt en blokkeert vervolgens de apparaten die daarover liegen.

Overigens kunnen niet alle mobile management platfomen je helpen met het afdwingen van EAS policies, of ontbrekende ondersteuning toevoegen aan mobiele apparaten. De Zenprise server kan dit bijvoorbeeld niet, hoewel het bedrijf beweert dat dit in toekomstige versies van de server en client wel zal kunnen.

Bron: Techworld