Zoeken naar:
Een nieuwe backup vendor, maar is dit zo en waarom ?

Als eerste wil ik iets vertellen over mijn huidige ervaringen:

Ik heb de afgelopen jaren gewerkt met backup oplossingen van Veritas (nu Symantec), Legato, ArcServe, BackupAgent, Veeam, ManageEngine en waarschijnlijk nog een paar… Word je wel steeds kritischer als er een nieuwe vendor langskomt. Ik ben in ieder geval al zijn 20 jaar aan het back-uppen en heb dit gedaan met oplossingen lokaal (naar tape of NAS) op virtuele platformen en in de cloud.

Iets over backup in het algemeen:

Vaak wordt backup en disaster recovery besproken in 1 onderwerp. Dit is niet terecht want beide functionaliteiten verschillen aanzienlijk van elkaar. Waar een backup bedoeld is om historische data te bewaren (vaak 5 tot 7 jaar) is het bij disaster recovery voornamelijk gericht om de meeste recente data snel terug te halen. Hier zie je dan ook meteen het belangrijkste verschil en de meeste uitdagingen van backup vendoren. Een backup dient te worden ondersteund door een hele goede database waarin je snel versies van bestanden kan terugvinden welke zelfs jaren geleden verwijderd zijn. Bij een disaster wil je graag zo snel mogelijk de meeste recente data terug plaatsen zodat de impact zo laag mogelijk is. In de praktijk zie je vaak dat hier overeen wordt gekeken en dat er eigenlijk maar 1 van de 2 in gebruik is genomen.

Op dit moment zie ik dat veel bedrijven migreren van een op locatie server omgeving naar een cloud server omgeving. De cloud provider biedt vaak een hogere server beschikbaarheid dan welke het bedrijf zelf op locatie kan realiseren. Er zijn allerhande aan redundante componenten opgenomen in de infrastructuur om 99,999% beschikbaarheid te bieden. Steeds meer cloud providers begrijpen ook dat er een backup gemaakt moet worden van de data, toch is het bijna altijd bedoeld voor een disaster recovery scenario. Vaak is er bijvoorbeeld een 30 dagen retentie opgenomen. In veel gevallen kan dit ook voldoende zijn, voornamelijk waarbij het database gedreven applicatie servers zijn, moet dit ook voldoende zijn. Toch leert mijn ervaring dat ook database gedreven applicaties soms afhankelijk zijn van data welke langer geback-upte dienen te worden dan deze 30 dagen.

Een voorbeeld hiervan heb ik uit een praktijk situatie van een klant van mij: er was een onduidelijkheid opgevallen in November in de database welke veroorzaakt was in Januari. In Januari heeft de externe software leverancier een update uitgevoerd in de test omgeving en na goedkeuring deze ook uitgevoerd in de productie omgeving. In November wilde de administratie vast voorbereidingen treffen voor de afronding van het jaar. Tijdens deze voorbereiding kwam de fout in de database naar voren. Natuurlijk is er eerst contact opgezocht met de software leverancier om te zien of dit een bekend probleem was en of dit elders ook voorkwam. Ook is er gekeken of er updates of patches waren uitgevoerd welke dit probleem veroorzaakte. Niks wat te vinden. Wel was het probleem niet te reproduceren in de test omgeving welke sinds januari niet meer geupdate was. Na uitgebreid onderzoek bleek dat de productie database op enig punt keek naar een gebruikers OU in de local user database welke of verwijderd was of niet aangemaakt was in de productie omgeving. Dit probleem had zich al moeten laten zien in Februari maar aangezien deze actie allen werd aangeroepen tijdens een jaar afsluiting werd dit pas in November gezien. Probleem was echter dat deze klant enkel maandelijkse back-ups maakte van de database servers. Het was hierdoor niet mogelijk om de user te herstellen zodat de fout kon worden hersteld. De oplossing bleek uiteindelijk te zitten in het restoren van de database op de test server waar deze user nog wel op bestond, alle maand afsluitingen opnieuw te draaien en vervolgens de database en de user te herstellen naar de productie database. Dit was een in menstraject en hierdoor is de productie van de bedrijf meerdere dagen verstoort geweest.

Het is dan ook gewoon te kort door de bocht om te zeggen dat een 30 dagen retentie altijd volstaat en sinds dien adviseer ik dan ook om dit als disaster recovery aan te houden maar de echte backup nog wel te blijven gebruiken.

Er zijn veel verschillende methodes om te backuppen:

Met de komst van virtualisatie zijn we instaat om de verkregen hardware capaciteit van een server of serverpark veel efficiënter te gebruiken. Ook is het mogelijk geworden om de schijfcapaciteit te centraliseren (hetzij fysiek hetzij virtueel) waardoor de backup strategie ook aangepast kan worden. Waar vroeger de impact van de backup groot was op de bestaande productie omgeving zijn we nu instaat om dit supersnel uit te voeren. Toch is het niet altijd mogelijk of verstandig om een backup te maken van enkel de gevirtualiseerde infrastructuur.  De meeste backup software is zich tegenwoordig wel bewust van de onderliggende bestandssysteem of de onderliggende database maar een snapshot methode levert vaak niet de juiste informatie om snel een bestand of database object te kunnen herstellen. Om deze functionaliteiten goed te kunnen backuppen is het nogsteeds (20 jaar geleden was dit namelijk ook al zo) om met agents te werken. Agents gedreven backup geeft je een goede indexering van de verschillende versies van bestanden op verschillende tijds momenten. Ook biedt de agent tegenwoordig een data compressie waardoor het dataverkeer tussen server en het de backup opslag vaak al geoptimaliseerd wordt.

Oké een lange introductie voor het beschrijven van een ‘nieuwe’ backup vendor….

Nieuwe is deze backup vendor zeker niet. Sinds 1992 zijn ze alleen maar bezig met het ontwikkelen van de meeste betrouwbare en veelzijdige backup oplossing in de markt.  Het product wordt enkel verkocht doormiddel van een partner netwerk in meer dan 50 verschillende landen in de wereld. Wat voornamelijk opvalt is dat ze nooit iets hebben gedaan aan marketing/ naamsbekendheid. De mond op mond reclame en samenwerking met partners heeft ze voldoende geholpen om een succesvolle onderneming te zijn. Nu zie je dit ook wel iets terug in de look and feel van dit product.

Alles ziet er nog uit of dat het ontwikkeld is in 1992. Toch als je onder de motor kijkt zien je dat er veel technisch ontwikkeld wordt. Zo is er ondersteuning voor bijna alle bekende backup targets. Denk hierbij aan HPE StoreOnce – NetApp Snap Store maar ook aan cloud backup targets als Azure en AWS. Wat voornamelijk opvalt is dat er backup gemaakt kan worden van alle windows besturingssystemen welke er tot nu zijn uitgekomen. Er is dan ook support voor de backup van Windows XP en Windows NT tot Windows 10 en Windows Server 2019. Hiernaast worden er bijna alle Linux/ Unix versies ondersteund en zelfs nog alle versies van Netware en Alpha VMS. Deze Duitse software fabrikant heeft een groot deel van zijn ervaring dan ook in de backup van Unix en Novell Netware. Wederom allemaal producten waarbij de technische kennis voornamelijk de bovenhand voort en de verkoop en marketing afdeling een ondergeschikt kindje zijn.

Juist hierom wil deze software fabrikant de support op dit product zo veel mogelijk in eigen hand houden. De partners dienen dan ook te voldoen aan een zeer strikt certificeringsprogramma willen ze zelfstandig support mogen uitvoeren. Hierdoor worden problemen en ervaringen in het product altijd uit eerste hand ontdekt en worden deze direct opgevolgd. Het product voldoet dan niet alleen aan Duitse degelijkheid, maar ook de support op het product is heel direct en altijd direct met kennis van zaken.

Veel van de eerdere genoemde backup fabrikanten hebben een hele goede marketing en verkoop afdeling maar bieden op het gebiedt van support vaak niet de juiste toegevoegde waarde.

Voor nu heb ik voldoende geschreven of mijn eerste ervaring met deze backup vendor. Mijn volgende blog artikel gaat veel meer over de technische oplossing van deze fabrikant. Ben je nu nieuwsgierig geworden na het lezen van dit artikel, download dan de product brochure van de fabrikant en hou andere berichten op mijn blog over backup nauwlettend in de gaten.

[email-download-link namefield=”YES” id=”4″]

Is Rapid7 de nieuwe Security Officer ?
In dit artikel beschrijf ik wat Rapid7 kan betekenen voor een organisatie en hoe het de security officer kan helpen de juiste maatregelen te nemen. Rapid7 heeft namelijk een vulnerability manager wat in normaal Nederlands betekend dat InsightVM is staat is de kwetsbaarheden binnen een ICT infrastructuur inzichtelijk te maken. Priorieiten te stellen en gezamenlijk op te lossen.
Nu is dit artikel ontstaan om te beschrijven of Rapid7 instaat is om de security officer (CISO) te vervangen. Mijn doel is dan ook om te beschrijven wat de rol van tools zijn zoals deze van Rapid7, maar ook om aan te tonen dat de rol van security officer toch erg gewenst is.
Even een stukje achtergrond over mijzelf. Ik heb in het verleden nog niet eerder gewerkt met vurnerability management. Wel ben ik uitvoeren verantwoordelijk geweest voor het doen van een security audit en het maken van een rapport hierover. Dit waren vaak project gebaseerde audit welke voornamelijk gericht worden om een goede moment opnamen vast te leggen en vervolgens de top 5 prio inzichtelijk te maken. Voor een dergelijke audit maakte ik vaak gebruik van splunk of maakte ik een export van log files en gebruikte auditing tools van Microsoft en de betrokken firewall vendor. Veel van deze tools geven inzicht in wat er verkeerd is geconfigureerd en geven je een hele lange lijst met mogelijke beveiligingsrisico’s. Om dit in een advies en rapport om te zetten kosten dit dan ook vaak dagen werk en lag de interpretatie van de logs altijd bij de security enigeer.
Mijn start om InsightVM te gaan gebruiken is het aanvragen van een trailaccount. Wat opvalt is dat het starten van de trail direct toegang geeft tot de cloud infrastructuur van InsightVM. Even lezen geeft mij duidelijkheid dat deze cloud infrastructuur additioneel is en dat eigenlijk alles lokaal geïnstalleerd kan worden. De cloud geeft je toegang tot tal van extra rapportage mogelijkheden en voegt AI toe aan de oplossing. Hiernaast kan je in het console direct de software downloaden welke je lokaal nodig heb.

 

Even iets kort over de architectuur. Er zijn verschillende methodes om inzicht te verkrijgen in het netwerk. Inzicht is de eerste stap welke gezet dient te worden. Wanneer je enkel gebruik wenst te maken van de cloud infrastructuur dan is het mogelijk om agents te installeren op je servers en werkplekken. Hiermee kan je de kwetsbaarheden inventariseren op die apparaten. Om nu inzicht te krijgen in onderling verkeer of om de mogelijkheid te hebben om correlaties te maken dien je een ochestrator in te richten binnen het netwerk. Deze ochestrator heeft ook de mogelijkheid om alle informatie van de agents te verzamelen waardoor het ook als een standalone oplossing ingericht kan worden.
Er zijn dus verschillende uitrol methodes : agents , ochestrator en als laatste een network sensor. Belangrijk is om te weten dat de agents nu geschikt is voor Windows, Linux en MacOs. De ochestrator kan worden uitgerold als een OVA, Linux embeded of als een MSI voor een Windows device (hoeft geen server te zijn maar heeft wel de voorkeur). Het is met de orchestrator ook mogelijk om zelf een netwerkscan uit te oefenen en het is mij al gebeurt dat dit dan apparaten ontdekte in met netwerk waar ik geen weet van had. Hiernaast is het mogelijk om de ochestrator te verbinden aan je DHCP server en aan bijvoorbeeld AD of een LDAP server om de gebruikers gegevens op te halen. Wat het woord ochestrator natuurlijk al zegt is dit uiteindelijk het hard van de te verzamelen informatie. Bij meerdere netwerken op verschillende locaties is het ook mogelijk om de ochestrator daar uit te rollen. Er zit hier niet echt een limit in, enkel is het gebruik van de cloud dan wel een must wanneer je meer dan 50 locaties aan elkaar gaat verbinden.

 

Voor een Security Officer moet de eerste stap ook zijn om alle gegevens te verzamelen. Hiervoor dient er toegang te zijn tot alle systemen en ook hierin is de rol als security officer gewenst. Natuurlijk hoeft dit geen natuurlijk persoon te zijn en mag dit een fictief persoon zijn of zelfs een tijdelijk rol. Wel krijgt deze rol toegang tot alle systemen en enige vorm van beveiliging rond deze rol is dan ook zeker aan te bevelen.

 

Na het verzamelen van alle gegevens komt de 2de stap, prioriteiten stellen aan de gevonden kwetsbaarheden. Lees hiervoor mijn vervolg blog.

 

Follow by Email
LinkedIn
LinkedIn
Share
Instagram