Lost in the Noise

Helaas draaien er nog veel implementaties van Oracle zonder gebruik te maken van de standaard beschikbare audit tools. In andere omgevingen, waar dit wel het geval is, worden de verkeerde keuzes gemaakt. Dit Whitebook gaat dieper in op de maatregelen die u kunt treffen om uw installatie te beschermen tegen ongeautoriseerde toegang. Het biedt een handreiking naar een aantal bekende zwakheden in een Oracle omgeving en geeft een set van maatregelen die u kunt treffen om dit te voorkomen of in elk geval sneller te detecteren.

Introductie

Helaas draaien er nog veel implementaties van Oracle zonder gebruik te maken van de standaard beschikbare audit tools. In andere omgevingen, waar dit wel het geval is, worden de verkeerde keuzes gemaakt. Dit Whitebook gaat dieper in op de maatregelen die u kunt treffen om uw installatie te beschermen tegen ongeautoriseerde toegang. Het biedt een handreiking naar een aantal bekende zwakheden in een Oracle omgeving en geeft een set van maatregelen die u kunt treffen om dit te voorkomen of in elk geval sneller te detecteren.

Bekende problemen

Veel bedrijven maken gebruik van firewalls, intrusion detection systemen en diversen andere security tools om hun besturingssystemen of netwerk te bewaken. Ook binnen Oracle kunt u ongeautoriseerde toegang en misbruik van rechten detecteren met standaard auditing hulpmiddelen.

Iedere databaseomgeving zou moeten worden beschermd met een basis set van audit tools. Het absolute minimum is het bewaken van gebruikerstoegang en gebruik van systeemrechten. Helaas is hiermee de ‘gevoelige’ data nog niet beschermd. Veel voorkomende ‘fouten’ zijn onder andere:

• een onveilige TNS listener;
• zwakke wachtwoorden voor standaard accounts;
• het missen van essentiële security updates;
• onveilige code van een derde partij (PL/SQL packages).

Het schema (afkomstig van Red Database Security) hieronder geeft een beknopt overzicht van enkele bekende aanvallen die welke zelfs zonder dat de gebruiker in de database is ingelogd mogelijk zijn:

Figuur 1, aanvallen zonder authentificatie

Zelfs als alle audit functies binnen de database aan staan, is het belangrijk altijd de laatste beveiligings updates te installeren. Zo was het bijvoorbeeld in Oracle 10.2.0.2 mogelijk om meer rechten te krijgen door het uitvoeren van een redelijk eenvoudige exploit. In deze versie start Oracle het ‘alter session set nls’ commando op met SYS rechten. Door een eenvoudige aanpassing uit te voeren op het oraclient10.dll bestand, was het mogelijk DBA rechten te verkrijgen (zie figuur 2).

Figuur 2, oraclient10.dll exploit van oak.

Dit soort problemen wordt in de praktijk snel opgelost met security patches. Het is dus van groot belang deze altijd in de gaten te houden en indien relevant zo snel mogelijk door te voeren.

Audit tools

Veel van de bekende problemen zijn te verhelpen, of in ieder geval sneller te detecteren, door het gebruik van audit tools in uw Oracle database. Een aantal ‘best practices’ met het implementeren van een auditplan zijn:

• zet auditing aan voor alle database logins;
• log alle ‘failed login attempts’;
• zet auditing aan voor het gebruik van system privileges;
• zet auditing aan voor elke structurele verandering in de database;
• gebruik systeem level logging (bijvoorbeeld listner.log).

Daar naast is het wenselijk om waar mogelijk te kijken naar:

• Fine Grained Auditing (FGA);
• audit toegang en veranderingen aan kritieke data;
• overweeg het gebruik van externe audit tools zoals bijv. Guardium, AppRadar, AppDefend, Chakra, etc.

Het is belangrijk de log gegevens te analyseren. U kunt hier dagelijkse rapportages voor opstellen. Denk bijvoorbeeld ook aan procedures, wanneer u onregelmatigheden tegen komt.

Enkele voorbeelden

Als eerste moet auditing worden aangezet. Het onderstaande commando zorgt ervoor dat alle toegang door gebruikers, of dit succesvol is of niet, opgeslagen wordt.

Met het bovenstaande commando is auditing actief op de database voor de toegangscontrole. Helaas worden niet alle wijzigingen bijgehouden aan het schema. Wijzigingen aan bijvoorbeeld: tables, indexes, clusters, views, sequences, procedures, triggers, libraries, etc. worden (nog) niet opgeslagen.

Sommige gebruikers kunnen zelf auditing uitzetten en dus activiteiten in de database verbergen. Het onderstaande overzicht laat zien dat de standaard gebruikers MDSYS, CTXSYS en WKSYS in dit kader potentiële risico’s zijn.

Voor deze functies kunnen we ook auditing aanzetten. Een handige manier om dit te doen, is gebruik te maken van een spool file. Als alle commando’s klaar zijn, kunnen deze vervolgens uitgerold worden over de database:

Een andere optie is, om toegangsrechten van gebruikers direct te genereren uit de database. Hiervoor kunt u gebruik maken van de ‘view dba_sys_privs’ optie.

Deze instellingen zijn te controleren met het volgende commando:

Iedere keer dat een gebruiker nu toegang probeert te krijgen tot een database, zal de Oracle kernel controleren of er een audit record aangemaakt moet worden c.q. bijgewerkt moet worden ( of zoals in het voorbeeld; een sessie record ). De kernel zal een record genereren in een tabel (AUD$) met als eigenaar de SYS user. Deze is standaard te vinden onder de SYSTEM tables.

Notitie: Deze optie is mogelijk gevoelig voor Denial of Service aanvallen. Wanneer de SYSTEM tables vol lopen, kan de database gaan vastlopen. Zet daarom limieten op de grootte van deze tabel!

Met het volgende commando, is het mogelijk gedetailleerde connectie verzoeken te laten zien:

Ook is het mogelijk de ‘failed login attempts’ te bekijken doormiddel van de volgende optie:

Dit overzicht laat twee potentiele misbruiken zien. Gebruiker test3 heeft 4 maal geprobeerd in te loggen op de zelfde dag. Het kan zijn dat deze gebruiker zijn/haar wachtwoord is vergeten, maar er kan ook iemand geprobeerd hebben het wachtwoord te raden. Het volgende commando geeft wat meer informatie:

Het bovenstaande overzicht laat zien dat de gebruiker succesvol is ingelogd vanaf de zelfde terminal op dezelfde dag. Een te hoge waarde bij het aantal ‘failed login’ pogingen zou onderdeel uit kunnen maken van een dagelijkse security audit. Wanneer deze waarde oploopt, zou er nader onderzoek moeten volgen.

Een andere variatie op het bovenstaande commando, is het aantal pogingen door onbestaande gebruikers.

Het bovenstaande overzicht laat mogelijk misbruik zien. Deze pogingen zouden nader onderzocht moeten worden. Ook is het mogelijk de database te controleren op toegang op een ‘vreemd’ tijdstip ( bijvoorbeeld buiten kantooruren ). Dit kunnen natuurlijk batch verwerkingen zijn, maar het kan ook ongeautoriseerde toegang betekenen!

Het bovenstaande overzicht laat de connecties zien voor 8 uur ‘s morgens en na half 8 ‘s avonds. Alle verbindingen en in het bijzonder die van SYS en SYSTEM zouden nader onderzocht moeten worden op legitimiteit. Ook laat het overzicht een verbinding zien vanaf een potentiële vreemde host!

Conclusie

De audit tools van Oracle zijn erg krachtig, maar lijken soms erg complex. Als u de Oracle documentatie er op na slaat, ziet u dat er diversen strategieën zijn om uw databases te auditen.( Er zijn vele variaties op de bovengenoemde voorbeelden mogelijk! ).

In Oracle is het mogelijk praktisch alles te auditen binnen de Oracle RDBMS, maar dit kan voor uw organisatie wellicht geen gewenste situatie zijn. U zult dus moeten testen, welke audit opties geschikt zijn om in te zetten in uw organisatie. Hoewel het aanzetten van audit trails een enorme hoeveelheid informatie oplevert, is het noodzaak ook actie te ondernemen op deze informatie. Zorg voor een goede procedure, hoe om te gaan met eventueel misbruik!

Voor gedetailleerde auditing van uw databases, zou u gebruik kunnen maken van database triggers en fine grained auditing (FGA). Deze laatste opties zijn echter wat lastiger te implementeren, doordat hier aanvullend programmeer werk aan te pas komt. Overigens is de meeste informatie eenvoudige te beschermen, zonder uit te komen op ‘row-level’ audits:

En natuurlijk het belangrijke uitgangspunt:

Geef gebruikers niet meer rechten dan ze nodig hebben!

Referenties

• Hacking hardened Oracle Databases – Alexander Kornbrust (Red-Database-Security);
• Oracle Security step-by-step – A survival Guide for Oracle Security (Pete Finnigan);
• Oracle Security Handbook (Aaron Newman and Marlene Theriault).

bron: http://www.whitehorses.nl/whitebooks/2007/auditing-basics-voor-oracle

Hoewel security experts weten dat er meer is dan een goed ingerichte firewall, IDS/IPS omgeving en ACL lijsten, schijnen veel managers toch nog de illusie te hebben dat hun ICT netwerk hiermee ‘veilig’ is. Natuurlijk helpt een firewall, maar 100% beveiligen is onmogelijk of in ieder geval een erg kostbare zaak en heeft toch echt meer voeten in de aarde. Door beveiliging op een integrale wijze aan te pakken kunnen de onderkende risico’s met minder kosten worden afgedekt.

Willen we informatiebeveiliging goed regelen dan moeten we de taal spreken die managers spreken. De belangrijkste doelstelling voor iedere organisatie is overleven (ook vaak continuïteit genoemd). Voor iedere manager of directeur is dat wel duidelijk. Toch zie je deze doelstelling maar zelden expliciet terug in de jaarverslagen, missies en beleidsplannen van de organisaties. Om deze continuïteit te waarborgen moet de organisatie waarde toevoegen aan de producten en diensten die ze verkoopt. Michael Porter introduceerde hiervoor halverwege de jaren tachtig de zogenaamde “waardeketen” waarbij onderscheid gemaakt werd tussen de primaire en secundaire processen.

Figuur 1: Waardeketen van Porter

In de huidige wereld waar informatie overal en altijd beschikbaar moet zijn, wordt het ondersteunen van deze primaire en secundaire processen door ICT steeds belangrijker. Daarmee wordt beveiliging een ‘hot item’. Maar we moeten doel (primaire en secundaire processen) en middel (ICT) niet door elkaar halen.

Om een voorbeeld te geven: Microsoft heeft onlangs een dienst gepresenteerd waarmee gebruikers medische dossiers digitaal beschikbaar kunnen stellen. Volgens Google’s vice president of engineering hebben steeds meer instanties (medische) informatie nodig die beschikbaar is over patiënten, georganiseerd en toegankelijk voor iedereen. Persoonlijk maken wij ons hier zorgen over omdat beschikbaarheid één item is, maar daarnaast zijn ook de, exclusiviteit en integriteit belangrijke en bekende begrippen geworden. Of die nu echt geholpen zijn met het online beschikbaar stellen vragen wij ons af.

Informatiebeveiliging moet zich dan ook richten op de combinatie van beschikbaarheid, integriteit en exclusiviteit om zo de continuïteit van de organisatie, de bedrijfsprocessen en de informatie te waarborgen. Maar daarnaast moeten we wel rekening houden met wetgeving zoals een Wet Bescherming Persoonsgegevens.

Veel managers denken bij het horen van ‘informatiebeveiliging’ aan de knipperende lampjes op de firewalls. (vooral als deze blauw zijn doen ze het erg goed! Wie op infosecurity is geweest heeft zelf kunnen zien dat de stands met de meeste lampjes de meeste bezoekers trokken). Vergeten wordt vaak dat deze firewall (een technische maatregel) alleen zijn werk goed doet als ook de organisatorische, procedurele, bouwkundige en elektronische maatregelen geregeld zijn. Om nog maar niet te spreken over informatie die op een andere manier de organisatie verlaat, we kennen allemaal de incidenten met USB-sticks en verloren laptops, daar helpt een firewall echt niet tegen.

Een simpel voorbeeld maakt duidelijk wat we bedoelen: als de verantwoordelijkheden niet zijn toegewezen zal de firewall snel een doos met mooie knipperende (liefst blauwe) lampjes zijn waar niemand naar om kijkt, hij staat er, de lichtjes branden dus hij doet het. Als het patch beleid niet is beschreven in procedures voert vervolgens niemand op tijd de juiste updates door waardoor er al snel een gatenkaas ontstaat, maar gelukkig de lichtjes blijven branden, dus we zijn veilig. Ook moeten we er natuurlijk voor zorgen dat onze firewall in een stevig gebouwde serverruimte staat en moeten we zorgen dat er een alarm afgaat als iemand die serverruimte openbreekt om de firewall te stelen. Kortom een combinatie van technische, procedurele, organisatorische, bouwkundige en elektronische maatregelen is noodzakelijk om de firewall goed en vooral veilig zijn werk te laten doen en de firewall is slechts één maatregel.

Hier komt een begrip om de hoek waarin de beveiligingsmaatregelen aan elkaar, aan de waardeketen van Porter en aan informatie- en fysieke beveiliging wordt gekoppeld zodat managers snappen wat we nu echt bedoelen: integrale beveiliging (ook wel comprehensive of enterprise security genoemd).

We beginnen met een definitie voor dit begrip:
Integrale beveiliging is de beveiliging van informatie (geautomatiseerde en niet geautomatiseerde data) en de fysieke beveiliging (beveiliging van materieel en personeel) om de continuïteit van de organisatie te waarborgen door, op basis van risicomanagement en een kosten/batenanalyse, technische, procedurele, organisatorische, bouwkundige en elektronische maatregelen te selecteren en te implementeren.

Dit klinkt natuurlijk goed, maar wat betekend het nu voor uw organisatie?

Door beveiliging op een integrale wijze aan te pakken ontstaat een pakket aan maatregelen dat afgestemd is op de specifieke situatie en processen van de organisatie. Uiteraard moeten deze maatregelen op basis van risicomanagement worden vastgesteld. Deze risico’s moeten worden gewaardeerd, prioriteiten moeten worden gesteld en beslissingen moeten worden genomen over al dan niet te nemen beheersingsmaatregelen. We willen natuurlijk geen maatregelen nemen, maar risico’s af dekken en het heeft weinig nut om een briefje van € 10,- te beveiligen met een kluis van € 1000,-.

We pleiten dan ook voor een benadering die begint bij de directie en waarbij managers zich af vragen:

• Wat moeten we beschermen?
• Waarom moeten we juist dat beschermen?
• Wat gebeurd er als we het niet goed beschermen?

Als deze vragen beantwoord zijn kunnen we met behulp van het integrale beveiligingsmodel de juiste maatregelen selecteren, implementeren en de status ervan monitoren. Wijzelf gebruiken hierbij graag het volgende model om duidelijk te maken waar we het over hebben.

Figuur 2: Integrale beveiliging

De verbetering van de integrale beveiliging gaat over alle producten, diensten, materialen, medewerkers en vestigingen van de organisatie. Het betreft alle bedrijfsprocessen van de organisatie (en de koppelvlakken met de klanten) om de continuïteit van de bedrijfsvoering te kunnen waarborgen. De kritieke processen, die per organisatie verschillen, verdienen hierbij natuurlijk de hoogste prioriteit. We kunnen allerlei mooie theorieën ontwikkelen en ideeën bedenken maar uiteindelijk gaat het erom op operationeel niveau maatregelen te implementeren waarmee we ook echt beter beveiligd zijn (dus toch die firewall, maar dan in combinatie met alle andere procedurele, organisatorische, bouwkundige en elektronische maatregelen). Het integraal beveiligingsbeleid, dat afgestemd is op het beleid, de missie en de doelstellingen van de organisatie, vormt het vertrekpunt voor alle beveiligingsmaatregelen.

Alle medewerkers moeten hun steentje bijdragen. Het heeft geen zin om duizenden euro’s te besteden aan maatregelen, als de medewerkers ze niet snappen en ze niet uitvoeren (dan laten we de opzettelijke handelingen maar even buiten beschouwing, maar vergeet niet: de vijand zit ook intern daar helpt die firewall niet tegen). Het (top)management van de organisatie vervult een voorbeeldfunctie die nogal eens wordt onderschat. Als het management onvoldoende steun geeft aan de maatregelen (of ze zelfs probeert te ontlopen onder het mom van dat geldt niet voor mij als directeur) dan kan men niet van de medewerkers verwachten dat zij zich wel aan de regels houden. Beveiligingsbewustzijn moet zich niet alleen richten op de medewerkers, maar juist ook op de managers.

Kortom de integrale beveiliging is meer dan een stel knipperende blauwe lampjes op de firewall maar is een bedrijfskundige uitdaging die gebaseerd moet zijn op risicomanagement. De coördinatie en eindverantwoordelijkheid voor beveiliging moet op een hoog niveau binnen de organisatie worden opgepakt. Het vereist een aanpak die zichtbare steun geniet van het management, daarbij steeds kijkend naar de kritieke bedrijfsprocessen voor de organisatie en die firewall kan één van de maatregelen zijn.

We moeten met zijn alle af van de ‘whack a mole’ cultuur, waarin we incidenten oplossen door er maar een dure appliance tegen aan te gooien. Laten we beginnen bij het kritisch beoordelen van onze kritieke processen en daar de technische, procedurele, organisatorische, bouwkundige en elektronische maatregelen op af stemmen.

Door ing. Godert Jan van Manen & drs. Thimo Keizer RSE

bron: http://www.security.nl/artikel/17348/1/%22We_hebben_een_firewall,_dus_onze_beveiliging_is_geregeld!%22.html