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!

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-encryptie, HTTPS 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!

Kartevent met softwareprofessionals

Afgelopen zaterdag zijn alle medewerkers uitgenodigd om te gaan karten bij de Kartfabrique. 

Zo is het werk niet alleen leerzaam, maar ook supergezellig! 

We begonnen met bijpraten met een drankje in de bar, en daarna stapte iedereen in zijn kart. Zodra we begonnen met karten wilde iedereen superfanatiek de snelste tijd behalen. Jan heeft de snelste tijd gehaald door in 58.140s over het parcours heen te karten! Een eervolle tweede vermelding is voor Joeri met een snelste rondetijd van 58.389!

Na het karten hebben we gezellig nagepraat met een drankje en gepoold, om zo samen de dag af te sluiten.

WhatsApp Image 2018-04-24 at 13.08.56.jpeg

 

 

Een Hackathon zoals het is bedoeld

Vorige weekend hebben we met een groep medewerkers een supertoffe Hackathon georganiseerd, bestaande uit een serie challenges.

Tijdens de voorpret waren er al bijzondere challenges bedacht. Ze varieerden van het maken van een website binnen een half uur, tot het PEN-testen van een wireless accessible REST-API. Maar ook het hacken van een wireless netwerk met een *CRACK* attack in Kali was een challenge.

 
hackathon_2.jpg
 

We organiseren de hackathons op verschillende locaties en evalueren samen wat de prettigste werkomgeving is. We kiezen werkomgevingen die creativiteit en werkplezier het best ondersteunt. Een ruimtelijke huiselijke omgeving blijkt hier tot nu toe het best te passen.

De volgende dag, aan het einde van de hackathon bleken er alleen winnaars te zijn.

 

Je applicatie hosten in containers

Het verplaatsen van de hosting van een eigen rekencentrum naar een cloud-omgeving kan veel besparing opleveren. Bedrijven verplaatsen daarom hun hosting op grote schaal naar de cloud.

Veel organisaties denken daarbij dat virtual machines dan de beste oplossing is. Jammer want ze missen dan de kans om software te hosten in containers. Hosten in containers heeft vele voordelen. In dit artikel leggen we uit wat containers zijn en wat de voor- en nadelen zijn van containers.

Wat zijn containers?

Een container biedt de mogelijkheid om het Operating Systeem te sharen over meerdere containers. Ze zijn daardoor veel goedkoper qua hosting dan virtual machines. 

Het Operating Systeem onder de container bevat alle benodigde libraries die een applicatie nodig heeft om te functioneren. De containers zelf zijn daardoor zeer compact en zijn binnen een paar seconden te creeren. Dit maakt ze niet alleen goedkoper, maar ook veel flexibeler.

Containerization is geen nieuw begrip. Het idee om de OS laag te virtualiseren bestaat al sinds begin deze eeuw. 

Het container framework ‘Docker’ heeft het begrip containers praktisch gepopulariseerd. Veel innovatieve bedrijven hebben Docker snel geadopteerd. 

 
VM_vs_Container_stack.png
 

De nadelen van containers.

Evenals de virtual machine niet de universele vervanger is van de fysieke server, is de container dit niet van de virtual machine. Beide technologieën hebben hun krachten. Containers floreren in een omgeving met microservices. Ze schalen mooi, doordat ze zeer snel te creeren zijn afhankelijk van het benodigde dataverkeer.

Containers zijn echter wel gevoeliger voor virussen doordat ze het onderliggende Operating Systeem delen. Ook kunnen ze diep reiken in het OS om überhaupt te functioneren. VM-instanties bieden deze controle en veiligheid wel. 

Overweeg containers

Bij veel bedrijven staat veiligheid op nummer één en kennis omtrent containers is vaak niet paraat, virtual machines zijn daarom een veilige keuze.

Jammer, want de toekomst van containers is veelbelovend en het zal niet lang duren voordat de meerderheid deze techniek adopteert, zoals dit nu gebeurt met VM-instanties in de cloud.