Categorie Archief: Geen categorie

Backup’s en de zekerheidsparadox

Door | Geen categorie | Geen reacites


Een zeer persoonlijk verhaal hoe mijn goede intenties bij het veiligstellen van mijn privédata, zo maar verkeerd uitpakten.

 

mickey blog

Het moest er natuurlijk een keer van komen: waar ik als BCM-professional heel goed weet hoe de theorie in elkaar zit, ga ik bij het toepassen in de praktijk toch bijna het schip in.

De lessen die ik heb geleerd zijn algemeen toepasbaar.

 

Het komt misschien bekend voor, een modern huishouden met meerdere PC’s, laptops, telefoons en tablets in gebruik. De muziek- en fotocollecties zijn dusdanig uit hun jasje gegroeid dat die op een NAS zijn geplaatst en niet meer op 1 of meer PC’s.

Ik heb mooie getrapte opzet van de dataopslag van mij en mijn huisgenoten ingericht, inclusief on-premise back-up naar het NAS en off-premise back-up van het NAS op een USB-schijf. Dit doet al enkele jaren naar tevredenheid dienst als ik iets meer dan een jaar geleden besluit om het maken van fysieke backups van het NAS op een USB-schijf te stoppen en het nog gemakkelijker ‘in de cloud’ te maken. Vanuit mijn vak vertrouw ik mijn (Amerikaanse) clouddienstverlener maar half, dus alle back-up bestanden worden keurig versleuteld voordat ze in de cloud worden opgeslagen. Na een paar dagen blijken alle mappen en bestanden in de cloud aanwezig, onleesbaar, maar wel herstelbaar op het NAS. Ik kijk er met een gerust hart niet meer naar om.

 

Tot dat.

Bijna een jaar later merk ik bij de installatie van een nieuw fotobewerkingspakket dat niet alle foto’s op het NAS goed worden weergegeven of zelfs onleesbaar zijn. Mmmm. Nieuwe toepassing leest geen bestanden van oude versies?

De volgende dag zijn er nog veel meer beschadigde bestanden, nu ook spreadsheets en documenten. Alle corrupte bestanden hebben zeer recente aanmaak- en wijzigingsdatums. Geen enkel bestand kan geopend worden met het pakket waarmee het is aangemaakt, of het nou om Excel, Word of Photoshop gaat. De paniek slaat toe: is dit ransomware aan het werk?

 

Op geen van de Mac’s, PC’s, noch het NAS zijn sporen van malware te vinden. Mooi!

 

Maar het aantal corrupte bestanden op het NAS blijft groeien. Minder mooi, wat is er dan aan de hand?

 

Het valt me op dat de betroffen bestanden allemaal zijn aangepast nadat het NAS een tijdje stroomloos is geweest. En op de PC’s is met lokale bestanden (nog) niets aan de hand. Het probleem ligt dus waarschijnlijk in het NAS. Nog verder zoeken (er kwam zelf een hex-editor aan te pas) geeft aan dat lokale NAS-bestanden worden vervangen door hun versleutelde cloudversie. De oorzaak is boven water, de kraan kan nu dicht: ik heb de cloud synchronisatie meteen stopgezet.

Maar mijn probleem is hiermee nog niet verdwenen: krijg ik de data die alleen op het NAS stond (muziek, foto’s) wel weer terug?

 

De supportafdeling van de NAS-leverancier gaat aan de slag. Het verdient sowieso kudo’s dat ze voor een consumentenartikel een jaar of zes na aanschaf aan werk gaan. Maar na een week van opgestuurde files, logs en remote support toegang is de enige zekerheid die me geboden kan worden: er is iets misgegaan met de encryptiesleutel na de power-off. Het waarom blijft een mysterie. Het gevolg is dat het NAS niet meer in de cloudfiles kan kijken wat de oorspronkelijke aanmaakdatum, filegrootte, etc. is en dat dus ook niet goed kan vergelijken met de files op het NAS. Dit is de eerste fout.

 

De tweede fout in de NAS-software pakt nog erger uit: omdat de back-up naar de cloud in sync modus staat (2-weg is de default instelling, jawel, en het omzetten naar 1-weg kan, maar is niet vanzelfsprekend te vinden en uit te voeren) begint het NAS de cloudfiles terug te kopiëren. Waarom? Waarom niet gewoon een foutmelding?

 

Al met al bevind ik me in een situatie waarin de oplossing die mij meer zekerheid moet bieden, zich tegen zichzelf (en mij!) heeft gekeerd en zonder tussenkomst mijn primaire begint aan te vallen. Om deze reden is het ook niet mogelijk om een simpele restore uit te voeren – ik kan er niet zeker van zijn dat ‘in the cloud’ alles in orde is en het ook niet controleren omdat alles versleuteld is.

Het lijkt wel op de paradox van de slang die zijn eigen staart te pakken heeft.

 

Er is ook wel wat geluk.

De NAS-leverancier heeft een decryptie-tool op de PC beschikbaar. En met het oorspronkelijke wachtwoord waarmee de versleutelde synchronisatie is opgezet blijkt het nog goed te werken ook. Pffff.

Nog meer geluk ligt op de plank: mijn oude vertrouwde USB-schijf met een backup van een jaar terug. Herstel is dus mogelijk, en naar achteraf blijkt ook nog met een enigszins normale inspanning.

 

Het opzetten en implementeren van een nieuw, beter doordacht, gedeeld filesysteem met lokale en off-site backup en vraagt meer tijd, en is niet echt eenvoudig. De oplossing bestaat uit meerdere replicatie manieren van PC’s naar het NAS, 1-weg synchronisatie van het NAS naar de cloud, en toch ook maar op gezette tijden een ouderwetse fysieke backup. Wel blijkt uit mijn nieuwe analyse dat mijn oude opzet zwaar onvoldoende was voor onze veranderde behoeften.

 

Al met al heb ik een aantal lessen geleerd, die algemeen bruikbaar zijn:

  • (proces) Ga op gezette tijden na of je in staat bent om bestanden (intact 😉 ) terug te zetten (dit heeft iedereen toch in zijn integraal beveiligings- en continuïteitsplan staan?)
  • (proces) Ga op gezette tijden na of de oplossing die je gebruikt nog voldoet aan al huidige wensen en eisen (of die van de toezichthouder) en andere veranderingen (nog meer PC’s, telefoons of tablets in huis, sterk groeiende opslagbehoefte (films e.d.). Ook dit is een punt voor je integraal beveiligingsplan.
  • (proces) Bepaal welke gegevens echt belangrijk voor je zijn, en ga na of bovenstaande oplossing daarvoor voldoet: een derde punt voor het beveiligingsplan.

 

  • (techniek) Vertrouw niet op één technologie of één leverancier
  • (techniek) De cloud is niet persé in alle gevallen de beste plaats voor een off site backup:
    • Je bent voor de synchronisatie afhankelijk van software waar je maar weinig tot geen controle op hebt (fouten liggen op de loer)
    • Je wilt je gegevens toch beschermen tegen snooping, dus encryptie in de cloud is een must, maar hiermee wordt het spel wel een stuk complexer en foutgevoeliger
  • (techniek) 2 weg synchronisatie is geen goede backup methode, hoe aantrekkelijk en eenvoudig dit ook lijkt in combinatie met de cloud en remote toegang tot deze data (iCloud, OneDrive, Dropbox, etc., etc., simpelweg omdat het (te) snel gaat: een logische fout op één van de meedraaiende systemen staat onmiddellijk op allemaal, en dan?
  • (techniek) Neem de tijd om het te testen

 

  • (privé) Een gemiddeld modern huisgezin heeft tegenwoordig bijna meer IT in huis dan een klein bedrijf. Het kan geen kwaad om eens na te denken over een gestructureerde manier om de belangrijke data veilig te stellen.
  • (privé) Snel klikken door de standaardinstellingen kan tot verassingen leiden

Continuïteit en de nieuwe tanden van de toezichthouder

Door | Geen categorie, uit het nieuws | Geen reacites

RBS had zijn continuïteitsplannen niet op orde

Aangepast op 23 februari 2018

Royal Bank of Schotland (RBS) kreeg vandaag boetes aan de broek van in totaal meer dan € 75 mln na een dagenlange storing in 2012. De Britse toezichthouder Financial Conduct Authority (FCA) volgt hiermee zijn Ierse collega Central Bank of Ireland (CBI) en de Britse Prudential Regulation Authority (PRA). Hoe staat het in Nederland?

Wat was er aan de hand?

In het voorjaar van 2012 liep het even goed spaak voor RBS en haar dochterondernemingen NatWest en Ulster Bank . Als gevolg van een fout gelopen software update konden ze gedurende meerdere dagen een groot deel van hun klanten geen diensten verlenen. In Ierland liep dit zelfs op tot bijna een hele maand. Geldautomaten functioneerden niet meer. Er konden geen overboekingen worden gedaan of ontvangen en klanten waren niet in staat om hun rekeningen te bekijken.
De boetes komen bovenop de schadevergoeding die RBS / Natwest /Ulster Bank rechtstreeks aan de getroffen klanten betalen (ca. € 175 mln).

De vragen die ik twee weken geleden stelde bij een storing van de belastingdienst gelden ook bij RBS. Wanneer besluit je om het continuïteitsplan voor een dienst te activeren? Of was dat er niet? Zo nee, waarom niet? Of waarom was dat niet bruikbaar voor deze situatie? Wanneer was de laatste oefening? In een realistische setting?

En Nederland?

Een aantal algemene aspecten aan deze zaak zal ook voor de Nederlandse financiële instellingen een waarschuwing zijn om hun Business Continuity Plannen op orde te houden:

  • de CBI en FCA hebben de boete bepaald aan de hand van Europese richtlijnen over goede en inzichtelijke beheerprocedures. Deze regels gelden dus ook in Nederland ;
  • het betrof oude centrale systemen (‘legacy’) in een zeer complexe omgeving. Ook dit zal herkenbaar zijn voor veel Nederlandse financiële instellingen;
  • het RBS ‘IT bedrijf’ dat de betrokken IT systemen onder haar hoede had, was afhankelijk van Indiase outsourcing. Er wordt volop gespeculeerd dat RBS zelf nog onvoldoende kennis in huis had. En dat dat ook bij de Indiase outsourcer maar mondjesmaat beschikbaar was. Dat een upgrade in een complexe omgeving dan misgaat is niet zo vreemd. Outsourcen is ook bij Nederlandse financiale instellingen aan de orde van de dag.
  • De upgrade waar de ellende door werd veroorzaakt, was midden in de week was gepland. De druk die ontstaat omdat ‘de winkel weer open moet’ kan zeer hoog oplopen. Dit kan het ontstaan van, of het slecht afhandelen van de ontstane problemen versterkt hebben. De druk zal in ieder geval niet bijdragen aan een ‘rationele’ overweging bij de betrokken medewerkers. Ook in Nederland worden kleine wijzigingen veelvuldig op doordeweekse dagen doorgevoerd om de druk op de weekendplanning niet te groot te maken.

Zolang in Nederland de term ‘langdurige storing’ gebruikt wordt voor een ochtend of middag, lijkt het hier zo’n vaart niet te lopen. Maar ook Nederlandse banken hebben (zeer) regelmatig met kleine verstoringen te maken. Er gaat bijna geen week voorbij of er is wel een bank die een paar uur last heeft van een storing. Kijk maar eens op Nu.nl of allestoringen.nl. Maar zoals hierboven aangegeven is het in de kern in Nederland niet veel anders.

Toezicht wordt serieus

Met de hoge boetes van vandaag blijkt dat de toezichthouders voldoende ‘bite’ hebben. Ik hoop maar dat deze Engels/Ierse case ook toe leiden dat Business Continuity in Nederland voldoende goed wordt ingevuld. Het is altijd beter om een vlekkeloze dienst te verlenen en een boete is tenslotte altijd ‘zonde geld’. Voor de meer dan € 250 mln die RBS nu moet aftikken, kun je toch een behoorlijk BCM programma opzetten.

En andere sectoren? Ook daar wordt beter op continuïteit gelet, zie bijvoorbeeld de Telecom sector. Wellicht later meer hier over. Dat er in Nederland ooit een boete gegeven gaat worden omdat een organisatie niet goed genoeg voor elkaar heeft is niet de vraag. Wel in welke sector dit zal zijn, en hoe hoog de boete zal zijn.

Persoonlijke noot (23 februari 2018)

De oorspronkelijke foto die bij dit artikel prijkte is in verband met een copyright claim van het Algemeen Nederlands Persbureau (ANP) verwijderd. Nu ben ik een groot voorstander van het principe dat je van andermans spullen en ideeën afblijft. Zo koop ik heel braaf mijn e-books bij bol.com en mijn muziek in de iTunes store. Dus als het ANP hier een punt heeft zal ik ook zeker de rechten betalen voor de periode dat deze afbeelding op dit blog heeft gestaan. Wel heb ik in dit specifieke geval mijn vraagtekens of het plaatje nu werkelijk wel zo origineel is dat een Nederlandse organisatie een claim kan leggen op een foto die iedere willekeurige Londenaar of tourist zomaar vanuit de openbare ruimte kan maken vanaf exact hetzelfde gezichtspunt.

In de praktijk zijn er dan ook legio andere nieuwsorganisaties die dit hebben gedaan. Nieuwsgierig geworden? Kijk dan naar:

  • SkyNews: https://news.sky.com/story/ftse-100-firms-flourishing-after-splitting-from-bailed-out-rbs-10793574
  • Reuters: https://www.reuters.com/article/us-rbs-layoffs/royal-bank-of-scotland-to-cut-880-it-jobs-by-2020-union-idUSKCN1AV1BR
  • The Telegraph: http://www.telegraph.co.uk/business/2017/02/20/royal-bank-scotland-confirms-plan-stop-sale-williams-glyn/
  • CanaryClaims: https://www.canaryclaims.co.uk/eu-launches-investigation-into-rbs/
  • Google Streetview: https://www.google.nl/maps/place/48+Haymarket,+St.+James’s,+London+SW1Y+4SE,+Verenigd+Koninkrijk/@51.5096994,-0.1329307,3a,75y,219.9h,109.25t/data=!3m6!1e1!3m4!1sKPF1THdwo01Ql9B0R6-8QQ!2e0!7i13312!8i6656!4m5!3m4!1s0x487604d163ddbb35:0x4aefc3016766dde2!8m2!3d51.5094555!4d-0.1331901 

Of zou die officieel uitziende brief die ik thuis gestuurd kreeg toch een hoax of een (papieren) phishing mail zijn?

 

Fix it, even if it ain’t broke

Door | Geen categorie | Geen reacites

Antiek SSL protocol is kwetsbaar

Het kwetsbare SSL protocol voor versleuteling van kritische of persoonlijke informatie op het Internet is toch al lang vervangen door betere opvolgers? Nou meestal niet. Lees hier hoe dat komt, welke stappen nodig zijn in uw IT Riskmanagement proces om dit soort verassingen in de toekomst te voor te zijn.

Hoe een poedel een bedreiging werd

Recent werd bekend dat er een fundamentele denkfout zit in het 18 jaar oude SSL protocol (van het slotje en de groene adresbalk in uw browser). Deze fout is relatief eenvoudig te misbruiken door iemand die in staat is zich tussen uw browser en de website die u bezoekt te plaatsen. Dus bent u kwetsbaar op ieder openbaar en/of onbeveiligd wifi netwerk. En ja, ook communicatie via onderzeese glasvezelkabels, die standaard door bevriende veiligheidsdiensten als de NSA en GCHQ gemonitored worden, loopt gevaar. De onderzoekers noemden de fout ‘Poodle’.

Poodle is sinds kort meer dan een zorgvuldig gekapte hond

Poodle is sinds kort meer dan een zorgvuldig gekapte hond

Met TLS is gelukkig al 15 jaar een verbeterde versie van het SSL protocol beschikbaar zult u zeggen en alle moderne browsers, of die nu op een PC, Mac, telefoon of tablet draaien, ondersteunen dat. Waar maken we ons druk over?
Het venijn van deze kwetsbaarheid zit hem in het feit dat TLS weliswaar in alle moderne apparatuur beschikbaar is, maar dat tegelijkertijd bijna nergens SSL support is ‘uitgezet’. De boeven van hierboven (sic ) kunnen door manipulatie zorgen dat niet het beste protocol gebruikt wordt, maar het kapotte SSL. En de gebruiker merkt hier niets van, want het slotje blijft zichtbaar en de adresbalk blijft groen.

Uw rol als IT manager, diensteigenaar, compliance manager of auditeur.

U kunt vragen of u of uw klanten er last van hebben, en zo ja hoe groot het risico dan is. Daarnaast is de vraag of u dit had kunnen voorkomen zeker zo belangrijk.

Het is bijna zeker dat het doorlopend ondersteunen van SSL nooit een bewuste keuze op managementniveau is geweest. Het zit zo diep weggestopt, en het vinkje om SSLv3 te ondersteunen staat standaard op ‘ja’, dat hier geen formeel proces aan te pas is gekomen. Het is bij audits van de systemen misschien wel gezien, maar nooit als issue aangemerkt omdat er geen problemen bekend waren. Als er al een discussie heeft plaatsgevonden, is die in het verleden misschien uit commerciële afwegingen in het voordeel van SSL geslecht, omdat een aanzienlijk deel van uw klanten niet beter kan.
Het SSL risico is dus waarschijnlijk nooit expliciet in de risk management besluitvorming naar voren gekomen en de facto op de werkvloer geaccepteerd.

Vandaag gaat het om SSL, morgen zullen er weer andere dreigingen de kop op steken. Uw organisatie heeft dus een vast omlijnde strategie nodig om legacy support (het blijven gebruiken van verouderde hard- en software) in ieder geval te signaleren, maar beter tot een minimum te beperken. Life cycle management, de gestructureerde aanpak om verouderde en verouderende hard- en software op te sporen en te vervangen, voortkomt naast het hier besproken security issue ook veel continuïteitsproblemen.

Maar er zijn er ook stappen nodig in het (IT) risk management proces. U kunt hierbij denken aan:

  • In de Business Impact Analyse (BIA) een vraag opnemen hoever u uw klanten van dienst wil zijn, ook als dat tegen hun eigen belang in gaat;
  • In de BIA opnemen hoe groot de imagoschade kan zijn als er op grote schaal gegevens van uw klanten op straat komen te liggen als gevolg van legacy;
  • In de Risico Analyse (RA) expliciet evalueren in hoeverre u bent blootgesteld aan legacy gevaren.

Met andere woorden: zorg ervoor dat u uw risico’s kent, dan kunt u ze bewust accepteren als u ervoor kiest om niet te handelen.
Overweeg daarnaast om een snelle reactiemacht (CIRT, Computer Incident Response Team) op te richten. Denk daarbij wel aan voldoende mandaat.
Als u veel zaken doet met (online)leveranciers van diensten, zou het gebruik van legacy oplossingen en het vlot oplossen van issues in het contract moeten staan.

En wat moet u nu zelf aan uw SSL probleem doen?

Het Nationaal Cyber Security Center (NCSC) adviseert om overal SSL uit te zetten, tenzij dat niet anders kan. Vooral bij organisaties waar nog volop Windows XP (!) wordt gebruikt zal dit niet zonder meer kunnen. Maar ook op moderne apparaten en software is dit niet vanzelfsprekend of eenvoudig.
Bovendien kan het geen kwaad om uw personeel, zeker als dat regelmatig op pad is en gebruik maakt van wifi netwerken, te attenderen op het feit dat ‘gratis’ bijna altijd wel een ‘prijs heeft’.

Om terug te komen op de titel van het blog: Voor security gaat het adagium “don’t fix it if it ain’t broke” niet op. Er zullen altijd kwetsbaarheden bestaan in oude versies van systemen en applicaties die het op het oog nog best goed doen. De blootstelling van u en uw klanten die daar aan gekoppeld is, is te groot om te laten bestaan.

Nota bene: u kunt hier nagaan of uw apparaat en browser (nog) kwetsbaar is.
En aanwijzingen om SSL op de meeste apparaten en browsers uit te schakelen vindt u hier.

Alle eieren in één mandje?

Door | Geen categorie | Geen reacites

Gistermiddag gebeurde het. Theorie werd persoonlijke werkelijkheid. Mijn netwerkleverancier KPN had regionale problemen met “Internet”.
Helaas werd al snel duidelijk dat dit zowel de vaste als de mobiele (IP) dienstverlening van KPN betrof: noch over de koperkabel, noch via de mobiele telefoon was het mogelijk om websites te bezoeken, mail te ontvangen of te versturen. Alle schermen toonden alleen maar een draaiend wieltje. En toen werd me rap duidelijk dat ik zelf in de situatie was beland waar ik mijn klanten als Business Continuity consultant altijd voor waarschuw: als je meerdere diensten van één leverancier ‘stapelt’, nemen de gevolgen van een storing enorm toe. Zeker als het dan gaat om een dienst die sluipenderwijs steeds belangrijker wordt voor de voortgang van je primaire bedrijfsprocessen , dan kan dat de bedrijfsvoering behoorlijk in de war lopen. Voor mij betekende het een halve middag geen websitebeheer, en geen e-mailafhandeling.
Het stapelen van diensten wordt de laatste jaren zeer voortvarend door alle telecomleveranciers gestimuleerd met Alles-in-eenpakketten, Familievoordeelopties, etc. Door het combineren van vaste tele- en datacom met mobiele en met TV bij één provider kunt u aanzienlijke besparingen realiseren op uw maandelijkse lasten. Het nadeel hiervan is dan natuurlijk wel dat als er dan iets mis gaat bij uw provider, u met een beetje pech ook niets meer kunt. Dat kan natuurlijk een zeer weloverwogen beslissing zijn (“die 1 of 2 keer dat dit per jaar kan gebeuren neem ik voor lief”), maar misschien overkomt het u en is dat een vervelende verrassing. In dit laatste geval bent u, net als ikzelf, toe aan een herziening van uw persoonlijke of zakelijke impact- en risicoanalyse.
In mijn geval is mijn conclusie dat ik voorlopig het risico van een kortdurende Internetblackout voor lief neem en geen extra kosten ga maken door een deel van mijn diensten elders onder te brengen. Maar bij de eerstvolgende contractvernieuwing ga ik het proces nog een keer doorlopen; misschien dat ik dan zonder veel extra kosten wel extra zekerheid kan inkopen.