BYOD.. Wel of niet?

Bring your own device, als je daar 15 jaar geleden over begon zou dat absoluut ondenkbaar geweest zijn. Het idee dat een apparaat aangesloten wordt op je bedrijfsnetwerk waar je geen controle en geen zicht op hebt zal nog menig beheerder doen gruwelen, ik kom in ieder geval nog voldoende pentesters tegen die hier grote problemen mee hebben.

Maar is het nog wel zo’n groot probleem? En wat zijn dan de overwegingen om te bepalen of je BYOD toe wil staan of niet, en welke maatregelen zijn er nodig als je die weg dan in slaat?

Oude mac met rugzak
er zijn grenzen..

Wat verstaan we onder BYOD

BYOD komt veel vaker voor dan we denken en strikt gezien is het waarschijnlijk zelfs zo dat we in bijna 100% van alle IT omgevingen tot op zekere hoogte te maken hebben met BYOD situaties.

In het kort is Bring Your Own Device het best te omschrijven als het uitvoeren van zakelijke activiteiten op een aparaat (laptop, telefoon, pc, fax) dat niet onder beheer staat van de IT afdeling van je organisatie.

De meest duidelijke situatie is natuurlijk wanneer een medewerker zijn of haar eigen laptop gebruikt om op te werken, veelal omdat ze dat gemakkelijker vinden of omdat dat systeem beter/sneller is dan wat ze van hun werkgever krijgen.

Een ander scenario is dat de gebruiker een eigen telefoon gebruikt. Wederom omdat deze beter is dan de zakelijke telefoon of domweg omdat er geen telefoon verstrekt wordt en er toch contact met de collega’s, leveranciers of klanten nodig is anders dan alleen teams meetings.

Daarnaast kan een medewerker ook nog vanaf een privé pc of laptop in de avonduren nog even snel een mail beantwoorden (webmail) of zelfs op vakantie even in een internetcafé inloggen op een van de systemen daar (de horror.. niet doen 🙁 ).

Er zijn nog wel meer grensgevallen te bedenken, maar we houden het hier even bij. Voor de rest van dit artikel focussen we ons op de werkplek in de vorm van de PC of de laptop. Mobiele telefoons is een post op zichzelf waard, dus die bewaren we nog even voor later ;).

Security

Volledige segmentatie van alle data, alle netwerken en alle devices die met elkaar in aanraking komen zou de meest veilige situatie opleveren, en meteen ook de meest onwerkbare. Er moet dus gekeken worden naar wat er allemaal mogelijk is op dit vlak om te bepalen of een BYOD oplossing de moeite waard is.

Aan technische mogelijkheden op dit vlak geen gebrek, zeker binnen het Microsoft 365 ecosysteem is er inmiddels meer dan voldoende mogelijk om de benodigde segmentatie zelf voor een groot deel te automatiseren. Met labeling van data (dataclassificatie – Microsoft Purview) heb je de segmentatie van je data op orde. Door je endpoints allemaal netjes in MDM (Microsoft Endpoint Manager) te hangen en zake als EDR en AIR (Automated Investigation and Remidiation) in te regelen hou je zicht op wat er met die data gebeurt en kan je een deel van je incident response automatiseren.

De tools zijn er dus wel, maar hoe pakken we dat dan aan, en wat voor impact heeft dit op de wel/geen BYOD discussie?

Een lange adem

Soms kosten dingen gewoon tijd..

Het inregelen van alle technische maatregelen zoals eerder omschreven (en dat is nog maar een kleine selectie) is een proces van lange adem, veel werk en een hoop keuzes.

Allereerst zal er iets van beleid gerealiseerd moeten worden. De configuratie keuzes die gemaakt moeten worden kunnen deels op de baselines van Microsoft bepaald worden. Echter, de verfijning en aansluiting op je eigen organisatie is van groot belang, niet op de laatste plaats voor de werkbaarheid van de oplossing.

Je beleid bijvoorbeeld moet voorzien in het model waarmee je dataclassificatie toe gaat passen. Ben je bijvoorbeeld ISO27001 gecertificeerd? Dan heb je een dergelijk model in je beleid staan, maar in veel andere gevallen zal dit ontbreken.

Ook voor het onder beheer brengen van je endpoints is mogelijk nog een hele weg te gaan, zeker ook omdat je misschien wel helemaal schoon wil beginnen zodat je zeker weet dat alle devices direct goed in beheer genomen worden en compliant zijn aan het beleid. (Full disk encryptie? Mag een gebruiker zelf local admin zijn op zijn systeem? (een hele discussie op zichzelf)).

Herinner je je dat dataclassificatie beleid nog? Nu we bepaald hebben wat de bedoeling is moeten we dat ook nog zien toe te passen op de berg data die je al hebt.. Het is gemakkelijk om te zeggen dat je alle bestaande data als vertrouwelijk markeert en de gebruikers labels mogen wijzigen als dat nodig is, maar hoeveel impact heeft dat op de werkwijze van de gebruikers? En hoeveel tijd gaat ze dat kosten?

Vragen en uitdagingen genoeg dus, en we zijn pas bij het voortraject.

en dan?

Voorbereidingen klaar? Go!

Alle voorbereidingen zijn getroffen, het dataclassificatie beleid is ten uitvoering gebracht, alle systemen zijn onder beheer. Je nieuwe medewerker vraagt of hij zijn eigen laptop mag gebruiken omdat de resolutie beter voor zijn ogen is.

Eindelijk zijn we dan bij de BYOD vraag aangekomen..

Er zijn nu twee routes, wanneer je er voor kiest om eigen hardware toe te staan (we hebben het even over laptops/pc’s) kan je stellen dat je dit alleen accepteert als de laptop opgenomen wordt in het MDM systeem. De hardware is dan wel nog in eigendom van de gebruiker, maar alles wat er op staat is onder regie van de werkgever. Als je vooraf afspraken maakt over bepaalde hardware eisen (TPM bijvoorbeeld) is er in deze route geen noemenswaardig verschil tussen hardware die de organisatie zelf koopt en hardware van de eindgebruiker.(voor dit verhaal dan).

De tweede route is het scenario waarbij de eindgebruiker niet wil dat zijn/haar laptop wordt opgenomen in het centrale MDM systeem. Over het algemeen vind ik dit een onwenselijke situatie en ik zou ik vragen hebben over waarom hij/zij dat dan niet zou willen. De voornaamste reden zal het privé gebruik van het apparaat zijn en de onwil om daar toegang toe te geven (begrijpelijk). Maar dat wil niet zeggen dat dit scenario niet toch voorkomt en er legitieme use-cases zijn.

Unmanaged BYOD

Deze tweede route brengt ons bij een unmanaged BYOD scenario. Als je de eerdere stappen gevolgd hebt, het beleid en de classificaties in orde zijn en je omgeving voorbereid is zijn er wel mogelijkheden op dit vlak.

Middels conditional acces policies kan er onderscheid gemaakt worden tussen welke systemen en data er benaderd mogen worden door de diverse clients die we kennen (managed, unmanaged, location based enzovoorts).

In het geval van een unmanaged device zou je nog kunnen toestaan dat de webmail gelezen wordt en eventueel ook nog dat documenten met een bepaalde classificatie in de web vorm bekenen en bewerkt kunnen worden. Het downloaden van de data, het installeren van applicaties en het inloggen in gevoelige SaaS systemen is uit den boze op een unmanaged systeem.

Mogelijkheden

Is er dan echt niets mogelijk in het kader van Bring Your Own Device? Zeker wel! Wil je de gebruikers toch grote vrijheid geven op hun eigen devices is er altijd nog de mogelijk om een centrale werkplek op de bouwen vanaf waar alsnog alles gedaan kan worden. Het downloaden van data naar je eigen (dus niet zakelijke, unmanaged) laptop kan nog steeds niet, maar eenmaal ingelogd op het centrale platform (zoals Azure Virtual Desktop, zie ook mijn “Virtual Walled Garden” post) kan je in die volledig beheerde omgeving alles doen wat je met een managed systeem ook zou kunnen.

Dit brengt me dan ook bij een van de (ik denk meest voorkomende) scenario’s waarbij je mogelijkerwijs met grotere aantallen “BYOD” devices in je omgeving te maken krijgt. Wanneer er op grote schaal extra krachten ingehuurd moeten worden voor kortere tijd kan je je afvragen of je hiervoor de nodige devices wil aanschaffen en klaar wil hebben liggen op de plank, of dat je ze misschien wil huren. Deze mensen werken mogelijk ook niet op je eigen kantoren, maar misschien wel exclusief vanuit thuis.

Allemaal factoren waar je verminderd grip op hebt, door deze devices ook niet toe te laten op je netwerk, maar de werkzaamheden gecontroleerd centraal uit te laten voeren hou je optimaal grip op je data en bied je toch de vrijheid om te werken met de tools die passen bij de situatie.

Het gebruikersgemak van Bring Your Own Device

Laptop op een tuintafel
Een werkplek moet je eigenlijk kunnen maken zoals deze bij jou past..

Bring Your Own Device mogelijkheden spreken erg aan op het vlak van gebruikersgemak bij je eindgebruikers. Als ze kunnen werken met systemen die ze kennen, in situaties die bij ze passen, zal er minder snel buiten de zakelijke IT omgeving heen gewerkt worden.

Eerder schreef ik op dit vlak ook al wat over Security Awareness, en in het stuk over de Virtual Walled Garden ging ik in op de mogelijke oplossing die ook op dit vraagstuk pas. Maar ik kan ook niet genoeg benadrukken dat de bewustwording van de gebruikers, en het faciliteren van een comfortabele omgeving waar je als IT verantwoordelijke grip op hebt, cruciaal zijn voor de veiligheid van je data/organisatie.

In het verlengde daarvan zijn we er vanuit security oogpunt dus bij gebaat om een omgeving aan te bieden met net voldoende vrijheden om te voorkomen dat gebruikers dingen gaan doen die we niet willen, maar met voldoende grip zodat we precies weten wat er gebeurt.

Overigens is er mogelijk ook een heel ander probleem dan een inrichtingsvraagstuk als je veel gebruikers hebt die hun eigen spullen willen gebruiken. Het is (zeker ook gezien de situatie op de arbeidsmarkt) aan te raden om na te denken of die goedkope zakelijke laptop nog wel past bij de beleving die je je medewerkers wil bieden.

Microsoft heeft natuurlijk een erg nette Surface lijn beschikbaar, maar je hoeft niet direct zo ver te gaan (alhoewel ze verhoudingsgewijs niet een zo heel duur zijn ten opzichte van de Dell, of HP alternatieven.). Het is in ieder geval wel goed om eens na te denken bij de hardware die je standaard voert, ook hier speelt de beleving van de gebruiker weer een grote rol.

Conclusie?

Of BYOD bij je organisatie/omgeving past is sterk afhankelijk van het soort organisatie dat je bent en het soort data waar je mee werkt. Als de data zeer gevoelig of zeer waardevol is zijn oplossingen waarbij je openingen bied om de data te extracten zonder dat je daar zicht, of controle, over hebt onwenselijk.

Maar zelfs in die scenario’s zijn er ook rollen in je organisatie waarbij meer vrijheid misschien wel passend is. Als je daar dan de juiste voorwaarden voor schept zoals, segmentatie, conditional acces en de vele andere mogelijkheden in dat vlak, is er misschien toch best wel wat mogelijk.

Ook met een centrale werkplek die je optioneel aanbied voor de mensen die dan toch met hun eigen device willen of moeten werken is er best wel ruimte te creëren voor dergelijke situaties.

Mijn advies zou in ieder geval zijn om naast het belang van het beschermen van je omgeving ook goed te kijken naar de belevenis van je gebruikers. Probeer te voorkomen dat ze het idee hebben hun werk niet goed te kunnen doen met de middelen die je ze bied. In deze gevallen zullen ze zelf op zoek gaan naar oplossingen en werkwijzen, en die zijn vrijwel zeker niet in lijn met het beleid dat je hebt vastgesteld.

Boekenkast
Beleid hebben we vaak kasten vol.. Nu de uitvoering nog..

Security awareness

Iedereen die voor een organisatie van een beetje formaat werkt zal inmiddels wel bekend zijn met Security Awareness trainingen. Wat is nou een datalek, wat moet ik doen bij een datalek en hoe houd ik mijn werkomgeving en daarmee de data van je werkgever en haar klanten zo veilig mogelijk. Soms voelt het een beetje als die verplichte hoepel waar je jaarlijks doorheen moet springen. Maar toch is het echt de moeite waard om aandacht te besteden aan wat er allemaal voorbij komt bij een dergelijke training.

De ontwikkelingen

Het aanbod in de markt voor de verschillende trainingen op dit gebied is gelukkig flink gegroeid en daarmee ook zeker in kwaliteit verbeterd. Een meer interactieve vorm van trainen begint gelukkig ook meer en meer de norm te worden. Echter, wat mogelijk een nog veel belangrijker aspect is dat de trainingensteeds vaker geplot worden op de deelnemer als mens, en niet zo zeer alleen de deelnemers als medewerker.

Dat laatste is niet geheel onbelangrijk. Met de verschuiving van centrale werkplekken zoals Citrix en Remote Desktop omgevingen naar toch weer meer werken op de endpoints zelf (laptops telefoons) wordt het ook moeilijker om je bedrijfsdata veilig op te bergen in een centrale omgeving met een hoge muur er omheen. Er is natuurlijk van alles technisch te realiseren om de potentieel onwenselijke toegang tot deze data en systemen te voorkomen, maar feit is wel dat de gebruikers buiten het zicht van je eigen infrastructuur op pad gaan met hun devices en jouw data.

Combinatieslot

Alles op slot of totale vrijheid?

De waarheid ligt uiteraard in het midden en het antwoord is sterk afhankelijk van de data waarmee gewerkt wordt. In het geval van privacy gevoelige data zal je eerder geneigd zijn om de zaak goed op slot te zetten terwijl er andere scenario’s denkbaar zijn waarbij meer vrijheid op zijn plaats is.

Toch wil je in alle gevallen wel grip houden op je endpoints en alles wat daar op staat. Effectief resulteert dat er in dat in de gevallen dat je meer vrijheid geeft je ook meer monitoring zal toepassen om ten alle tijden te weten welke applicaties er gebruikt worden, welke datastromen er van en naar deze endpoints gaan, welke processen er allemaal draaien en hoe dit alles met elkaar samenhangt.

Alhoewel alles op slot zetten de veiligste optie lijkt heeft het wel als gevolg dat de kans dat de gebruikers om de officiele IT systemen heen gaan werken aanzienlijk toeneemt. Als de gebruiker vindt dat hij/zij niet goed kan werken met de aangeboden toolset zal er gezocht worden naar alternatieve werkwijzen die mogelijk buiten het zichtveld van de security en IT afdelingen liggen, met alle risico’s van dien.

Zoals met alles is het dus zaak om een balans te vinden en dat valt of staat met een goed beeld van de risico bereidheid van een organisatie. Die zal anders zijn voor een ziekenhuis dan bij een loodgieter, maar de ene loodgieter is ook de andere weer niet.

Sidenote: Technische uitdagingen bij totale vrijheid

Bij een groot deel van de organisaties zie je dat er een consolidatie plaatsvind van security componenten in het Microsoft framework. Het verwerken van deze data vergt verregaande automatisering en veel kennis, zeker ook omdat enkel het verwerken niet voldoende is, er moet ook nog geacteerd worden op de bevindingen. (Bij voorkeur automatisch). Het consolideren van deze componenten in één omgeving maakt de implementatie overzichtelijker en sneller en je kan bovendien leunen op de expertise van een gigant als Microsoft. Het voordeel is dat het vrijwel onzichtbaar is voor de eindgebruiker en zelfs voor een groot deel van de beheerders, maar het risico is dat de effort om dit goed te implementeren vaak onderschat wordt.

Gevolgen voor security awareness

Hebben de bovenstaande keuzes dan impact op de security awareness training? Voor sommige feitelijke componenten wel uiteraard, je kan lastig in een training verkondigen dat de gebruiker zelf geen applicaties mag installeren terwijl dat wel zo is. Maar in zo goed als alle andere onderdelen van de security awareness training zou het niet al te veel uit moeten maken

Security awareness zou moeten gaan om het activeren van bewustzijn en gedragsveranderingen. En dat gaat verder dan alleen de training zelf natuurlijk. Het moet normaal worden om elkaar ook aan te spreken op zaken die niet door de beugel kunnen, dus ook jij kan die projectengineer die “tijdelijk” even het wachtwoord Welkom01 invult daar gewoon op aanspreken.

Elkaar aanspreken is dus geen synoniem voor “de ander voor de bus gooien” en dat is misschien ook nog iets waar we met zijn allen in het security domein nog wat over kunnen leren. Tenzij iemand een “veelpleger” wordt moeten we er vanuit gaan dat security nou eenmaal niet top-of-mind is voor iedereen. Daarnaast heeft harder schreeuwen maar zelden tot een oplossing geleid (ik hoop dat mijn kinderen dat ooit nog leren).

Bomen in een bos
De gebruikers zien door de bomen het bos niet meer

Mensen met een technische achtergrond zijn geneigd om te vergeten dat niet iedereen dezelfde technische basiskennis heeft. We grijpen dan ook te vaak naar het uitleggen van de technische maatregelen. Zaken als “controleer de URL in de mail goed voor je klikt” terwijl het overgrote deel van de bevolking geen idee heeft van wat een URL nu eigenlijk is, laat staan hoe je een Office365 safelink kan controleren.

Focus op gedragsverandering

Het is goed om mensen bekend te maken met termen zoals Phishing, Spam, Malware, Cryptolocker en al dat soort zaken, maar voornamelijk om context te bieden voor alle berichten die ze daarover tegenwoordig voorbij zien komen.

Het doel van security awareness zou niet zo zeer het trainen van technische handelingen moeten zijn. Maar een gezond wantrouwen tegenover zaken die je zelf niet onder controle hebt. En doe dat in een context die mensen kennen of waar ze meer affiniteit mee hebben. Een voorbeeld:

Als iemand ergens snoep op de grond vind hebben we allemaal geleerd dat we dat beter niet op kunnen eten. Dit leren we al op jonge leeftijd en gaan zelfs nog een stapje verder, als je snoep aangeboden krijgt van een vreemde leren we onze kinderen dat je dat moet weigeren.

Hoe is dit anders dan het vinden van een USB stick op de parkeerplaats? Je zal er zelf niet ziek van worden of worden gedrogeerd, maar je laptop wel..

Snoepgoed
Snoep, toch?

Door te linken aan allerlei zaken die al vanaf onze jeugd in ons brein geprint zijn kunnen we security zaken die van origine puur technisch zijn aanhaken op ons instinct wat we al jaren gekweekt hebben.

Een ander makkelijk voorbeeld is vreemden binnenlaten op het kantoor. We zouden thuis iemand die bij de deur staat die we niet kennen nooit zomaar binnen laten, maar toch vinden we het op kantoor vrij normaal om iedereen maar gewoon mee door de deur te laten lopen. Er heerst een soort van schaamte om toch even te vragen of die persoon er wel hoort.

Daarnaast moeten we ons aanleren dat we berichten die we ontvangen allereerst moeten toetsen op of we een dergelijk bericht wel verwachten en of het past bij de afzender. Een directeur die ineens een Engelse mail stuurt om geld over te maken terwijl hij dat anders nooit zou doen moet natuurlijk alarmbellen af laten gaan. Maar ook de mail van een “webshop” die ineens op je zakelijke adres binnen komt terwijl je daar zakelijk niets koopt moet wel wat te denken geven.

Conclusie

Ik heb de wijsheid niet in pacht en er zullen ongetwijfeld anderen zijn die hier een andere visie over hebben. Maar ik denk dat we het met zijn allen eens zijn dat te technische security awareness trainingen eerder een averechts effect hebben op de bewustwording. Gelukkig lijkt de markt voor dergelijke trainingen zich dat ook te realiseren. Wel zijn er kansen voor trainigen juist gericht op het IT personeel van een organisatie.

Met een focus op gedragsverandering en het aansluiten op zaken die mensen al kennen vanuit het dagelijkse leven die niet per se IT gerelateerd zijn kunnen we gebruik maken van het gezonde wantrouwen wat iedereen tot op zekere hoogte in zich heeft. IT is immers meer en meer verweven in het dagelijkse leven, en het bewustzijn van de risico’s die daarbij komen kijken behoren dan ook tot de basiskennis die iedereen zou moeten hebben.

Ik heb een game geschreven

Eigenlijk een hele tijd terug al, maar het was er nog niet echt van gekomen om daar hier wat over te schrijven. Nu met een klein beetje extra tijd is het wel aardig om eens wat inzage te geven over hoe ik het schrijven van een web-based spel nu eigenlijk aangepakt heb. Niet op de laatste plaats omdat ik daar 0 ervaring mee had, en als ik het kan dan kan jij het ook.

Het gaat hier om clickfarm.nl een simpele web game die uiteindelijk draait om het verzamelen van zo veel mogelijk geld met een zo goed mogelijk gebalanceerd en geautomatiseerd productie proces.

Clickfarm landbouw knop
Dit zou ik niet handmatig blijven doen 😉

Waarom heb ik een game geschreven?

Ik vroeg me af of ik mezelf iets helemaal nieuws kon leren, alhoewel ik in het verleden wat PHP geschreven heb in in mijn werk de nodige scripts schreef wilde ik graag weten of ik ook HTML, CSS en Javascript kon leren.

Wat begon met een knop die simpelweg een teller liet oplopen mondde uit in een volledig spel met meer dan 2.000 regels code (dat had vast efficiënter gekund). Ik heb veel geleerd over JavaScript en ook het nodige over HTML en CSS, maar daar ligt voor mij toch minder de focus.

Random clickfarm broncode
Random clikcfarm code (game geschreven)

Mijn doel was dus het leren van een nieuwe taal, en dit is de eerste keer geweest dat er voor mij ook echt wat geklikt heeft waarbij ik het gebruik van objecten, functions en al dergelijke zaken ook heb kunnen plaatsen. Alles wat ik hierna geschreven heb voelt aanzienlijk eenvoudiger omdat er blijkbaar wat op zijn plek gevallen is.

Hoe heb ik de game geschreven?

Excessief gebruik van Google en heel veel proberen. De aanpak was heel iteratief en ik heb niet vooraf een groot plan gemaakt over hoe de bouw er uit zou gaan zien, sterker nog, de meeste functionaliteit is on the fly bedacht terwijl ik het aan het schrijven was. In dat opzicht is het een klein wonder dat het spel zo goed werkt als dat het doet.

Verder heb ik zeker in de latere stadia van de ontwikkeling veel input gebruikt vanuit onder andere het forum op Tweakers.net om het nodige in balans te brengen.

Ik denk wel dat dit een mooi voorbeeld is van hoe je als je enige affiniteit hebt met scripting vrij eenvoudig je kennis steeds verder kan uitbreiden. Begin met een klein projectje en bouw daar op door, probeer niet meteen de lat te hoog te leggen en accepteer dat het een zeer iteratief proces gaat zijn.

Learn krijtbord

Wat is er van gekomen?

Los van dat ik er een hoop van geleerd heeft hebben een hoop mensen veel tijd van hun leven verloren met het spelen van het spel. Op de piek waren er 400+ gelijktijdige spelers met een paar duizend bezoekers per dag op de site. Ik heb nooit reclame op de site gehad, maar wel de mogelijkheid geboden om donaties te doen, en wonderwel ook daadwerkelijk voor een aardig bedrag aan donaties ontvangen (dat had ik niet verwacht).

Voor mezelf is het voornaamste doel bereikt, ik heb weer een nieuwe taal geleerd waar ik comfortabel mee aan de slag kan. De stap naar NodeJS is inmiddels ook gezet dus ook daar ben ik inmiddels de nodige kennis van op aan het doen.

Tot slot

Alhoewel ik niet uitsluit dat ik later nog een klein stukje verder schrijf aan het spel en mogelijk het een en ander zal moderniseren acht ik dit ook weer niet heel waarschijnlijk. Het is een mooi project geweest en ik heb er een hoop van geleerd, maar het verder onderhouden zou wel aardig wat tijd gaan kosten waar voor mijzelf eigenlijk niets meer tegenover staat.

De code van het spel is beschikbaar op Github, mocht iemand nog goede toevoegingen aanbieden via die route zal ik die waarschijnlijk nog wel implementeren.

GitHub – HermanRonk/Clickfarm: Clickfarm webgame

Detron Open Script Night – Ronde 1

Als een van de Business Developers bij Detron IT Consultants mag ik samen met het als team altijd zoeken naar methoden om onze collega’s kennis te laten maken met nieuwe systemen en technieken. Maar soms moet je ook de aanpak van deze kennisdeling eens op de schop gooien om zo een andere groep mensen te bereiken of een hoger niveau te behalen. Zeker op het gebied van het schrijven van een script ten behoeve van automatisering zien we het niveau flink stijgen en moeten we de aanpak dus veranderen.

Zo gaan we na 2 jaar aan PowerShell bootcamps eens proberen om op een hele andere wijzen kennis te delen over niet alleen PowerShell, maar ook andere scripttalen waar we in onze dagelijkse werkzaamheden mee in aanraking komen. Het resultaat van wat berichten heen en weer tussen collega’s was dat we vanuit het Detron ICT Kenniscafé (communicatie middel en organisatie van een deel van onze kennissessies en trainingen en mijn hobby op het werk 😉 ) ook wel een Open Script Night konden houden. Hier kunnen collega’s of externe sprekers in 10-20 minuten een demo en toelichting geven van iets wat ze zelf gemaakt hebben en misschien handig is voor collega’s.

Als we deze korte sessies combineren met een introductie van een nieuwe of bestaande techniek die voor iedereen interessant kan zijn hopen we een leuke actieve avond te hebben. Het is niet de bedoeling dat bezoekers alleen maar gaan zitten luisteren, maar ook direct met de laptop aan de slag kunnen om ervaring op te doen met wat ze horen en zien.

Ondanks dat ik met al 6 jaar bezig houd met het organiseren van trainingen en sessies heb ik anders dan het welkomstwoord nog nooit zelf inhoudelijk gesproken op een sessie, gezien een van mijn hobby’s nogal wat met scripting te maken heeft (clickfarm.nluitleg) was dit een mooie gelegenheid om hier ook een keer verandering in te brengen. Tijdens de eerste Detron Open Script Night zal ik 30 minuten spreken over twee tools die mij enorm helpen en een stukje techniek waar ik dagelijks mee in aanraking kom. Een van de andere onderwerpen  waar we deze eerste avond naar gaan kijken is git, wat mij betreft ook een onmisbaar stuk gereedschap voor het onderhouden van je scripts.

Onderwerp 1: Visual Studio Code (script editor)

Visual Studio Code een erg mooi stukje gratis software van Microsoft voor het schrijven van je code. Voor de meeste talen is er een intellisense module beschikbaar. Daarnaast zorg de Emmet.io integratie voor een aanzienlijke versnelling van het schreven van de code. Ook een directe integratie met git draagt bij aan een goede workflow. Visual Studio Code - Script editor

Onderwerp 2: Postman

Eigenlijk al een stukje voorbereiding op het derde onderwerp, maar Postman is een tool voor het testen van allerlei web connectoren (om het maar eens heel simpel uit te leggen). De eerste keer dat ik er mee in aanraking kwam was voor het testen van de backend voor Clickfarm, maar inmiddels gebruik ik de tool ook zakelijk.

Postman API Test suite

Onderwerp 3: Web-connectoren (API’s)

Wanneer je meerdere (SaaS) systemen aan elkaar wil koppelen ontkom je niet meer aan allerlei verschillende API’s. Nou zijn er aardig wat standaarden, maar in hoofdlijnen werken ze technisch veelal hetzelfde. Reden genoeg om eens beter te kijken wat nu de kracht kan zijn van een goede API, maar ook wat de uitdaging kan zijn als je meerdere passieve systemen wil koppelen.

api grafische weergave

 

Let’s encrypt

Sinds gisteren is Let’s Encrypt in public beta en daarmee dus ook voor iedereen beschikbaar. Nou zal dat niet iedereen direct wat zeggen, maar ik denk dat dit een ontwikkeling is die een grote verandering op het internet met zich mee zal brengen. Nou betreft het wel een verandering die voor 90% van de mensen niet zullen merken, maar dat maakt het niet minder belangrijk.

letsencrypt-logo_0

Wat veel mensen niet beseffen is dat verkeer van en naar een website in principe voor alle “hops” tussen jouw pc en de server vrij in te zien is. Voor banken zijn we al wel gewent aan het feit dat er een groen slotje bij de domeinnaam moet staan, maar bij veel andere websites denken we daar niet over na. Het gebruik van encryptie lost dat probleem op, het verkeer tussen de client en de server is met certificaten beveiligd en voor de tussenliggende systemen niet in te zien.

Het probleem is echter dat de certificaten hiervoor geld kosten, alhoewel ze niet heel duur zijn (12 euro per jaar grofweg) wordt het voor veel content niet echt als noodzakelijk gezien om de bezoeken te beveiligen. De complexiteit van het onderhouden van deze certificaten is echter een groter probleem. Niet alleen is het veel handwerk om een certificaat goed op je eigen server te installeren, maar het is ook nog eens iets wat je niet moet vergeten bij te houden (wederom handmatig).

Let’s encrypt brengt hier verandering in, niet alleen zijn de certificaten gratis, maar er wordt een tool meegeleverd die de hele aanvraag en implementatie voor je uitvoerd. Daarbij zorgt de tool ook voor een tijdige vervanging van de certifcaten wanneer de einddatum in de buurt komt (een “le” certificaat is 90 dagen geldig).

Het draaien van de tool geeft een wizard die er grofweg zo uit ziet:

Certificaat Aanvraag

En de rest gaat eigenlijk vanzelf, je kan nog even aangeven of de site zowel via HTTP als HTTPS bereikbaar moet zijn of enkel via HTTPS en dat was het dan.

Wanneer we dan controleren of het certificaat goed geïmplementeerd is zien we dat ook dat helemaal in orde is:

Certificaat Controle

Het mooie aan de automatische implementatie is ook dat er eigenlijk niets in de weg staat om dit ook bij shared hosting oplossingen te implementeren. Het gehele traject kan volledig geautomatiseerd worden en een gebruiker hoeft er dus helemaal niets aan te doen. Wat misschien wel nog een blokkade kan zijn is dat voor een groot aantal providers een aardig stukje omzet kan wegvallen doordat ze nu geen tussenpartij meer hoeven te zijn tussen de grote certificaat verstrekkers en de “consument”.

Voor het testen van dit soort zaken gebruik ik overigens meestal een VM bij Digital Ocean, het grote voordeel is dat je deze per uur betaald, wat een root voordeel is voor het even snel testen van nieuwe dingen. De bovenstaande link is overigens een referral link, die levert je 10 dollar aan start tegoed op (1 maand voor een server met 1 core en 1 GB ram). Mocht je mij geen extra tegoed gunnen kan je natuurlijk altijd zelf even het adres invullen als je een account wil :). De gebruikte testomgeving heb ik gebouwd op Ubuntu 15.10 met Apache, PHP en MySQL.

 

 

Connected

Je kan het tegenwoordig zo gek niet meer bedenken of het is verbonden met de “cloud”, waar dat voor je telefoon nog redelijk vanzelfsprekend is gaat er misschien bij je wasmachine minder snel een lampje branden. Toch is alles wat je tegenwoordig met een app op je telefoon of tablet kan bedienen over het algemeen aangesloten op een “cloud”. Dus als je je lampen kan bedienen met een app op je telefoon, of als je je auto van te voren kan verwarmen is dat over het algemeen iets wat via een internet dienst werkt. (uitzonderingen daargelaten natuurlijk).

Nou is dat natuurlijk allemaal heel erg handig, maar er zijn ook wel een aantal haken en ogen waar we denk ik op dit moment net even te gemakkelijk mee om gaan. Zo doet eigenlijk iedereen de aanname dat de leverancier van dergelijke spullen er voor zorgt dat alles veilig is, alleen is dat wel altijd het geval? Ze zullen ongetwijfeld tot op zekere hoogte hun best doen, mogelijk brengen ze tussentijds ook firmware updates uit voor hun devices.. Maar als je nu al een beetje vreemd begint te kijken bij het woord firmware in combinatie met je wasmachine of lamp is de kans aanzienlijk dat je deze nieuwe versie nooit zal uitrollen. En dan hebben we natuurlijk ook het moment waarop de leverancier geen ondersteuning meer levert op het apparaat..

Wat gebeurt er als dan een of andere knutselaar ontdekt dat je doormiddel van een simpel commando de temperatuur van je wasdroger net iets hoger in kan stellen waardoor je was toch al 10 minuten sneller droog is. Klinkt als een wenselijke situatie, mensen die een product beter maken door met de firmware aan de slag te gaan. Helaas heeft niet iedereen de beste bedoelingen, en zelfs de mensen die dat wel hebben kunnen fouten maken.. Wat als dan iemand de temperatuur niet “iets” verhoogd, maar verdubbeld, met brand als gevolg? In dit geval zou je daar zelf nog wat voor gedaan hebben (een andere firmware inladen), maar wat als een dergelijke setting naar je wasdroger gepushed zou kunnen worden via een verbinding naar de cloud die eigenlijk alleen maar bedoeld was om jou te laten weten hoe laat de wasmachine klaar zou zijn?

Een dergelijk scenario is niet denkbaar als je een niet connected “dom” apparaat hebt, maar als je alles aan het internet gaat hangen en geen goede maatregelen treft voor de veiligheid van dergelijke embedded systemen wordt het een heel ander verhaal. En dan gaat het dus lang niet altijd over de bedoelde functionaliteit, in het geval van de wasdroger kan het zo zijn dat de fabrikant de connectie eigenlijk alleen gebruikt voor het doorgeven van de resterende droogtijd naar een app. Maar als bij het ontwikkelen van de firmware / software onvoldoende is nagedacht over het scheiden van bijvoorbeeld de aansturing van de machine en het verzamelen en verzenden van data zoals resterende looptijd is de kans nogal groot dat een creatieveling wel een manier vind om de beide systemen met elkaar te verbinden.

Nou klinkt dit misschien wat vergezocht, alleen als je dan bedenkt dat er in de VS meer dan een miljoen auto’s teruggeroepen worden omdat de boodcomputer van afstand de besturen is, tot en met het aansturen van het gas en rempedaal aan toe denk ik dat we misschien wel een beetje zijn doorgeslagen. Nou ben ik op zich niet tegen de ontwikkeling om apparaten aan het internet te hangen om ze vanaf afstand te kunnen monitoren / aansturen, maar ik denk wel dat we nog een hoop te leren hebben om dit op een veilige wijze te kunnen doen.

De vraag is ook een beetje hoe dit soort problemen voorkomen kunnen worden. Bedrijven zijn nog wel eens geneigd om shortcuts te nemen als ze denken dat de kosten van een eventuele terugroepactie of een rechtszaak lager zijn dan de kosten om het probleem daadwerkelijk te voorkomen. Ik zelf denk dat bedrijven hier niet meer mee weg gaan komen nu dit soort informatie steeds vaker voor het grote publiek beschikbaar is. Het zal wel nog even duren voordat de echte grote logge bedrijven de omschakelen zullen maken, maar op termijn zal de veiligheid een grotere rol gaan spelen en eindelijk ook de aandacht krijgen die het verdient.

Totdat goed beveiligde connected apparaten mainstream geworden zijn is het denk ik in ieder geval een goede zaak om jezelf steeds weer af te vragen of het wel nodig is om een product daadwerkelijk aan een cloud te hangen, en of het het risico waard is.