Tag: richtlijnen

Paspoortchip eenvoudig te kraken

  door

We waren er al bang voor, maar hebben toch allemaal gehoopt dat het wat langer zou duren.

De RFID-chip in het nieuwe Nederlandse paspoort is via gratis verkrijgbare software eenvoudig te kraken. Dat liet de Nederlandse beveiligingsonderzoeker Jeroen van Beek gisteren in De Telegraaf weten. De paspoortchip bevat onder meer de naam, geboortedatum, burgerservicenummer, foto en vingerafdrukken van de houder. Volgens Van Beek is de chip van korte afstand uit te lezen en te kopiëren (bron).

Overigens gaat de discussie verder dan dit, omdat er aan alle kanten kopieën van paspoorten worden gemaakt. Met name in hotels vinden ze dat een kopie van een paspoort moet kunnen en veel medewerkers zullen zelfs denken dat het een eis is omdat ze je anders geen kamer mogen geven.

Het College Bescherming Persoonsgegevens (CBP) lanceerde donderdag een aantal richtlijnen om zowel consumenten als bedrijven bewust te maken van de wetgeving. Bedrijven mogen in sommige gevallen wel vragen om legitimatie, maar een kopie maken is in de meeste gevallen verboden (bron).

Nu zitten we dus met een paspoort dat gemakkelijk gekopieerd kan worden en we zitten met bedrijven die niet weten wat de richtlijnen zijn. Tijd voor de overheid om hier maar weer eens een campagne tegenaan te gooien?

Een mooie slogan heb ik al voor ze verzonnen: “Weet hoe het hoort met een paspoort” (oh ja, deze URL natuurlijk niet direct registeren want dan kan de overheid het niet meer doen).

NCSC geeft beveiligingsrichtlijnen voor webapplicaties uit

  door

Nu we deze week gezien hebben dat we niet alleen de schuld bij de website eigenaren neer kunnen leggen maar zelf ook onze verantwoordelijkheid moeten nemen, sluiten we de week af met de richtlijnen voor webapplicaties. Daar kun je als consument misschien wat minder mee, maar voor alle website eigenaren geldt dat de ogen geopend moeten worden.

Het Nationaal Cyber Security Centrum heeft ICT-beveiligingsrichtlijnen voor webapplicaties uitgegeven. De beveiligingsrichtlijnen voor webapplicaties van het NCSC vormen een leidraad voor het veiliger ontwikkelen, beheren en aanbieden van webapplicaties en bijbehorende infrastructuur (bron).

Nu zouden we natuurlijk kunnen denken dat geen enkele website eigenaar aan dergelijke richtlijnen kan voldoen. Hij of zij heeft een geweldig idee en ontwikkelt daar een mooie website bij. Toegegeven, dat behoort inderdaad tot de mogelijkheden. En eerlijk gezegd hoop ik dat dergelijke innovators inderdaad niet direct gegrepen worden door een hacker.

Maar bedenk ook dat veel, reeds bestaande organisaties, de weg naar het internet gevonden hebben. Deze maken de website niet op een zolderkamertje maar hebben er een afdeling voor zitten of besteden het uit aan een gespecialiseerd bedrijf. Voor die gevallen kunnen we beveiligingsrichtlijnen wel degelijk in de ontwikkeling worden meegenomen.

Alleen moeten we dan beseffen dat we niet voor een dubbeltje op de eerste rang kunnen zitten. Ontwikkelen kost nu eenmaal geld en veilig ontwikkelen kost nu eenmaal nog wat meer. Maar een van de functionele eisen die je aan de opdrachtnemer mee kunt geven is dat de webapplicatie aan richtlijnen van het NCSC moet voldoen. Voldoet het niet? Dan nemen we het niet in beheer en krijgt de opdrachtnemer niet betaald. Klinkt hard, maar zo simpel zou het kunnen zijn.

Ja, natuurlijk schrijf ik: zou het kunnen zijn. Ik besef me ook wel dat de commercie nu eenmaal vaker de overhand heeft dan de beveiliging. We moeten zo snel mogelijk met onze site online en als daar de beveiliging voor moet wijken, dan is dat maar zo. Klinkt ongeloofwaardig? Ja, ben ik met je eens. In dit geval maakt men tenminste nog een bewuste keuze voor een lager niveau van beveiliging. In het merendeel van de gevallen staat men nog helemaal niet stil bij de beveiliging.

Ach, zolang zowel de opdrachtgever als de opdrachtnemer voor het ontwikkelen van een website nog de Euro-tekens in de ogen hebben, zal beveiliging altijd het ondergeschoven kindje blijven. Jammer, maar voorlopig waarschijnlijk wel de waarheid.

Maar zeg niet dat je niet gewaarschuwd bent en zeg niet dat er geen hulpmiddelen aanwezig zijn, want die zijn er genoeg. We moeten ze alleen willen ontdekken en we moeten accepteren dat het veilig ontwikkelen van nieuwe applicaties nu eenmaal wat langer duurt en wat meer kost. Doen we dat niet dan zijn we “Penny wise, pound foolish” en kunnen we er bijna op wachten tot we gegrepen worden.

Wie weet: binnenkort naast een Thuiswinkel.org keurmerk ook een NCSC-keurmerk? Ik kijk er naar uit.

Normen, best practices en richtlijnen

  door

We hebben al goed nagedacht over onze aanpak op het gebied van informatiebeveiliging. Het zogenaamde “low hanging fruit” hebben we inmiddels wel geplukt en gaan nu meer en meer aanlopen tegen wat meer specifieke vragen. Hoe gaan we dit nu weer oplossen? Hoe gaan we daar nu weer mee om? Geen nood, er is genoeg informatie beschikbaar en die kan ons erg goed van pas komen. Op naar deze vraag dan maar:

Wordt bij de inrichting van de beveiliging gebruik gemaakt van normen en/of best practices en richtlijnen uit de branche of van organisaties met gelijke typologie voor standaardisatie van de integrale beveiliging?

We hebben het al eerder aangehaald, misschien heeft onze branchevereniging of hebben onze concurrenten nog wel interessante informatie beschikbaar die ons goed verder kunnen helpen. Niet geschoten is altijd mis, dus niet gevraagd is ook geen antwoord.

Ok, nu willen we niet als onwetend overkomen bij onze concurrenten dus eerst gaan we ons eigen desk research doen. Wel zo fair, toch? Beginnen we met de Code voor Informatiebeveiliging, dat is al een belangrijk raamwerk om ons verder te helpen. Niet door alles wat daarin staat zomaar te implementeren, maar wel om volgens een bepaalde structuur te werken. Een belangrijk aspect daarbij is het eerste deel van die Code (27002). Sla de eerste 4 hoofdstukken niet over om direct met de maatregelen te beginnen, maar lees juist die eerste hoofdstukken extra goed. Daarin staan de kaders, daarin staat de aanpak…en daarin staat ook dat de Code vertaald moet worden naar de eigen organisatie en dat daarbij keuzes gemaakt moeten worden.

Google ook eens op de Code voor Informatiebeveiliging. Voor de Code zelf moet betaald worden maar er is genoeg geschreven over hoe andere organisaties het aanpakken. Er is genoeg herbruikbaar materiaal te vinden. Beter goed gejat dan slecht verzonnen, zou ik zeggen.

Ik benadruk het nog maar eens: er staat nergens in de Code dat je alle maatregelen moet implementeren, er staat dat je goed moet nadenken over de specifieke risico’s voor jouw organisatie en dat de Code je daarbij behulpzaam kan zijn. Kortom: niet zomaar maatregelen implementeren maar eerst nadenken over de mogelijke risico’s.

Maar hoe gaan we nu om met die specifieke punten waar jij met je organisatie tegenaan loopt? Ook daarvoor geldt “Google is your friend” (ja ik weet het, er wordt door sommigen anders over gedacht). Loop je ergens op vast, Google dan eens met de juiste termen en je komt al snel hele bergen informatie tegen. Desk research is met de intrede van internet alleen maar makkelijker geworden en er komt nog steeds veel bruikbare informatie bij. Na de desk research kun je altijd nog even met je concurrent schakelen om na te gaan hoe zij met aspecten zijn omgegaan. Ook kun je altijd nog een specialistische interne afdeling benaderen of extern advies inhuren als dat wenselijk is.

We hebben het al vaker geschreven: als we het wiel opnieuw uit gaan vinden dan zal dat wiel ongetwijfeld weer rond worden. Dat hoeven we dus niet te doen. Nee, hergebruik wat beschikbaar is en vertaal dat naar de eigen organisatie. Een wiel is inderdaad rond, maar een wiel van een tractor zal moeilijk passen op het frame van een fiets. Heb je echt zulke grote wielen nodig of kan het ook wel een maatje kleiner? Daar zit hem wellicht de belangrijkste vraag.

Normen, best practices en richtlijnen

  door

Gisteren hebben we vriendschap gesloten met onze auditafdeling. Eigenlijk zijn het helemaal niet van die nare (of rare) mensen, toch? Nee, eigenlijk hebben zij ook wel het beste voor met de organisatie. Aan deze vernieuwde samenwerking gaan we nog veel plezier beleven. Maar we nemen uiteraard wel onze eigen verantwoordelijkheid en proberen de informatiebeveiliging eerst zo goed mogelijk zelf in te richten. Daarmee zijn we aangekomen bij vraag 4.

De vierde vraag die we moeten stellen is:
Is bij de inrichting van de integrale beveiliging gebruik gemaakt van normen, best practices en richtlijnen uit de branche?

En het antwoord? Ja, nee of weten we het eigenlijk niet?

Inmiddels weten we dat we informatiebeveiliging serieus moeten nemen, maar waar moeten we beginnen? Geen nood, er zijn genoeg hulpmiddelen beschikbaar om de eerste paar stappen goed te zetten. Maar, voordat je je verstapt, wil ik je er nog wel even op wijzen dat het niet zozeer gaat om de beveiligingsmaatregel maar juist om het afdekken van een risico. Houden we dat voor ogen dan gaan we niet domweg allerlei standaard normenkaders implementeren (die een overkill aan maatregelen veroorzaken).

Nee, uitgaande van de risico’s, die per organisatie, per business unit, per locatie, per proces, per land, per gebouw en ga zo nog maar even door kunnen verschillen. Nu kunnen we allerlei normen, best practices en richtlijnen gebruiken om de meest effectieve en efficiënte wijze van beveiligen te bepalen.

De bekendste norm is waarschijnlijk de Code voor Informatiebeveiliging (ISO27001/27002 of voor de gezondheidszorg: NEN7510). Een uitstekende basis, zou ik zo zeggen, maar er is meer. Google er eens lustig op los en je zult zien dat er al veel, heel veel, geschreven is over informatiebeveiliging. Kijk bijvoorbeeld ook eens wat er beschikbaar is vanuit National Institute of Standards and Technology (NIST) en Federal Information Processing Standards (FIPS). Wat houd je tegen om dat her te gebruiken? Is het niet beter goed gejat dan slecht verzonnen?

Verder zijn er vast ook nog wel richtlijnen uit de branche die we kunnen hergebruiken. Beveiliging heeft misschien vele nadelen, maar een groot voordeel is er ook. Veel organisaties zien het (nog) niet als onderscheidend vermogen ten opzichte van de concurrentie. Benchmarken in de branch is daarom vaak niet zo’n probleem. Waar je normaliter zwaar concurreert kan het zomaar zo zijn dat de Security Manager van je concurrent graag met je samen werkt. Waarom? Nou, simpelweg omdat hij of zij met dezelfde problemen in de maag zit.

Zo, de concurrentie is ook geen probleem meer en we weten nu dat we via internet en allerlei beschikbare normeringen al een aardig stuk op weg zijn. Nu moeten we er alleen nog voor oppassen dat we het vakgebied straks niet echt leuk gaan vinden want dan is het hek van de dam. Maar goed, we zijn weer een stap verder en kunnen met een gerust hart op weg naar vraag 5.

Nogmaals, voor diegene onder jullie die echt niet 10 dagen willen wachten, je kunt de quickscan zelf ook al doorlopen door hier te klikken of door me snel uit te nodigen voor die bak koffie.