Wanneer is security effectief?

In de rol als Security Manager heb ik in het verleden verschillende voorstellen gedaan voor nieuwe security trajecten. De beslissers die ik tegenover me trof waren op dat moment eigenlijk maar in één ding geïnteresseerd: ‘Wat is de Return On Security Investment?’ Of te wel: ‘Al zet je tien slagbomen voor ons kantoor, ik wil weten wanneer ik die euro’s terugverdien’.

Als beslisser kun je jezelf vandaag de dag echter niet meer onttrekken aan een gefundeerde mening over security. Of je wordt persoonlijk aansprakelijk gesteld, of de reputatie van jouw organisatie wordt geschaad. Dit kan al door een simpele USB-stick die een van je medewerkers verliest.  Je moet er grip op krijgen!

De vraag is echter: Wanneer vind je security effectief?

Voor iedereen binnen een organisatie zal dit een ander antwoord opleveren. Zo zal de directie geïnteresseerd zijn in de organisatiebrede verdeling van verwantwoordelijkheden en budgetten voor security. De IT-Manager wil graag weten in hoeverre securityprocessen (vulnerability management, patch management, incident management) effectief zijn. De business unit manager wil graag weten in hoeverre zijn processen veilig en effectief door IT-security ondersteund worden. De IT-Security Officer is op zoek naar de effectieve werking van security oplossingen. De Corporate Security Officer heeft van nature interesse in alle bovenstaande zaken, dat legt zijn functie hem op.

Dit zijn slechts enkele voorbeelden van de individuele waardebeleving rondom security.  Een ander aandachtspunt hierbij is dat iedereen de lat voor zichzelf op een andere hoogte legt. Dit heeft direct te maken met het accepteren van restrisico’s. Het risicoprofiel van de organisatie speelt hierin naar mijn mening een grote rol.

Omdat de informatiebehoefte zo verschilt per rol in de organisatie moet security monitoring & rapportage hiermee rekening houden. Een samenhangende verzameling security metrics zal die gemengde informatiebehoefte moeten invullen. Voor mijzelf komt hier de samenhang tussen mens, proces en techniek om de hoek kijken. Voor ieder van die drie aandachtspunten zullen security metrics opgenomen moeten worden in de rapportage. De onderstaande tabel geeft enkele voorbeelden.

Categorie	Voorbeeld
Mens	·         Aantal medewerkers die de awareness training hebben doorlopen. ·         Aantallen afdrukken die op de printer zijn achtergelaten. ·         Naleving van de Clean Desk Policy. ·         Aantallen mails met vertrouwelijke data naar ‘privé’-accounts.
Proces	·         Gemiddelde tijd om incidenten op te lossen. ·         Gemiddelde kosten om kwetsbaarheden te identificeren en op te lossen. ·         Percentage systemen die gepatched zijn op het vereiste niveau.
Techniek	·         Aantal tegengehouden DDOS-aanvallen. ·         Aantal virussen die zijn ontdekt. ·         Aantal virusuitbraken die zijn voorkomen. ·         Aantal botnets die zijn ontdekt.

Momenteel zijn verschillende fabrikanten van securityproducten in staat om grote hoeveelheden informatie te rapporteren. Op basis van SIEM-oplossingen en GRC-oplossingen worden adviezen gegeven en workflows in gang gezet om geconstateerde misstanden op te lossen. Zo kan de RSA Envision SIEM-oplossing méér dan 1500 standaard rapporten opleveren. Een GRC-oplossing is in staat om te rapporteren over een totaal framework als COBIT met honderden controls en bijbehorende metrics, die voornamelijk gericht zijn op processen.

Het is bijna onmogelijk om hieruit een effectieve standaardrapportage te kiezen die recht doet aan de verschillende waardebelevingen met betrekking tot security, zoals ik die bovenstaand heb aangegeven.  

Is er tot nu toe dan geen set security metrics samengesteld die inspeelt op individuele wensen en de drie aandachtspunten mens, proces en techniek? Het antwoord is ja, en nee!

Er zijn verschillende initiatieven. Binnen COBIT 5.0 is de bijdrage van IT (en daarmee IT-security) aan de business centraal komen te staan. Zoals ik al eerder aangaf is COBIT erg procesgeoriënteerd. ISO 27004 geeft een richtlijn voor security metrics met betrekking tot het security management proces (ISO 27001). NIST heeft op basis van SP 800-55 een richtlijn opgesteld voor security metrics die meer technisch geörienteerd zijn. Het Center for Internet Security heeft een verzameling metrics samengesteld die grotendeels procesgeoriënteerd zijn.

Andrew Jaquith heeft met zijn boek ‘SecurityMetrics: Replacing Fear, Uncertainty, and Doubt’ in mijn ogen de beste kijk op security metrics neergezet. Dat is onderbouwd door de periodieke MetriCon meetings waar indringend gediscussieeerd wordt over de juiste security metrics. In hoofdstuk 10 bouwt Jaquith een ‘Balanced Security Score Card’ op met de indeling: financieel, klant, intern proces en leren & groeien. De voorbeelden van security metrics die hij geeft zijn veelzijdig en kunnen goed gebruikt worden om individuele wensen in te vullen. Daarbij is het ook mogelijk om samenhang aan te brengen tussen mens, proces en techniek.

Heeft Jaquith daarmee de ultieme methode en verzameling security metrics te pakken?

Wellicht, maar bedenk goed op welke wijze jouw organisatie stuurt op organisatiedoelstellingen. De balanced scorecard methode, zoals Jaquith in hoofdstuk 10 beschrijft, is van nature een top-down aanpak. Dat houdt in dat midden management en medewerkers mee moeten in de rapportagecultuur en beperkte mogelijkheid hebben tot eigen inbreng. De effectiviteit van security besturen in een organisatie is in mijn ogen sterk afhankelijk van de wijze waarop de organisatie als geheel bestuurd wordt. En de balanced score card past daar misschien niet bij.

Als je in jouw organisatie de effectiviteit van security duidelijk wilt maken, houd dan goed rekening met de individuele wensen. En probeer samenhang aan te brengen tussen mens, proces en techniek. Als je al gebruik maakt van standaardrapportages houd die dan eens tegen het licht en bekijk of ze voldoen aan die individuele wensen. Pas ze zonnodig aan.

Heb jij specifieke ervaringen op dit gebied, of heb je een uitgesproken mening over de waarde van security? Laat die dan weten! Alvast bedankt.  

Security organiseren - de triade (2)

In een vorig artikel heb ik aangegeven dat na een certificeringstraject voor ISO 27001 al vlug sprake is van practical drift. De discipline van verantwoord omgaan met vertrouwelijke informatie verandert al vlug in nalatigheid (bewust of onbewust). 


Voor goede aandacht voor security binnen een organisatie ben ik er van overtuigd dat de CEO, de CIO en de CSO intensief moeten samenwerken. Todd Fitzgerald heeft daar een goed artikel over geschreven in 2007. Ondanks dat security zich in snel tempo aanpast aan de ontwikkelingen op het gebied van cybersecurity blijft datgene wat Todd Fitzgerald beschrijft van waarde. 


Het spreekt me erg aan juist omdat het uitgaat van een gedeelde verantwoordelijkheid waarbij de betrokkenen elkaar moeten vinden en begrijpen. En dat is vaak niet het geval in een (hiërarchische) organisatie. 


Het vorige artikel zoomde in op de vragen die de CEO aan de CSO kan stellen voor een betere samenwerking. Onderstaand zijn de vragen weergegeven die de CIO aan de CSO kan stellen.

• Welke inspanning is er minimaal nodig om veilige software te ontwikkelen?
• Wat moeten we doen om audit issues te voorkomen in de softwareontwikkeling, zonder significante kosten of vertragingen op te lopen bij onze IT-projecten?
• Hoe zie jij jouw rol, als reviewer van geïmplementeerde securitymaatregelen of als promoter vóór de implementatie?
• Welke technologieën zijn er beschikbaar om het arbeidsintensieve aspect van patch management, vulnerability management, configuration management en compliance monitoring te verminderen?
• Kun je nuttige informatie over reële risico’s in onze branche en alternatieve tegenmaatregelen die organisaties gebruiken opleveren?
• Hoe kunnen we verzekeren dat we aan minder risico’s blootstaan, zodanig dat we op een acceptabel risiconiveau zitten?
• Welk tastbaar voordeel bieden de investeringen in security om de business mogelijk te maken?
• Welke interne en/of externe audit issues worden verholpen door de investeringen in security?
• Welke IT-resources zijn nodig, in aanvulling op security medewerkers, om de security oplossing te kunnen implementeren? Welke ondersteuning van de business hebben we nodig?
• Hoe integreren we de security eisen in het software ontwikkelingsproces? Voeren we die taken al uit?
• Hebben we alle noodzakelijke kennis en ervaring in huis om deze security oplossing te implementeren? Moeten we wellicht overwegen om enkele van de functies uit te besteden?
• Wat zijn de kritieke succesfactoren voor succesvol beveiligen van de IT-infrastructuur? Hoeveel is genoeg?
• Hoe kun jij me helpen om mijn tijd en inspanning, met betrekking tot compliance activiteiten, te reduceren?

Er zijn natuurlijk veel vragen te bedenken. Het komt er op neer dat verantwoordelijke mensen binnen de organisatie zich er van bewust zijn dat ze die gedeelde verantwoordelijkheid hebben. Je kunt hier natuurlijk vanuit vele invalshoeken je licht op laten schijnen (leiderschap of onderhandelen). Maar dat gaat te ver voor dit artikel.  

Zie jij binnen jouw organisatie hoe de drie (CEO,CIO en CEO) samenwerken op het gebied van security? Of zie jij geheel andere positieve verbanden waardoor security juist goed georganiseerd is? Dat is interessant. Laat het me weten!

Blijf alert! Je hebt het laatste artikel over de triade nog van me te goed. Heb je opmerkingen, of wil je bepaalde onderwerpen terugzien? Laat het me dan weten. Reageer!

Je data is écht veilig

De Sunday Times heeft 70 apps voor smartphones onderzocht op het verzenden van vertrouwelijke informatie. Door gebruik te maken van  ‘MiddleMan’ is gebleken dat 21 apps vertrouwelijke data verzonden (telefoonnummer, emailadressen, locatiegegevens, smartphone-ID, …). We kijken er natuurlijk niet van op dat gebruikers achteloos de voorwaarden accepteren. Maar de bepalingen voor het verzamelen van allerlei informatie zijn veelal onderin weggestopt door de producent/leverancier van de apps.

Verzamelen van de data is nog tot daar aan toe. Maar de voorwaarden maken niet duidelijk waar die data naartoe gezonden wordt. De Sunday Times geeft aan dat de data onder andere naar China en India gestuurd worden. De European Data Protection Directive geeft aan dat vertrouwelijke data niet naar landen buiten de Europese economische grenzen gestuurd mogen worden. Tenzij die landen er een ‘vergelijkbare’ wet-/regelgeving met betrekking tot privacy  op na houden. Dit geldt tot op de dag van vandaag niet voor China en India.

In mijn vorige blog schreef ik over de immense hoeveelheid apps die er te downloaden zijn in de appstore.

Vijfhonderdvijfentachtigduizend!

Daarbij wees ik ook op de gevaren voor het gehele ecosysteem van appstores die door Enisa in kaart gebracht zijn (meer dan 65 risico’s).

We weten dus nu van 21 apps dat er vertrouwelijke data verzameld wordt, waarvan enkele data naar China en India sturen. Dat brengt de totale blinde vlek op 584.979 apps en 64 risico’s die we nog niet helder hebben.

Kortom, Bring Your Own Device is een echte uitdaging voor de IT-afdeling, het security team, de juristen en HR binnen jouw organisatie!

Ik wil je echter ook wijzen op de positieve kant van dit verhaal. 

Vorige week vond het jaarlijkse Mobile World Congress plaats in Barcelona. Naast allerlei mooie gadgets presenteerde de GSM Association (GSMA) richtlijnen voor ‘Privacy-by-Design’ voor mobiele ontwikkelaars.  De GSMA stelt dat iedere gebruiker privacy op zijn eigen manier beleeft (verwachtingen, behoeften, eisen, bezwaren, …). Daarmee moet op een proactieve manier vanaf het ontstaan van een app rekening gehouden worden.

De GSMA wil de richtlijnen laten adopteren door bijna iedereen in de gehele ecosysteem van de appstores: ontwikkelaars, fabrikanten van apparatuur, leveranciers van platformen en operating systems, mobiele providers, adverteerders en data analytics. Vodafone, Orange en Deutsche Telekom hebben al toegezegd deze richtlijnen te zullen naleven. De verwachting is echter dat Apple, Google, Microsoft en RIM deze richtlijnen niet gemakkelijk zullen adopteren omdat ze soms haaks staan op de business modellen van deze giganten.  

De richtlijnen van GSMA bevatten enkele goede suggesties:

·         Stel apparatuur default in op de beveiliging van privacygevoelige gegevens.
·         Geef gebruikers de controle over herhaling van het gebruik van persoonlijke informatie (niet éénmalig dus).
·         Laat gebruikers instemmen bij updates. Voer geen ‘heimelijke’ updates op de achtergrond uit.  

De vraag is of de veiligheid van (persoonlijke) vertrouwelijke informatie door deze richtlijnen wordt vergroot?

Het ecosysteem rondom de appstores bestaat uit vele individuele ontwikkelaars. Tel daarbij de kans dat de ‘app-giganten’ de richtlijnen zullen adopteren op. Gelet op de grote aantallen apps en de andere risico’s blijft er realistisch gezien een risicovolle situatie over.

De richtlijnen van GSMA dragen sterk positief bij maar ik ben er van overtuigd dat iedere organisatie moet nadenken over de apps die ze toe willen laten op mobiele apparatuur. Het opstellen van een app-whitelist is een realistische overweging.

Ikzelf werk al meer dan 20 jaar op het snijvlak van organisatie en IT. Daarvan richt ik me de laatste 12 jaar op security. 

‘Privacy is een doodgeboren paard’ (NRC Next, 7 maart 2012)

De nieuwe iPad is vandaag aangekondigd en ik besluit te berichten over privacy. Het zijn onvoorstelbare getallen waar Apple ons mee overdonderd: 315 miljoen IOS-apparaten verkocht, waarvan 65 miljoen in het laatste kwartaal van 2011 (Webwereld.nl). Daarbij komt dat er meer dan 585.000 apps in de appstore staan waarvan 200.000 voor de iPad.

Onvoorstelbaar? Ga even zitten!

Er zijn meer dan 25 miljard apps gedownload! Dat is gemiddeld 80 apps per iPhone of iPad!

Ik wil dan toch wijzen op een rapport van ENISA waarin meer dan 65 risico’s in het ecosysteem van de Appstore en Android market zijn geïdentificeerd.  Als organisatie heb je geen controle meer over de aanschaf of ontwikkeling van veilige software. Dat ligt in handen van potentieel 585.000 individuele app-ontwikkelaars, Apple, Google en RIM (BlackBerry). Hoezo, privacy met zoveel iPads, apps en risico’s?  

En dat heb je binnen de muren van je organisatie toegelaten. Erger nog, ook buiten de muren van je organisatie, waar medewerkers onder het genot van een kopje Starbucks koffie vertrouwelijke klant- of patiëntgegevens zitten te verwerken.

Wat moet je dan met de titel van deze blogpost: ‘Privacy is een doodgeboren paard’?

Het artikel gaat in op de geschiedenis van privacy en stelt dat ‘privacy al 200 jaar wordt bedreigd met uitsterven. En zo hoort het!’

Vandaag is ook de dag van de Big Brother Awards, voor ‘de grofste privacyschenders van het jaar’. Hierin neemt de overheid een groot deel van de genomineerde instanties voor haar rekening. Daarbij komt dat de Europese Unie recent nog met wetsvoorstellen is gekomen voor strengere online privacybescherming. Kortom, het is een onderwerp dat aandacht verdient en ook krijgt.

Privacy is volgens de auteur van het artikel (Lynn Berger) een bedreigde diersoort. De aandacht voor een bedreidge diersoort ontstaat als de bedreiging reëel is. Anders is het de aandacht niet waard. Het speelt geen enkele rol als we onze dagelijkse bezigheden op sociale media neerzetten. Maar als Google op 1 maart de privacyvoorwaarden van al haar individuele producten stroomlijnt stromen de media weer vol met tips, trucs en waarschuwingen.

Privacy is natuurlijk niet een technologie-gebonden issue! Het fotograferen van straten door Google wordt in ieder land anders beleefd. Topless zonnen is in Nederland ook aanvaard, terwijl het in Amerika ondenkbaar is. Daarentegen spreken Amerikanen honderduit over hun salaris en zijn de kaken daarover in Nederland stijf op elkaar gesloten.

Voor de oude Grieken was duidelijk dat deelname aan debat een beter mens van je maakte. Je moest wel deelnemen aan het openbare leven, waardoor je privacy onder druk kwam te staan. Ronddwalen in je eentje kon in de Middeleeuwen een teken van krankzinnigheid zijn.

In de achttiende eeuw is de mens begonnen met het opnieuw erkennen van privacy. Denk aan aparte kamers in de architectuur en stemhokjes. Sindsdien hebben zowel groepen en geloofsgemeenschappen in de samenleving, als koningshuizen zich beklaagd over gebrek aan privacy. Het ‘interview’ werd in Europa gezien als een inbreuk op de privacy, terwijl het ontstond in Amerika waar de hang naar details over het privéleven toenam.

Privacy is altijd ‘tegen’ iets: staatsinvloed of –inmenging, sociale bemoeienis, journalistieke nieuwsgierigheid. Het balanceert op de rand van de steeds veranderende samenleving. Iedere schending van privacy is een ‘ijkmoment’. Privacy gaat over de grens tussen publiek en privé.

OK, mooi dat historisch besef! Maar hoe moet je daar nou mee omgaan?

Je moet er niet voor weglopen. Door de grens op te zoeken, het positief te benaderen en het debat erover te voeren is het voor zowel voor- als tegenstanders duidelijk waar de grens ligt. Het is een discussie binnen jouw organisatie, waar alle controle over aanschaf of ontwikkeling van veilige software weg is gevallen. Dat geldt ook voor de beheersbaarheid van veilige omgang met vertrouwelijke informatie door je collega’s. Zij werken buiten de deur op eigen apparatuur en leggen contact via een, door henzelf gekozen, provider.

Kortom, je zult als CEO, CIO of Security Officer een weg moeten vinden om verloren terrein goed te maken. Volgens mij is het meer dan gerechtvaardigd om de discussie aan te gaan over het monitoren van gebruikersgedrag, lees ‘de veilige omgang met vertrouwelijke informatie buiten de grenzen van de organisatie’. Het historisch besef van privacy, waar het geciteerde artikel een mooie beschrijving van geeft, helpt je bij het aangaan van die discussie.

Het College Bescherming Persoonsgegevens heeft trouwens een goede richtlijn opgesteld voor het monitoren van gebruikersgedrag (internet/email): ‘Goed werken in netwerken’. Daarin staan goede vuistregels. 


Monitoren van gebruikersgedrag is een essentiële component van de beveiliging binnen de organisatie. Dit heb ik ook in de vorige blog post 'Security en Het Nieuwe Werken' aangegeven. 

Lynn Berger is auteur voor o.a. NRC Next. Zij werkt aan een proefschrift over de geschiedenis van privacy aan de Colombia University in New York. Ikzelf werk al meer dan 20 jaar op het snijvlak van organisatie en IT. Daarvan richt ik me de laatste 12 jaar op security.