FBI topman wil tweede internet voor kritieke systemen

Het zal nooit lukken om de netwerken van energiebedrijven en banken adequaat te beveiligen, een manier om de systemen te beschermen is het opzetten van een gescheiden en beveiligd internet.

“De uitdaging met het internet is dat je niet weet wie de aanval uitvoert”, aldus de FBI-topman. Een belangrijke maatregel is volgens hem het ontwikkelen van netwerken waar geen anonimiteit bestaat en waar alleen betrouwbare werknemers toegang toe hebben. (bron)

Nu ken ik niet de exacte achtergrond van de stelling die door de FBI-topman geroepen wordt, maar het klinkt toch een beetje vergezocht. Als we er voor zorgen dat alleen betrouwbare werknemers toegang hebben tot het tweede internet, dan kan ons niets gebeuren. Ja ja, maar wie kun je dan vertrouwen en is het niet zo dat iedereen zijn prijs heeft? Wil men dit tweede internet aanvallen dan infiltreert men in de organisaties die daar toegang toe hebben en we kunnen weer van vooraf aan beginnen. Waarschijnlijk wordt dit tweede internet ook wel weer ergens gekoppeld aan het huidige internet en anders dan breken we toch gewoon op een andere manier in bij die organisaties die over kritieke systemen beschikken?

Omdat we de bankovervallen niet kunnen voorkomen besluiten we om alle banken maar te sluiten en in een tweede afgescheiden dimensie onder te brengen. The Matrix…here we come. Maar is dit al niet geprobeerd met “Second Life” en wie hoort daar nog wat van? En als ik als klant van die bank nu wil internet bankieren…mag ik dat dan via het huidige internet of moet men mij eerst betrouwbaar genoeg vinden om toegang te krijgen tot het tweede internet?

Nee, ik hoop toch dat deze FBI-topman er andere gedachten bij heeft. De kritieke systemen kunnen we immers niet los zien van andere systemen, organisaties en processen. Bedenk alleen maar welke organisatie toegang mag hebben tot dit tweede internet. Waarom zij wel en wij niet?

Ik kan me er maar weinig bij voorstellen en ben benieuwd naar de vorderingen op dit gebied. Maar laten we eerlijk zijn, moeten we als organisaties er niet gewoon voor zorgen dat we zelf de boel beter op orde hebben? Natuurlijk zijn er zware technische aanvallen die moeilijk zijn tegen te houden. Maar kijken we naar de recente incidenten en de oorzaken daarvan dan moeten we misschien wel concluderen dat die niet veroorzaakt zijn door ingewikkelde aanvallen maar juist door simpele feiten en doordat veel organisaties de basis gewoon niet op orde hebben.

Voordat we dus gaan investeren in een tweede, veiliger, internet (dat uiteindelijk ook weer aangevallen zal worden), kunnen we er beter voor zorgen dat we de basis geregeld hebben. We kunnen er dus beter voor kiezen om onze voordeur gewoon op slot te doen voordat we besluiten onze waardevolle spullen in een ander gebouw onder te brengen (waar we dan ook de voordeur van moeten sluiten).

Een mogelijke meldplicht voor digitale inbraken

De discussie is al meerdere malen gevoerd en zal waarschijnlijk ook nog vaker gevoerd worden als de meldplicht voor digitale inbraken niet van de grond komt. Het blijft een interessant onderwerp met voors en tegens. Maar laten we iets verder kijken dan onze neus lang is.

De Europese Commissie wil vanaf volgend jaar richtlijnen om het vertrouwen in certificaat-autoriteiten als DigiNotar in de toekomst te herstellen. Eurocommissaris Neelie Kroes denkt verder na over een mogelijke meldplicht voor digitale inbraken…

Een Iraanse hacker kraakte dit jaar de Nederlandse ssl-autoriteit DigiNotar en wist daardoor honderden vervalste certificaten aan te maken. De kritiek op het handelen van DigiNotar was groot en het bedrijf ging failliet. Securitybedrijven pleiten als reactie op de problemen voor beveiligingsstandaarden. Verder denkt het Nederlandse parlement na over de oprichting van een zogeheten ‘ict-brandweer’. (bron)

Kijken we terug naar het bericht dat we gisteren aanhaalden. Dan is het niet zo gek dat de IT-managers het onderwerp zo stressvol vinden. Je gaat er toch vanuit dat jouw leverancier van certificaten het goed voor elkaar heeft. Helaas weten we inmiddels beter. Maar trek deze lijn eens door. Gaan we er ook niet vanuit dat onze energieleverancier het goed voor elkaar heeft? Willen we niet zeker zijn van een bepaalde stroomvoorziening?

Geloof me, deze vraag gaat veel verder dan je certificaat-leverancier en je energiemaatschappij. Het geldt uiteindelijk voor de gehele keten. Wij als organisatie kunnen het nog zo goed voor elkaar hebben, maar als onze leveranciers en afnemers er minder aan doen, dan komt het al snel onder druk te staan.

We hebben de leveranciers nodig om onze eigen producten en diensten te kunnen leveren. We hebben de afnemers nodig om onze producten en diensten aan te kunnen verkopen. Allemaal geen hogere wiskunde natuurlijk. Maar wat als we de leveranciers onder druk zetten? Zij moeten nog goedkoper gaan leveren omdat we anders niet op prijs kunnen concurreren. Drie keer raden waar zoal op beveiligd wordt.

We haalden het al vaker aan. Informatiebeveiliging is gewoon een bedrijfskundig onderdeel dat we af moeten stemmen op onze strategie. Daar zit hem, in de huidige economie, wellicht een knelpunt. Er zijn verschillende concurrentiestrategieën (focus, differentiatie en prijs).

Veel organisaties kiezen op dit moment voor een prijsstrategie. Blijkbaar kunnen zij zich onvoldoende onderscheiden en blijkbaar durven ze geen keuze te maken voor bepaalde marktsegmenten. Kiezen we inderdaad voor “prijs” dan moeten we de keten onder grote druk zetten om maar zo goedkoop mogelijk te leveren. Dan gaan we al snel bezuinigen op kwaliteit…en daar is informatiebeveiliging onderdeel van.

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.

Communicatie over beveiligingsmaatregelen

Risicomanagement, beveiliging en beveiligingsmaatregelen kunnen een lastig onderwerp zijn en het grote nadeel dat we daarbij ervaren is dat iedereen er verstand van heeft…althans, dat denken ze. Specialisten in het vakgebied weten wel beter, die weten zelfs dat geen enkele informatiebeveiliger het totale vakgebied kan overzien en zich zal moeten richten op een of meer deelgebieden.

Juist als iedereen er een mening over heeft wordt de volgende vraag belangrijk:
Verloopt de communicatie over de beveiligingsmaatregelen en incidenten altijd via één centraal punt (bijv. afdeling Communicatie, CSO, CIO)?

Beveiliging is niet iets wat we in een ivoren toren kunnen inrichten en waarbij we vervolgens achterover kunnen leunen omdat het vanzelf wel gaat werken. Beveiliging vereist communicatie…en laten we vooral niet vergeten dat communiceren een vak apart is (zelfs in de letterlijke betekenis). We zullen dus de samenwerking aan moeten gaan met andere afdelingen en als we het willen hebben over het communiceren over beveiligingsmaatregelen en incidenten dan is de communicatie afdeling daar een belangrijke “stakeholder”.

Bij onjuiste communicatie kan een beeld ontstaan dat niet juist is, dat de status van de beveiliging niet juist weergeeft. We moeten daarbij wel onderscheid maken. Net als we dat doen voor beveiligingsmaatregelen, die preventief, detectief, repressief of correctief kunnen zijn. Dezelfde indeling kunnen we gebruiken bij onze communicatie over beveiliging (met name preventief en detectief) en incidenten (met name repressief en correctief).

Na een incident (de zogenaamde crisiscommunicatie maakt daar onderdeel van uit) zien we dat de wijze van communicatie van belang is. Communiceren we op een verkeerde wijze, zeggen we de verkeerde dingen of reageren we te laat dan kan dat ons imago grote schade toebrengen. Sterker nog: veel organisaties kunnen het incident best aan…maar de gevolgschade als gevolg van een onjuiste wijze van communicatie kan hen de kop kosten.

We zouden hier natuurlijk voorbeelden kunnen noemen, maar die zijn nogal vluchtig. Google eens op beveiligingsincidenten en je hebt al snel de meest actuele te pakken. Kijk dan eens hoe er gecommuniceerd is, wat er gezegd is en met name wat de reacties van de lezers zijn. Daar kunnen we van leren, enorm veel zelfs.

De reacties van de lezers (uiteindelijk onze klanten) geven allereerst een beeld over het incident en hoe dat ervaren wordt. Maar vaak geeft het ook een goed beeld over hoe die klant toch al over ons dacht. De reacties gaan veelal niet eens meer over het incident maar over zaken die vele jaren eerder gespeeld hebben en die als negatief zijn ervaren. Klanttevredenheid meten we allemaal vooral met mooie statistische gegevens en sociaal wenselijke vragen met nog meer sociaal wenselijke antwoorden. Daar maken we een mooie grafiek van en we gaan weer door met de waan van de dag.

Juist reacties die we krijgen als gevolg van een incident kunnen ons inzicht verschaffen in de algemene klanttevredenheid.

Er zit ook een positieve kant aan dit verhaal. Als ons imago sowieso al goed was dan vergeeft onze klant ons onze misstap wel. Communiceren we daar ook nog eens juist, tijdig en volledig over dan kan dat ons imago zelfs versterken. Het vertrouwen van de klant neemt toe, we nemen ze niet in de maling maar erkennen dat ook wij fouten kunnen maken. We moeten er dan natuurlijk wel voor zorgen dat we het “low hanging fruit” waar we gisteren al kort op ingingen hebben geplukt…en dat fruit omvat meer, veel meer, dan alleen de controle op clean desk natuurlijk.

Misschien is het nu een mooi moment om je aan te sporen met “common sense” te kijken naar de maatregelen die binnen jouw organisatie genomen zijn en de wijze waarop risicomanagement is ingericht. Grote kans dat je veel laag hangend fruit tegen komt…pluk het, maar zorg ervoor dat je mandje niet te vol wordt. Laat dan liever nog wat fruit hangen zodat we dat op een later tijdstip kunnen plukken.

Voorschriften voor vertrouwelijke informatie

Gaan we het nu alweer over voorschriften voor informatie hebben? Ehm, juist, inderdaad. De nuance zit hem nu in het feit dat het hier over vertrouwelijke informatie gaat. We willen immers niet dat onze informatie op straat komt, maar we willen al helemaal niet dat onze vertrouwelijke informatie daar belandt.

De vraag:
Zijn er voorschriften opgesteld ter bescherming van vertrouwelijke informatie tegen onbevoegde kennisneming, verlies en/of beschadiging?

Het interessante bij deze vraag is dat gegevens afzonderlijk niet vertrouwelijk hoeven te zijn, maar dat als we ze samen brengen ze dat in eens wel weer zijn. Vergelijk het met je inlognaam en wachtwoord. Afzonderlijk van elkaar kun je er niet zoveel mee (ja, ja, ik weet het met illegale activiteiten kun je alsnog erg ver komen, maar dat gaat voor nu te ver). Brengen we ze echter samen dan zijn we ineens een stap verder. Als je weet dat mijn inlognaam “pietje1234” is dan is dat een feit. Weet je aan de andere kant dat mijn wachtwoord “Welkom01” is dan heb je wederom een feit te pakken. Ken je beide en weet je dat ik via Hotmail mail dan is het een koud kunstje om namens mij in te loggen.

Ik wil je overigens nergens toe aansporen. De gegevens zijn natuurlijk fictief…maar excuses voor alle Pietjes en voor alle mensen die Welkom01 als wachtwoord gebruiken.

Dezelfde parallel geldt voor de gegevens in veel van onze databases. De afzonderlijke gegevens zeggen misschien niet zoveel, maar de combinatie van meerdere gegevens kan ineens vertrouwelijk zijn. Juist daarom willen we extra inzoomen op de voorschriften voor vertrouwelijke informatie.

Natuurlijk willen we gemeld hebben als niet vertrouwelijke informatie in verkeerde handen terecht is gekomen of als we die op het dak van onze auto hebben achtergelaten voordat we wegreden (geloof me, het gebeurt vaker dan je denkt). Maar misschien moeten we wel andere stappen ondernemen als blijkt dat het hier om vertrouwelijke informatie ging.

Een issue daarbij is dat medewerkers er, in enkele gevallen, niet bij gebaat zijn om het te melden. Stel je voor, straks volgen er sancties. Nee, we beschouwen de informatie als verloren en maken gewoon een nieuw printje. Natuurlijk kunnen we bepalen om sancties op te leggen bij dergelijke incidenten. We geven de medewerker een veeg uit de pan en in het ergste geval nemen we afscheid van elkaar. Dat is toch een beetje de put dempen als het kalf verdronken is. Beter is het om te proberen de schade te beperken. Analyseer wat er gebeurt is en of we de informatie wellicht nog terug kunnen krijgen zonder dat ons imago kleerscheuren oploopt.

Lukt dat niet omdat we de informatie echt uit het oog zijn verloren, dan zullen we met de billen bloot moeten. We kunnen natuurlijk met ons voltallig personeel gaan zitten duimen, in de hoop dat de informatie niet ineens in de krant belandt…maar dat kan destructief zijn voor ons imago en is dus erg risicovol. Aan de andere kant, als we onze verantwoordelijkheid nemen en de klant informeren dat we zijn gegevens rond hebben laten slingeren, dan weten we zeker dat we in de krant komen.

Een lastig besluit en in heel veel gevallen een besluit dat we niet vanuit beveiliging moeten nemen. Nee, we informeren de juiste managementlagen en komen misschien zelfs met het crisisteam bij elkaar om het vervolg te bepalen. Geen leuke situatie natuurlijk, maar wel van groot belang. Dergelijke incidenten willen we niet onder onze beveiligingspet houden, daar is ons petje te klein voor.

Vertrouwelijke informatie verdient dus wat extra aandacht…en laat dat “wat” eigenlijk maar weg. We moeten zowel preventief, detectief, correctief als repressief extra nadenken over de impact van die informatie. Doen we dat niet dan staan we vast en zeker binnenkort in de krant…en negatieve berichten zijn ook reclame, maar of we daar op zitten te wachten is de vraag.

Beveiligingsincidenten: melden, vastleggen, analyseren en rapporteren

Vallen we niet in herhaling, zul je zeggen? Voor een deel wel, maar we gaan het hier met name hebben over de verzameling incidenten. Die we, in een eerder stadium gemeld hebben gekregen, die we hebben vastgelegd, die we analyseren en die we vervolgens ook nog eens aan het management rapporteren.

De vraag die we stellen is:
Worden de beveiligingsincidenten gemeld, vastgelegd, geanalyseerd en gerapporteerd?

Het melden van beveiligingsincidenten hebben we eerder al aangehaald. Ik ga er voor het gemak vanuit dat we deze meldingen ook registeren (ja, ik weet het, aannames zijn levensgevaarlijk). Incidenten kunnen losstaand zijn maar kunnen ook onderdeel van een groter probleem zijn. De kunst is nu om door al die verschillende incidenten heen te kijken en de verbanden te leggen tussen meerdere incidenten.

Als dat lukt kunnen we nog meer op zoek naar de echte oorzaken van een probleem. Ook hierbij geldt weer dat een eenmalig incident iets totaal anders kan zijn dan een bundeling van beveiligingsincidenten. Daarom analyseren we op een hoger abstractieniveau wat er zoal gemeld en gebeurd is. Kunnen we daar lijnen in ontdekken dan kunnen we ook structurele oplossingen aandragen.

Stel dat we veel meldingen krijgen van geblokkeerde accounts van een specifieke afdeling. Dat kan toeval zijn, maar het kan ook zo zijn dat meerdere mensen al jaren onder hetzelfde account werken. Persoonlijke accounts zijn in de praktijk groepsaccount geworden. Later zullen we dus niet meer na kunnen gaan welk individu een bepaalde actie heeft gepleegd, maar ook beschikken we zeer waarschijnlijk niet over voldoende licenties wat weer tot boetes kan leiden.

We raken hier met beveiliging het vakgebied van “business intelligence”. Beide ingewikkelde vakgebieden maar als we ze goed in weten te regelen kan dat enorme synergetische voordelen opleveren. De BI-specialist ontwikkeld de methoden om grote aantallen gegevens te analyseren en wij gaan met de uitkomsten van die analyses bedenken welke mogelijke beveiligingsissues daaraan kleven.

Uiteraard maken we ook aan het management inzichtelijk wat er zoal gebeurt. We rapporteren niet de afzonderlijke incidenten (tenzij ze echt noemenswaardig zijn natuurlijk), maar rapporteren de trends en de uitkomsten van de analyses. Zo wordt het management betrokken maar niet lastig gevallen met allerlei technische details (waar ze of geen interesse in of geen verstand van hebben). We zetten beveiliging op de kaart en tonen onze meerwaarde aan voor het bereiken van de doelstellingen van de organisatie. En hoe mooi die doelstellingen vaak ook omschreven zijn, ze komen bijna altijd op het volgende neer: verhoging van omzet (of optimale inzet van budget voor non-profits), verlaging van kosten en bescherming van imago.

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.

Regelmatig incidenten in ziekenhuizen

Bijna de helft (46 procent) van de ziekenhuizen in Nederland heeft maandelijks of vaker te maken met een incident. Hierbij gaat het om incidenten als diefstal, verbale agressie en fysieke agressie…Dit blijkt uit onderzoek van Securitas onder ruim 350 werknemers uit verschillende ziekenhuizen. Bijna de helft van de ondervraagden geeft aan minimaal maandelijks te maken te hebben met een incident. Nog eens 42 procent zegt dat hun ziekenhuis meerdere keren per jaar te maken heeft met incidenten. De meeste incidenten vinden plaats op de spoedeisende hulp. De top vijf van meest voorkomende incidenten is:
1. diefstal
2. verbale agressie
3. fysieke agressie
4. inbraken op ongeoorloofde afdelingen
5. seksuele intimidatie

(bron)

Het is te hopen dat je binnenkort niet hoeft te worden opgenomen in een ziekenhuis want je bent je leven er niet zeker. Eerst wordt er ingebroken en worden jouw persoonlijke spullen uit je nachtkastje gestolen, vervolgens wordt je uitgescholden voor van alles en nog wat, waarna je klappen krijgt. Als laatste wordt je ook nog seksueel geïntimideerd waarna je met een nog half open wond naar huis wordt gestuurd om verder uit te zieken. We denken allemaal dat we naar huis worden gestuurd omdat het teveel geld kost om ons daar te houden, maar de echte reden is dat het thuis veel veiliger is dan in het ziekenhuis. Het is voor onze eigen bestwil.

Nou, een vooruitzicht waar je van opknapt, toch? En dan te bedenken dat er voor de ziekenhuizen de NEN7510 beveiligingsnorm is, kun je nagaan hoe het gesteld is met instellingen waar zo’n norm niet voor aanwezig is.

Er is blijkbaar nog genoeg te doen in de ziekenhuisbranche. Op zich een natuurlijk lastig te beveiligen sector want het zijn nu eenmaal open instellingen waar je snel naar binnen moet kunnen als je eerste hulp nodig hebt.

Zware beveiliging voor Oktoberfest Duitsland

De Duitsers dempen de put nadat het kalf verdronken is. Zien we dat niet zo vaak na incidenten dat er korte termijn aandacht is voor de beveiliging? Heel benieuwd hoe het over een aantal jaar zal gaan, dan is de aandacht weer verslapt en moet er weer zo goedkoop mogelijk gewerkt worden.

Wilde je dus ooit naar het Oktoberfest? Dan is dit misschien wel je kans om het op de veiligste manier te doen.

Met de gebeurtenissen rond de Loveparade in het geheugen is de beveiliging rond het Oktoberfest in München zwaarder dan ooit tevoren. Ook kwamen vorig jaar dreigementen binnen van terreurnetwerk al-Qaeda. Er zullen drie beveiligingsringen met betonnen obstakels komen rond het feestterrein. Jaarlijks trekt het festijn zo’n zes miljoen bezoekers. Het Oktoberfest viert dit jaar zijn 200e verjaardag, op 18 september gaat het bierfeest van start (Bron).

Als jullie het niet erg vinden laat ik het Oktoberfest aan me voorbij gaan, ik gooi thuis wel een spuitworst op de BBQ en drink daar een biertje bij. Mij niet gezien om tussen 6 miljoen Duitsers naar slagermuziek te gaan luisteren. Na de gebeurtenissen op de Loveparade en bij ons de Dodenherdenking mijd ik grote mensenmassa’s voorlopig even.