Kennismakingsevent 29 maart 2019

Afgelopen vrijdag was ons kennismakingsevent in het sfeervolle Jazzmin op het science park. De groep geïnteresseerde softwareprofessionals omarmden al snel onze missie en fijne sfeer.

Na het welkom heeft Jan onze historie en missie toegelicht. Vervolgens heeft Ewan zijn ervaringen verteld. Deze ervaringen werden natuurlijk aangevuld door de ervaringen van Stijn, Rens, Fabian en Joeri. Daarna hebben we uitgelegd wat we de komende jaren voor de software-industrie willen betekenen. Met name onze twee pijlers Cloud Software Development en Cloud Transities kwamen uitgebreid aan bod.

Daarna natuurlijk gezellig napraten met Bites & Drinks; het meest leuke en waardevolle om in groepje zo ervaringen te delen.

Met dank aan de organisatoren en de gastvrijheid van Jazzmin.

Tot de volgende keer!

Haal meer uit je data

Een introductie tot Data Mining met CRISP-DM

Het belang van data

Data is altijd al een belangrijke factor geweest in de zakenwereld, maar nog nooit was het zo makkelijk om data te verzamelen als tegenwoordig. Giganten zoals Google en Facebook hebben ons geleerd, dat hoe meer data je tot je beschikking hebt, des te beter kan je groeien als bedrijf. Hierbij wordt snel vergeten dat je alleen met pure data niet veel kan zeggen. Het is een heel proces en ook een bepaalde manier van kunst om van je data inzichten te genereren en dat is waar de echte waarde pas tot stand komt. Om je hierbij te helpen werd CRISP-DM bedacht. In het vervolg van dit artikel worden voorbeelden gebruikt binnen het domein van websites en webapplicaties om het proces van CRISP-DM beter te verduidelijken.

 

CRISP-DM

CRISPDM-Extended.png

CRISP-DM staat voor Cross Industry Process for Data Mining en is het standaard proces met betrekking tot het genereren van inzichten uit ruwe data. De complete CRISP-DM methodology bestaat uit meerdere levels van abstractie, maar in dit artikel wordt hoofdzakelijk op de 6 fasen ingegaan. Daarnaast worden de desbetreffende generieke taken besproken om een beter beeld van de fasen te kunnen krijgen. Deze zes fasen zijn als volgt:

 

  1. Business Understanding

  2. Data Understanding

  3. Data Preparation

  4. Modeling

  5. Evaluation

  6. Deployment

 

CRISP-DM gaat uit van een flexibele aanpak, het moet dus altijd mogelijk zijn om van een fase naar een vorige fase te kunnen gaan.

Business Understanding

De eerste fase is een belangrijke fase, die vaak over het hoofd wordt gezien. De focus ligt bij een goed begrip krijgen van de projectdoelstellingen en -vereisten vanuit een zakelijk perspectief. Binnen deze fase hoor je de probleemdefinitie en het voorbereidend plan op te stellen voor je doelstellingen. Zorg er dus voor dat je weet waar je naar op zoek bent en met welke middelen je aan de slag wil gaan om deze doelstelling te bereiken.

Een website met doel te informeren zal een metric, die beschrijft hoe lang een gebruiker op een pagina blijft, interessanter vinden, dan een webwinkel, die meer wil weten over het gedrag voordat een conversie plaatsvindt.

Data Understanding

ai-artificial-intelligence-blur-546819.jpg

In deze fase ga je dieper in op je data, die je van plan bent om te gebruiken. Bekijk goed welke bronnen je ter beschikking hebt en in hoeverre deze bij dragen aan het behalen van je doelstellingen. Het identificeren van kolommen die missende of onbetrouwbare informatie bevatten is cruciaal. Je zult vast moeten leggen in hoeverre deze data nog bruikbaar is of beter genegeerd kan worden. Hier komt nog bij dat bepaalde metrics verschillende definities kunnen hebben afhankelijk van de persoon die deze vraagt.

Zorg er dus voor dat elke metrics een duidelijke definitie heeft en dat deze definitie ook gedeeld wordt met de personen die de data moeten interpreteren of gebruiken.

Een voorbeeld zou de metric sessieduur zijn. Om deze metric goed te kunnen interpreteren is het van belang om te weten wanneer een sessie start en stopt. Definitie één kan zijn: “De sessieduur is gelijk aan de tijd dat men ingelogd is”. Een andere definitie kan als volgt zijn: “Een sessie start bij de eerste interactie van een gebruiker en nadat de gebruiker 15 minuten inactief is geweest zal deze sessie stoppen; De sessieduur is de tijd tussen de eerste en laatste interactie”. Dan stelt zich wel weer de vraag, wat is een interactie? Alleen clicken, of ook scrollen?

Data Preparation

            Als het goed is heb je een goed begrip daarvan hoe je data uit ziet aan de hand van de vorige fase. Iets dat je opgemerkt zou kunnen hebben, is dat de een kolom data bevat die dezelfde elementen soms anders weergeeft. Een andere opmerking zou kunnen zijn, dat de data die je hebt gemeten verschillende eenheden bevat binnen dezelfde kolom of de verkeerde data types. Het is de bedoeling van deze fase om deze kolommen op te schonen, zodat er geen misverstanden zijn en alle daten aan dezelfde eisen voldoen.

            Stel je voor jou website bevat een formulier waar gebruikers in kunnen vullen hoe groot ze zijn. Nu heeft jouw website internationale gebruikers en vullen deze soms in cm, m of feet in. Aan de hand van je gedefinieerde metrics in de vorige fase, zul je deze kolom kloppend moeten maken, zodat elk getal of cm, m of feet is.

Modeling

            In deze fase is het de bedoeling de data zo te transformeren en te modelleren, dat deze klaar is om gevisualiseerd te worden. Afhankelijk van de complexiteit van je vraagstuk zal deze fase voor uitdaging kunnen zorgen. In vele gevallen wil men een trend waar kunnen nemen binnen bepaalde classificaties of groeperingen, waardoor vaak aggregaties toegepast worden.

            Voor dit voorbeeld hebben wij een webshop en het vraagstuk is wat voor invloed de sessieduur heeft op het koopgedrag. Bij deze aanpak groeperen wij de gebruikers per 3 minuten die ze doorbrengen op de website, omdat de gemiddelde sessieduur 8 minuten is. Hierdoor krijgen wij 5 groeperingen met een voldoende aantal gebruikers om er een mening over te vormen. De overigen gebruikers filteren wij weg, gezien deze voor ruis zorgen. Voor elk van deze groep berekenen wij de som van het aantal conversies die ze hebben gepleegd elke dag. Nu kunnen wij deze tabel makkelijk visualiseren om er uiteindelijk een conclusie uit te kunnen halen.

Evaluation

            Dit is de fase, die beslist of de ontdekkingen voldoen aan de criteria. Hierbij wordt terug gekeken naar het gehele process hoe men tot deze statistieken is gekomen. Je vraagt je af of de data die gebruikt werd, compleet en toepasselijk is, men controleert of er geen fouten zijn ontstaan tijdens de data preparation en modeling en als alles klopt kan men doorgaan naar Deployment. Is dit niet het geval, gaat men terug naar de desbetreffende stap gaat vanuit daar weer verder. Een fenomeen dat regelmatig voorkomt, is dat er inzichten waargenomen worden, die voor het desbetreffende partij al eerder heeft waargenomen, dit kan afhankelijk van de situatie handig zijn of betekenen dat je met een nieuw vraagstuk aan de slag moet.

Deployment

Dit is de laatste fase waar men alleen terecht komt als de evaluatie geslaagd is. Activiteiten binnen deze fase is een deployment plan schrijven, kijken hoe men deze inzichten voortdurend kan monitoren & onderhouden en het maken van het Final Report en/of Presentation. Met andere woorden er wordt ervoor gezorgd, dat de inzichten duidelijk weergegeven, goed beschikbaar gesteld en bijgehouden worden, zodat er bedrijfsdoelen of keuzes gevormd kunnen worden.

XML External Entities (XXE)

XML External Entities (XXE).jpg

Wat is het en waar komt het voor?

Een jaar of tien geleden is XML de standaard geworden en sindsdien is het gebruik ervan sterk toegenomen. Daarmee is XML tegelijkertijd ook voor kwaadwilligen steeds interessanter geworden. Een van de kwetsbaarheden die XML met zich meebrengt, die deze aanvallers gebruiken, zijn XML External Entities, afgekort XXE.

Zoals voor de meeste bekend is, is het mogelijk om in XML via de syntax <!ENTITY entity-name SYSTEM “URI/URL”> een eigen entiteit te definiëren. Dit kan in het document zelf gedaan worden - een internal entity - of door een extern document via een URI/URL te importeren, waarin deze definitie staat - een external entity. Het laatste geval is waar de kwetsbaarheid XXE gebruik van maakt. Het kan zich dan ook voordoen op elke plek waar dit toegestaan is.

Een typische XXE-aanval geeft op de plaats van de URI/URL een XML bestand mee waarin kwaadwillige code staat, of juist een verwijzing naar iets volledig anders. Denk aan iets als “file:///etc/passwd” om toegang tot privégegevens te kunnen krijgen. Of een URL in de vorm van “https://”192.168.1.1/private”, waarmee via dit IP-adres van de router het bedrijfsnetwerk verkend kan worden.

Wat kunnen de gevolgen zijn?

Zoals zojuist vernoemd, heeft een aanvaller vele mogelijkheden om gebruik te maken van deze kwetsbaarheid in XML. Het zal dan ook erg afhangen van het doel van de aanvaller wat de gevolgen zullen zijn. Enkele mogelijke gevolgen van een XXE exploitatie zijn:

  • Extractie van (gevoelige) gegevens.

  • Blootstelling van de interne structuur van je bedrijf.

  • Een DoS, zoals de Billion Laughs aanval.

  • Legio andere aanvallen, doordat er remote requests gedaan kunnen worden.

Hoe beveilig je je er tegen?

Deze kwetsbaarheid doet zich in tegenstelling tot sommige andere voor op één specifieke plek. Hierdoor is XXE in theorie heel makkelijk te verhelpen, namelijk door simpelweg XML in zijn geheel te vermijden. Gebruik als alternatief een simpeler data format, zoals JSON.

Echter, als XML alom gebruikt wordt in jouw applicatie of web service, dan is bovenstaande oplossing niet of lastig toe te passen. In dat geval kun je als bedrijf logische stappen nemen zoals XML-validatie - zodat niet zomaar ongecontroleerd alle XML geparsed wordt - en het verminderen of zelfs vermijden van serialisatie. Implementeer hiervoor bijvoorbeeld Apache Xerces in je pipeline om dit na een relatief simpele set-up geautomatiseerd te laten doen. Daarnaast kun je een dependency checker zoals Dependency-check-maven implementeren, die kwaadaardige XML files detecteert, zelfs als ze zeer diep nested zijn.

 

Vooruitblik

Het volgende artikel zal over een vrij algemeen fenomeen gaan: Broken Acces Control. Voor de echte hacker is dit een absolute basisvaardigheid. Voor ieder serieus bedrijf zou hiervoor dan ook een absolute basisbeveiliging moeten zijn. In de praktijk blijkt dit echter vaker niet dan wel het geval te zijn. Soms door laksheid, maar vaak door onwetendheid. Want hoe zorg je er als bedrijf nu eigenlijk voor dat niet heel je database direct volledig bloot gesteld wordt doordat de secretaresse een foutje gemaakt heeft? Lees het in het vijfde artikel van mijn cybersecurity reeks.

Het generaliseren van Jenkins Pipelines binnen een complexe omgeving/organisatie.

In een complexe en dynamische omgeving wilt men waar mogelijk, altijd iets generaliseren om de complexiteit te verminderen. In een omgeving waar alle teams CD (Continuous Delivery) enabled moeten zijn, is het dus handig dat nieuw gevormde teams gelijk aan de slag kunnen met Continuous Delivery. In plaats van dat de teams alles opnieuw moeten uitvinden, terwijl dat binnen de organisatie al meerdere keren gedaan is, kan het team gelijk aan de slag met de kennis die vergaard is door de jaren heen binnen de organisatie.

Jenkins Pipelines.png

Een voorbeeld: hoe je nieuwe teams CD enabled inricht.

Door een standaard pipeline te bieden voor de teams, waarmee ze gelijk aan de slag kunnen, richt je CD enabled in. Als het ware creëer je dan een pipeline als product voor deze teams. Door verschillende standaard pipelines aan te bieden is het mogelijk om de complexiteit voor de omgeving te minimaliseren. In deze blog laat ik je zien hoe je hiermee begint en de manier waarop je pipelines implementeert door middel van Jenkinsfiles (Pipeline als code/script).  Met dit blogaritkel geeft Ewan inzicht in één van de oplossingen voor een gegeneraliseerde Jenkins pipeline, maar natuurlijk zijn er nog velen manieren.

 

Stap 1: inventariseer de huidige oplossingen binnen de organisatie

Allereerst, is het van belang om de huidige oplossingen binnen de organisatie te inventariseren, bijvoorbeeld: wat voor tools gebruiken de teams? Hierdoor maak je de variatie tussen de teams en de complexiteit van de organisatie zichtbaar. Vervolgens ga je op basis van deze variatie beslissen, welke tools je in de pipeline gebruikt, en welke teams een andere werkwijze volgen om de standaarden van de organisatie te volgen. De oplossingen die gemaakt zijn binnen de organisaties kun je ook inventariseren. Wie weet komen daar weer hele andere oplossingen uit, die je als gegeneraliseerde/standaard Jenkins pipeline zou kunnen toepassen.  

 

Stap 2: bouwen/verzamelen scripts

Binnen deze stap is het belangrijk om als basis vanuit de volgende denkwijze een gegeneraliseerde Jenkins pipeline te realiseren: zorg er allereest voor dat alles ´Configuration as Code’ is. Iedere Jenkins server, pipeline of job moet als code uitgeschreven staan. Hierdoor voorkom je dat er handmatig beheer nodig is via een UI, wat foutgevoelig kan zijn als de verkeerde mensen het gebruiken. Omdat alles in code is geschreven, komt het regelmatig voor dat je zelf handmatig een script moet schrijven in plaats van een plugin in Jenkins gebruikt, die je via de UI werkend krijgt. Mogelijk moet je voor elke tool die je in de pipeline toepast een script schrijven. Binnen complexe organisaties zijn er vaak al scripts bruikbaar die ergens in een repository staan. Wanneer je deze scripts allemaal gebouwd of verzameld hebt, kan je deze scripts runnen vanuit een job om het overzichtelijk te houden.

 

Stap 3: creëer downstream jobs

In deze stap zorg je ervoor dat je downstream jobs maakt, die een enkele script uitvoeren voor een specifieke tool. Op deze manier is het mogelijk om Jenkinsfiles flexibel te creëren. Het uitvoeren van meerdere downstream jobs achter elkaar vanuit de upstream job, zorgen ervoor dat je gemakkelijk een pipeline maakt door blokjes (downstream jobs) aan elkaar te koppelen. Hierdoor is het heel makkelijk om standaard Jenkinsfiles te maken, omdat dit alleen een kwestie is van aangeven welke blokjes je kiest. Verder zit de implementatie ver weg gestopt voor de teams, waardoor zij met beperkte kennis gemakkelijk aan de slag kunnen. Daarnaast is het voor de teams belangrijk dat zij de juiste parameters meegeven aan de downstream jobs om er voor te zorgen dat de pipeline succesvol wordt afgerond.

Jenkins logo.png

 Stap 4: maak standaard Jenkinsfiles

Zoals eerder beschreven, hoeft de Jenkinsfile alleen maar downstream jobs aan te roepen. Hierdoor zijn de Jenkinsfiles redelijke basaal en komt er niet veel bij kijken. Om het allemaal nog eenvoudiger te maken, is het mogelijk om ervoor te kiezen om in de Jenkinsfile nog een stukje code toe te voegen. Hierdoor laden de parameters zich automatisch in uit de repo van een team, waardoor het team alleen een bestand nodig heeft waar de variabele in staan. Op deze manier is de instapdrempel voor de teams nog lager en is het mogelijk om direct aan de slag te gaan. Uiteindelijk zit in de repo van het team alleen een file waar de variabele in staan, en een Jenkinsfile die de juiste Jenkinsfile inlaadt die nodig is voor die specifieke applicatie. Deze Jenkinsfile staat dan in een repository samen met alle configuraties voor de downstream jobs (CI/CD Library).

Stap 5: Laat de teams het gebruiken

Nu de standaard Jenkinsfiles klaar zijn, kun je de gegeneraliseerde Jenkins pipelines implementeren bij de teams. Met de vergaarde gegevens en feedback zijn aanpassingen in de pipeline zo gedaan. Wanneer een team er een nieuwe tool bij wil? Beslis met je team of het daadwerkelijk nodig is en werk het indien nodig uit als een nieuwe block. Verder is het mogelijk om de teams zelf functionaliteiten en tools toe te laten voegen door middel van pull requests op je CI/CD Library. Omdat het allemaal als code staat in een repo kun je alles community-driven laten draaien. Hierdoor heb je er zelf ook minder werk aan!

Ga je binnenkort met Jenkins aan de slag en heb je nog vragen? Laat het mij dan vooral weten.

Uitdagingen front-end web development

Front-end web development is het deel van de applicatie waar de gebruiker interactie mee heeft. In het geval van een website: het zichtbare deel van de applicatie. HTML, CSS en JavaScript zijn de meest voorkomende talen die gebruikt worden voor websites of webapplicaties. Front-end web development kent een aantal uitdagingen, waaronder het correct tonen van de website in verschillende browsers. Daarnaast wil je natuurlijk dat de site en webpagina’s snel laden voor de bezoeker.

Front-end development frameworks.png


De gebruiker staat op nummer één

Het waardevolle aan de specialisatie van front-end web development: dat de developer een hoop veranderingen aan het uiterlijk van de website kan aanbrengen om het de gebruiker makkelijker te maken. Daarmee kan de Front-End Developer daadwerkelijk verschil maken. Tegelijkertijd brengt dit voor de developer ook uitdagingen met zich mee. Een interface die voor de gebruiker prettig aanvoelt, een duidelijke navigatie en een website die vlug laadt creëer je natuurlijk niet vanzelf! In deze blog geeft Swen daarom praktische tips hoe je met deze uitdagingen aan de slag gaat.

 

Zorg dat de website werkt in iedere browser

De code voor front-end web development lijkt eenvoudig, maar door de verscheidenheid aan browsers vormt dit toch een uitdaging. Zorg ervoor dat de website in iedere browser werkt. Iedere webbrowser implementeert de standaarden namelijk net iets anders; in de ene browser kan een webpagina er perfect uitzien en in de andere browser kan de site een complete mislukking zijn. Het is dus van belang om alle gangbare browsers te blijven testen. Testing en debugging komt hierbij om de hoek kijken. Daarnaast is het mogelijk dat je in sommige gevallen een melding krijgt van een bug, waarbij je in  eerste instantie de bug niet kan reproduceren. Vervolgens switcht je terug naar de Microsoft browser Edge en dat je ineens wel allerlei problemen tegen komt.

Front-end+development+tools.jpg

Deze problemen zijn deels te ondervangen door de styling basic te houden en voor een beperkt aantal extra styling opties te kiezen. Deze specificaties zijn namelijk binnen de HTML en CSS standaarden goed gedefinieerd en werken op vrijwel alle browsers correct. Daarnaast is het belangrijk om voordat je naar buiten treedt alle browsers te testen, zodat je zeker weet dat het daadwerkelijk werkt. In sommige gevallen kom je er achter dat je wat extra code moet schrijven specifiek voor één browser, maar dat komt niet heel veel voor.

Doe er alles aan om de snelheid van de website te behouden

Een trage website zorgt voor een hoop irritatie bij de bezoeker. Je wilt natuurlijk niet dat de gebruiker je website vroegtijdig verlaat door een zeer vertraagde laadtijd van webpagina’s.

Een belangrijke trend op front-end web development gebied hierin: applicaties sneller maken door  niet meer naar full page loads te gaan. Full page load: wanneer een gebruiker naar een ander deel van de site gaat (door bijvoorbeeld op een menu item te klikken) en vervolgens de volledige HTML, CSS en JavaScript opnieuw ingeladen wordt. Tegenwoordig willen websites er steeds meer naartoe dat je alleen de content verandert die ook daadwerkelijk belangrijk is om te wijzigen. Op deze manier hoef je veel minder informatie op te halen en hoeft de browser niet de volledige site opnieuw te renderen. Met als positief gevolg: de pagina wordt een stuk sneller, waarbij je niet meer een paar minuten tegen een wit scherm aankijkt.     

Drie tips voor website performance                                            

In deze paragraaf vind je nog drie praktische en direct toepasbare tips om je website te versnellen en de user experience te verbeteren:

  1. Beperk het aantal requests op een pagina. Het is voor je code structuur overzichtelijk indien je de JavaScript in bestanden opdeelt. De structuur is hierdoor in een oogopslag helder. In productie leidt deze werkwijze wel tot een veel tragere website. Daarom de tip om alle Javascript in één bestand te zetten. Hierdoor neemt is de hoeveelheid data veel kleiner. Dit beperkt de laadtijd van een pagina. Wanneer je JavaScript samenvoegt het advies om deze te verkleinen met een minification compressor. 

  2. Gebruik foto’s en video’s met mate: beeldmateriaal op webpagina’s leidt tot het trager laden van de webpagina. Plaats daarom op de site alleen thumbnails van lage resolutie. Hierdoor laden afbeeldingen sneller. Maak de foto klikbaar, zodat deze in hoge resolutie in een apart venster verschijnen. Dit scheelt aanzienlijk in de hoeveelheid data naar de browser.

  3. Laad alleen de informatie die wijzigt: gebruik een volledige pagina refresh als dat echt nodig is. En kies de elementen uit de DOM (Document Object Model) die veranderen en plaats daar de nieuwe inhoud in.

 

Laad alleen applicaties die echt voor de server zijn

Tot slot delen we nog een belangrijke tip die je een hoop tijd en ruimte zal besparen: werk met Docker. Dit helpt je om sites lokaal te ontwikkelen. Met Docker kun je eenvoudig images maken en deze online zetten. Eerder werden er vaak virtuele machines gebruikt, dit is echter niet praktisch gezien de hoeveelheid overhead die ontstaat bij het gebruik van virtuele machines. Bij Docker worden alleen de applicaties en onderdelen geladen die écht nodig zijn.

 

Wil je ook een snellere website of nagaan of jouw website echt in alle browsers goed werkt? Deze blog heeft je dan tips en inzichten gegeven, hoe je zelf met front-end web development aan de slag kunt. Nog vragen? Neem contact met ons op.

Unit Testen versus Integratie Testen

Integration Testing vs Unit Testing.jpg

De meeste software bedrijven maken al gebruik van Unit Testen. Benieuwd naar de verschillen en in wat voor scenario je welke vorm van Testing gebruikt? In deze blog zullen we je aan de hand van voorbeelden laten zien, wanneer je Unit Testen gebruikt en kiest voor Integratie Testen. Doe er dus je voordeel mee!


Unit Testen

Om je geheugen op te frissen zullen we beiden Testen eerst verder toelichten. We beginnen met ‘Unit Testen.’ De term geeft het eigenlijk al aan: Unit Testen worden gebruikt om een unit van een code te testen. Daarbij wordt het kleinste mogelijke stukje code dat van nut is getest. Dit is in praktijk meestal een methode. Bij een methode verwacht je een vaste output bij een bepaalde input. Dit concept is wat Unit Tests testen. Een Unit Test is voornamelijk bedoeld voor programmeurs; zij kunnen hiernaar kijken en begrijpen de uitkomst van de test. Het doel van Unit tests is om te bewijzen dat de unit correct is in ieder omstandigheid.

 

Integratie Testen

Een breder begrip vormen Integratie Testen. Dat wil zeggen dat je meerdere componenten met elkaar samen gaat testen. Integration Testen worden toegepast om te bewijzen dat de componenten samen met elkaar kunnen werken. In tegenstelling tot bij Unit Testen zijn de uitkomsten van Integratie Testen voor buitenstaanders wel interessant, omdat deze makkelijker te begrijpen zijn. Voorbeelden van Integratie Testen zijn:

 

  •   Een web client testen die met de backend praat.

  •   Het testen van een component die praat met de database.

 

De belangrijkste verschillen tussen Unit Testen en Integratie Testen

De begrippen Unit Testen en Integratie Testen zijn nu duidelijk. In de onderstaande tabel staan de verschillen tussen beiden testvormen op een rijtje:

Unit Testen versus Integratie Testen

Beiden Testen toepassen

Integration Testen zijn vaak moeilijker te schrijven. Daarom is het belangrijk om verschillende en kwalitatief goede Unit Tests te hebben. In de praktijk is dit ook vaak het geval. Wanneer je genoeg unit tests hebt geschreven kun je ervan uit gaan dat de componenten het doen. Verder hoef je in deze situatie ook niet opnieuw door middel van Integration Testen uit te voeren, waardoor je je kunt focussen op de interactie tussen de componenten.

 

Daarnaast is het belangrijk om Unit Testen en Integration Testen met elkaar te combineren.
Als twee componenten veel met elkaar communiceren en het over belangrijke complexe data gaat, kun je niet zonder Integratie tests, want je moet kunnen garanderen dat de dataoverdracht tussen de componenten goed verloopt en dat fouten goed worden afgehandeld. Je kunt je voorstellen dat dit meer tijd kost om te schrijven dan een unit test, maar op deze manier wordt wel op de juiste manier de integratie tussen beiden componenten getest. Dit wordt ook wel de interactie genoemd. Daarnaast is investeren in Unit Testen en Integratie Testen een goed idee om het product schaalbaar te houden voor de toekomst. De meeste programmeurs gebruiken hierin de volgende opzet, wanneer het gaat om Testen:

  • Unit Testen (80%)

  • Integratie Testen (10%)

  •     Systeem Testen (10%)

 

Unit testing versus integration testing.jpg


Learning: zorg dat Unit Testen niet op elkaar afhankelijk zijn!

In deze blog delen we tot slot nog een learning. Het volgende gaat namelijk in de praktijk vaak mis: dat Unit Tests op elkaar afhankelijk zijn. Hierbij doet de volgende situatie zich voor: één unit test data verandert en de andere unit gaat deze data vervolgens gebruiken. Een unit test moet namelijk onafhankelijk van elkaar kunnen runnen. Het is de bedoeling dat één stuk code getest wordt en als deze afhankelijk is van een ander gaat het al snel mis. Houdt hier dus rekening mee bij de opzet van een Unit Test.

 

Dit blogartikel heeft je inzichten gegeven in de verschillen tussen Unit Testen en Integratie Testen. Met welke vorm van Testing ga jij binnenkort aan de slag? Kun je hier wel wat hulp bij gebruiken? Neem dan vrijblijvend contact met ons op.

Tips & tricks Google Analytics: meer zinvolle data halen uit je account

Bijna iedere website is tegenwoordig gekoppeld aan een Google Analytics account.    Wanneer je het dashboard van Google Analytics opent, komen er een hoop statistieken te voorschijn. Maar op welke manier voegt deze omgeving vol met data nou echt iets toe aan het bedrijfsresultaat? In dit blogartikel worden daarom een aantal tips en tricks gegeven hoe je meer waardevolle data uit Analytics statistieken haalt.

 

analytics-1925495_960_720.png

Tip 1: gebruik filters

Het Google Analytics account beschikt over een hoop data van de gekoppelde website. Lang niet al deze data zijn relevant. Filters helpen bij het toevoegen van zinvolle data. Filters zorgen er namelijk voor dat in dataweergave irrelevante data worden verwijderd. Een filter kan toegevoegd worden door in het hoofdmenu van Google Analytics naar het tabblad ‘beheerder’ te gaan. Het is belangrijk om er rekening mee te houden dat de wijzigingen, die door het gebruik van filters worden aangebracht, niet zo maar terug te draaien zijn. Om te beginnen met filters is het belangrijk om eerst de onderstaande filters toe te passen:

  • Intern verkeer wegfilteren

  • Filteren op land

Door intern verkeer van de website weg te filteren, wordt voorkomen dat er een vertekend beeld ontstaat van het aantal relevante bezoekers op de website. Op deze manier worden bijvoorbeeld werknemers, die de website bezocht hebben, niet opgenomen in de statistieken. Door het uitsluiten van het IP-adres van het bedrijf kan dit gerealiseerd worden. Meer weten? klik dan hier.

Daarnaast is het belangrijk om te filteren op land. Dit voorkomt namelijk een hoop referral spam, dat vaak uit het buitenland afkomstig is. Op deze manier blijven alleen de waardevolle data-gegevens  over. Wanneer het bedrijf zich op verschillende landen richt, kun je natuurlijk ook op meerdere landen tegelijkertijd filteren.

 

Tip 2: creëer een segment

De website genereert een hoop verkeer, maar natuurlijk wil je weten hoeveel van deze bezoekers daadwerkelijk waardevol zijn voor de website? Deze inzichten kunnen verkregen worden door het webgedrag van de bezoekers in verschillende segmenten in te delen. Zo kan er een segment worden gecreëerd van het aantal bezoeker op de website, dat overgaat tot een conversie. Op deze manier kan achterhaald worden in hoeveel procent van het totaal aantal sessies op de website er een conversie heeft plaatsgevonden. Een conversie kan bijvoorbeeld zijn: de aankoop van een product, een bezoeker meldt zich aan voor de nieuwsbrief of een gebruiker download een whitepaper. Segmenten kunnen gecreëerd worden binnen de overzichtspagina ‘doelgroep, acquisitie & gedrag’.


35682917315_37863a7e19_b.jpg

 

Tip 3: vergelijk segmenten met elkaar

Om het Google Analytics account maximaal te benutten, kunnen er verschillende segmenten met elkaar vergeleken worden. Op deze manier kan bijvoorbeeld achterhaald worden of meer mannen of juist vrouwen de website bezoeken? Of welke apparaten jouw bezoekers gebruiken en tot welke leeftijdsgroepen zij behoren en noem maar op… Segmenten met elkaar vergelijken doe je op dezelfde overzichtspagina, waarop je ook een segment aanmaakt, namelijk ‘doelgroep, acquisitie & gedrag’.

 

Tip 4: maak een aangepast rapport

Wanneer je Google Analytics opent en op het dashboard terecht komt, komen er een aantal standaard rapporten tevoorschijn. Deze bestaan niet altijd uit de meest zinvolle informatie. Daarnaast wil je natuurlijk in één oogopslag de belangrijkste resultaten van de website inzien.  Google Analytics heeft daarom een functionaliteit gecreëerd waarin je zelf een aangepast rapport kunt maken. Zo kun je bijvoorbeeld meteen zien hoe vaak er een conversie heeft plaatsgevonden, doordat er bijvoorbeeld een offerte op de website is aangevraagd. Een aangepast rapport creëer je door linksboven op ‘aanpassing’ te klikken. Vervolgens ga je naar ‘aangepaste rapporten’ en klik je op ‘+nieuw aangepast rapport’.

 

Met de bovenstaande tips kun je nu hopelijk zelf aan de slag, om waardevollere data uit je eigen Google Analytics account te halen, die de bedrijfsresultaten zullen versterken. Nog vragen? Mail dan naar e.groot@search4solutions.nl

Google Analytics logo.png

Continuous Integration met GitLab

Door Freek Schoenmakers

Logo_gitlab.png

Bij softwareontwikkeling is samenwerking essentieel. Vaak werken een heleboel ontwikkelaars tegelijk aan hetzelfde softwareproject. Het is daarom van belang dat versiebeheer goed geregeld is. Hier biedt GitLab goede ondersteuning voor. Met GitLab kun je heel gemakkelijk versies beheren en verzoeken plaatsen om een nieuwe feature aan een release toe te voegen. Maar dat is niet het enige. Een andere – zeer nuttige – functie van GitLab zijn de zogenoemde pipeline tools. Hiermee wordt het build-, test-, deployment- en provisioningproces geautomatiseerd. Naast vele softwarebedrijven zoals Ticketmaster, Uber, ING en Alibaba maakt ook Universiteit Utrecht succesvol gebruik van GitLab.


Wat is het?

Pipeline tools ondersteunen softwareontwikkeling door het automatiseren van taken zoals testen. Een pipeline is een groep jobs die worden uitgevoerd in stages. De jobs worden parallel uitgevoerd; als ze allemaal succesvol uitgevoerd zijn gaat de pipeline verder naar de volgende stage. Deze jobs en stages kunnen van alles omvatten, maar heel standaard zijn de build en test stages.

Hieronder zie je een schematische weergave van een pipeline uit een softwareproject van Freek Schoenmakers, een van onze Young Professionals. Deze pipeline bestaat in totaal uit drie stages (build, test en deploy) en vier jobs.

Freek_pipeline_1.png

In de build stage wordt een oplossing gecompileerd en wordt het resultaat eventueel opgeslagen als artifact. Vervolgens worden in de test stage twee jobs uitgevoerd. In deze jobs wordt een serie geautomatiseerde tests losgelaten op de artifacts van de build stage. De testresultaten worden opgeslagen als artifact en als alle tests succesvol doorlopen zijn is de job voltooid. Je ziet in het schema een test codestyle. De projectgroep had afgesproken om volgens een vaste stijl te werken, zodat alle code op elkaar lijkt en daardoor goed leesbaar is. De oplossing uit de build stage werd getest op deze codestyle. Dat scheelt de code reviewers een hoop tijd!

Als laatst wordt in het voorbeeld de deploy stage doorlopen. Hierbij wordt een release-build van de oplossing gecompileerd en bewaard. Op die manier is het heel makkelijk om een oudere versie opnieuw te downloaden en te vergelijken. Dit kan bijvoorbeeld handig zijn bij een vergadering met een opdrachtgever. Merk op dat hier in de deploy stage alleen een release-build gemaakt is. Voor dit project was niet meer nodig. Echter, in professionele omgevingen zou de deploy stage bijvoorbeeld de nieuwe versie naar een server kunnen uploaden en zo automatisch de server bijwerken.

“Pipelines bieden veel flexibiliteit en mogelijkheden rondom projectontwikkeling en automatiseren taken die anders veel tijd zouden kosten.”

Je kunt zelf met een kort script precies definiëren hoe de pipeline verloopt. Welke stappen moeten er worden doorlopen vóór het starten van de pipeline, welke stages bevat deze, uit welke jobs bestaat iedere stage, wat houdt elke job precies in, et cetera. Dit biedt veel flexibiliteit en mogelijkheden rondom projectontwikkeling en automatiseert taken die anders veel tijd zouden kosten.

Freek_pipeline_2a.png

In GitLab kun je overigens verschillende statistieken zien over de pipelines, zoals hiernaast en hieronder weergegeven. De statistieken die je hier ziet hebben betrekking op het softwareproject dat net beschreven is.

Freek_pipeline_2b.png

verschillen met GitHub

Niet alle services hebben deze pipeline tools op dezelfde manier geïntegreerd. Zo heeft GitHub externe services nodig, bijvoorbeeld Travis CI. Hierdoor ontstaat het risico om  een ‘radertje in de machine’ te worden. GitLab daarentegen zet de pipeline tools centraler neer, waardoor deze de bron vormen van alle activiteiten.

verschillen met Azure DevOps

Echter, ook bij GitLab is er nog altijd ruimte voor verbetering. Zo kan het gebruiksvriendelijker. Op dit moment maak je een configuratiebestand aan en vervolgens pikt GitLab dit bestand automatisch op. Ter vergelijking: Azure DevOps heeft hier een mooie grafische interface voor. Hier kun je gemakkelijk jobs en stages toevoegen en nieuwe pipelines configureren zonder direct in script bestanden te rommelen.

Een ander voordeel van Azure DevOps is dat het doorlopen van het deployment-proces beter is ingebouwd. Door deze integratie kunnen de resultaten van een pipeline gemakkelijk gedeployed worden zonder tussenkomst van een externe service. Dit is ook mogelijk in GitLab, maar daar zijn extra services voor nodig waardoor het minder eenvoudig is dan bij Azure. Zo is er bijvoorbeeld integratie mogelijk met Prometheus voor performance monitoring en Kubernetes voor clustermanagement.

Al met al zijn er veel voordelen van Continuous Integration en ik hoop je te hebben geïnspireerd om te profiteren van de services die GitLab hiervoor biedt. Meer informatie? Ga naar onze Continuous Delivery 3.0 of Continuous Intelligence pagina.

A/B testing

Door Ewan Klomp

directionalsign_83858.png

Veel mensen denken dat A/B testing enkel iets is voor grote bedrijven, met heel veel gebruikers zoals Facebook of Amazon. Maar niets is minder waar. Met de komst van tooling zoals Google Optimize is het mogelijk om ook bij kleine bedrijven A/B tests effectief uit te voeren. A/B testing met weinig moeite en zeer beperkte kosten. Op deze manier ontstaat een nog betere en completere teststraat. Ook kan de Product Owner nog beter inzicht krijgen in het softwaregebruik.

Wat is A/B Testing ook al weer?

Om nog even het geheugen op te frissen: bij een A/B test krijgen gebruikers applicatieversie A of applicatieversie B. Op basis van tevoren bepaalde metrics wordt uiteindelijk één van de versies als definitieve versie gekozen voor alle gebruikers.

Door A/B tests kan een softwareproducent betere beslissingen nemen op het gebied van User Interfaces, door bijvoorbeeld te kijken naar welke versie correleert met de grootste conversie.

Google Optimize als A/B test tool, biedt een goede integratie met Google Analytics.

Google Optimize

In dit artikel gaan we dieper in op Google Optimize. Optimize biedt een goede integratie met Google Analytics. Daarnaast heeft het een gratis versie waardoor je snel alle opties kunt onderzoeken. Uiteraard zijn er meer tools waarmee A/B tests uitgevoerd kunnen worden, zoals the A/B testplatform van VWO of het experimentenplatform van Optimizely. Welke het best bij jouw organisatie past is afhankelijk van je teststrategie.

google-optimize-logo-480x480-1-140x140@2x.png

Implementatie A/B Testing

Een A/B test opstellen is in feite een experiment uitvoeren. Je begint met een hypothese, verandert een element en bekijkt de statistieken (lees resultaten) van de vooraf bepaalde metrics.

Google Optimize heeft een editor waarmee je webelementen gemakkelijk kunt bewerken. Je meet met deze webelementen de metrics vanuit je Google Analytics doelen. Een andere nuttige functionaliteit van Google Optimize is dat je je direct op op bepaalde gebruikers kunt richten, op basis van bijvoorbeeld gedrag of locatie.

A/B Testing en Continuous Delivery 3.0

Met A/B testing leg je ook een directe link met het Continuous Intelligence en Continuous Planning gedeelte van Continuous Delivery 3.0. Op deze wijze krijg je nog meer informatie van gebruikers, op basis van de verzamelde metrics. Hier kan de Product Owner de backlog prioritering op aanpassen

AB_testing.png

Het figuur toont hoe de resultaten van A/B testing het Continuous Intelligence proces en Continuous Planning proces voeden

Bijvoorbeeld: als de conversie met de nieuwe versie niet is verhoogd, kan je een work item aanmaken waarin je onderzoekt hoe je de conversie wel kunt verhogen.

Via de bovenstaande aanpak kun je laagdrempelig kennismaken met de mogelijkheden om je product en je ontwikkelprocessen te verbeteren met A/B Testing, Continuous Intelligence en Continuous Planning. Ik hoop je geïnspireerd te hebben om A/B testen te implementeren in jouw teststraat! Download nu de whitepaper over A/B-testing.

Sensitive Data Exposure

Door Lucas Dresscher

Wat is het en waar komt het voor?

Lupa.jpg

Na het de vorige keer gehad te hebben over het fenomeen Broken Authentication, bespreekt Lucas Dresscher deze keer Sensitive Data Exposure. De naam van deze kwetsbaarheid maakt direct duidelijk waar het over gaat. Immers, vrijwel iedere applicatie verwerkt ‘Sensitive Dataoftewel gevoelige gegevens, in welke vorm dan ook: credentials, medische kenmerken, creditcard nummers etc. Het deel dat nu nog overblijft - en het meest interessant is - om te behandelen, is ‘Exposure. Want hoe en waar kan deze gevoelige data nu blootgesteld worden?

Waar de aanvalsmethode van de vorige behandelde kwetsbaarheid - Broken Authentication - vrij recht-toe-recht-aan was, ligt het deze keer complexer. Namelijk bij Broken Authentication heeft een aanvaller credentials weten te bemachtigen waarmee hij directe toegang krijgt tot gegevens die hij niet zou mogen zien. Bij Sensitive Data Exposure zit het verschil in het woord ‘directe’. Want in plaats van directe aanvallen uit te voeren, probeert een aanvaller deze kwetsbaarheid te benutten, zoals via man-in-the-middle-attacks of het bemachtigen van crypto keys.

Deze acties gebeuren voornamelijk op plekken waar data in doorvoer is, dus als deze verplaatst wordt. Dat komt doordat dit vaak de plekken zijn waar de gegevens minder goed of zelfs helemaal niet beveiligd zijn. Denk bijvoorbeeld aan data-overdracht in clear-text, via een HTTP of FTP verbinding. Toch zijn er ook Sensitive Data Exposure aanvallen die gedaan worden op databases. Deze zullen in mindere mate voorkomen. Maar met name oudere databases die bijvoorbeeld unsalted of (te) eenvoudige hashes gebruiken, zullen kwetsbaar zijn voor deze aanval.

Wat kunnen de gevolgen zijn?

Bij Sensitive Data Exposure probeert een aanvaller de kwetsbaarheid op een indirecte wijze uit te nutten, zoals via man-in-the-middle-attacks.

De gevolgen van Sensitive Data Exposure zijn vergelijkbaar met die van de eerder behandelde kwetsbaarheden. Wel zal het in dit geval - zoals de naam al zegt - met name gaan om gevoelige gegevens. De omvang van de impact van een aanvaller die bovenstaande methoden weet uit te nutten zal dus afhangen van de hoeveelheid gevoelige gegevens die je hebt, en hoe “gevoelig” deze voor je (gebruikers van de) applicatie zijn.

Hoe beveilig je je er tegen?

cyber-security-2537786_960_720.png

Omdat er in een groot aantal applicaties op vele verschillende plekken data in doorvoer is, lijkt het ogenschijnlijk lastig om je tegen deze kwetsbaarheid te beveiligen. Er zijn echter enkele eenvoudige maatregelen die je kunt nemen. Overigens zijn dit zaken die eigenlijk standaard door ieder bedrijf goed moeten zijn geregeld.

De eerste maatregel tegen Sensitive Data Exposure is het classificeren van je data. Bedenk daarbij wat voor soort data je applicatie verwerkt, zowel in opslag als in doorvoer. Bekijk vervolgens welke beveiligingsbenodigdheden elke classificatie nodig heeft en pas deze toe. Sla je in jouw applicatie bijvoorbeeld weinig of geen gevoelige gegevens op? Dan is de noodzaak en de mate van beveiliging anders dan wanneer er terabytes aan medische dossiers worden verwerkt.

Maatregelen tegen Sensitive Data Exposure
1. Data classificatie
2. Encryptie-technieken
3. Data minimalisatie

De tweede en verder ook meest invloedrijke beveiligingsmethode is encryptie. Zorg ervoor dat zowel opgeslagen data en getransporteerde data is versleuteld. Gebruik hiervoor sterke encryptie algoritmen die up-to-date zijn en waarschijnlijk nog lange tijd zo blijven. Gebruik bijvoorbeeld AES-encryptieHTTPS voor data in doorvoer en in ieder geval géén MD5 voor hashing.

Een derde en laatste maatregel die je kunt nemen, is het minimaliseren van data opslag. Het is een beetje een open deur, maar sla simpelweg niet meer op dan strikt noodzakelijk is. Immers, wat je niet hebt, kan ook niet worden gestolen.

Vooruitblik

Volgende keer is het de beurt aan de eerste minder bekende kwetsbaarheid: XML External Entities (XXE). Nadat XML een jaar of 10 geleden de standaard is geworden, zijn de meeste instanties sindsdien wel bekend geraakt met de vele voordelen die het te bieden heeft. Maar hoe bekend zijn ze met de nadelen die het met zich meebrengt? Of specifieker, hoe kwetsbaar is jouw applicatie of web service tegen de mogelijke aanvallen die het gebruik van XML met zich meebrengt, zoals een DoS-aanval? Lees het in het volgende artikel van onze cybersecurity reeks.

Succesvolle start nieuwe Young Professionals

Search4Solutions organiseert regelmatig Young Professional borrels op het Utrecht Science park. De laatste Development Borrel in september was weer erg leuk en succesvol.

De informele kennismakingsborrel is voor jong talent dé kans om te ontdekken wat wij doen en waar we voor staan. En wie kan hierin beter inzicht geven dan degenen die het programma zelf al hebben gevolgd? De aanwezigheid van bestaande Young Professionals was een enorm waardevolle aanvulling aan de bijeenkomst. Veel dank aan deze groep. Ze zetten zich met enthousiasme in en dragen dit enthousiasme ook over.

IMG-20180529-WA0003.jpg

In september zijn weer acht nieuwe young professionals (YP’s) met het programma gestart. Op dit moment doorlopen ze een internship om ze klaar te stomen voor softwarebedrijven.

Vanaf dag één wordt gekeken naar hun specialiteiten en interesses door middel van persoonlijke gesprekken. Op basis daarvan komen de professionals in een passend opleidingstraject, zoals Continuous Delivery 3.0 of (Advanced) Software Engineering.

Onze bestaande groep verzorgen de training en begeleiden de nieuwe YP's. Zo begeleiden Ewan Klomp en Stijn Dautzenberg het Continuous Delivery traject en begeleidt Lars Tijsmans het Software Engineering traject.

De nieuwe professionals krijgen diverse uitdagende en interessante opdrachten, totdat ze expert zijn en zelfstandig aan de slag kunnen bij softwarebedrijven.

Wij wensen onze nieuwe teamleden heel veel succes!

Wil je ook aan de slag als Young Professional, neem dan hieronder contact op of bel direct 030-268 53 98.

Developers Day bij Unit4

Vandaag waren we op bezoek bij de Dev-Day van Unit4, voor het demonstreren van cloud based ontwikkelstraten. We hebben twee implementaties van deze ontwikkelstraten gedemonstreerd. Beide implementaties zijn bij klanten uitgevoerd op basis van het Continuous Delivery 3.0 gedachtegoed van het NISI. De implementaties zijn uitgevoerd binnen ons Young Professional Programma.

Jacco Mook presenteerde een implementatie voor een Legacy systeem waarbij de backoffice en frontoffice in iteraties is gemigreerd naar Continuous Delivery. Bij de implementatie is onder meer Jenkins en Linux gebruikt.

CD3.0 1.jpg

De scripting voor Jenkins bleek hier een uitdaging. Die uitdaging heeft te maken met de beperkingen in de pad-namen van Jenkins.

Uiteindelijk zijn aanvullende scripts geschreven om het probleem op te lossen..

In het tweede deel presenteerde Stijn Dautzenberg een implementatie voor een andere klant. Deze klant wilde GIT-versiebeheer voor 100 maatwerk versies van een softwareproduct combineren met een functionele programmaopzet.

IMG-20181003-WA0002.jpg

Door de functionele opzet kunnen OO-concepten niet worden toegepast, om wijzigingen in de core via inheritance door te voeren over de 100 maatwerk versies. Hierbij hebben we gebruik gemaakt van een concept dat bij Continuous Delivery 3.0 kenniscentrum van het NISI is ontwikkeld.

Een hele leuke dag. Met dank aan Unit4.

IMG_20181003_161204.jpg

Continuous Delivery 3.0 Maturity Model

Door: Ewan Klomp & Jan Vlietland

In 2016 hebben we het Continuous Delivery 3.0 Platform ontwikkeld. In dit artikel introduceren we het bijbehorende Continuous Delivery 3.0 model.

Tijdens de implementatie van het platform bij softwarebedrijven hebben we een patroon opgemerkt in de implementatiestappen. Bijvoorbeeld een unit testset wordt doorgaans eerder gemaakt dan de acceptatie testset.

Deze afhankelijkheden hebben geleid tot het onderstaande Continuous Delivery 3.0 Maturity Model.

ContinuousDelivery30 Maturity Model v1.0.png

Verticaal staan de 5 Continuous Delivery 3.0 gebieden, zijnde Intelligence, Planning, Integration, Testing en Deployment. Horizontaal staan de 5 stappen naar volwassenheid.

 

Introductie Ewan Klomp - DevOps Engineer / Continuous Delivery

20180815_195621.jpg

Hallo, mijn naam is Ewan Klomp en ben bij Search4Solutions werkzaam als Continuous Delivery Expert.

Als eerste Young Professional heb ik het programma en de groep zien groeien in professionaliteit en kennisdeling. We zijn begonnen met een kleine club informaticastudenten die een passie voor software development hebben. Inmiddels zijn we uitgegroeid tot een grote club young professionals die met passie aan onze projecten werken.

Zelf heb ik mij kunnen specialiseren op het gebied van Continuous Delivery, door intern een traineeship te volgen. Daarna met de opgedane kennis in het bedrijfsleven te stappen, in projecten die mij deze kennis liet benutten. Deze projecten waren leuk en succesvol. Eveneens heb ik in die tijd mijn studie Informatiekunde met veel plezier afgerond. 

Nu maak ik als Young Professional de stap naar voltijd. Ik kijk er zeer naar uit om deze stap te mogen maken en ik ben benieuwd wat het mij gaat brengen.

In de tussentijd wil ik mijn opgedane kennis delen met de community die we hebben opgebouwd. In de komende tijd komen er op deze pagina daarom artikelen die u zou kunnen helpen met uw Continuous Testing processen. Vorige week is een artikel uitgekomen over cross platform UI Testing met Xamarin als voorproefje op deze reeks.

In de volgende delen zal u meer kunnen lezen over AT testen, performance testen en A/B testing. Wilt u eerder meer weten? Neem dan contact met ons op.

Broken Authentication

Door Lucas Dresscher

Wat is het en waar komt het voor?

In dit tweede artikel van mijn serie over de “OWASP Top 10 Application Security Risks – 2017” lijst behandel ik de kwetsbaarheid Broken Authentication. Misschien herkent niet iedereen direct deze officiële term, maar wel zeer herkenbaar is de zoveelste krantenkop waarin staat “Miljoenen accounts gehackt door datalek”. Broken authentication heeft hier veelal mee te maken.

Broken authentication kan de oorzaak zijn van zo'n krantenkop, maar vaker is het een gevolg. Vrijwel alle applicaties volgen namelijk voor inlog processen en dergelijke het volgende drie stappen principe:

1. Identification: “Wie ben je?” - dit is vaak de gebruikersnaam.
2. Authentication: “Ben je wie je zegt dat je bent? - dit is vaak het wachtwoord.
3. Authorization - “Wat mag je?” - dit zijn de rechten die deze gebruiker heeft.

Zoals de naam Broken Authentication doet vermoeden, doet het zich voor in de tweede stap. Een aanvaller gebruikt verkregen credentials om zich voor te doen als een bepaalde gebruiker om op deze manier diens rechten te krijgen. De aanvaller kan aan deze gegevens gekomen zijn door bijvoorbeeld eerdere datalekken, maar ook door zelf een Brute Force Attack (BFA)/Dictionary Attack of een ietwat geavanceerdere Rainbow Table Attack uit te voeren.

Wat kunnen de gevolgen zijn?

Bij een applicatie die kwetsbaar is voor Broken Authentication is het risico op identity theft zeer groot. Tevens kan er andere (bedrijfs)gevoelige gegevens geopenbaard worden. Dit zou niet moeten gebeuren, aangezien de meeste accounts die gehackt worden van gewone gebruikers zijn. Deze groep hoort in theorie zo weinig mogelijke rechten te hebben. Echter, de praktijk leert dat - veelal uit gemakzucht - dergelijke groepen veel meer rechten hebben dan nodig is. Hierdoor kan zelfs een matige hacker met het kraken van een simpel account al ver komen, laat staan een gevorderde hacker. Onder het volgende kopje “Hoe beveilig je je er tegen?” behandel ik dit probleem verder.

Hoe beveilig je je er tegen?

Om te voorkomen dat je direct in gevaar bent als de secretaresse op een phishing mail geklikt heeft, is het van belang dat je als bedrijf goed nagedacht hebt over Identity and Access management (IAM). Dit is gebaseerd op de volgende drie principes: (1) need to know basis, (2) least privilege en (3) segregation of duties. Ofwel, ga voor elke gebruikersrol precies na welke rechten nodig zijn en stel het systeem vervolgens zo in – en niet meer. Zorg er daarnaast voor dat gebruikerstaken gescheiden zijn; iemand die een aanpassing kan voorstellen, moet deze niet zelf kunnen goedkeuren.

Hieronder geef ik een korte lijst met do’s en don’ts om Broken Authentication tegen te gaan.

DO'S

  • Multi-factor authentication: hiermee laat je de gebruiker met twee of meerdere verschillende manieren authenticeren, in plaats met alleen een wachtwoord. Een veelgebruikte implementatie is een combinatie van een wachtwoord en een code verkregen via SMS of via een authenticator app zoals Google Authenticator.

  • Bouw een weak-password check in, die controleert of een gebruiker geen wachtwoord uit de lijst met met 1000 of 10000 slechtste wachtwoorden (uit gemak) wilt instellen.

  • Beperk het aantal inlogpogingen die iemand kan doen en log alle mislukte inlogpogingen.


DON'TS

  • Gebruik geen default credentials. Oftewel, stel geen standaard gebruikersnamen, wachtwoorden of andere accountgegevens in. Denk aan standaardgebruikersnamen admin of gebruiker1 en standaardwachtwoorden als password of wachtwoord.

  • Leg de gebruiker buiten de weak-password checker en een standaard minimumlengte van in ieder geval 8 tekens niet teveel restricties op tijdens het instellen van hun gebruikersgegevens. In tegenstelling tot wat sommige bedrijven nog steeds denken, is onderzocht dat verplichtingen als speciale tekens en hoofdletters of het verplicht periodiek aanpassen van je wachtwoord juist averechts werkt.


Vooruitblik

In het volgende artikel zal ik een kwetsbaarheid behandelen die velen verwarren met degene die ik hier heb besproken: Sensitive Data Exposure. Sensitive Data Exposure heeft zeker overeenkomsten met Broken Authentication, maar is op meerdere vlakken toch fundamenteel anders. Waarin zit dit verschil? Kun je je als bedrijf met enkele hier besproken preventiemaatregelen ook direct tegen deze kwetsbaarheid beveiligen? En welke rol speelt encryptie hierin? Lees het in het derde artikel van mijn Cybersecurity reeks.


 


 


 

 

Cross-platform UI testing met Xamarin

Door: Ewan Klomp

Nadat Microsoft begin 2016 Xamarin overnam, heeft Microsoft grote stappen gezet om cross-platform applicaties met goede performance in C# te bouwen. De snelheid is nog niet helemaal als Native code. Maar door de mogelijke code sharing tussen de twee platformen (iOS en Android) is het een degelijke optie. Zeker wanneer er geen zware computationele berekeningen nodig zijn. Dit artikel gaat dieper in op hoe je User Interface tests uit één project, op beide platformen draait.

Simpele werkwijze

De user interface test van Xamarin werken met een interface. De user interface test library heet Xamarin.UITest en de interface de IApp interface. Xamarin kan met dezelfde interface beide platformen bedienen. Door de IApp interface is het klikken van een object op iOS en Android heel simpel, met dezelfde app.Tap(string) method call.

Creëren van test cases

De methoden die de IApp interface heeft zorgen dat er diverse, geavanceerde test cases gecreëerd kunnen worden. De mogelijkheden zijn vergelijkbaar met die van grotere test platformen zoals Selenium. Ook kan je met Xamarin objecten makkelijk vinden door middel van naam of XPath. Vervolgens kun je ze klikken of er tekst bij invoeren. Natuurlijk bevat Xamarin specifieke methoden voor gestures zoals drag/drop, pinching, en swiping om een gebruiker zo goed mogelijk na te bootsen.

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

Hoe het werkt

Als je dus binnen je test een object aan wil klikken genaamd ´buttonHome´, voer je de functie app.Tap(buttonHome) uit. Dit zoekt dan het object met id ´buttonHome´ op in de huidige views die open staan. Om er voor te zorgen dat de juiste view de juiste ID heeft moet de ID op de juiste plek in de layout files toevoegen: .xib voor iOS en .xaml voor Android.

  • Op iOS geef je een id op deze manier mee aan een element in de .xib file:
    <accessibility key="accessibilityConfiguration" identifier="buttonHome"/>

  • Bij Android in de .xaml op deze manier:
    android:id="@+id/buttonHome"

Let hier op

In principe is het mogelijk om een test te schrijven die draait op Android en IOS. Het probleem zit soms in het verschil van gedrag tussen de platformen op het gebied van views. Hier moet dan binnen 1 testcase een verschillende implementatie voor geschreven worden. Verder is het van belang dat elk element van een testcase waarmee je werkt zijn eigen unieke ID heeft en hetzelfde zijn op beide platformen. Bij een juiste implementatie is het enige verschil de initialisatie van de applicaties voor het testen. Let er op dat je de ID’s van de objecten gelijk houdt op beide platformen. Hierdoor kunnen juiste objecten op de juiste plek gevonden worden.

En nu jij

Hopelijk heb ik je enthousiast gemaakt en ga je zelf met Xamarin aan de slag. Als je hier meer over wilt weten kun je me bereiken via ons contactformulier:

Kwetsbaarheid Nummer 1: Command Injection

Door: Lucas Dresscher

Wat is het en waar komt het voor?

In dit artikel behandel ik de nummer 1 op de “OWASP Top 10 Application Security Risks – 2017” lijst: injection. Injection houdt in dat een aanvaller, via een vorm van input in een applicatie, code kan doorsturen naar een interpreter. Het doel van de aanvaller is om hiermee onrechtmatig gegevens te verkrijgen en te gebruiken/misbruiken. Rechtsonder staat een praktijkvoorbeeld van injection:

OS_Command_injection.png

Ondanks dat bijna iedereen die in de IT werkt bekend is met injection, is injection nog steeds de meest voorkomende kwetsbaarheid in applicaties. Dit is opmerkelijk, maar ook heel logisch. Het grootste probleem aan deze kwetsbaarheid is dat er vrijwel overal in een applicatie injection flaws kunnen zitten. Op elke plek waar sprake is van user input data – URL’s, XML of JSON inputs, cookies etc. - kan een aanvaller (trachten te) gebruiken voor injection. Hierdoor zijn er vele varianten, zoals de welbekende (No)SQL injection maar ook LDAP injection, EL injection en OS command injection. Het is daardoor niet gemakkelijk om je applicatie volledig tegen deze kwetsbaarheid te beveiligen.


Wat kunnen de gevolgen zijn?

injection.jpeg

Afhankelijk van de fail securely maatregelen die genomen zijn (zie “Hoe beveilig je je er tegen?”), kan er van alles met je data gebeuren, en op elke schaal. Typische gevolgen van een geslaagde injection-aanval zijn verlies of corruptie van data, ontzegging van toegang tot data en het doorspelen van data aan (criminele) derde partijen.

Hoe beveilig je je er tegen?

Hoewel er dus vele vormen van injection zijn, zijn de preventie- en detectiemaatregelen tegen alle vormen vergelijkbaar. Hieronder volgt een overzicht van de mogelijke maatregelen die je kunt nemen.

Preventiemaatregelen

  1. De beste manier om injection te voorkomen is input validation. Controleer en valideer alle vormen van user input in je code alvorens je deze gebruikt voor een aanroep naar je interpreter.

  2. Gebruik een veilige API voor je applicatie, die het gebruik van een interpreter volledig omzeilt.

  3. Fail securely, oftewel beperk de schade als er iets fout gaat. Beperk bijvoorbeeld de hoeveelheid informatie die weergegeven wordt als resultaat van een query door TOP (SQL), LIMIT (MySQL) of ROWNUM (Oracle) aan de query toe te voegen.

Detectiemaatregelen

  1. Voer een handmatige source code review uit. Ga na waar in je applicatie user input wordt gegeven en controleer op deze plekken de input validation.

  2. Voer op elke plek waar injection mogelijk is een geautomatiseerde test uit. Gebruik hiervoor bijvoorbeeld het MetaSploit Framework in combinatie met Kali Linux.

Vooruitblik

In het volgende artikel zal ik de op één na meest voorkomende kwetsbaarheid in applicaties behandelen: Broken Authentication. Dit is een kwetsbaarheid die al vele jaren hoog in de lijst staat.

"BROKEN AUTHENTICATION ZAL IN HET VOLGENDE ARTIKEL WORDEN BEHANDELD"

Door de alsmaar groeiende beschikbare rekenkracht die aanvallers hebben voor bijvoorbeeld Brute Force Attacks zal dat ook nog wel lang zo blijven. Gelukkig kun je je applicatie met een aantal maatregelen hiertegen beveiligen. Hoe? Lees het in het volgende artikel van mijn Cybersecurity reeks.

Eerder verschenen:
Introductie Lucas - Cybersecurity

 

Introductie Lucas - Cybersecurity

Foto.png

Mijn naam is Lucas Dresscher, ik ben 22 jaar oud en ik studeer informatica aan de Universiteit Utrecht.

Daarnaast werk ik 2 dagen per week als Cybersecurity expert in het Young Professional programma, voor Softwarebedrijven in Nederland.

Cybersecurity is een zeer omvangrijk vakgebied; het is letterlijk overal in de IT-wereld. Daarbij is Cybersecurity ook nog eens enorm relevant en actueel. Dit maakt het fenomeen voor velen al snel ontastbaar en afschrikwekkend. Dat wordt versterkt wordt door de enorme hoeveelheid vaktermen en de honderden beschikbare Cybersecurity tools.

Het is dan ook mijn persoonlijke doel om deze ongrijpbaarheid van cybersecurity weg te nemen en het PEN-testen praktisch in te richten. Ik wil de onnavolgbare Wizzkid wegen vervangen door duidelijkheid.

Een kleine hoeveelheid van mijn kennis over cybersecurity deel ik op dit blog, door een reeks van de meest voorkomende kwetsbaarheden in software. Hiervoor hanteer ik de erkende “OWASP Top 10 Application Security Risks - 2017” van het Open Web Application Security Project, zijnde: 

  1. Injection

  2. Broken Authentication

  3. Sensitive Data Expose

  4. XML External Entities

  5. Broken Access Control

  6. Security Misconfiguration

  7. Cross-Site Scripting

  8. Insecure Deserialization

  9. Using Components with Known Vulnerabilities

  10. Insufficient Logging & Monitoring

Bij elk van deze kwetsbaarheid geef ik een uitleg over de kwetsbaarheid, waar het zich in applicaties voordoet en bovenal, wat je er tegen kunt doen.

In het eerstvolgende blog begin ik meteen met de nummer 1 van de lijst: Injection. De meesten zullen deze beruchte kwetsbaarheid herkennen in de vorm van SQL injection, maar er bestaan nog vele andere varianten. Welke zijn dit allemaal? Wat kunnen de gevolgen ervan zijn? En wat doe je er nu precies tegen? Lees het binnenkort in mijn cybersecurity reeks.

Maandelijkse kennisdeling voor Young Professionals

Maandelijks komen de Young Professionals bij elkaar om kennis en kunde te delen.. Deze groep is als high potential geidentificeerd en helpen softwarebedrijven hun vraagstukken (in deeltijd) op te lossen.

IMG_20180531_181705.jpg

De Young Professionals implementeren software-oplossingen op de volgende gebieden:
- Continuous Testing
- Continuous Deployment
- Continuous Intelligence (Data Analytics)
- Cybersecurity & PEN-testing
- Geautomatiseerde bedrijfsprocessen

IMG_20180531_182445.jpg

Het is erg nuttig gebleken om deze praktijkervaringen met elkaar te delen. Het leren versnelt en het werkt inspirerend en motiverend. Elke Young professional bereidt een korte presentatie voor. We kiezen altijd voor interactie en samenwerking. De presentaties zijn vooral bedoeld als initiator tot discussie.

IMG_20180531_184533.jpg

Het Young professional programma identificeert de beste software studenten. Na een internship van 3 maanden zijn het Young professionals die het verschil maken bij softwarebedrijven.

Wil je meer weten over het Young Professional programma neem dan contact op via: 030-268 53 98.

Cybersecurityavond Hogeschool Utrecht

Op 23 mei hebben Ewan Klomp, Lars Tijsmans en Jan Vlietland van het Young Professional programma een Cybersecurity avond met Hogeschool Utrecht gehouden.

IMG-20180529-WA0010.jpg

Het onderwerp van de avond was:

"Cybersecurity en de softwareontwikkelaar".

 

De stelling was: 

"elke ontwikkelaar moet verstand hebben van Cybersecurity". 

Het was een avondvullend programma waarin presentatie, discussie en experimenten speels werden afgewisseld. Een leerzame avond vol ontmoetingen tussen professionals en young professionals, met als doel om met elkaar antwoorden te vinden.

IMG-20180529-WA0003.jpg

De eindconclusie was dat:

"bijna elke ontwikkelaar moet verstand hebben van Cybersecurity".

We danken Hogeschool Utrecht voor de interesse en gastvrijheid. Tot een volgende keer!