Hoogleraar: ‘Bedrijven denken te licht over beveiliging’

NIJMEGEN – Veel bedrijven denken te licht over het online beveiligen van klantgegevens. Dat zei hoogleraar computerbeveiliging Bart Jacobs van de Radboud Universiteit in Nijmegen dinsdag. Volgens Jacobs moeten bedrijven bij het opzetten van een ICT-project er rekening mee houden dat een kwart van het budget moet worden geïnvesteerd in het beveiligen van de website en daarbij de klantgegevens. (bron)

Als een hoogleraar het zegt dan zal het wel waar zijn, toch? En deze hoogleraar kan ik natuurlijk alleen maar bijvallen. Er wordt inderdaad te licht gedacht over beveiliging en daar moet vanaf heden verandering in komen. Tenminste als het aan mij ligt, maar dat roep ik natuurlijk al jaren en dat blijf ik ook roepen. Op een gegeven moment moeten anderen dat dan toch overnemen?

Veelal zien we trouwens dat beveiliging nog steeds niet begrepen wordt. De gevolgen uiten zich dan inderdaad in een beveiligingsincident, maar de oorzaken liggen meestal buiten het vakgebied. Incidenten worden bijvoorbeeld veroorzaakt door onbekendheid met beveiliging, door gebrek aan patchmanagement, door bezuinigingen op de verkeerde gebieden en ga zo nog maar even door.

Natuurlijk moeten we niet de hele beveiliging in 1x volledig dicht willen timmeren. Dat is ook helemaal niet nodig (en enorm kostbaar). Wat we wel kunnen doen is ervoor zorgen dat we bij alle nieuwe ontwikkelingen beveiliging ook meenemen. Dat doen we niet door uit te gaan van de beveiligingsmaatregelen, maar door de risico’s die we af willen dekken. Doen we dat op de juiste manier dan zullen we minder en minder risico’s lopen (nieuwe zaken zijn immers al redelijk beveiligd).

Vervolgens kijken we naar alle zaken die we nu al in beheer hebben. Daarbij kijken we goed naar de meest kritische bedrijfsprocessen en de daarbij behorende kritische informatiesystemen (uiteraard in termen van: beschikbaarheid, exclusiviteit en integriteit). Op basis daarvan kunnen we dan ook de grootste risico’s in de operatien wegnemen.

Zo werken we het “achterstallig” onderhoud weg en voorkomen we dat onveilige systemen in productie gaan. De komende jaren zorgen we er steeds voor dat er meer en meer bestaande systemen beter beveiligd worden en over een aantal jaar hoeven we ons al een stuk minder zorgen te maken.

Maar, zoals gezegd, zijn de oorzaken voor de beveiligingsincidenten vaak gelegen buiten het vakgebied. We moeten dus zorgen voor zogenaamd “goed huisvaderschap”. Daar profiteert niet alleen de beveiliging van maar het zorgt er ook voor dat we op andere gebieden “in control” raken. Sterker nog, het zou zomaar zo kunnen zijn dat hierdoor ook de efficiëntie binnen de organisatie toeneemt.

Vergezocht? Nou, dat valt volgens mij wel mee. Kijk nog even naar patchmanagement. Dat zorgt er niet alleen voor dat de systemen voorzien zijn van de laatste patches, maar zorgt er ook nog eens voor dat nieuwe functionaliteiten in de systemen worden doorgevoerd. Je werkt toch ook niet meer met wordPerfect 6.1? Nee, je bent inmiddels gewend geraakt aan de nieuwst Office versie van Microsoft en die heeft het voor een berg mensen makkelijker gemaakt om brieven te typen, toch?

Nou dan, waarom zorgen we er dan niet voor dat we voor andere systemen ook over de laatste patches beschikken? Komt het omdat we het niet weten of omdat we het niet willen? Zo zie je maar, de gevolgen uiten zich als beveiligingsincident maar de oorzaken liggen ergens anders.

Bekendheid met meldingsplicht beveiligingsincidenten

Zo, inmiddels hebben we de medewerkers verteld dat ze beveiligingsincidenten moeten melden en we hebben ze ook geprobeerd duidelijk te maken wat wij onder beveiligingsincidenten verstaan. Nu is het natuurlijk de vraag of het aantal meldingen inderdaad toeneemt.

Het gaat dus niet zozeer om de vraag, maar het feit of het ook echt werkt. De vraag:
Is het personeel duidelijk gemaakt dat beveiligingsincidenten gemeld moeten worden?

Bekende termen zijn “opzet”, “bestaan” en “werking”. In opzet en bestaan kunnen we het best goed geregeld hebben. We hebben mooie beleidsdocumenten, mooie procedures en voorschriften en we hebben ze ook nog eens beschikbaar gesteld op het intranet en via de mail aan iedereen verzonden. Nu willen we toch wel graag weten of het allemaal effect heeft, oftewel: werkt het? Want daar gaat het toch uiteindelijk allemaal om, is het niet?

We kunnen de medewerkers natuurlijk allemaal op de man (of vrouw) af vragen of ze weten dat ze beveiligingsincidenten moeten melden. Grote kans dat het antwoord volmondig ja is. Het is immers logisch dat we dat soort zaken melden. Toch is hier het risico op sociaal wenselijke antwoorden te groot. We zullen dus op zoek moeten naar aanvullende mogelijkheden om te testen of er ook echt gemeld wordt.

Nu wil ik je natuurlijk niet aanmoedigen om allerlei illegale of niet toegestane acties uit te voeren, maar er zijn best manieren om te kijken hoe het er mee gesteld is. Is het zichtbaar dragen van toegangspasjes binnen jouw bedrijf bijvoorbeeld verplicht? Draag dan het pasje eens een dag niet zichtbaar om te kijken of je er op wordt aangesproken (dat werk natuurlijk minder goed als je iedereen binnen het bedrijf persoonlijk kent).

Loop eind van de dag, als iedereen al lekker naar huis is, nog eens een rondje over je afdeling en kijk welke waardevolle spullen of informatie voor het grijpen ligt. Je zou dat kunnen melden, je zou er niets mee kunnen doen, of je zou de informatie kunnen verzamelen en eventueel een briefje achter kunnen laten dat ze het bij jou op kunnen komen halen. In principe mist iemand de volgende dag de informatie en hij gaat op zoek. Heb je een briefje achter gelaten dan zal hij het bij je op komen halen, ligt dat briefje er niet dan zal hij met een zoekende blik over de afdeling lopen.

Laat eens een deur open staan (uiteraard even in de gaten houden wie er stiekem naar binnen glipt) en kijk wat mensen doen. Laten ze de deur zelf ook open staan, doen ze de deur juist dicht of bellen ze even met de beveiliging om door te geven dat deze deur open staat?

Een aantal simpele manieren om te testen hoe het gesteld is met de beveiligingscultuur van de medewerkers. Nemen ze zelf actie, doen ze juist helemaal niets of maken ze er melding van? Zodra we dat weten kunnen we weer volgende stappen zetten en het melden van beveiligingsincidenten verder onder de aandacht brengen.

We moeten er dan natuurlijk wel voor zorgen dat het melden makkelijk is. Dus geen lange wachttijden als ze telefonisch melden en geen ingewikkelde formulieren om het op papier te doen.

Een leuke optie is om er een competitie van te maken. Iedere zoveelste melder krijgt een taart, gemelde beveiligingsincidenten worden gebruikt om de medewerkers te trainen (bijvoorbeeld door ze te behandelen in ons “security krantje”). Oppassen natuurlijk dat medewerkers er geen sport van gaan maken om maar zoveel mogelijk incidenten te veroorzaken, dan schieten we juist weer door naar de verkeerde kant.

Voorwaarde is natuurlijk wel dat we over voldoende (en kwalitatief goede) capaciteit beschikken om de incidenten op te pakken, te analyseren en verbeteringen door te voeren.

Beveiligingsincidenten zien er op papier vaak ingewikkeld uit: zware aanvallen op het netwerk, ramkraken om ons gebouw binnen te dringen…maar juist de dagelijkse gang van zaken kunnen grote risico’s met zich meebrengen en voor die dagelijkse gang van zaken hebben we de oren en ogen van onze medewerkers nodig om de boel steeds veiliger te krijgen.

Duidelijkheid over beveiligingsincidenten

We willen graag zicht hebben op de beveiligingsincidenten die zich voordoen zodat we kunnen analyseren en waar mogelijk verbeteringen door kunnen voeren om dergelijke incidenten in de toekomst te voorkomen.

Daarvoor kunnen we natuurlijk een procedure opstellen en in het beleid opnemen dat beveiligingsincidenten gemeld moeten worden, maar zijn we er dan?

De vraag:
Is het personeel duidelijk gemaakt wat onder een beveiligingsincident verstaan wordt (niet alleen beschadigingen of verlies van bedrijfsmiddelen, maar ook het verrichten van handelingen die in strijd zijn met de beveiligingsprocedures)?

Technisch kunnen we allerlei systemen inzetten om beveiligingsincidenten te constateren. We hebben mooie alarmsystemen en als een inbreker het in zijn hoofd haalt om bij ons in te breken dan gaan alle toeters en bellen af. Ook op het netwerk of de firewall hebben we systemen ingericht die automatisch melding maken als onze policies worden overtreden.

Hiermee hebben we een mooie basis, maar we moeten niet vergeten dat de medewerkers onze ogen en oren zijn binnen de organisatie. We moeten ze duidelijk maken wat het verschil is tussen een incident en een beveiligingsincident en dat is makkelijker gezegd dan gedaan. Het inloggen na de vakantie met een verkeerd wachtwoord is een incident, gewoon even de helpdesk bellen die je wachtwoord wijzigt in “Welkom01”. Maar wat als een collega, tijdens jouw vakantie, geprobeerd heeft in te loggen met jouw account? Dan is het al snel een beveiligingsincident als jij er geen toestemming voor hebt gegeven.

Probleem hierbij is natuurlijk dat je er maar moeilijk achter komt waardoor jouw account geblokkeerd is. Ben je het echt vergeten of is er iets anders aan de hand? We zullen dus niet alleen de medewerker duidelijk moeten maken wat we onder een beveiligingsincident verstaan maar moeten ook (bijvoorbeeld) de medewerkers van de helpdesk nadere instructies geven zodat zij beveiligingsincidenten kunnen achterhalen.

Termen die we daar tegenwoordig wel voor gebruiken zijn de zogenaamde: “first line of defense” (de medewerker), “second line of defense” (de helpdesk) en “third line of defense” (de beveiligingsafdeling). Hoe meer deze 3 lijnen weten over beveiligingsincidenten, hoe groter de kans dat we ze gemeld krijgen.

Het lijkt misschien tegenstrijdig, en leg het inderdaad maar eens aan het management uit: we doen van alles aan beveiliging en vertellen de medewerkers dat beveiligingsincidenten gemeld moeten worden. Dan zal er wel een afname plaatsvinden op dit gebied, toch? Nou, die afname ontstaat pas na verloop van tijd. Doen we het goed dan zullen we eerst juist meer meldingen ontvangen. Meer zaken worden immers opgemerkt als beveiligingsincident.

Met een goed verhaal krijgen we dat wel aan het management uitgelegd. Het gaat er hierbij om of we “compliant” willen zijn of juist “in control” willen komen. In het eerste geval zetten we mooie zaken op papier en hopen er het beste van (het aantal meldingen zal waarschijnlijk niet toenemen). In het tweede geval zorgen we ervoor dat wat we bedenken ook echt gaat werken en dat kost tijd (en het aantal meldingen zal waarschijnlijk toenemen).

Een mooie graadmeter dus. Zien we een toename in het aantal meldingen van beveiligingsincidenten dan hoeft dat niet perse te betekenen dat we een groter risico lopen dan vorig jaar. Nee, het kan net zo goed betekenen dat we juist erg goed bezig zijn en meer grip op de zaak beginnen te krijgen.

Onderscheid tussen incidenten en beveiligingsincidenten

We zijn er vorige week al kort op ingegaan, maar vandaag zoomen we nog wat dieper in op het verschil tussen incidenten en beveiligingsincidenten.

De vraag is dan ook niet voor niets:
Wordt er onderscheid gemaakt tussen beveiligingsincidenten en overige incidenten?

We schreven al dat we vanuit beveiligingsoptiek graag willen weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken. Gisteren voegden we daaraan toe dat we het melden van incidenten zo makkelijk mogelijk willen maken om geen informatie verloren te laten gaan.

Nu kunnen we op papier en met een beetje Googlen best wat leuke definities ontwerpen voor het verschil tussen incidenten en beveiligingsincidenten. Dat moeten we zeker niet nalaten, maar we moeten degene die de incidenten als eerste te horen krijgen daar ook in trainen. En dat is makkelijker gezegd dan gedaan. De helpdesk medewerker heeft zijn “target” en moet binnen 5 minuten de klant weer op pad sturen (soms met een kluitje het riet in, maar het target is gehaald).

Daarmee gaat kostbare informatie verloren, die daarna wellicht nooit meer is terug te halen. Voor die beveiligingsincidenten die zich vaker voordoen is het nog mogelijk om mensen daarin te trainen. Ga maar na: na een alarmmelding van het inbraakdetectiesysteem weet de beveiligingsbeambte inmiddels wel wat hij moet doen en hoe hij moet reageren. Maar hoe reageert hij of zij als er een melding wordt ontvangen van een gijzeling op de directieverdieping?

Als het goed is hebben we natuurlijk allerlei procedures voor het opvolgen van incidenten maar het gaat er juist ook om dat degene die er mee geconfronteerd wordt zo creatief (en stressbestendig) is dat er ook echt wat in gang wordt gezet. De procedures zijn een goed hulpmiddel, maar niemand gaat, als het gebouw in de brand staat, een dik calamiteitenplan lezen.

We zullen dus mensen moeten trainen in het ontdekken van (mogelijke) beveiligingsincidenten maar juist ook in de opvolging daarvan. Dat geldt overigens niet alleen voor meer fysieke incidenten maar ook voor incidenten op informatiebeveiligingsgebied. Zien we dat de website uit de lucht gaat dan moeten we snel analyseren of het een technische storing betreft of een aanval van een scriptkiddie. De opvolging moet daarop worden afgestemd.

Omdat het verschil tussen een incident en een beveiligingsincident niet altijd duidelijk is, moeten we de meldpunten een mindset meegeven waarbij ze signalen herkennen. Jammer dat ze de targets even niet halen, maar het reageren op een beveiligingsincident is toch echt even belangrijker.

Juist als we helpdesken uitbesteden (al dan niet naar het buitenland) wordt het risico groter dat we beveiligingsincidenten missen. Er is immers weinig betrokkenheid bij onze “business” en de targetdruk is alleen maar groter. Een serieus risico waar we rekening mee moeten houden.

Als laatste halen we hier nog even kort de oorzaak-gevolg relatie aan. Dat hebben we al vaker gedaan, dus daar verwijs ik graag naar. De melding is veelal een gevolg (“mijn account is geblokkeerd”), de oorzaak kan soms een beveiligingsincident zijn (een collega heeft geprobeerd mijn account te gebruiken). Bij de melding moeten we dus op zoek naar de melding achter de melding…tenminste, als we echt iets van de incidenten willen leren…en dat verschilt dan weer juist niet tussen incidenten en beveiligingsincidenten want we willen beide structureel oplossen, toch?

Beveiligingsincidenten

Als we beveiliging goed (genoeg) inrichten dan kunnen we er op vertrouwen dat we de risico’s voldoende hebben afgedekt. Preventief zijn we bezig om juist die activiteiten op te pakken die bijdragen aan de continuïteit van onze organisatie. Toch zullen we zien dat preventieve maatregelen alleen niet genoeg zijn, nee, we zullen ook detectie moeten inregelen voor het geval er toch iets onverwachts gebeurt. We moeten met onze repressieve en correctieve maatregelen daarop in kunnen spelen om zo snel mogelijk terug te gaan naar de “business as usual”.

De vraag die daarbij speelt is:
Is er vastgelegd wat verstaan wordt onder beveiligingsincidenten?

Vanuit de IT zijn we gewend om te werken met incidenten. Een verstoring van de applicatie melden we bij de helpdesk zodat we zo snel mogelijk weer aan het werk kunnen. Logisch en als we er echt serieus mee bezig zijn dan richten we het incident management proces in conform ITIL.

Daar moeten we vooral mee door blijven gaan, want dit is zeker een aspect dat bijdraagt aan de continuïteit van de organisatie. Toch moeten we ook na gaan denken over wat we exact verstaan onder een beveiligingsincident. Deze kan veel overeenkomsten vertonen met een incident (conform IT), maar kan wel degelijk op een andere wijze worden opgelost.

Om het niet te cryptisch te maken even een kort voorbeeld: stel je komt terug van vakantie en bent je wachtwoord vergeten. Je probeert 3x in te loggen en blokkeert helaas je account. Helpdesk bellen en na een paar minuten kun je gelukkig toch weer aan de slag. Een incident dat we op moeten lossen omdat je anders liever weer terug gaat naar je vakantieadres. Maar stel nu dat tijdens jouw afwezigheid een collega geprobeerd heeft om met jouw account in te loggen. Hij moest even in je mailbox zijn om een mailtje te lezen. Jij komt terug en kunt niet meer inloggen, terwijl je er zeker van bent dat je het juiste wachtwoord hebt gebruikt. Verstaan we dit nog onder een incident of hebben we het hier toch eerder over een beveiligingsincident?

Enerzijds is het dus niet altijd gemakkelijk om de juiste definitie te hanteren voor beveiligingsincidenten, maar anderzijds is het ook nog lastig om ze te detecteren. Hoe kan de medewerker van de helpdesk nu weten of het een incident is omdat jij je wachtwoord bent vergeten of dat het een beveiligingsincident is omdat een collega geprobeerd heeft in te loggen?

Lekker relevant zul je zeggen. Ik ben net terug van vakantie en wil (of moet) weer aan de slag. Toch is het voor de beveiligingsaanpak relevant. Misschien probeert die collega namelijk nog wel meer illegale activiteiten uit te voeren. Stel dat het was gelukt om in te loggen en dat hij namens jouw een mail had gestuurd aan de directeur die hij voor stommeling uit maakt dan zijn de gevolgen wel anders.

Vanuit beveiligingsoptiek willen we graag weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken.

Storingen groter gevaar in NL dan cyberaanvallen

Storingen vormen bij Nederlandse bedrijven een veel groter gevaar dan cyberaanvallen, zo stelt het Centraal Bureau voor de Statistiek (CBS). Er werd gekeken naar beveiligingsincidenten bij zowel Nederlandse als andere Europese landen. Storingen, oftewel de uitval van ICT-diensten of vernietiging / verminking van gegevens door storingen in hardware of software komt in Nederland bij 19% van de bedrijven voor. Aanvallen van buitenaf (7%), infecties (7%) en datalekkage door Inbraak, pharming of phishing (4%) vormden een veel kleiner deel van de incidenten (bron).

Als het Centraal Bureau van de Statistiek het onderzocht heeft dan zal er toch zeker een kern van waarheid in de gegevens zitten. Goed om te weten natuurlijk, zo kunnen we met feiten naar buiten treden.

Het geeft maar weer eens aan dat we informatiebeveiliging moeten relativeren en wel op die manier dat de grootste dreiging helemaal niet van buitenaf komt. Natuurlijk moeten we aan “grensbewaking” doen en blijven doen (en daar kan ook nog heel wat in verbeterd worden). Maar het wordt belangrijker om ook eens naar de interne organisatie te kijken.

Helaas wordt in het bericht niet aangegeven waardoor die interne storingen veroorzaakt worden. Dat kan natuurlijk technisch falen van de systemen zijn, foutieve instellingen, fouten van medewerkers en ga zo maar door. Maar wat te denken van de bewuste activiteiten van medewerkers? Nog te vaak worden allerlei technische beveiligingsmaatregelen ingezet terwijl met organisatorische en procedurele maatregelen veelal meer effect te bereiken is tegen lagere kosten.

Een overig opmerkelijk feit:
Ook vergeleken met de ons omringende landen is het aandeel bedrijven met ICT-beveiligingsincidenten hoog. In Duitsland was het 22 procent, in België 24 procent en in het Verenigd Koninkrijk slechts 10 procent…Nederland behoort met Denemarken en Noorwegen tot de landen met de meeste ICT-beveiligingsincidenten.

Kortom: werk aan de winkel voor de Nederlandse organisaties. En het wordt misschien wat vervelend maar dat begint toch echt bij het bewustzijn van het management.

Maakindustrie angstig voor lek bedrijfskennis

Een onderzoek in de Maakindustrie, uitgevoerd door Securitas, geeft interessante inzichten, een korte samenvatting:

  • Het lekken van bedrijfskennis naar de concurrent wordt als beveiligingsrisico gezien
  • Bedrijven zijn bang voor sabotage van het productieproces
  • Bedrijven vinden hun bedrijf kwetsbaar voor beveiligingsincidenten
  • Bedrijven zetten zeer beperkt het topmanagement in om draagkracht voor het beveiligingsbeleid te vergroten
  • Een groot deel van de bedrijven doet helemaal niets om de draagkracht en het commitment voor het beveiligingsbeleid te vergroten.

In het westen van Nederland ziet 28 procent van de bedrijven het lekken van bedrijfskennis naar de concurrent als grootste beveiligingsrisico. Hiermee is het de enige regio die dit als belangrijkste risico ziet.

Terwijl bedrijven in de maakindustrie landelijk gezien het meest bang zijn voor sabotage van het productieproces, ziet het westen van Nederland het lekken van bedrijfsinformatie juist als grootste risico. In de andere regio´s staat dit op de tweede of derde plaats. Het westen van Nederland lijkt binnen de maakindustrie een vreemde eend in de bijt. Ze hebben niet alleen een andere inschatting van het beveiligingsrisico, ze vinden hun bedrijf (met 29 procent) ook opvallend kwetsbaarder voor beveiligingsincidenten dan de rest van Nederland. In het oosten is dit percentage bijvoorbeeld 17 procent.

In het midden van Nederland zet slechts 15 procent het topmanagement in om draagkracht voor het beveiligingsbeleid te vergroten. In de rest van Nederland is dit percentage bijna 10 procent hoger. Het topmanagement van bedrijven kan juist heel goed ingezet worden voor het verhogen van de betrokkenheid bij het beveiligingsbeleid. Leidinggevenden hebben een voortrekkersrol. Wanneer zij hun commitment niet regelmatig uitspreken, of vertalen in het bedrijfsbeleid, zal de rest van het bedrijf ook niet volgen. Op deze manier blijft beveiliging een ondergeschoven kindje. 35 procent van de Nederlandse bedrijven in deze branche doet zelfs helemaal niets om de draagkracht en het commitment voor het beveiligingsbeleid te vergroten. Dit is in alle regio´s van het land ongeveer gelijk. (bron).