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.