Een groot deel van de Oracle-beheerders negeert de Critical Patch Update (CPU). Oracle-beheerders verbazen zich hier niet over.
Oracle-beheerders zijn niet verbaasd over dat patches door databasebeheerders (dba’s) worden genegeerd. Uit onderzoek van Sentrigo, beveiliger van databases, blijkt dat een groot deel van de Oracle-databasebeheerders nog nooit een Critical Patch Update (CPU) heeft binnengehaald. "Ik praat het niet goed. Maar het verbaast me niet. Tijdens een cursus voor Oracle-dba’s werd deze vraag kortgeleden ook gesteld en maar twee van de tien cursisten zei dba’s te patchen", zegt Erik Sekeris, Oracle Certified Master en werkzaam als Oracle-dba bij Sogeti.
De CPU van Oracle is op kwartaalbasis beschikbaar en bevat hoofdzakelijk patches voor beveiligingslekken. Sentrigo vroeg de bezoekers van bijeenkomsten van verschillende Oracle Users Groups (OUG) wat zij met de CPU doen. Tien procent gaf aan de meest recente patch te hebben binnengehaald. "Om de continuïteit van de applicatie te garanderen moet er een heel testprogramma worden doorlopen. En dat duurt net zo lang totdat de nieuwe patch er is", vertelt Marinus Kuivenhoven, Oracle Technology Specialist bij Sogeti en expert van het Computable Topic security.
Noodzaak
Ook dat 67,5 procent van de beheerders nog nooit een patch heeft binnengehaald verbaast de twee beheerders niets. "Een kleine klant ziet de noodzaak er niet van in", zegt Kuivenhoven. Sekeris: "Ze sparen het op tot een jaar of anderhalf jaar. Maar vervolgens denkt me ‘laat maar zitten.’ Vooral overheden en de semi-overheid patchen vaak minder vaak dan nodig is. Dat komt omdat zij aan regels gebonden zijn, waardoor het testtraject lang is.
Sekeris vindt het vanuit een technisch oogpunt niet verstandig dat er niet getest wordt. "Maar de kans dat er beveiligingsproblemen ontstaan is niet zo gek groot. Maar als het wel gebeurt, dan gaat wel alles plat."
…
Sekeris vindt het vanuit een technisch oogpunt niet verstandig dat er niet getest wordt. “Maar de kans dat er beveiligingsproblemen ontstaan is niet zo gek groot. Maar als het wel gebeurt, dan gaat wel alles plat.”
…
Hoezo is “de kans niet zo gek groot”? Lijkt me een beetje een geval “boter op het hoofd”.
Is meneer Sekeris soms de MSSQL worm van een paar jaar geleden vergeten? Natuurlijk horen de meeste DBs niet direct aan het internet gekoppeld te zijn, maar binnen een (groot) netwerk is de kans op een gehackte/besmette PC/laptop/workstation zeer reeel. En dan gaat het heel snel van kwaad naar erger, dat zou meneer Sekeris als “security expert” als geen ander moeten weten …
Dat mag dan wel zo zijn, maar vergeet vooral de laatste zin niet van de quote die je zelf aanhaalt. Vergeet ook vooral niet de gehele quote nog eens te lezen. Ik kan me niet aan de indruk onttrekken dat hier in de vertaling wat geblunderd is. Sekeris heeft het over het testen van de patches en het ontstaan van risico’s door de patches ongetest toe te passen. Dat lijkt me redelijk los te staan van de MSSQL-worm waar je aan refereert.
Verder in het artikel nog een foutje:
“… en maar twee van de tien cursisten zei dba’s te patchen”. Ik kan me niet voorstellen dat Oracle-dba cursisten daadwerkelijk hun databasebeheerders patcht 😉
Laten we duidelijk zijn: Ikzelf vind dat de CPU’s gewoon aangebracht moeten worden (en dan liefst op de database en niet op de DBA ;-). Oracle brengt die patches niet voor niets uit, breng ze dan ook gewoon aan. Ik ga het nog steeds niet goedpraten, maar vanuit de organisatie geredeneerd kan ik me voorstellen dat DBA’s het niet doen (testen, regelgeving, …).
De kans op een beveiligingslek is niet zo gek groot: Veel Oracle databases staan op Linux/UNIX machines, netjes afgeschermd op een intern netwerk. (En wat dat betreft ben ik ook niet zozeer een security expert, maar een eenvoudige DBA). Kans en impact spelen hierbij een rol. Kans mag dan misschien niet groot zijn, impact is wel degelijk groot.
En tot slot: de quote “niet verstandig dat er niet getest wordt” moet uiteraard zijn “niet verstandig dat er niet gepatched wordt”.
Als DBA kan ik me best voorstellen dat er DBA’s zijn die de CPU overslaan. Zodra de patch beschikbaar is wachten wij een paar dagen, aangezien het weleens voorkomt dat Oracle binnen een week met een “nieuwe” CPU aankwam.
Het zoekwerk naar de patchdocumentatie en de patch zelf is, op de niet al te vriendelijke Oracle site, al een werk op zich. Eenmaal alle informatie verzameld, dan start het werk, wat wij grotendeels gescript hebben. Hier zit de hem de winst (en valt, als Oracle de CPU generiek maakt, nog meer winst te behalen).
In onze testomgeving, 2 (consolidatie) database servers met totaal 46 databases, kost het 1 tot 1,5 uur werk. Ervaring leert dat grote van de database er (nagenoeg) niet toe doet. De voorbereiding kost ongeveer hetzelfde dus laten we zeggen max. 4 uur voorbereiding en test patchen.
Kortom, het werk valt best mee, mits je e.e.a. goed op een rijtje hebt. Het testen hoeft, met een gedegen testplan, m.i. ook niet (te) veel tijd te kosten.