Auditscripts in de praktijk

Auditscripts in de praktijk

J

Je zit niet op onnodig werk te wachten? Wat is dan handiger dan een tool te gebruiken die het auditbewijsmateriaal automatisch voor je oplevert?

REINIER OLISLAGERS

Dat kan door auditscripts te gebruiken: een ook voor mensen leesbare lijst instructies die settings en gegevens relevant voor audits opvraagt uit een draaiend systeem. Het gaat hier dus om een computerprogramma dat draait op de te auditen systemen. Zie in listing 1 als voorbeeld een deel uit 1 het Lynis Linux/Unix auditscript dat kijkt welk operating system wordt gebruikt. Systeembeheerders of auditors met de juiste rechten kunnen die scripts op enkele of vele machines laten lopen, waarna de auditor de output analyseert en toetst aan zijn normenkader. Tenslotte kan de auditor systeembeheerders vragen naar de reden van onduidelijke of naar zijn mening onjuiste instellingen. Het lijkt een droom van eenvoud en auditgemak, maar zoals bij alle tools zitten er wel addertjes onder het gras. Hierna deel ik mijn ervaringen bij het schrijven en gebruiken van auditscripts in de hoop dat ze van pas kunnen komen voor collega-auditors. WannEEr scripts? Scripts hebben alleen zin als ze passen binnen het controledoel van een audit. Auditscripts hebben betrekking op specifieke systemen zoals bepaalde netwerkapparatuur, operating systems, databases, webservers, applicaties. Afhankelijk van de systemen die de scripts bevragen, kunnen applicatieve audits, gericht op beveiliging binnen applicaties, en/of infrastructurele audits, gericht op

operating system/netwerk/database, worden ondersteund. Mijn collega's en ik hebben scripts met succes gebruikt om bij uitgebreide audits snel een overzicht te krijgen van de beveiliging van een groot aantal systemen. Voordelen Gebruik van auditscripts bij het controleren van auditobjecten kan de volgende voordelen hebben: • Auditors met minder specialistische kennis kunnen toch een audit uitvoeren: ze hoeven zich niet zo te verdiepen in welke commando’s ze moeten gebruiken om resultaten te krijgen en kunnen zich meer richten op het analyseren van scriptresultaten. Werken met auditscripts maakt het makkelijker om een antwoord geven op de vraag van de systeembeheerder: ‘wat wil je precies op settingsniveau weten’ en daarmee de discussie met gecontroleerde snel op een niveau met voldoende technisch diepgang te brengen. Ditzelfde voordeel kun je overigens behalen door de commando's buiten scripts om in auditwerkprogramma's vast te leggen. • Efficiëntievoordeel door herhaalbaarheid en schaalbaarheid: scripts kunnen zonder veel extra inspanning op vele systemen en in verschillende soorten audits worden gebruikt. • Betrouwbaarheid uitkomsten: automatisch geven van opdrachten om instellingen en bestanden de IT-Auditor nummer 2 | 2013

IT Auditor_13_02.indd 23

23 23/05/13 10:20 PM

# Check operating system case ùname` in # IBM AIX AIX) OS="AIX" OS_NAME="AIX" OS_FULLNAME=ùname -s -r` OS_VERSION=ùname -r` CPU=ùname -p` HARDWARE=ùname -M` FIND_BINARIES="whereis -b" SYSCTL_READKEY="" ;; # Mac OS X Darwin) OS="MacOS" if [ -x /usr/bin/sw_vers ]; then OS_NAME=`/usr/bin/sw_vers -productName` OS_VERSION=`/usr/bin/sw_vers -productVersion` OS_FULLNAME="${OS_NAME} ${OS_VERSION}" else # Fall back to pretty safe name OS_NAME="Mac OS X" OS_FULLNAME=ùname -s -r` OS_VERSION=ùname -r` fi HARDWARE=ùname -m` HOMEDIRS="/Users" FIND_BINARIES="whereis" OS_KERNELVERSION=ùname -r` SYSCTL_READKEY="" ;; Listing 1: Een stuk auditscript op te vragen is minder foutgevoelig dan het handmatig (laten) invoeren van die commando's. • Vergelijkbaarheid uitkomsten: omdat steeds dezelfde commando's worden gebruikt is het gemakkelijk om resultaten van verschillende systemen (binnen één audit of tussen verschillende audits) te vergelijken en daar conclusies uit te trekken. Je kunt scripts logischerwijze het beste gebruiken als de ontwikkelen beheerkosten van de scripts en de kosten van analyse van de resultaten

24

lager zijn dan de kosten van het verkrijgen en analyseren van je auditbewijs langs andere weg (bijvoorbeeld handmatig, via tooling gecontroleerde). Om deze kosten te bepalen of te schatten, moet je ook de nadelen van scripts beoordelen. Deze komen hierna aan de orde. nadelen Auditscripts hebben de volgende beperkingen: • Een script test alleen een bepaald systeem of subsysteem zoals een Oracle-database. Het test niet het

onderliggende operatingsystem (zoals Unix) of het netwerk waarover het verkeer gaat. Het kan mogelijk zijn om scripts voor die onderliggende/gerelateerde systemen te gebruiken. Ook dan blijft het zaak rekening te houden met het feit dat andere verbonden systemen invloed kunnen hebben op de beveiliging van de systemen waarop de scripts gedraaid worden. Een oplossing is deze beperkingen te compenseren door aanvullende controlewerkzaamheden, zoals ‘normaal’ auditen, runnen van

de IT-Auditor nummer 2 | 2013


23/05/13 10:20 PM

•

•

•

•

•

scripts op andere subsystemen en het uitvoeren van vulnerability scans. Scripts bestrijken alleen technische aspecten van een systeem. Toch kunnen ze ook een hulpmiddel zijn bij het toetsen van organisatorische en procesmatige aspecten. Zo kan de output van een script een indicatie geven van het aantal uitgevoerde changes in een periode. Verschillende settings kunnen alleen in combinatie een securityrisico opleveren, of het kost teveel moeite om de normen voor de settings automatisch te laten controleren door het script. Settings kunnen niet altijd gemakkelijk automatisch geanalyseerd worden. Een voorbeeld: een account met hoge rechten op operating systemniveau dat ook hoge rechten heeft binnen een database. Een ander voorbeeld is het beoordelen van werkelijke toegangsrechten aan de hand van een soll autorisatiematrix. Gevolg is dat voor de analyse van scriptresultaten vaak nogal wat aanvullend handmatig werk nodig is. Samenhangend met het vorige punt: false positives door compenserende maatregelen. Als voorbeeld: een Sybase database staat zo ingesteld dat toegang over een unencrypted netwerkverbinding is toegestaan. Op operating systemniveau of via een firewall is echter de toegang tot de Sybase netwerkpoort dichtgezet, zodat de database niet over het netwerk benaderbaar is. Er is inhoudelijke systeemkennis nodig om dit te onderkennen en het punt niet (of met een laag risico) in het auditrapport op te nemen. Goede, tijdige communicatie met de betrokken beheerders over de resultaten van het script kan hier wonderen doen. Aanpassingen door gecontroleerden in de scriptresultaten kunnen meestal niet worden ontdekt. Hierop kom ik later terug bij de behandeling van functiescheiding. Een script moet bijgewerkt worden

voor nieuwe releases van software en mogelijk voor nieuwe configuraties bij de gecontroleerde, als het script daar niet op was berekend. • Bij herhaalde toepassing van scripts: wegvallende kennis van wat het script precies doet als basis voor het uitvoeren van de audit. Wanneer een auditor niet meer exact weet wat het script wel of niet bestrijkt, kunnen gaten in een audit ontstaan. Eigen tooling gecontroleerde Een belangrijk punt bij het besluiten of je auditscripts gaat gebruiken is een analyse van de extra moeite die het kost boven andere manieren van bewijs verzamelen en analyseren. Vooral grotere organisaties zullen – ten behoeve van management of interne controleafdeling – vaak zelf tools hebben voor security control/ monitoring (gespecialiseerde producten of systeembeheerproducten) zoals Nessus, NetIQ, TripWire of eigen geschreven tooling. Als de gecontroleerde eigen tooling heeft is het relatieve voordeel van eigen auditscripts vaak te klein of negatief. Vaak is het bij dergelijke tooling mogelijk en zelfs gewenst om aanvullende queries/rapportages en zelfs scripts te runnen. Bij grotere ondernemingen kan de organisatie zelf controles configureren en eventueel zelf geschreven agents inzetten die op de te controleren systemen data doorgeven. Hiermee kan een belangrijk deel van de functionaliteit van de tooling worden geleverd. Daardoor kan de functionaliteit van een dergelijk standaardpakket zeer verschillen tussen implementaties. In dit geval zijn er minstens drie mogelijkheden: 1. De auditor maakt gebruik van de standaard monitoring/rapportagetooling van de gecontroleerde. Risico hierbij is dat auditbewijs alsnog handmatig moet worden verzameld als het systeem onvoldoende aansluit bij de auditdoelstellingen. Met andere woorden: de controledoelstellingen van de tooling van de gecontroleerde moeten

de auditdoelstellingen dekken. 2. De auditor maakt gebruik van de tooling van gecontroleerde maar definieert (ook) eigen queries of rapportages binnen die tooling. Het risico bestaat wel dat het schrijven van queries veel tijd kost terwijl ze niet ook in andere omgevingen kunnen worden ingezet. 3. De auditor gebruikt geen tooling van de gecontroleerde maar laat zijn eigen auditscripts lopen. Dit leidt uiteraard tot (een zekere mate van) dubbel werk en in de praktijk moet worden afgewogen of deze aanpak daadwerkelijk verstandig is of een gevolg van een ‘not invented here’ syndroom aan de kant van de auditor door onbekendheid met de tooling van gecontroleerde. Wanneer de gecontroleerde eigen tooling heeft, zou je als auditor toch wèl eigen scripts kunnen gebruiken in de volgende gevallen: • Als de bij de gecontroleerde aanwezige tooling te beperkt is en je als auditfunctie niet makkelijk meer functionaliteit kan krijgen. Let wel: weeg de kosten van het script af tegen de kosten van toolinggebruik plus de kosten van handmatig extra informatie opvragen. • Als het te moeilijk is de integriteit en functionaliteit van die tooling zelf te verifiëren, bijvoorbeeld wegens complexiteit of uitgebreide aanpassingen aan de tooling. Een audit op beveiliging van een omgeving zou kunnen uitlopen op een audit van het beheer en functionaliteit van de tooling rond die omgeving. Dit kan een valide audit zijn maar daar moet wel expliciet over besloten worden. • Samenhangend met het vorige punt: Wanneer je snel een inschatting wilt hebben van de beveiligingssituatie van een systeem en het doorgronden van de (adequaatheid van) tooling van de gecontroleerde te lang duurt. • Indien er sprake is van gebrek aan functiescheiding bij het ontwikkelen en uitvoeren van de tooling, de IT-Auditor nummer 2 | 2013


25 23/05/13 10:20 PM

zoals het geval is wanneer systeembeheerders zichzelf controleren. • Als je vergelijkbare resultaten wilt hebben door middel van een standaard auditscript over verschillende afdelingen/organisaties heen (benchmarking). Wanneer je zelf auditscripts schrijft, omdat tooling wordt gebruikt die niet voldoende is voor audit loop je het gevaar dat je je eigen softwareontwikkelingsbedrijf start om organisatorische bottlenecks te omzeilen. Dit kan echter de enige mogelijkheid zijn als er essentiële onderdelen ontbreken in de tooling. scripts: opZEt En dE gEcontrolEErdE Het soort auditfunctie (intern, extern) en de organisatiestructuur van de gecontroleerde(n) heeft invloed op de manier waarop je kunt en moet ontwikkelen en testen. Voordat je een script schrijft is het daarom verstandig om ervoor te zorgen dat de procedures rond het ontwikkelen, testen en uitvoeren passen bij de manier van werken van de auditafdeling en de gecontroleerde(n). Verderop wordt de relatie met gecontroleerde bij het uitvoeren van audits met scripts behandeld. acceptatie Hoewel ze leesbaar zijn voor mensen, zijn scripts uiteindelijk computerprogramma's die veelal met hoge rechten worden uitgevoerd. Een volwassen beheerorganisatie zal dergelijke scripts niet zomaar op haar productiesystemen willen laten draaien. Bij het ontwikkelen en laten draaien van de scripts moet liefst de reguliere ontwikkel/changeprocedure van de organisatie worden gevolgd. Hiervoor is een aantal mogelijkheden: • Scripts worden getest en geaccepteerd door een centrale IT-organisatie. • Er is geen centrale IT-organisatie met deze bevoegdheid, dus scripts worden per audit geaccepteerd. Dit kan bijvoorbeeld gebeuren bij

26

externe audits, dochterondernemingen of buitenlandse vestigingen. Bij de laatste variant moet voldoende tijd ingepland zijn in de audit voor acceptatie door de gecontroleerde. Bij het aanleveren voor acceptatie moet de scriptschrijver vooral letten op zaken als: • beveiliging: doet het script geen dingen die niet mogen, bijvoorbeeld het schrijven van settings, het uitproberen van wachtwoorden; • functionaliteit: komt eruit wat eruit moet komen – en liefst in alle verschillende mogelijke configuraties en versies van het gecontroleerde systeem; • load: gaat het systeem/de applicatie niet plat als het script wordt uitgevoerd. samenhang met gecontroleerde systemen Het script moet natuurlijk werken op de draaiende releases en geïnstalleerde modules van de applicaties/ systemen van de gecontroleerde. De scriptschrijver moet hiermee rekening houden bij het schrijven. Een script kan bij sommige versies van het te controleren systeem foutieve of geen uitkomsten geven als het test op functionaliteit die in die versie ontbreekt of anders is. Het uitspitten van documentatie en uitgebreid testen kan dit ondervangen, maar dit moet opwegen tegen de vereiste extra tijd/kosten. Een praktijkvoorbeeld: een Oracle script vraagt auditinformatie op en werkt in Oracle 9. In Oracle 8 geeft het geen uitvoer maar een foutmelding dat de query verkeerd is omdat Oracle in versie 9 een nieuwe kolom heeft toegevoegd aan de tabel, die in versie 8 nog niet bestaat. De code was ongeveer als volgt (zie Listing 2): het is geldige SQL en niets doet vermoeden dat dit niet werkt op Oracle 8, behalve als je de handleidingen van Oracle 8 en 9 met elkaar vergelijkt. Een praktische oplossing om het script te kunnen gebruiken voor beide versies is een ‘schieten met hagel’

aanpak: herhaal de niet-werkende query en pas de kopie aan voor Oracle 8 met commentaar waarin je aangeeft waarom je dat doet. Resultaat is dat je twee keer naar dezelfde dingen vraagt, waarbij op z'n minst één query de gewenste informatie geeft. Ik ga overigens verderop in het artikel dieper in op foutafhandeling.

Praktijktip Ik zou uit efficiency-overwegingen kiezen voor één redelijk algemeen script voor verschillende versies dat misschien niet altijd alle informatie teruggeeft maar wel duidelijk laat blijken als commando’s niet ondersteund zijn in die versie. Liever één Oracle script dan drie voor Oracle 9, 10 en 11, die apart ontwikkeld en aangepast moeten worden.

Ook is het handig om te kiezen voor een algemene manier van uitvoeren die zo onafhankelijk mogelijk is van de specifieke implementatie in een organisatie op een bepaald moment. Dus een SQL script voor een database in plaats van een shellscript (op operating system niveau dus) dat SQL commando's uitvoert, omdat je dan afhankelijk bent van die specifieke combinatie van shell en operating system. Dit voorkomt dat je bij een wijziging van architectuur of gebruik van het script bij een andere (deel)organisatie met andere componenten veel tijd kwijt bent aan het herontwikkelen, testen en laten accepteren van scripts.

Praktijktip Help de gecontroleerde (en de auditor) door in de outputbestandsnaam liefst de naam van het systeem mee te geven zodat er geen dubbele bestandsnamen voorkomen: makkelijk bij zippen/comprimeren van alle runs van scripts op verschillende systemen binnen één audit.

Functiescheiding Vaak is het zo dat auditors geen readonly account met hoge rechten hebben binnen de te controleren omgeving. In klassieke Unix-omgevingen en op veel



23/05/13 10:20 PM

Windows omgevingen is het niet gebruikelijk dat er zulke accounts zijn ingericht. Dit kan een bevinding op zich zijn maar brengt wel met zich mee dat auditors zelf geen scripts kunnen uitvoeren, of ze moeten tijdelijk beheerdersaccounts hebben (wat eveneens nogal ongewenst is). Een oplossing is het laten uitvoeren van auditscripts door de gecontroleerde en als auditor zelf de resultaten te beoordelen. Dit vereist wel een afdoende functiescheiding tussen de afdeling die het script uitvoert en de afdeling die verantwoordelijk is voor het instellen van de parameters waarop de scripts controleren. Immers, als je mensen zichzelf laat controleren bestaat de verleiding om de resultaten een iets... charmantere inhoud te geven. Een voorbeeld in een mainframeomgeving: als het script securityinstellingen controleert, moet het niet worden uitgevoerd door de afdeling waar het RACF system-wide special attribute is belegd, maar door die met system-wide audit. Een situatie die wij meemaakten is dat de gecontroleerde scriptcommando’s aanpaste, omdat die op zijn systeem niet goed liepen. Zo zorgde hij ervoor dat een aantal foutmeldingen in de output wegens ontbrekende bestanden niet voorkwamen, terwijl wij juist uit de foutmeldingen konden opmaken wat er wel en niet geïnstalleerd was. Het risico is te ondervangen (of te beperken) door: • Zelf uitvoeren van het script onder een eigen account. Zoals gezegd, zijn er vaak maar weinig omgevingen met alleen-lezen/auditor accounts met de vereiste rechten op het hele systeem. Het is geen goed idee om als auditor het script onder een account met schrijfrechten uit te voeren. • Wanneer de auditor zelf geen alleen-lezen account heeft: bij beheerders gaan zitten terwijl ze het script uitvoeren om te controleren dat er geen veranderingen plaatsvinden. • Enkele verbandscontroles in te bedden in het script. Als de

gecontroleerde de uitvoer overtuigend wil wijzigen zal hij op meerdere punten aanpassingen moeten doen. Bijvoorbeeld: • logging checken door zowel loggingconfiguratie als logoutput op te nemen; • logs van uitgevoerde commando's laten genereren door het script en dit confronteren met de scriptoutput; • queries op totaal- en detailniveau uitvoeren en de resultaten correleren; • opnemen van een hash van de tekst van het script in de output en van de output in weer een ander bestand (of, als mogelijk, aan het eind van de output). • Ter plekke steekproef/waarneming van settings uitvoeren of vergelijken met resultaten komend uit andere delen van de audit (bijvoorbeeld wijzigingen gevonden bij auditen van change-management kunnen hun weerslag hebben in configuratie of logging en kunnen terugkomen in de scriptuitvoer). • Inschatten van het risico via andere controleactiviteiten in de audit die gericht zijn op de integriteit en professionaliteit van de gecontroleerde. Op basis van deze inschatting kan de auditor besluiten om aanvullende maatregelen te treffen. • Compileren van het auditscript tot ‘gewoon’ programma, dat een systeembeheerder alleen met veel moeite en kennis kan aanpassen. Dit wordt verder niet behandeld, omdat bij onze organisatie is gekozen voor het niet compileren van de scripts. Nadelen van zelf compileren zijn: • Test/acceptatie door gecontroleerde zal meer voeten in de aarde hebben (bijvoorbeeld bij externe gecontroleerden, gecontroleerden met eigen acceptatieprocedures). • Het compileren van scripts vereist vaak meer programmeerwerk (bijvoorbeeld gebruik maken van een databasedriver bij databasescripts) en komt vaak neer op het herprogrammeren van scripts in

een programmeertaal. De meerwaarde van het uitvoeren van deze activiteit door een auditafdeling boven het laten uitvoeren door de gecontroleerde lijkt me zeer twijfelachtig. Hergebruik Als de gecontroleerde zelf geen of onvoldoende controle-tooling heeft, kan het zin hebben om de auditscripts aan hem over te dragen voor eigen beheer en gebruik. Hierbij moet je je wel realiseren dat onderhoud/ uitvoeren van een script het halve werk is; het analyseren van de scriptoutput vereist ook kennis en wellicht tooling. Dit aspect wordt later nog verder behandeld. Ook moet je voorkomen dat je je eigen werk gaat controleren; bij overdracht moet duidelijk gesteld worden dat de scripts gericht zijn op het verkrijgen van auditbewijs, wat niet hoeft samen te vallen met de behoeften van de gecontroleerde. In de praktijk is het overigens al zo dat auditscripts in elk geval terechtkomen bij de gecontroleerde, waarbij je een deel van je normenkader deelt. De gecontroleerde kan dit vervolgens ook voor zijn eigen controledoeleinden gebruiken, dus het formeel overdragen van scripts is geen groter probleem. Ten slotte zou ik aangeven dat de scripts naar beste kunnen zijn ontwikkeld maar dat de afnemer uiteraard moet controleren en verbeteren wat nodig is. Auditscripts kunnen bijvoorbeeld checks op bepaalde subsystemen missen of bij dagelijks gebruik in bepaalde situaties veel load genereren. scope en normen Auditscripts moeten aansluiten op controledoelstellingen, dus moeten ze ook aansluiten op de normen en te toetsen kwaliteitsaspecten van de audit. Hierna zal ik ingaan op de manier waarop mijn collega's en ik de scope en normenkader voor auditscripts bepaald hebben. Een script wordt wegens de kosten en moeite in het algemeen geschreven voor meerdere audits, waardoor de IT-Auditor nummer 2 | 2013


27 23/05/13 10:20 PM

cursor c_dbaobjauditopts is select owner,object_name,alt,aud,com,del,gra,ind,ins,loc,ren,sel,upd,ref,exe from dba_obj_audit_opts where alt <> '-/-' or aud <> '-/-' or com <> '-/-' or del <> '-/-' or gra <> '-/-' or ind <> '-/-' or ins <> '-/-' or loc <> '-/-' or ren <> '-/-' or sel <> '-/-' or upd <> '-/-' or ref <> '-/-' or exe <> '-/-'; Listing 2: Deel Oracle script een grotere set normen moet worden meegenomen waaruit bij elke audit een keuze kan worden gemaakt. Hierdoor is het dan ook belangrijk om in het script of bijbehorend werkprogramma of documentatie te vermelden welke normen de basis zijn voor welke queries in het script, zodat de auditor bij het controleren weet welke uitkomsten hij wel en welke hij niet moet beoordelen. Zelf kies ik ervoor om de bron van de normen in de scripttekst zelf op te nemen, zodat wijzigen van scripttests of normen minder kans geeft op het vergeten van het aanpassen van de normen of scripttests. De volgende bronnen van normen zijn denkbaar en grotendeels vergelijkbaar met die voor audits waarbij geen auditscripts worden gebruikt: • Algemeen security- en IT beleid van de organisatie, inclusief algemene normen waarnaar wordt verwezen, bijv. ISO 27001/2 voor Information Security Management, Sarbanes-Oxley voor US beursgenoteerde bedrijven, Wet Bescherming Persoonsgegevens, NEN 7510 (voor zorginstellingen), COBIT (Control Objectives for Information Technology), ITIL (Information Technology Infrastructure Library).

28

• Normen van de gecontroleerde systeembeheer/security/interne controle-afdelingen zelf. • Algemene securitynormen voor het te controleren systeem: • Technische documentatie/best practices/normen van leveranciers, zoals de IBM Red Books. • Normen van auditen securityorganisaties, bijvoorbeeld CIS (Center for Internet Security), NSA (US National Security Agency), NIST (US National Institute for Standards and Technology), ISACA, SANS Institute, PvIB (Platform voor Informatiebeveiliging). • Tegenvoorbeelden van securityzwakke defaultinstellingen bij installatie, voor zover niet elders gedocumenteerd. Een voorbeeld is het standaard SCOTT/TIGER account dat vroeger bij Oracle databases voorkwam, of het in cursussen vaak gebruikte Cisco enable wachtwoord sanfran. Het loont soms de moeite om cursusmateriaal en beheerdersdocumentatie door te spitten op zoek naar veel gebruikte wachtwoorden en configuraties die een zwakke beveiliging opleveren en dergelijke; daarom is dit punt apart vermeld. • Normen komend uit professional

judgement, tipgevers/bronnen binnen de organisatie en collegaauditors bij andere organisaties. opZEt En tEstEn Van scripts Wanneer je bepaald hebt hoe het ontwikkelen en gebruik van scripts past binnen je organisatie en je normenkaders hebt, waaruit je scriptcommando's haalt, wordt het tijd om het script te schrijven en functioneel te testen. Bij het ontwerpen van scripts is het enorm belangrijk om een goede structuur aan te brengen zodat de schrijver en gebruiker bij de vele scriptopdrachten het overzicht niet verliezen. structuur Een indeling die handig kan zijn bij het schrijven van scripts is: • Meta-informatie/audit trail van het script. Hierbij kan gedacht worden aan: • Versie van het script dat wordt gedraaid: dit is nodig om werkprogramma's en eventuele analysetooling te laten aansluiten op de juiste commando's. • Uitvoerdatum en -tijd: handig om resultaten te correleren met overige controlewerkzaamheden (bijvoorbeeld naar change management).



23/05/13 10:20 PM

•

• • •

• Systeemnaam/IP adres of overige identificerende informatie zodat altijd teruggevonden kan worden op welke systeem het script heeft gedraaid, ook al wordt het outputbestand hernoemd. Dit helpt ook als de naam van de bestanden altijd hetzelfde is wegens technische beperkingen, zoals bij sommige databasescripts. • Gebruikersaccount waaronder het script gelopen heeft: dit geeft vaak een indicatie of het script met de juiste rechten is gedraaid. • Opvragen van geïnstalleerde modules/componenten van het systeem: dit helpt om te kijken of er bij volgende versies van de scripts nog extra informatie voor die modules moet worden opgevraagd. • Gebruikte versie van het systeem: kan aanwijzing geven voor output die niet correct of compleet is voor die versie, bijvoorbeeld bij nieuwe auditfuncties op een systeem. • Aantal uitgevoerde tests/checks/ commando's: de auditor kan dit aantal confronteren met een telling van de resultaten uit het script om zo de volledigheid van de scriptoutput te checken. Configuratie: algemene instellingen, vaak met security-implicaties, zoals settings voor automatische updates/patches. Een ander voorbeeld bij een databasescript is informatie over soort en versie van het onderliggende operating system, wat handig kan zijn bij het bepalen van welke compenserende controls op operating system-niveau moeten en kunnen plaatsvinden. Deze categorie is voor mij eigenlijk ook een vergaarbak van wat elders niet past. Logische toegangsbeveiliging: gebruikers en rechten, inclusief beheerders. Continuïteit: backup/recovery, transactielogbestanden bij databases, enzovoorts. Performance: instellingen voor het meten van performance, delen van

performance monitoring logs, enzovoorts. • Auditing/logging: instellingen voor het bijhouden van kritische wijzigingen van systeeminstellingen, alsmede het volgen van gedrag van gebruikers. Ook hier kan je (een deel) van de gegenereerde logs opvragen zodat later de afhandeling van incidenten door de organisatie kan worden getoetst. • Consolideren van outputbestanden en opruimen: als er meerdere outputbestanden zijn gegenereerd, kan het script deze met een compressie-utility zoals zip, tar, bzip2 comprimeren en de overbodige outputbestanden verwijderen. Ook kan het tijdelijke bestanden verwijderen, het outputbestand hernoemen naar de systeemnaam en een melding geven aan de gebruiker dat het script gereed is. Afhankelijk van de mogelijkheden van het gecontroleerde systeem kan het script in dit gedeelte ook hashes van het scriptbestand (de source dus) en outputbestand(en) genereren om enige bescherming tegen aanpassing door systeembeheerders te geven. Vorm Zoals aan het begin van het artikel aangegeven, gebruiken scripts door mensen leesbare instructies, in tegenstelling tot gecompileerde programma's. Voordelen zijn dat systeembeheerders makkelijker kunnen controleren dat de juiste informatie wordt verkregen, er niets wordt aangepast en dat de invloed op de performance acceptabel is. Aangezien een script niet is gecompileerd maar voor mensen leesbare tekst bevat, kunnen collega-auditors en security-experts ook makkelijker bijdragen leveren. Omdat het script een tekstbestand is, kunnen licentie, indicatie van auteur/verantwoordelijken, contactinformatie en instructies voor het uitvoeren van het script bijgevoegd worden. Dit verkleint de kans dat aparte documentatie uit de pas gaat lopen met het script zelf.

Tenslotte zijn scripts vaak flexibeler dan gecompileerde programma's, waardoor het mogelijk is om relatief snel nieuwe auditdoelstellingen of systemen/functies te verwerken in het script. Listing 3 toont het begindeel van een script gericht op DB2 voor Linux/ 2 Unix/Windows. Het vraagt de systeemidentificatie van de DB2-omgeving op. Hier komen de eerder beschreven vermelding van licentie, auteur, uitvoeringsinstructies en een verwijzing naar normenkaders terug. (zie listing 3) inhoud Het is een vereiste dat het script alleen gegevens opvraagt en niet wijzigt. Een uitzondering kan zijn dat het tijdens de verwerking voor zichzelf tijdelijke bestanden/objecten (bijvoorbeeld temporary tables, of cursors in een database) aanmaakt die automatisch gewist worden. Bij een script op operating systemniveau kun je output die nog verder moet worden verwerkt naar de directory van het script of tijdelijke directory sturen en vervolgens die tijdelijke bestanden na afloop verwijderen. Hierbij moet je natuurlijk waarborgen dat toegang tot die tijdelijke bestanden afdoende beperkt is (bijvoorbeeld uitvoer naar een /tmp of homedirectory onder Unix, tevens het expliciet zetten van permissies met behulp van chmod). Hieruit blijkt ook een verschil met scripts die gebruikt worden tijdens penetratietesten: deze kunnen bijvoorbeeld brute force wachtwoordaanvallen of exploits uitvoeren, waardoor schade of veranderingen aan het systeem kunnen worden aangericht. Auditscripts hebben tot doel alleen informatie op te halen; penetratietests hebben juist tot doel om systemen te manipuleren en daardoor ongewenste toegang te krijgen. De ietwat gechargeerde conclusie: een auditscript moet door minder specialistische mensen dan penetratietesters kunnen worden gebruikt. de IT-Auditor nummer 2 | 2013


29 23/05/13 10:20 PM

-- This script is provided under the MIT license: -- Copyright (C) 2011 by Reinier Olislagers --- Permission is hereby granted, free of charge, to any person obtaining a copy -- of this software and associated documentation files (the "Software"), to deal -- in the Software without restriction, including without limitation the rights -- to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -- copies of the Software, and to permit persons to whom the Software is -- furnished to do so, subject to the following conditions: --- The above copyright notice and this permission notice shall be included in -- all copies or substantial portions of the Software. --- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -- AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -- LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -- OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -- THE SOFTWARE. -- For each database on the instance to be checked, connect first: -- e.g. db2 connect to sample user ADMINISTRATOR -- then run using -- db2 -es "-td;" +s -x -f db2seccheck.sql -l db2cmdlog.txt -r db2secout.txt -- -es: display SQLSTATE messages; +e: display no sqlstate -- -f: script file -- -l: log files with commands given -- -r: output to report file -- +s: don't stop execution on error -- -td;: use ; as a command line terminator (quoted to avoid problems with unix shells) -- -x: suppres printing of column headers -- Repeat running the script for all databases. (= ADMINISTRATORS, This script is meant to give an overview of DB2 security and configuration. It only selects information and does not modify data. Although this script has been tested, please review this script in advance and possibly run this on a test machine to verify this. If you have any suggestions for improvement or corrections, we would be very grateful to receive them. Listing 3: Deel DB2 script (wordt vervolgd op volgende pagina)

30



23/05/13 10:20 PM

DO NOT CHANGE ANYTHING BELOW THIS LINE! If commands are not correct, please inform us in advance. Thank you. =) -- Based on: -- CIS security benchmark v. 1.1.0 (references in script are references to paragraph number) -- http://www.scribd.com/doc/37067585/CIS-IBM-DB2-Benchmark-v1-1-0 -- DB2 Security and Compliance Solutions for Linux, Unix, and Windows -- http://www.redbooks.ibm.com/abstracts/sg247555.html -- ================================================ -- 1. Script metadata -- ================================================ VALUES ('--TestID:'); VALUES ('Name'); VALUES ('--TestDescription:'); VALUES ('Informational: unique name for the tested server.'); VALUES ('--Explanation:'); VALUES ('Helps distinguish output from multiple scripts.'); VALUES ('Combines host and instance information.'); VALUES ('--Norm:'); VALUES ('None'); VALUES ('--Results:'); -- Note: by default, spm_name is the host name, but this can change -- SELECT VALUE FROM SYSIBMADM.DBMCFG WHERE NAME = 'spm_name'; -- todo: check if DB2INSTDEF could be replaced by more specific variable -- maybe DB2INSTANCE - or simply db2 clp GET INSTANCE select REG_VAR_VALUE from sysibmadm.reg_variables WHERE REG_VAR_NAME='DB2SYSTEM'; select REG_VAR_VALUE from sysibmadm.reg_variables WHERE REG_VAR_NAME='DB2INSTDEF'; VALUES ('--RecordEnd'); VALUES (''); Listing 3: Deel DB2 script

Een ander belangrijk punt bij het bepalen van welke commando's een script moet uitvoeren, is dat de load van het te controleren systeem niet teveel mag oplopen bij uitvoeren. Een praktijkvoorbeeld is het doorzoeken van Unix-bestandssystemen op world-writable files ofwel bestanden die door alle Unixaccounts te beschrijven zijn. Dit vormt een probleem als een machine remote (bijvoorbeeld een netwerkbestandssysteem op een SAN) of trage bestandssystemen heeft.

Omdat het niet mogelijk leek om voldoende generiek uit te maken of een bestandssysteem remote was, was de oplossing om de zoekcommando's met een commando (nice) af te remmen en om de zoekopdracht te herschrijven zodat meerdere zoekslagen (bijvoorbeeld zoeken naar world-writable files en files met suid/ guid tegelijk) in één keer uitgevoerd werden. Een ander alternatief zou kunnen zijn om alleen voor bepaalde kritische bestanden te kijken of ze world-wri-

table zijn, maar dit vereist meer onderhoud in het bijhouden van het script omdat je de lijst van kritische bestanden per release/mogelijke configuratie/geïnstalleerde software zou moeten bijhouden. De vorige punten geven al aan dat het belangrijk is om te weten welke commando's welk effect hebben. Meer of minder voor de hand liggende bronnen van kennis over de te geven commando's: • Systeemdocumentatie, overige documentatie (bijvoorbeeld de IBM Red Books). de IT-Auditor nummer 2 | 2013


31 23/05/13 10:20 PM

• Bestaande scripts die bijvoorbeeld op internet of in de organisatie beschikbaar zijn. • Sites voor beheerders. • Trainingen. • Beheerders en interne controleafdelingen bij de organisatie.

Praktijktip Betrek systeembeheerders tijdens het bouwen van de scripts; vaak hebben ze nuttige tips voor commando's die een script efficiënter of effectiever maken.

Omdat scripts zoveel mogelijk versieonafhankelijk moeten zijn en acceptabel voor de gecontroleerde, verdient het aanbeveling alleen gedocumenteerde commando's te gebruiken. Als uit oogpunt van effectiviteit of efficiency alleen een ‘onofficieel’ commando kan worden gebruikt, moet je dat duidelijk al dan niet in het script documenteren en beargumenteren. Vaak worden deze onofficiële commando's dan in de praktijk door systeembeheerders gebruikt, omdat ze een leemte in de officiële set commando's opvullen.

Praktijktip Documenteer in het script wat het commando doet, liefst onder verwijzing naar leveranciersdocumentatie, welke controles je daarmee zou kunnen afdekken en waarom je gekozen hebt voor dat commando in plaats van mogelijke alternatieven. Eventueel kan dit ook in een begeleidend document gebeuren. Dit geeft duidelijkheid bij discussies over de vraag of de juiste uitvoer wordt gegenereerd. Het documenteren van de reden waarom een commando wordt gebruikt kan helpen als jij of je opvolger later een makkelijkere manier gevonden lijkt te hebben om output te krijgen die echter niet goed werkt. Een voorbeeld van documentatie is te vinden in de laatste regels van het extract van scriptoutput van Listing 4, bij het CIS1.0.3 record: geen resultaat maar een aansporing aan de auditor om handmatig te controleren.

32

Het detailniveau van de scriptuitvoer is een kwestie van keuze. Je kunt kiezen om het script alle ruwe data te laten uitvoeren, of het script data te laten analyseren en alleen de resultaten weg te schrijven. Wat mij betreft moet de uitvoer van het script voldoende gedetailleerd zijn om als auditor zelf de analyse te kunnen maken. Ruwere informatie is ook minder manipulatiegevoelig door gecontroleerde: hij weet niet wat jij gaat controleren en moet eventuele kruisverbanden zelf ook leggen. Bovendien weet je nooit of je bepaalde data nog kunt relateren aan andere scriptresultaten of auditbewijs. Verder is het zo dat de taal waarin je scripts schrijft voor veel systemen niet erg geschikt is om gemakkelijk stukken tekst te laten analyseren en bewerken. Als je databasescripts schrijft ben je bijvoorbeeld vaak gebonden aan de beperkingen van SQL. Ook kun je er niet van uitgaan dat een systeem bepaalde makkelijke hulplibraries of commando's heeft (bijvoorbeeld awk en sed op een Unixsysteem) – vooral bij gehardende, zwaar beveiligde systemen zal dit optreden. Het is dan efficiënter om de wat ruwe scripoutput na ontvangst door de auditor (half )automatisch te laten analyseren. Dit onderwerp komt terug in de paragraaf ‘Analyse en voorbewerkingstool’. Misschien nog wel belangrijker is dat je bij meer gedetailleerde output vaak kunt achterhalen of de commando's in het script wel de gewenste uitvoer genereren. Wanneer je geen ruwe output hebt, is het onmogelijk om te bepalen of een ‘component niet aanwezig’ resultaat komt doordat het commando dat zocht naar die component niets opleverde of dat het commando niet werkte. Listing 4 toont een deel van de uitvoer van mijn DB2 Linux/Unix/ 3 Windows script. Het toont de table spaces (mapping tussen logische databaseobjecten als tabellen en de fysieke opslag ervan in bestanden/ partities4) en bevat een sectie die de

auditor aanspoort zelf te controleren op het operating system account waaronder DB2 draait. Zie regel zes van onderen in listing 4. Het is handig om de commando's in het script zo eenvoudig mogelijk te houden zodat de kans op foutieve uitvoer zo klein mogelijk is. Aan de uitvoer van TestID SO_TABLESPACES in Listing 4 van regel 10 tot aan ‘-- RecordEnd:’ is te zien dat ik er voor gekozen heb om de commando's die deze output genereren zo eenvoudig mogelijk te houden, wat in dit geval helaas betekent dat de output ongestructureerde elementen bevat die beter apart vermeld hadden kunnen worden. Het bepalen van het detailniveau was één van de meest verhitte onderwerpen van discussie bij ons team, wat misschien aangeeft dat de beste oplossing niet voor de hand ligt. Wanneer mogelijk laat ik scripts alle uitgevoerde commando's volgen en het resultaat wegschrijven naar een logbestand. Dit is niet alleen handig bij het ontwikkelen, maar ook bij gebruik in productiesystemen omdat het kan helpen bij het zoeken naar de reden van falen van scriptcommando's. Bovendien kan het dienen als een extra controle op de juistheid en volledigheid van het gedraaide script. In listing 5 een deel van het 5 logbestand van mijn DB2 script waarin te zien is dat de uitgevoerde commando's goed werden uitgevoerd.

Praktijktip Probeer zoveel mogelijk fouten netjes af te vangen in je script: het is immers een programma, dat op onvermoede manieren kan vastlopen. Natuurlijk is er een spanningsveld tussen goede foutafhandeling en scriptcomplexiteit. Een voorbeeld: oudere versies van Oracle stopten met uitvoer naar het scherm als een buffer vol zat. Die buffer had een beperkte maximumomvang. De oplossing was het maken van één hoofdscript dat per controle een ander script aanroept. Zo blijft het bufferprobleem beperkt tot één controle.



23/05/13 10:20 PM

--TestID: SO_TABLESPACES --TestDescription: Tablespaces --Norm: None --Explanation: Tablespaces present on instance Ref: http://www.db2dean.com/Previous/AdminView.html --Results: 2011-05-13-03.31.21.326671 0 SYSCATSPACE DMS ANY 2011-04-09-05.29.08.287534 NORMAL 98304 98288 69424 28864 70.63 24576 24572 17356 7216 17356 4 24 -1 -1 -0 1 1 IBMCATGROUP 10 2011-05-13-03.31.21.326671 1 TEMPSPACE1 SMS SYSTEMP 2011-04-09-05.29.08.303369 NORMAL 4 4 4 0 100.00 1 1 1 0 0 4096 32 -- IBMTEMPGROUP 10 2011-05-13-03.31.21.326671 2 USERSPACE1 DMS LARGE 2011-04-09-05.29.08.303397 NORMAL 32768 32640 384 32256 1.17 8160 96 8064 96 4096 32 192 -1 -1 -1 1 IBMDEFAULTGROUP 10 2011-05-13-03.31.21.326671 3 SYSTOOLSPACE DMS LARGE 2011-04-09-05.29.49.439385 NORMAL 32768 32752 608 32144 1.85 8188 152 8036 152 4096 4 24 -1 -1 -1 1 IBMCATGROUP 10 --RecordEnd

4096

192 1

8192 0

8192 0

--TestID: CIS1.0.3 --TestDescription: DB2 service under least privileges --Explanation: Ensure that DB2 is running under the least privileges at OS level as needed. --Norm: None --Results: Please check at operating system (e.g. Unix) level. --RecordEnd Listing 4: Deel DB2 scriptoutput de IT-Auditor nummer 2 | 2013


33 23/05/13 10:20 PM

05/13/2011 03:31:21 VALUES ('--TestID:') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. 05/13/2011 03:31:21 VALUES ('Name') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. 05/13/2011 03:31:21 VALUES ('--TestDescription:') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. 05/13/2011 03:31:21 VALUES ('Informational: unique name for the tested server.') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. 05/13/2011 03:31:21 VALUES ('--Explanation:') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. 05/13/2011 03:31:21 VALUES ('Helps distinguish output from multiple scripts.') 05/13/2011 03:31:21 DB20000I The SQL command completed successfully. Listing 5: Deel DB2 scriptlog script klaar... en nu? Wanneer het script gereed lijkt, moet de schrijver functionele tests uitvoeren. Hiervoor zijn verschillende mogelijkheden: • Inrichten en gebruiken van een eigen testomgeving. Het inrichten en onderhouden van een eigen testomgeving kan nogal veel werk kosten, maar heeft als voordeel dat de auditor meer kennis van het systeem opdoet. Met de huidige virtualisatietechnieken en gratis systemen voor ontwikkelingsdoeleinden is dit ook gemakkelijker geworden. In onze organisatie hadden we een eigen testomgeving voor veelgebruikte Windows- en databaseomgevingen; ons team was ook aanspreekpunt voor de technische controle op deze omgevingen. • Een testaccount gebruiken. Een account op een testomgeving, vooral bij grotere systemen (Unix, mainframe, AS/400), kan een goede oplossing zijn. Hierbij is het belangrijk dat het account de juiste inzagerechten heeft. • Testen laten uitvoeren onder het account van beheerders, onder toezicht van de scriptschrijver. Wellicht te doen voor een enkel

34

simpel script, maar de organisatie wordt hier al snel te zwaar door belast. Het is bij functioneel testen handig om enkele auditors van uiteenlopend kennisniveau te betrekken om de output (en eventuele instructies of tooling hiervoor – zie hierna) te beoordelen op het afdekken van de controledoelstellingen, duidelijkheid en gemak. analyse en voorbewerkingstool Als het script bij testen oplevert wat het moet opleveren, is het tijd om een bijbehorend controlewerkprogramma voor het uitvoeren van audits met het script af te maken/te schrijven. De volgorde waarin dit gebeurt, zal afhangen van de manier waarop de auditorganisatie werkt. Zoals al eerder behandeld is, kun je scripts zo uitgebreid maken dat ze voor globale audits, maar ook diepgaandere audits gebruikt kunnen worden. Dan kun je een standaard werkprogramma maken dat de belangrijkste punten uit het script laat analyseren. Als er specialistische of meer diepgaande audits zijn, kunnen ter zake kundige auditors de scriptresultaten desgewenst diepgaander analyseren aan de hand van

een toegespitst werkprogramma, dat eventueel per audit apart kan worden opgesteld. Een voorbeeld van verschillend gebruik van scripts: bij een infrastructurele audit wordt onder meer gecontroleerd op autorisaties van systeemaccounts op een database; bij een applicatieaudit van bijvoorbeeld een HR-pakket op een Oracle database worden alleen gebruikersautorisaties relevant voor die applicatie op databaseniveau gecontroleerd. Zoals eerder aanbevolen, is een script vaak geschreven voor de grootste gemene deler van uitvoeren presentatiemogelijkheden van een systeem. Ook is het gezien de kans op fouten verstandig om scripts zo simpel mogelijk te houden. Hierdoor leveren scripts vaak een grote hoeveelheid ruwe gegevens op die ook nog eens in een lastig formaat staan. Een voorbeeld is de uitvoer van TestID SO_ TABLESPACES in Listing 4. Het is soms efficiënter om auditors dergelijke output handmatig te laten analyseren. Afstemming met de betrokken systeembeheerder zal ook veelal makkelijker gaan. Bij grotere hoeveelheden geanalyseerde systemen of ingewikkelde output waarbij handmatige analyse



23/05/13 10:20 PM

foutgevoelig wordt, kunnen wellicht Computer Aided Audit Tools (CAATS) als ACL, IDEA of Excel gebruikt worden. Als ook dit niet gemakkelijk kan, kan het de moeite waard zijn om tooling te maken die het script zelf vooranalyseert (dat wil zeggen conclusies verbindt aan gevonden output) of de output ordent voor verdere verwerking door de auditor of andere CAATS. Als de lay-out van de output van verschillende auditscripts op meerdere systemen vergelijkbaar is, kan dit zelfs een efficiënte manier zijn om output te ordenen. Zo gebruik ik voor zoveel mogelijk scripts een outputformaat dat grotendeels hetzelfde is en gemakkelijk omgezet kan worden in een Excel-, Access- of CSV-bestand. Hiervoor heb ik een tool ontwikkeld (zie het screenshot in figuur 1), te downloaden via https://bitbucket. org/reiniero/db2securityscript. Wil je zo'n tool maken of de auditor met CAATS de output direct laten analyseren, dan moet de scriptoutput modulair zijn: per record/element van het script mag er maar één soort output worden gegeven. Zo is verdere manipulatie of vergelijking (in de tijd of met scriptoutput van andere systemen) gemakkelijker. Een voorbeeld van hoe het niet moet is te vinden in de output in Listing 4 bij het SO_TABLESPACES record: hierbij zijn per tablespace allerlei kolommen toegevoegd die eigenlijk weer in aparte records hadden kunnen staan. Soms kan dit echter niet anders omdat opdelen/opmaken van data in het script zelf (bijvoorbeeld in SQL) bijna niet gaat en dan is iets vaak beter dan niets. In het controlewerkprogramma moet een norm staan, een verwijzing naar de query met daaruit volgend bewijs uit het auditscript en de toetsing van het bewijs aan de norm. Hierbij kan het praktisch zijn om in het werkprogramma te verwijzen naar unieke IDs van controles in het script en eventu-

Figuur 1: Screenshot output parser eel de manier van analyseren te beschrijven. Zodra je tooling of werkprogramma's gebruikt om scriptresultaten te verwerken (dus eigenlijk altijd) is versiebeheer, inclusief vastlegging van welke versie officieel getest en geaccepteerd is door de organisatie/gecontroleerde, onontbeerlijk. kundigheid van de scriptschrijver Uit het voorgaande blijkt al dat een aantal kundigheidseisen aan de scriptschrijver wordt gesteld: • Kennis van het gecontroleerde systeem: zonder voldoende diepgaande kennis van de architectuur en werking van het systeem is de schrijver simpelweg niet in staat om een zinnig script te schrijven. • Kennis van de security van het systeem, ook in relatie met verbonden systemen. Een voorbeeld: bij een auditscript op Unix moet je kennis hebben van de beveiliging in Unix maar ook de relaties met netwerkbeveiliging en beveiliging van databases en applicaties die op Unix kunnen draaien.

• Kunnen auditen of tenminste weten hoe het auditproces loopt en wat auditors nodig hebben. • Kunnen scripten/programmeren. Deze combinatie van kundigheden is tamelijk zeldzaam; een oplossing hiervoor kan zijn om scripts in te kopen of te downloaden: het is moeilijker om een script zelf te schrijven dan te beoordelen of het goed werkt. Het kan ook interessant zijn om samen met collega-auditors van andere organisaties of beroepsverenigingen scripts te ontwikkelen. HEt gEbruik Van auditscripts Hiervoor zijn de organisatorische en technische aspecten van het ontwikkelen van scripts behandeld. Hierna volgen mijn ervaringen met het gebruik van scripts bij audits. auditor en gecontroleerde Het is van wezenlijk belang om zo snel mogelijk, liefst bij de aankondiging van de audit, het script mee te sturen en af te spreken op welke systemen dit gedraaid gaat worden, wanneer de output klaar is en wie de IT-Auditor nummer 2 | 2013


35 23/05/13 10:20 PM

(bij zowel de gecontroleerde als aan de auditkant) aan te spreken is bij problemen. Dit zorgt ervoor dat de organisatie van de gecontroleerde niet nodeloos wordt belast door op het laatste moment de scripts te moeten runnen – zelfs bij het automatisch distribueren en uitvoeren van scripts zal dit eerst ingesteld moeten worden. Het maakt verschil of het script al getest en geaccepteerd is door de organisatie of niet; zie hiervoor het eerder behandelde deel over de opzet van scripts.

Praktijktip Het is handig om bij het intake/openingsgesprek van de audit te vragen naar de beveiligingsdoelstellingen en -beleid van gecontroleerde zelf zodat dit zo nodig in het auditscript verwerkt kan worden. Hiermee kunnen misverstanden achteraf mogelijk voorkomen worden.

Het risico van doorbreken van functiescheiding bij het laten uitvoeren van auditscripts is niet denkbeeldig. De eerder bij de opzet behandelde maatregelen kunnen dit risico minimaliseren of wegnemen. De gecontroleerde organisatie krijgt het script vooraf. Zelfs als de auditor zelf onder zijn eigen (alleen-lezen) account het script uitvoert, zal een volwassen organisatie het script willen zien om bijvoorbeeld performanceproblemen door excessieve queries voor te zijn. Dit betekent dat auditors rekening moeten houden met de mogelijkheid dat gecontroleerden de scripts gebruiken om hun systemen ‘auditproof ’ te maken; een reden te meer om het script veel ruwe gegevens te laten genereren en weinig te laten analyseren (zie het eerdere deel over de opzet van scripts). kundigheid en analyse Uit het verhaal tot dusver blijkt dat een uitgevoerd script geen kant en klare auditfindings oplevert. Er zijn dus eisen te stellen aan de kundigheid van de auditor die de resultaten analyseert:

36

• Kennis van het systeem is nodig voor het analyseren van de scriptoutput en beoordelen van false positives/compenserende controls. Compleet automatiseren van scripts/aanvullende tooling tot ‘stoplichtjesniveau’ kan wel maar kost veel tijd en heeft alleen zin als de auditors weten dat een getoonde oranje in werkelijkheid soms rood en soms groen is. • Kennis van systemen en relaties met onderliggende systemen (bijvoorbeeld operating system en netwerk bij een databaseaudit) is nodig om een geldig totaaloordeel te kunnen geven en zich bewust te zijn van de beperkingen van de scriptoutput. Ontbrekende deskundigheid is deels te compenseren door organisatorische specialisatie door te voeren: je kunt ervoor kiezen om ‘normale auditors’ de scripts te laten analyseren, maar wel de scriptschrijvers te betrekken bij de eerste paar audits om een goede analyse te waarborgen; bij ingewikkelde of grote audits is het aan te bevelen om dit altijd te doen. Hierdoor wordt ook aan kennisoverdracht gedaan. Het is voor een auditor bij de voorbereiding van de audit handig om de output van scripts uit een testsysteem of eerdere audits te analyseren en te kijken of hij hulp nodig heeft bij de analyse.

Praktijktip Het kan efficiënt zijn om een bepaald basisniveau aan systeemkennis verplicht te stellen, voordat met het script gewerkt wordt. Als er al een testomgeving beschikbaar is, kan het nuttig zijn om de auditor het script op deze omgeving uit te laten voeren. Aan de andere kant kan er gekozen worden voor training on the job in een meestergezel systeem. Beide keuzen kunnen werken, maar de benodigde tijd en moeite moet tevoren duidelijk zijn en ingepland worden.

Een andere methode om de analyse te versnellen, is om een ruwe analyse van

de resultaten te bespreken met de betrokkenen bij de gecontroleerde. Dit biedt ook een houvast bij interviews, omdat er over concrete voorbeelden/settings kan worden gesproken. Los van het voorgaande moet het resultaat van elke analyse op basis van scripts natuurlijk net als andere audit bewijs teruggekoppeld worden aan gecontroleerde voor wederhoor. Gezien de mogelijkheid van false positives/het missen van compenserende controls is dit belangrijk bij het gebruik van scripts. dossiervorming Het verdient sterk aanbeveling (het lijkt me zelfs verplicht uit oogpunt van beroepsregels) om de gebruikte scripts zelf en de ruwe output (eventueel gecomprimeerd) in het auditdossier te bewaren. Als analysetooling gebruikt wordt, zou ik ook deze output opnemen met verwijzing naar (het bestand met) de ruwe output. Het analyseprogramma zelf zou in zijn output een verbinding moeten leggen met de query/queries van het auditscript en de sectie van de uitvoer waar de gepresenteerde gegevens vandaan komen. Bij de afwerking van het werkprogramma volstaat dan een verwijzing naar de toolingresultaten en de analyses, bevindingen en conclusies van de auditor. Zo kan een reviewer altijd vanuit de bevinding van het rapport via het dossier en de ruwe output naar het originele commando uit het script gaan en vaststellen of de bevinding terecht was. Soms had ik inderdaad discussies met gecontroleerden, die claimden dat het verkeerde commando was gebruikt. Door deze dossierinrichting en de eerder genoemde documentatie in het script zelf kon ik dat redelijk gemakkelijk weerleggen. Feedback voor scriptschrijvers Mijn collega's en ik hebben bij het ontwikkelen en ondersteunen van auditscripts veel gehad aan de ervaringen van auditors bij het gebruik van de scripts. Auditors van verschil-



23/05/13 10:20 PM

lende ervaringsniveaus komen verschillende soorten omgevingen tegen, waardoor je een grote verscheidenheid aan reacties over de inhoud en bruikbaarheid van de scripts krijgt. Het is dan zaak af te wegen wat efficiënt in het script aangepast kan worden, wat in documentatie aangepast moet worden, wat door training van auditors aangepakt moet worden en wat niet (kosteneffectief ) te veranderen is.

conclusiE Scripts kunnen nuttig zijn, vooral om snel inzicht te krijgen in de security van complexe systemen. Aangezien ontwikkeling en testen van bruikbare scripts en bijbehorende documentatie veel werk kost, heeft het zin eerst te kijken of de gecontroleerde organisatie zelf afdoende controle/rapportagetooling heeft. Zorg voor een goed gestructureerd script, kundige analyse en volg goede

Drs. Reinier A. Olislagers ([email protected]) is werkzaam geweest als ontwikkelaar, technisch IT-auditor en audit supervisor in zowel in binnen- als buitenlandse organisatieonderdelen van ING. Hierbij heeft hij zowel normale auditwerkzaamheden als penetratietests uitgevoerd. Reinier is eind dertig, getrouwd en huisgenoot van twee katten.

ontwikkelmethodes, inclusief aansluiting bij acceptatieprocedure van de gecontroleerde. Hergebruik en delen van scripts tussen auditors kan wellicht de efficiency verhogen. Ik nodig eenieder uit samen te werken aan het DB2 script in wording van de auteur (https://bitbucket.org/ reiniero/db2securityscript) en scripts met NOREA collega's te delen. ■ Noten 1 Bron: http://www.rootkit.nl/projects/lynis.html. 2 Bron: https://bitbucket.org/reiniero/db2securityscript/src/f8aa6244e5c5/DB2SECCHECK.SQL. 3 Bron: https://bitbucket.org/reiniero/db2securityscript/src/f8aa6244e5c5/db2secout.txt. 4 Zie bijvoorbeeld http://www.ibm.com/ developerworks/data/library/techarticle/ 0212wieser/. 5 Bron: https://bitbucket.org/reiniero/db2securityscript/src/f8aa6244e5c5/db2cmdlog.txt.



37 23/05/13 10:20 PM

Auditscripts in de praktijk

Recommend Documents