Beveiligingsdeskundigen hebben Oracle relatief hard aangepakt. Patches zouden niet of te laat komen. Hoe staat het met die beveiliging?
De Britse beveiligingsdeskundige David Litchfield is de luis in de pels van Oracle. Hij heeft zich in het verleden regelmatig kritisch uitgelaten over de veiligheid van de software van dat bedrijf, vooral over de activiteiten op het gebied van het uitbrengen van patches die cruciaal zijn voor het veilig functioneren van de producten. Hij doet alle moeite om beveiligingslekken op te sporen, en vervolgens de onderneming in de gelegenheid te stellen die te repareren middels een patch.
Vroeger was de houding van Oracle tegenover onderzoekers als Litchfield niet bepaald vriendelijk. Er was een tijd dat de organisatie stelde dat zij onderdeel van het probleem te zijn. Zij zorgden er immers voor dat tot dan toe onbekende onvolkomenheden aan het licht kwamen. Zo zette Oracle de relatie met die onderzoekers op scherp, terwijl zij het concern juist met testen en adviezen kunnen helpen om de producten veiliger te maken.
Disproportioneel
Inmiddels is binnen Oracle veel veranderd. Langzamerhand heeft het bedrijf het proces van patches uitbrengen gestroomlijnd en reageert het beter op de ontdekking van onvolkomenheden. Ook is de communicatie verbeterd. Oracle is zelfs een weblog begonnen over beveiligingskwesties (blogs.oracle.com/security/), hoewel daar maar weinig activiteit valt waar te nemen.
Lucas Jellema en Marco Gralike, beiden van AMIS Services, zijn best tevreden over de aanpak van Oracle. Volgens hen is het bijvoorbeeld niet noodzakelijk om alle patches te installeren. Senior database consultant Gralike zegt iedere patch goed te evalueren en alleen dan toe te passen als hij relevant is. “Wij kunnen voor de tientallen databases die we voor onze klanten beheren met een relatief klein aantal patches het beveiligingsniveau handhaven.”
Volgens hem hebben veel beveiligingsproblemen met Oracle databases betrekking op de applicaties die de database benaderen. “Nogal wat webapplicaties, ontwikkeld in bijvoorbeeld PHP, Perl, ASP.NET of Java JSP, bieden zoekfaciliteiten die SQ-injection onvoldoende tegengaan. Een kwaadwillende kan dan letterlijke SQL-statements als zoektermen opgeven en daarmee ongewenste operaties in de database uitvoeren. Dat is geen lek in de database, maar een probleem in de applicatie. Dat is eigenlijk alleen op te lossen door training van de ontwikkelaars en nauwkeurig kwaliteitsonderzoek van de applicaties die in productie worden genomen.”
De pers spreekt volgens Gralike wel eens disproportioneel over een beveiligingslek. “Denk aan een lek dat onder speciale omstandigheden en een specifieke combinatie van instellingen en technologie optreedt. Het is terecht om dat te melden, om er aandacht aan te besteden, maar geef dan ook aan dat het alleen onder heel specifieke omstandigheden een risico vormt.”
