Patches voor mobiele apparaten dichten kwetsbaarheden in de beveiliging en voorkomen daarmee de verstoring van processen. Daarnaast brengen patches mobiele gebruikers nieuwe functies. Maar in veel gevallen faalt mobiel patchmanagement volgens de Computable-experts.
Als er smartphones en tablets in een professionele omgeving worden gebruikt dan is het nodig om die systemen op afstand te kunnen beheren, vindt ook algemeen directeur Kees Wiegers van KWIC Healthcare. ‘Applicaties kunnen wel in de cloud staan en altijd geüpdate worden naar de laatste versie, maar functionaliteiten die op een telefoon draaien moeten ook debug-mogelijkheden hebben en de mogelijkheid om patches te versturen’, zegt hij.
Kwetsbaar
Want ongepatchte systemen maken netwerken kwetsbaar voor onder andere aanvallen en lekken van data. Mobiele gebruikers hebben vaak echter geen boodschap aan vertraagde verbindingen of patches die op de achtergrond worden geladen en een reboot vereisen. ‘Prioritering en definiëren op welke wijze mobiele devices moeten worden gepatcht is dus een belangrijk aandachtspunt binnen mobility’, zegt Steven Dondorp, managing director bij Northwave.
Patchmanagement heeft volgens Dondorp namelijk twee gezichten; het is zeer onveilig patches niet uit te voeren, maar ze zijn soms ineffectief. Zo leiden patches volgens hem soms tot meer problemen dan de oplossing waarvoor ze geschreven zijn. Goed patchmanagement zou dan ook dezelfde gedachte moeten volgen als changemanagement, vindt Dondorp. ‘In eerste instantie gaat het om het detecteren en identificeren van systemen en mobiele apparatuur. Hoe meer mobility hoe complexer. Daarnaast gaat het er om dat de kennis aanwezig is over daarvoor beschikbare patches.’
Testen
Vaak wordt er niet getest, maar ook dit is volgens de experts juist een belangrijk aandachtspunt. ‘Tests kunnen blootleggen dat een organisatie eigenlijk geen goed patchmanagementbeheer voert. Door de besluitvorming over welke patches geschikt zijn voor bepaalde systemen te baseren op de uitkomst van tests, verbetert het beheer’, zegt Dondorp. ‘Daarnaast kunnen tests uitsluitsel geven over de juiste wijze van installeren en de registratie van alle bijbehorende procedures, zoals specifieke configuraties. Hier wordt vaak minder aandacht aan besteed terwijl dit juist een heel belangrijk punt is bij mobility.’
Er zijn verschillende oplossingen die patchmanagementtaken automatiseren. Deze besparen organisaties volgens Dondorp tijd en verlagen continuïteits- en aansprakelijkheidsrisico’s. Maar hij hamert erop dat juist de besluitvorming over de uitrol bij het management zelf blijft liggen. Niet alles kan dus geautomatiseerd worden.
Onderdeel
Bovendien vormt patchmanagement slechts een onderdeel van goed beheer’, zegt country manager Nederland Tonny Roelofs van Trend Micro. ‘Het beheer van mobiele apparaten via mobile device management moet naast patchmanagement ook cloudgebaseerde beveiliging, services voor het lokaliseren van apparaten én het op afstand leegmaken van zoekgeraakte of gestolen apparaten omvatten.’ Daarnaast is het informeren van gebruikers van mobiele apparaten over preventie van het verspreiden van malware heel belangrijk.
En Roelofs stipt nog een ander belangrijk punt aan. ‘Net als een app of een programma kan een besturingssysteem op een mobiel apparaat ook bugs bevatten. Het probleem is dat niet alle mobiele apparaten de laatste updates krijgen van de provider of de mobiele telefoonfabrikant waardoor cybercriminelen gebruik kunnen maken van beveiligingslekken. Patchen is dus belangrijk, maar nog belangrijker is ervoor zorgen dat er sowieso geen misbruik kan worden gemaakt van mobiele apparaten en dus niet te afhankelijk te zijn van deze patches.’
Aangezien patchen vaak synoniem is aan pleisters plakken om het eerste bloeden te stelpen en tetanusprik nog weleens vergeten wordt heeft het inderdaad twee gezichten:
1. Tijd versus stabiliteit
Testen kost tijd (en geld), zeker als dit grondig gedaan wordt door niet alleen naar de functionaliteit te kijken maar de werking als één geheel te beoordelen. Gebruikers willen echter alles snel, sneller en snelst en dus ontstaat er frictie waardoor hackers in het voordeel zijn. Want deze nemen namelijk wel de tijd om een systeem te doorgronden en als ze dan een lek gevonden hebben dan kost het ontwikkelaars altijd nog tijd om dit te dichten.
Patchen onderdeel van het Change management proces maken klinkt logisch maar….
2. Vrijheid versus controle
In https://www.computable.nl/artikel/opinie/cloud_computing/4546441/2333364/cloud-beheersbaar-maar-niet-beheerbaar.html heb ik hier al eens wat over geschreven want de ICT-(licht)vaardige zorgt voor een groeiend probleem van ‘shadow IT’: “…due to groups thinking they can do things cheaper and/or better than the formal IT group…” loopt beheer achter de feiten aan. Zeker als met techniek geprobeerd wordt om een organisatorisch probleem op te lossen: ‘It’s life Jim, but not as we know it’
Ik denk dat hier weer eens zeer duidelijk geillustreerd word wat nu eigenlijk de consequenties zijn van het hele byod verhaal, even los van de vaak aanzienlijke ‘verborgen’ kosten die ermee gepaard gaan.
Bij mijn weten en ervaren is IT nog steeds eerst heel goed nadenken voordat je uberhaupt een bepaalde stap in een bepaalde richting met IT zet. Het is precies wat Ewout hier bedoeld, patch management wordt een noodzakelijk kwaad wanneer men zich te weinig rekenschap geeft van het implementeren van, in dit geval, het hele byod verhaal.
Kijk, weer een case om naar de cloud te gaan, haha. Als het blijkbaar ingewikkeld is, laat het dan aan een expert over die op schaal opereert.
Om dit even concreet te maken, zie deze email van vandaag die ik krijg van Windows Azure:
“Dear Customer,
Maintenance affecting single instance deployments of Virtual Machines is postponed.
Recently, we notified you of a planned maintenance update impacting single instance deployments of Virtual Machines.
The planned maintenance will be delayed beyond this week in all regions and a new schedule will be released as we get closer to the new maintenance date. ”
Er was onderhoud gescheduled waarin alle VM’s patches en onderhoud krijgen. Geplande downtime dus, maar het mooi komt nog. Als je VM in een Availibilty zone hangt kun je dus plannen zonder downtime en ervoor zorgen dat de keten niet in gevaar brengen omdat je servers in verschillende “fault domains” stopt. MAW: Als je twee dezelfde servers in 1 availability zone hebt kunnen die nooit binnen 1 fault domain vallen en staan ze fysiek ook ik verschillende racks.
Als ik het artikel lees spreekt dit ook een voordeel uit daar niet Apps te ontwikkelen, maar op basis van de browser, ofwel “browser apps”. Die zijn niet native, minder chique en kunnen minder “offline”, maar lost dit probleem op de keyloggers na op.
Henri,
Een case om naar de cloud te gaan?
Als afnemer is het misschien prettig om zelf het onderhoudsschema op te stellen in overleg met de gebruiker want je zult maar net in een piek zitten waarbij iedereen moet overwerken terwijl de provider de machines uitzet om onderhoud te doen. Dat is uiteindelijk net zo goed unplanned downtime, ondanks de waarschuwing vooraf.
“Different cloud providers offer different levels of uptime and also have varying standards of customer services following a downtime incident.”
Een ‘dubbelgenaaid houdt beter’ principe helpt natuurlijk om dit soort verrassingen te voorkomen maar vertel me dan eerst eens welke kosten eraan zitten om alles dubbel uit te gaan voeren omdat een leverancier zijn eigen onderhoudsschema hanteert. Vergeet niet dat patches nog weleens leiden tot veranderde werking waardoor andere dingen in de keten het soms niet meer doen.
“The perfect storm of a disaster affecting an organization and coinciding with a cloud outage preventing access to business continuity resources would be unlikely, but at current levels of public cloud availability levels, it is far from impossible.”
En betreffende je laatste opmerking:
“Day-to-day production computing operations which are carried out using cloud infrastructure, or which rely on cloud-based software as a service, must be capable of being carried on off-line should the cloud be unavailable. And the cut-over needs to be relatively seamless.”