Tag: back-up

Virus gijzelt foto’s voor 50 euro losgeld

  door

Een nieuw Trojaans paard gijzelt bestanden door ze te versleutelen en eist 50 euro om ze weer toegankelijk te maken. De ransomware versleutelt alle afbeeldingen, documenten en snelkoppelingen en voorziet die van de .EnCiPhErEd extensie. Ook wordt er een bestand “HOW TO DECRYPT.TXT” met instructies achtergelaten. Daarin staat dat het slachtoffer de code van een Ukash of Paysafecard met 50 euro naar een Gmail-adres moet sturen. (bron)

Het is natuurlijk al erg genoeg als je gegrepen wordt door een virus, maar meestal lukt het dan nog wel om je gegevens veilig te stellen en je pc weer schoon te krijgen. Maar je moet er niet aan denken dat het virus dat je oploopt direct de foto’s (en andere bestanden) op je harde schijf versleuteld.

Daar gaan al je vakantiefoto’s en je wist al maanden dat je er weer eens een reserve kopie van moest maken, maar was daar nog niet aan toegekomen. Ja, wat doe je? Ga je inderdaad geld overmaken, in de hoop dat je inderdaad de sleutel krijgt? Want welke garantie heb je?

In ieder geval is het weer eens een goede waarschuwing om een extra reserve kopie te maken en ervoor te zorgen dat je anti-virus up-to-date is. Als er iets is dat ik liever niet kwijt ben dan zijn het mijn vakantiefoto’s.

Functiescheiding

  door

Van het hebben van rechten en het ontbreken van volledige overzichten van gebruikers is het een kleine stap naar het doorvoeren van functiescheiding.

De vraag:
Zijn er maatregelen getroffen die er in voorzien dat niet alle bevoegdheden bij het uitvoeren van specifieke werkzaamheden in één hand terechtkomen (functiescheiding)?

Bij functiescheiding denken we wellicht direct aan financiële gebieden waarin we die scheiding graag door willen voeren. We willen immers niet dat een persoon ons hele eigen vermogen met een druk op de knop naar zijn of haar Zwitserse bankrekening over kan schrijven. Daar ligt inderdaad de oorsprong van functiescheiding.

Maar zoals we al eerder zagen, willen we ook niet dat er mensen zijn met teveel rechten op de systemen. Niet teveel rechten op de financiële systemen maar ook niet teveel (beheer)rechten op de informatiesystemen. Het risico is gewoon te groot dat iemand, bewust of onbewust, het hele systeem lam legt.

Een discussie die hierbij al vaker gevoerd is, is die tussen beheerwerkzaamheden op de informatiesystemen en de inhoud van de informatie op die systemen. De beheerders hebben graag veel rechten omdat ze zo hun werk goed kunnen doen. Toch moeten we er even bij stil staan dat zij (veelal) geen toegang tot de inhoud van de informatie nodig hebben om back-ups uit te voeren of terug te zetten. Of in gewoon Nederlands: een beheerder moet wel een back-up kunnen maken van een Word-document maar hoeft niet te kunnen zien welke woorden er in dat Word-document staan. Ook hier kun je dus kijken op welke wijze we functiescheiding door kunnen voeren. Maar bereid je voor op de discussie die zal komen en bedenk nu alvast hoe je gaat controleren dat die rechten inderdaad zijn afgenomen…het is immers de beheerder die zichzelf die rechten af moet nemen.

Nu we zicht hebben op de medewerkers van de financiële afdeling en de IT-afdeling beginnen we al een aardig beeld te krijgen over de gebieden waar we functiescheiding toe kunnen passen. Deze basis kunnen we uitbreiden door op onderzoek uit te gaan naar die functies die ook een risico vormen als ze teveel rechten bezitten. Dat kunnen hele specifieke functies zijn, maar kunnen ook gewone gebruikers zijn.

Wilden we eerder al zicht hebben op de rechten die gebruikers hebben dan ligt daar de overeenkomst met functiescheiding. We zijn niet zo zeer bang voor het feit dat ze grote bedragen over kunnen maken of systemen plat kunnen leggen. We zien wel een risico als het gaat om de grote hoeveelheid informatie waarover ze kunnen beschikken. Hebben ze echt al die informatie nodig? En aan de andere kant: beschikken ze wel weer over alle informatie die ze nodig hebben om hun werk goed te doen?

Het doen aan functiescheiding lijkt een logische maar er komt een berg finetuning bij kijken. Niet teveel rechten geven, niet teveel rechten afnemen. Ze moeten hun werk kunnen doen maar wel binnen de kaders die we acceptabel vinden. Het klinkt dan ook makkelijker dan het in de praktijk is. We moeten keuzes maken, die keuzes effectueren en controleren en dat zijn geen gemakkelijke stappen.

Daarbij moeten we dan ook nog eens rekening houden met de omvang van de organisatie. In een grotere organisatie kunnen we risicovolle taken gemakkelijker over meerdere personen verdelen dan dat we dat in kleine organisaties kunnen doen. Denk nu niet dat functiescheiding voor een kleinere organisatie niet kan worden doorgevoerd of minder belangrijk is. Nee, misschien is het zelfs voor een kleinere organisatie nog wel veel belangrijker om eens goed te kijken naar wie wat kan.

Functiescheiding, een belangrijk aspect en zeker niet alleen voor beveiliging. Toch nog vaak een moeilijk praktijkgeval waar we goed over na moeten denken om het allemaal werkbaar te houden.

Het veilig opslaan van reservekopieen

  door

Nou, nog een keer over de reservekopieen dan voordat we dat verder met rust zullen laten. We hebben de eisen gesteld voor de beschikbaarheid, exclusiviteit en integriteit. We hebben keuzes gemaakt en we hebben getest of de gegevens ook echt benaderbaar zijn. Vandaag stellen we ons de vraag:

Worden de reservekopieen veilig opgeslagen (eventuele externe locatie)?

Waar slaan we de reservekopieen eigenlijk op? Doen we dat op tapes in ons eigen pand of kiezen we ervoor de tapes naar een ander pand te brengen? Hebben we zelf geen tapes en laten we de back-ups via internet overbrengen naar een extern datacenter en wie kunnen er dan eigenlijk allemaal bij? Oh ja, ik weet het, er zijn andere manieren dan tapes, maar het spreekt wel lekker tot de verbeelding, toch?

Laten we eerst ingaan op het opslaan van de reservekopieën in ons eigen pand. Dat is een optie, maar wat als ons hele pand afbrand? Hebben we dan nog ergens de gegevens beschikbaar? Hoe veilig is ons pand eigenlijk en welke incidenten vinden daar zoal plaats? Staat de back-up server op de kapstok bij de ingang (geloof me, ik heb het gezien) of kiezen we voor een veilig serverhok dat netjes op slot kan en waar de airco ervoor zorgt dat het niet al te warm wordt? Wie hebben er dan allemaal toegang tot de serverruimte en hebben zij allemaal die toegangsrechten wel nodig? Ook hier weer een groot aantal vragen die we onszelf kunnen stellen. Misschien kies je voor de, ogenschijnlijk, veiligere optie en host je de back-ups extern.

Maar ook in dat geval komen er een aantal vragen om de hoek kijken. Hebben we de juiste Service Level Agreements opgesteld en houdt de leverancier zich daaraan? Hoe betrouwbaar is die leverancier eigenlijk en wie is eigenaar van de servers en data? Staat de informatie in Nederland of ergens in het buitenland? Welke medewerkers bij de leverancier kunnen eigenlijk bij onze data? Er wordt nog wel eens gewerkt met een algemeen “Admin-account”, maar is nu nog te traceren welke medewerker er op welk moment dat account gebruikt heeft? Zo zie je maar, ook hier een aantal (en nog vele malen meer) vragen waar we toch even bij stil moeten staan.

Het doel blijft zo snel mogelijk weer over de data kunnen beschikken op het moment dat dat nodig is. Afhankelijk van de aard van de organisatie kunnen we ervoor kiezen onze data veilig op te slaan in ons eigen pand, op een andere locatie of extern onder te brengen bij een specialist. Hebben we te maken met echt spannende data die voor het voortbestaan van onze organisatie cruciaal is, dan kan het ook zomaar zijn dat we voor een combinatie kiezen.

Alles voor het voortbestaan van onze organisatie, toch? Ja, maar ook in dit geval moeten de kosten tegen de baten opwegen en met logisch nadenken komen we al een heel eind. Testen we vervolgens of het geplande ook nog werkt dan bieden we toch een bepaalde mate van zekerheid. Vinden we dat nog niet genoeg? Dan zullen we aanvullende maatregelen moeten nemen.

Het testen van reservekopieen

  door

We hebben het van de week ook al even aangehaald, maar vandaag gaan we er iets verder op in. Niet op de techniek, maar de gedachte er achter: Het testen van reservekopieen.

Logisch dan natuurlijk dat de formele vraag als volgt is:

Worden de reservekopieen getest of de gegevens benaderbaar zijn?

Gisteren schreven we het ook al. We maken geen reservekopieen om maar over kopietjes te beschikken of omdat het zo nodig moet van de Code voor Informatiebeveiliging. Nee, we maken ze om na een incident nog over de voor ons waardevolle informatie te kunnen beschikken. Daarom is het ook van belang om te testen of de reservekopien ook echt aan onze eisen voldoen.

Bevat de reservekopie inderdaad de voor ons belangrijke gegevens en zijn die gegevens nog benaderbaar? Als de gegevens uit een nogal exotisch programma komen is het ook van belang om te kijken naar de back-up van dat exotische programma. Anders beschikken we straks wel over de gegevens maar niet over het programma om die gegevens te kunnen lezen.

Ok, ok, maar jullie hebben de reservekopieen extern gehost, zoals dat zo mooi heet. Iedere nacht worden de gewijzigde gegevens weggeschreven naar onze leverancier. Hartstikke goed, maar weten we ook zeker dat we de gegevens weer snel genoeg terug kunnen halen? Hoe lang doen we er straks over om terabytes aan data terug te zetten? Kan dat binnen de tijd die we gesteld hebben voor onze kritische processen? En wat doen we als de internetverbinding door hetzelfde incident getroffen is? Kunnen we dan ook nog op tijd bij de data komen?

Ook moeten we goed kijken naar de kritische processen die als eerste de lucht weer in moeten. We moeten dus keuzes maken in de data die we als eerst terug zetten en de data die minder van belang is en wel even kan wachten. Al die terabytes aan informatie kunnen immers niet op hetzelfde moment over onze interverbinding en komen achter elkaar binnen.

Willen we er echt zeker van zijn dat het allemaal werkt? Ja, dan zullen we toch echt moeten gaan testen. Dat kan een papieren test zijn maar ook een test waarbij we de data echt terug gaan zetten om te kijken wat er gebeurt. De lessen die we daaruit kunnen trekken verwerken we weer zodat we onze aanpak van reservekopieen continu kunnen verbeteren. Je raadt het al: om zekerheid te hebben moeten we vaker testen en misschien zelfs noodscenario’s achter de hand hebben voor het geval dat.

Eisen ten aanzien van reservekopieen

  door

Serieus zijn we inmiddels met informatiebeveiliging bezig en we hebben al allerlei zaken opgestart om incidenten maar zoveel mogelijk te voorkomen binnen de bandbreedte die bij onze organisatie past. Daarnaast zijn we al druk geweest met het opzetten van de calamiteitenplannen en de uitwijkmogelijkheden voor als het echt een keertje fout gaat. Gelukkig kunnen we dan altijd terugvallen op onze reservekopieen (back-ups), toch?

De komende dagen gaan we wat verder in op de eisen ten aanzien van de back-ups en we stellen ons dus de vraag:

Zijn de eisen ten aanzien van reservekopieen (back-up) vastgelegd?

Net als we eisen stellen aan de beschikbaarheid, integriteit en exclusiviteit van de informatievoorziening en de onderliggende informatiesystemen moeten we deze eisen ook stellen aan de reservekopieen.

Hoe snel moeten we, na een incident, kunnen beschikken over deze reservekopieen? Hoe actueel moeten deze zijn of anders gezegd: hoeveel informatie mogen we maximaal kwijtraken? En wie kan er eigenlijk allemaal bij deze reservekopieen?

Het lijkt misschien of het hier puur en alleen gaat om de back-up tapes, maar niets is minder waar. Natuurlijk verandert er een berg met de invoering van virtualisatie en het werken “in the cloud”. Maar dan hebben we het meer over de achterliggende techniek. Hier hebben we het meer over de functionele eisen die we inzichtelijk moeten hebben.

Later deze week zullen we ook nog ingaan op het maken van de reservekopieën, het testen daarvan en de opslag ervan. Toch zijn dit alvast zaken waar we bij het stellen van eisen rekening mee moeten houden. Als we dan toch reservekopieen maken, laten we er dan ook voor zorgen dat we het goed doen. Anders zitten we straks met een berg data die niet aan onze eisen voldoet, die we niet tijdig weer tot onze beschikking hebben, die niet actueel is of waar de hele wereld inmiddels in heeft kunnen kijken.

Hebben we de laatste tijd de back-ups of delen daarvan terug moeten zetten? Ging dat helemaal goed of hebben we daar toch wat “lessons learned” uit kunnen halen? Als we dat nog nooit hebben gedaan wordt het misschien tijd om er toch eens een test tegen aan te gooien…