Tag: beveiligingsmaatregelen

Een hacker kan heel Nederland platleggen

  door

We sluiten deze week, die geheel onverwacht de week van de hacker, cracker en scriptkiddie is geworden, af met een geruststellend idee.

Eén hacker is in staat heel Nederland plat te leggen. Dat kan door in te breken in computernetwerken en bijvoorbeeld sluizen te openen, met overstromingen tot gevolg (bron).

Ook hier hebben we het gelukkig weer over een hacker die dit kan doen. Er wordt met geen woord gerept over een scriptkiddie…maar geloof me. De meest simpele aanvallen worden nu juist gepleegd door een scriptkiddie (omdat die immers niet weet wat hij doet). Geloof het of niet. Ook hackers en crackers hebben zo hun codes en ze hebben de balen van scriptkiddies die die code niet kennen of overtreden.

Overigens is dit niets nieuws want een aantal maanden geleden was er al van alles te doen om sluizen die met een simpel wachtwoord “beveiligd” waren, maar het sluit deze week natuurlijk wel erg mooi af en onderstreept de noodzaak van informatiebeveiliging.

Het is nu alleen nog wachten op een structurele aanpak. Veel organisaties hebben de afgelopen jaren flink bezuinigd op informatiebeveiliging. Daar lijken ze nu van terug te komen en informatiebeveiliging is ineens topprioteit waar zelfs het hoogste management zich tegenaan wil bemoeien. Maar als we dan toch de aandacht van het hoogste management hebben: mogen we dan ook alstublieft opteren voor die proactieve en structurele aanpak die nodig is en niet de reactieve aanpak die we nu volgen? Dat zorgt er niet alleen voor dat we beter beveiligd raken maar voorkomt ook dat we bakken met geld in de put scheppen.

Er zijn budgetten voor beveiliging en beveiligingsmaatregelen worden aan alle kanten aangeschaft en ingezet. Alles om maar te voorkomen dat we slachtoffer worden (jaja, het draait om imagoschade). Wat we vergeten is dat we nog steeds moeten redeneren vanuit de risico’s en niet vanuit de maatregelen.

Leest u de zin nog een keer en laat hem goed doordringen: Wat we vergeten is dat we nog steeds moeten redeneren vanuit de risico’s en niet vanuit de maatregelen.

Het lijkt tegen dovemansoren gezegd want na de virusaanval op de Gemeenten hebben we de virusscanners weer eens een update gegeven en gaan we weer rustig achterover hangen. Het is wachten op de volgende aanval en die zal sneller komen dan we nu verwachten…het is alleen maar te hopen dat het niet echt een keer uit de klauw loopt want als een hacker de sluizen open kan zetten dan krijgen we tot aan Amersfoort allemaal natte voeten.

Rest mij om u een fijn weekend te wensen en misschien moet je vast je lieslaarzen “uit het vet” halen.

Het communiceren over vertrouwelijke informatie

  door

Communiceren is een vak, dat mogen we inmiddels toch wel zeggen. We hebben nagedacht over de wijze waarop we over beveiliging en incidenten communiceren en eerder hebben we al voorschriften opgesteld voor de behandeling van vertrouwelijke informatie. Maar goed, het kan zomaar zijn dat we vertrouwelijke informatie toch ook eens moeten delen, dat we er over moeten communiceren.

De vraag:
Wordt er bij iedere communicatie-uiting op gelet dat geen vertrouwelijke informatie of informatie over de beveiligingsmaatregelen wordt gecommuniceerd?

Misschien denk je direct dat we onze vertrouwelijke informatie en informatie over beveiligingsmaatregelen niet aan de grote klok gaan hangen. Dat gaat niemand wat aan, toch? Toch zijn er situaties te bedenken waarbij we wel degelijk vertrouwelijke informatie of informatie over beveiligingsmaatregelen moeten delen. Op zich ook geen probleem, als we er maar controle over houden en als we er maar over nadenken wat we dan inhoudelijk communiceren. Misschien willen we de details wel voor onszelf houden, maar op een hoger abstractieniveau kunnen we misschien wel over de meta-data communiceren.

Het wordt inmiddels wat cryptisch, dus een concreet voorbeeld verduidelijkt de boel. Jaren geleden wilden organisaties niets kwijt over het feit dat ze gebruik maakten van een firewall tussen hun eigen netwerk en het internet. Dat was geheime informatie en mocht zeker niet op straat terecht komen. Door de jaren heen is iedere organisatie gebruik gaan maken van firewalls. Het feit dat je over een firewall beschikt is gemeengoed geworden, niets geheims meer aan. Toen dat onderkend werd was het nog een groot geheim welk merk firewall je dan eigenlijk inzette, maar die informatie verliest ook meer en meer het vertrouwelijke karakter. Zo geheim is het niet meer dat je gebruik maakt van Checkpoint of Juniper (of weet ik welke merken er zoal bestaan). Nee, nu zijn het met name de instellingen die we niet op straat willen hebben, we willen niet dat iedereen zomaar het patch-level weet, we willen niet dat iedereen gemakkelijk de openstaande poorten kan zien, we willen niet dat iedereen de inlognaam en het wachtwoord kan achterhalen.

Borduren we hier nog even op voort dan zien we dat dit bijvoorbeeld een situatie is waarbij we over vertrouwelijke informatie of informatie over beveiligingsmaatregelen moeten communiceren. Willen we een nieuwe firewall aanschaffen dan is het toch wel een goed plan om daarover te communiceren met mogelijke leveranciers. Besteden we een dergelijke aankoop niet aan en hoe weten ze anders wat ze straks moeten leveren?

De kunst is om niet de details bloot te geven maar wel duidelijk te zijn over de functionaliteiten die je er straks van verwacht. We zullen een dergelijke leverancier in vertrouwen moeten nemen, maar dat kan alleen als daar een basis van vertrouwen voor is.

Het communiceren over vertrouwelijke informatie of over beveiligingsmaatregelen kan dus noodzakelijk zijn, dat is ook geen probleem als we daar de controle maar over houden. Niet communiceren over de details dus, maar wel over de functionaliteiten. Daarvoor hebben we dan wel inzicht nodig in de informatie die wij als vertrouwelijk zien…maar daar hebben we in een eerder stadium al over nagedacht en die voorschriften werken inmiddels feilloos, toch?

Communicatie over beveiligingsmaatregelen

  door

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.

Implementatie van de beveiligingsmaatregelen

  door

Gingen we gisteren nog in op de OTAP-stappen die we doorlopen voordat we nieuwe informatiesystemen of beveiligingsmaatregelen inzetten. Vandaag gaan we in op het formeel goedkeuren van de maatregelen en het overdragen van die maatregelen aan de staande lijnorganisatie.

We stellen daarom de volgende vraag:

Zijn de beveiligingsmaatregelen geïmplementeerd en zijn systemen formeel goedgekeurd voordat ze in productie worden genomen (overdracht rapportages)?

We hebben al gezien dat we niet zomaar wijzigingen door kunnen voeren omdat dat impact kan hebben op onze productieomgeving…de omgeving waar we ons geld mee verdienen. Voor het gemak gaan we er vanuit dat we inmiddels een goede change management procedure hebben opgesteld en ingevoerd.

Toch zijn we er niet als we “slechts” een wijziging doorvoeren of een nieuw systeem inzetten. We moeten ervoor zorgen dat dat systeem ook geborgd wordt in de organisatie. Iemand binnen die organisatie moet verantwoordelijk zijn voor dat systeem, hij of zij moet weten dat er een verantwoordelijkheid is en deze verantwoordelijkheid moet formeel geaccepteerd worden.

Dat is natuurlijk altijd lastig, want niemand zit te wachten op extra verantwoordelijkheden. Maar als het goed is, is er iemand die opdracht heeft gegeven voor de ontwikkeling van een nieuw systeem. Is hij niet degene die verantwoordelijk is of heeft hij ook weer een opdrachtgever? Borging in de organisatie is van belang om ervoor te zorgen dat het systeem ook zijn werk blijft doen.

Niet makkelijk, maar wel een heel belangrijke stap. Zonder formele eigenaar zouden we een nieuw systeem nooit in de lucht moeten brengen. Overigens zien we hier dat IT vaak verantwoordelijk gesteld wordt, toch is de vraag of dat juist is. Het systeem ondersteund een bedrijfsproces, wie is verantwoordelijk voor dat bedrijfsproces en zou diegene ook niet (functioneel) verantwoordelijk moeten zijn voor dat systeem?

Lastiger wordt het natuurlijk als we met systemen te maken krijgen die meerdere processen ondersteunen. Denk alleen maar eens aan het emailsysteem. Welk proces ondersteund dat? Denk ook maar aan het hele netwerk. Wie is daar verantwoordelijk voor? Het eigenaarschap voor dergelijke systemen is nog weleens niet duidelijk belegd. Misschien toch goed om eens naar de verantwoordelijkheden te kijken. Niet alleen naar de taken, bevoegdheden en verantwoordelijkheden voor de informatiebeveiliging dus (zoals we in eerdere stappen al gedaan hebben) maar ook naar de taken, bevoegdheden en verantwoordelijkheden voor de bedrijfsprocessen en de informatiesystemen.

Hoe we dit exact binnen de organisatie beleggen is niet eens zo relevant. Van belang is dat we keuzes maken, die keuzes vastleggen en dat degene die verantwoordelijk is dat ook weet. Dan kunnen we de discussie verder intern wel voeren.

Het integraal beveilingsmodel is geevolueerd

  door

Zoals de kop al aangeeft is het integraal beveiligingsmodel (mijn geesteskind zullen we maar zeggen) geëvalueerd en op basis daarvan geëvolueerd. Het is nu weer helemaal bij de tijd en biedt de basis om integrale beveiliging binnen organisaties op te bouwen.

Een aantal zullen het model in de basis kennen en weten het achterliggende verhaal er al bij. Maar voor diegene die het model en met name het verhaal nog niet kennen…ik kom het graag toelichten. Neem daar wel de tijd voor want als ik er eenmaal over begin dan ben je nog niet van me af…er is ook zoveel over te vertellen.

Een model is altijd een versimpelde weergave van de werkelijkheid. Zo ook voor dit model, maar het biedt het raamwerk om de integrale beveiliging binnen organisaties goed op te pakken. Hiermee geven we dus aan dat beveiliging geen technisch aspect (firewalls en anti-virus) is maar veel meer een bedrijfskundig aspect dat zich richt op de continuïteit van de organisatie. Te vaak komen we nog tegen dat een organisatie informatiebeveiliging met allerlei technische maatregelen oppakt (waarbij men, ten onrechte, denkt voldoende beveiligd te zijn) zonder dat er daarbij gekeken wordt naar de risico’s voor de bedrijfsvoering.

Het almachtige doel voor iedere organisatie is continuïteit van de bedrijfsprocessen, de juiste inrichting van beveiliging draagt daar aan bij. Beveiliging is een kwaliteitsaspect en is ondersteunend aan de primaire en secundaire bedrijfsprocessen (de processen waarmee de organisatie haar geld verdient) en moet dus altijd afgestemd zijn op die processen. Niks technisch, toch? Beveiliging is dus geen panklare oplossing die je uit een boekje haalt maar maatwerk dat exact moet zijn afgestemd op de organisatie, haar processen, haar informatiesystemen, haar locaties, haar medewerkers, etc. etc. Maar nu ga ik eigenlijk al op de inhoud van het model in, mocht je er meer over willen weten dan kom ik het je graag in geuren en kleuren vertellen, mensen die ik het in het verleden al eens verteld heb staan meestal verbaasd met wat het vakgebied (volgens mij in ieder geval) allemaal inhoudt.

Voordat we afsluiten komt het kortweg hierop neer: beveiliging draait om het afdekken van risico’s voor de primaire en secundaire bedrijfsprocessen om de continuïteit van de organisatie te waarborgen, dat afdekken van die risico’s kunnen we doen door allerlei maatregelen (technisch, procedureel, organisatorisch, bouwkundig en elektronisch) maar dan wel de juiste combinatie van maatregelen die gebaseerd zijn op de risico’s aan de ene kant en de kosten aan de andere kant. Er is dus veel meer onder de zon dan een firewall en een anti-virus pakket.

Ik hoor wel van je als je er eens met me over wil brainstormen.

Top 10 ergste beveiligingsmaatregelen

  door

Nee ik heb ze niet zelf verzonnen of onderzocht en of ik het er volledig mee eens ben laat ik voor het gemak ook maar even in het midden.

Als het gaat om informatiebeveiliging zijn er verschillende manieren om informatie te beschermen, maar sommige gebruikte maatregelen waren, zijn en zullen nooit effectief zijn. Aan de andere kant kunnen deze maatregelen voor problemen zorgen, IT-afdelingen op kosten jagen en uiteindelijk meer kwaad dan goed doen. Fred Cohen, een van de eerste “virusschrijvers”, verzamelde tien van de ergste “security practices” (bron).

  1. Het wijzigen van wachtwoorden
  2. Een bron via reverse DNS lookup authenticeren
  3. Terugslaan uit zelfverdediging
  4. Gebruikers over technische zaken laten beslissen
  5. We kunnen de stekker er bij een incident uittrekken
  6. Het gebruik van ontdekte lekken als graadmeter
  7. Vertrouw wat de leverancier beweert
  8. De NSA gebruikt het, dus kan ik het vertrouwen
  9. We gebruiken best practices
  10. Het is voor uw veiligheid

Effectiviteit security-maatregelen simpel meten

  door

IT-ers hebben de neiging om veel te complexe standaarden te gebruiken om de security-situatie in hun organisatie inzichtelijk te maken. Probeer daarom de security-problemen zo weer te geven dat iedereen het kan begrijpen.

Beveiligingsmaatregelen worden vaak “verkocht” vanuit een angstscenario dat negatieve emoties oproept en minder vanuit een risico analyse waarbij op basis van een kosten/baten-analyse de juiste maatregelen worden geimplementeerd.

Juist door reeel te kijken naar de risico’s die een organisatie loopt kunnen de juiste en de juiste combinatie van maatregelen genomen worden. De risico’s die reeel zijn verschillen per organisatie, zo zal de ene organisatie meer last ondervinden van een brand terwijl de andere juist weer moeite heeft met netwerkverstoringen.