De databases in je datacentra bevatten de meest waardevolle informatie van jouw onderneming. Maar daarmee zijn ze ook het nummer één doelwit van cybercriminelen. En toch zijn in veel organisaties databases slecht beschermd en voldoen ze vaak niet aan compliance-eisen voor de beveiliging van opgeslagen gegevens. Hoe zorg je voor optimale databasebeveiliging en compliance, zonder afbreuk te doen aan de beschikbaarheid of prestaties van databases?
Oude gewoonten sluiten vaak niet aan op nieuwe realiteiten of op eisen rond compliance. Bij veel bedrijven is de it-beveiliging van de organisatie ingericht op netwerkniveau, met als doel cybercriminelen, hackers en schadelijke malware aan de rand van het netwerk tegen te houden. Door nieuwe bedrijfsprocessen en de bijbehorende nieuwe technologieën is het netwerkverkeer echter enorm toegenomen en dan is een degelijke ‘perimeterbeveiliging’ niet voldoende in staat om ongebruikelijke en verdachte netwerkpatronen te detecteren en te stoppen.
Ook nieuwe malware zoals Advanced Persistent Threats (APT’s) vormen een groot gevaar omdat deze zich voordoen als legitiem netwerkverkeer en vervolgens logingegevens proberen te stelen. Daarnaast hebben recente studies, zoals van de Enterprise Strategy Group (ESG), uitgewezen dat de grootste risico’s voor de diefstal van bedrijfsgegevens vaak van binnenuit komt, door misbruik van gebruiksrechten door medewerkers of externe medewerkers.
Niet afdoende
De hierboven genoemde nieuwe realiteiten betekenen dat een perimeterbeveiliging alleen niet afdoende en zeker geen fail-safe methode vormt voor het beveiligen van bedrijfskritische gegevens in het datacenter van de onderneming.
Databasebeheerders concentreren zich vooral op de beschikbaarheid en de prestaties van databases. Omdat databases voortdurend in gebruik zijn en een essentieel onderdeel zijn van bedrijfsprocessen, ligt er vanuit de business een enorme druk op de beschikbaarheid en prestaties van die databases. Databasebeheerders zijn daardoor zeer terughoudend om configuraties te wijzigingen, beveiligingspatches voor databases te installeren of beveiligingssoftware aan hun databaseservers toe te voegen waarvan ze denken dat deze de prestaties nadelig kunnen beïnvloeden.
Deze druk op beschikbaarheid en prestaties zorgt ervoor dat er te weinig aandacht is voor de beveiliging van databasegegevens. Uit een onderzoek van de Independent Oracle Users Group uit 2012, bleek bijvoorbeeld dat slechts 19 procent van de 350 ondervraagde databasebeheerders, consultants en ontwikkelaars kritieke Oracle-patches binnen drie maanden na publicatie installeerden.
Bescherming automatiseren
Er zijn inmiddels effectieve beveiligingsoplossingen beschikbaar die bedrijfskritische databases in het datacenter beschermen tegen een breed scala aan dreigingen: externe, interne en zelfs intra-database aanvallen. Deze oplossingen gaan niet alleen veel verder dan de ingebouwde – en vaak gemakkelijk te omzeilen – beveiligingsmogelijkheden van het dbms zelf, maar doen dat zonder de prestaties of de beschikbaarheid van de databases nadelig te beïnvloeden.
Daarbij kan ook worden gecontroleerd of de laatste patches zijn toegepast en is het mogelijk om de database te testen op veel voorkomende zwakheden, zoals het gebruik van eenvoudige wachtwoorden of standaard gebruikersaccounts, of de aanwezigheid van privacygevoelige gegevens – denk aan creditcardnummers, et cetera – die niet versleuteld in de database zijn opgeslagen.
Het kan echter soms erg lang kan duren voordat een databaseleverancier een patch beschikbaar heeft voor een nieuwe kwetsbaarheid. Gemiddeld is dat zo’n drie maanden. Daarnaast moet in veel gevallen de database gestopt worden om de patch te kunnen installeren, gevolgd door tests voor de functionaliteit. Dit is een probleem, omdat de meeste productiedatabases non-stop, 24/7 beschikbaar moeten zijn. In de praktijk zie je dan dat patches pas geïnstalleerd worden tijdens een geplande stop van de applicaties en de databases, over het algemeen eens per kwartaal. Het is dus heel goed mogelijk dat een database pas drie tot zes maanden nadat een kwetsbaarheid is ontdekt, wordt gepatched.
Een effectievere en snellere oplossing is het gebruik van een databasebeveiligingsoplossing die virtual patching biedt. Daarmee worden databases beschermd tegen kwetsbaarheden waarvoor nog geen officiële patch beschikbaar is of is geïnstalleerd. Over het algemeen is een virtuele patch al binnen enkele dagen na het ontdekken van een nieuwe databasekwetsbaarheid beschikbaar. Met een dergelijke oplossing worden aanvallen die misbruik proberen te maken van de nieuwe kwetsbaarheid, in real-time gedetecteerd en tegengehouden, zonder dat hiervoor de database down hoeft of opnieuw getest hoeft te worden. Virtual patching zorgt ervoor dat organisaties effectiever kunnen voldoen aan compliance-eisen voor de bescherming van gegevens in de database.
Tsja, DBA of service accounts van een zwak – of geen wachtwoord – voorzien is niet handig en er valt zeker nog veel te verbeteren aan de kant van de data(base) laag. Maat laten we niet vergeten dat database vaak mee komt met een applicatie en het patchen ervan nog weleens voor problemen met de werking zorgt.
Het gaat dus meestal niet om het wachten op patches maar om de toestemming deze aan te brengen van de leverancier. Maar dat is nog niet het enige probleem want er zijn ook nogal wat applicaties die gebruik maken van legacy oplossingen, bestaande beveiligingsproblemen worden helemaal niet meer opgelost.
Ik moet me hier even achter Ewoud zijn mening scharen. Met mijn ‘beperkte’ kennis van implementaties van allerhande dbases, is de security vaak een ondergeschoven kind of word belegt binnen de overige disciplines.
Ik hoor niet vaak dat men het sec heeft over de veiligheidsaspecten na implementatie.
Nog een aandachtspuntje… Uiteindelijk wel alle rechten goed instellen per gebruiker en dan de wachtwoorden er op de server in een tekstbestand bijzetten 🙂