Artikel. Red en green teaming bij Defensie (deel I) Een methodiek voor preventieve, testgerichte beveiligingsaudits (penetratietesten)

Artikel Red en green teaming bij Defensie (deel I)

Een methodiek voor preventieve, testgerichte beveiligingsaudits (penetratietesten) Maarten Buijs

In de praktijk blijkt steeds opnieuw dat penetratietesten een waardevolle aanvulling kunnen zijn op ‘standaard’ IT-audits. Er kan zelfs sprake zijn van bijstelling van een eerder uitgebracht oordeel. Helaas hebben penetratietesten nog een ‘cowboy-imago’ van nerds die maar van alles uitproberen. Dit artikel beschrijft een aanpak hoe dergelijke onderzoeken in te zetten en te structureren.

Organisaties zijn voor het goed functioneren van de informatievoorziening afhankelijk van betrouwbare geautomatiseerde informatiesystemen. Een voldoende mate van betrouwbaarheid wordt gerealiseerd door het treffen van een stelsel van organisatorische, procedurele, technische en fysieke beveiligingsmaatregelen. Het vaststellen van de toereikendheid van het getroffen stelsel van beveiligingsmaatregelen vindt doorgaans plaats door middel van een IT-audit. De IT-auditor kan voor het verzamelen van de benodigde evidence ter onderbouwing van het oordeel, gebruikmaken van verschillende technieken. De standaardaanpak van een IT-auditor bij het vaststellen van de toereikendheid van de technische maatregelen bestaat veelal uit het opvragen van systeemdocumentatie en technische instellingen van het onderzoeksobject. In veel gevallen zal de verantwoordelijke systeembeheerder, onder toeziend oog van de IT-auditor, zorgdragen voor het aanleveren van de voor de audit noodzakelijke evidence. Deze traditionele aanpak kent helaas enkele beperkingen. Als een auditor een risico signaleert, is het niet altijd eenvoudig om de hoogte van het risico in te schatten. De effectiviteit van maatregelen is soms lastig in te schatten evenals de mate waarin een bedreiging zich zal manifesteren. Daarnaast wordt bij een dergelijke aanpak vaak de omgeving van het object en de afhankelijkheid van het object met haar omgeving uit het oog verloren. Bedreigingen komen namelijk vooral uit de omgeving van het onderzoeksobject. Aan de hand van deze omgevingsfactoren wordt de zwakste schakel geïdentificeerd.

M.M. Buijs RE RI (Maarten) is teamleider IT-auditing bij de auditdienst van Defensie. Zijn taakgebied is ICT-infrastructuur en -beheerprocessen en fysieke en persoonlijke beveiliging. Dit artikel is mede gebaseerd op een afstudeerscriptie van de postdoctorale opleiding IT-Auditing aan de Erasmus Universiteit van Maarten Veltman, senior IT-auditor bij het Ministerie van Defensie.

Wat zijn penetratietesten Een penetratietest is een techniek die getroffen beveiligingsmaatregelen voor ICT-middelen onderwerpt aan uitgebreide beveiligingstests, uitgevoerd vanuit een perspectief van risicobeheersing. Deze tests proberen de werking van het stelsel van getroffen beveiligingsmaatregelen zodanig te beïnvloeden dat dit doorbroken of in enige mate negatief beïnvloed wordt. Het testen vindt plaats door de aanwezigheid van indringers en hieraan gekoppelde activiteiten in de (ICT-)omgeving van een organisatie te simuleren. In de uitvoering worden hiertoe methoden, technieken en middelen gehanteerd die binnen de hackergemeenschap gemeengoed zijn.

30 | de EDP-Auditor nummer 2 | 2007

TOOLS

ANALYSEREN

KENNIS DATABANK INTERNET

CROSS SITE SCRIPTING CODE REVIEW

ERVARING

INFORMATIE VERGARING

ONTWIKKELING

DENIAL OFSERVICE

FYSIEKE INSPECTIE

INRICHTING BACKDOORS

ONTWERP

BYPASSING

REPLAY

SESSION )3. PREDICTION HIJACKING WARDRIVING FINGERPRINTING

DUMPSTER DIVING

NETWORKMAPPING

VULNERABILITY SCANNING USER ENUMERATION

PINGING

)0

POORTSCANNING

KRAKEN WACHTWOORDEN BRUTEFORCE

GUESSING

MAN IN THE MIDDLE SLEUTELS

POORTSCANNING

WARDIALING SHOULDER SURFING

MISLEIDING SPOOFING

MAPPING SCANNING

PLAATSEN BACKDOORS

AANVALLEN

GESLOTENBRONNEN

SOCIAL ENGINEERING

FLOODING

REROUTING

OPENBRONNEN

SNIFFING

DENIAL OFSERVICE

BUFFER OVERFLOW

REVERSE ENGINEERING

STRALING

PASSIEF

ACTIEF

PRIVILEGE ESCALATION

RACE INPUT CONDITION MANIPULATIE

#/43

OPEN

!20

SNIFFING

$.3 ZONETRANSFER

3.-0 POLLING

Tests met betrekking tot informatiebeveiliging kunnen in verschillende stadia van de levenscyclus1 van een product plaatsvinden. De in dit artikel beschreven penetratietestmethodiek heeft betrekking op objecten in een productieomgeving. Een team van professionals voert een penetratietest uit. Wanneer de direct voor een informatiesysteem of netwerk verantwoordelijke lijnmanagers en andere betrokkenen (beheerders en gebruikers) niet op de hoogte worden gebracht van de werkzaamheden van dit team, is sprake van een red team penetratietest. Red team-activiteiten komen voor de medewerkers als een verrassing. Deze situatie waarborgt dat de handelswijze van medewerkers natuurgetrouw is. Indien de penetratietesten plaatsvinden na voorafgaande kennisgeving aan de betrokkenen wordt het team ook wel een green team [SGAA02] genoemd. Doordat bij een green team of blue team penetratietest de betrokken medewerkers op de hoogte zijn, verkeren zij in een verhoogde staat van paraatheid en kunnen door kennisgeving vooraf, beveiligingsmaatregelen aangepast en aangescherpt zijn. De opdrachtgever bepaalt, eventueel in overleg met de auditors, of er sprake zal zijn van red of green teaming. Een penetratietest kan als audittechniek fungeren in aanvulling op de standaard IT-auditwerkzaamheden. De bevindingen worden in dat geval gebruikt ter ondersteuning van een uitspraak over de kwaliteit van het getroffen stelsel van beveiligingsmaatregelen in bestaan. Deze audittechniek kan echter ook als op zichzelf staande techniek gehanteerd worden om een specifieke onderzoeksvraag te beantwoorden. In de literatuur zijn penetratietesten getypeerd en aan de hand van de typering geclusterd. Door een clustering te han-

BANNERGRABBING

teren, is de werking en achtergrond van een techniek eenvoudiger te duiden. Op basis van literatuurstudie [NIST03] [RUSS02] en ervaring zijn wij gekomen tot een clustering op activiteitenniveau. Dit betekent een clustering in drie gebieden: informatie vergaring (in de methodiek stap 4a), analyseren (stap 4b) en aanvallen (stap 4c). In het gebied ‘aanvallen’ is onderscheid gemaakt tussen kwetsbaarheden in relatie tot het ontwerp, ontwikkeling en de inrichting. In bovenstaand figuur is door middel van mindmapping samenhang tussen de verschillende technieken en de onderkende clusters aangebracht. De mindmap in bovenstaand figuur geeft een indicatie van de diversiteit van technieken en de onderlinge samenhang. Hierbij wordt opgemerkt dat deze mindmap geen volledig beeld geeft van alle mogelijke technieken. Ook zijn vanwege de overzichtelijkheid niet alle kruisverwijzingen en relaties in het figuur opgenomen. Zo kan een techniek op verschillende manieren ingezet worden. Een buffer overflow kan bijvoorbeeld leiden tot een Denial-of-Service (beschikbaarheid) maar kan ook leiden tot ongeautoriseerde toegang (privilege escalation, exclusiviteit). Onderzoeksobjecten Het soort objecten waarop een penetratietest betrekking kan hebben, loopt sterk uiteen. Het onderzoek kan gericht zijn op: - apparatuur (servers, werkstations, netwerkcomponenten); - programmatuur (databases, toepassingsapplicaties); - gegevens (documenten, data); - mensen (handelswijze, gedrag); - de organisatie (procedures en verantwoordelijkheden); - de omgeving (locatie, invloeden van buitenaf) of een combinatie van de bovengenoemde objectcategorieën.


Artikel Het onderzoeksdoel bepaalt uiteindelijk welke objecten onderdeel vormen van het onderzoek. Risicobepaling Het bepalen van het risico is vaak een impliciete vraag van de opdrachtgever. De IT-auditor moet aan de hand van een kans- en impactinschatting het risico duiden. In deze bepaling worden eigenschappen van de gehanteerde penetratietest technieken en middelen meegewogen. Aan de afzonderlijke technieken en geïdentificeerde kwetsbaarheden kunnen namelijk, ter bepaling van de risico’s, gewichten toegekend worden. Eigenschappen zoals het benodigde kennisniveau, complexiteit en benodigde middelen, bepalen mede het uiteindelijke risico (lees: kans dat een bedreiging manifest wordt). Ook factoren als tijd (hoe lang is de kwetsbaarheid bekend) en de verspreidingsgraad (bij wie is de kwetsbaarheid bekend) spelen hierbij een rol. Deze eigenschappen worden ook gehanteerd bij de vorming van een profiel (zie profielen en scenario’s). Een aantal van de genoemde eigenschappen vormt een onderdeel van beveiligingswaarschuwingen zoals de waarschuwingsdienst van GOVCERT. Deze dienst [WAAR07] geeft in haar waarschuwingen een risicoaanduiding aan. Microsoft kwantificeert eveneens de impact van een kwetsbaarheid in de waarschuwingen [MICR07]. Ook zijn er waarschuwingen van andere bedrijven waarin wordt aangegeven of de kwetsbaarheid lokaal of op afstand misbruikt kan worden. De ITauditor gebruikt al deze factoren als referentiepunt ter bepaling van het uiteindelijke risico dat gelopen wordt. Profielen en scenario’s De bovenstaande eigenschappen en niveaus kunnen gekoppeld worden aan een profiel. Door het aanmeten van een profiel kan de IT-auditor passende bedreigingen simuleren. Een profiel is een verzameling van eigenschappen (kenmerken en typeringen) welke tijdens de uitvoering van een penetratietest wordt gehanteerd. Bij een penetratietest is in beginsel sprake van twee profielen: een extern en een intern profiel. Op basis van de opdracht en de onderzoeksdoelstelling maakt de IT auditor een (gecombineerde) keuze. Extern profiel: dreiging van buitenaf De crux bij een extern profiel is dat er geen dan wel geringe voorkennis van de (detail)inrichting van het object van onderzoek en de omgeving beschikbaar is of gebruikt wordt. Ook is er in beginsel geen sprake van geautoriseerde fysieke toegang of andere speciale bevoegdheden tot het onderzoeksobject. Vervolgens kunnen binnen het profiel bepaalde factoren opgewaardeerd worden zodat een specifiek extern (dader)profiel ontstaat. Niveaubepalende factoren zijn het kennisniveau, complexititeit middelen en de factor tijd en geld. Op deze manier zijn er binnen het externe profiel verschillende gradaties te onderkennen (alles tussen reguliere internetgebruiker, script-kiddies tot buitenlandse inlichtingendienst).

Intern profiel: dreiging van binnenuit Bij een intern profiel is sprake van toegang tot gesloten informatiebronnen en autorisaties op omliggende infrastructuur dan wel fysieke toegang tot het object van onderzoek. Hierbij is enige mate van kennis van of toegang tot het object van onderzoek aanwezig. Voorbeelden van interne profiel typeringen zijn bezoekers, schoonmaker, medewerker, (eind)gebruiker, onderhoudsmonteur, systeembeheerder. Genoemde typeringen moeten vanwege de generalisatie genuanceerd worden gehanteerd. De ene eindgebruiker is de andere niet. Scenario’s In een scenario wordt de volgorde van gebeurtenissen en activiteiten vastgelegd. Op hoofdlijnen bestaan de volgende mogelijkheden: - eerst een extern profiel, gevolgd door een intern profiel; - het interne profiel en externe profiel parallel; - alleen het interne profiel; - alleen het externe profiel. Het klassieke scenario bestaat uit het in eerste instantie uitvoeren van een penetratietest volgens het externe profiel. Vervolgens worden penetratietests uitgevoerd met een intern profiel. De mogelijkheid bestaat om beide profielen afzonderlijk van elkaar te hanteren. Ook is het mogelijk de penetratietestactiviteiten van het interne profiel af te laten hangen van de resultaten van het externe profiel. Bij de activiteiten behorende bij het externe profiel van een red team penetratietest moet een auditor er altijd rekening mee houden dat de kans bestaat dat de activiteiten in een vroeg stadium worden opgemerkt, en het onderzoek daardoor noodgedwongen moet worden gestaakt. Afhankelijk van de onderzoeksdoelstelling en het exacte stadium waarin het onderzoek stukloopt kan dit enerzijds betekenen dat er geen conclusies getrokken kunnen worden. Anderzijds kan mogelijkerwijs de conclusie getrokken worden dat de beveiligingsmaatregelen (b.v. detectief) naar behoren functioneren. De IT-auditor kan vooraf scenario’s definiëren waarin ook theoretische gebeurtenissen in de praktijksituatie gebracht worden. Een scenario kan zijn om te onderzoeken welke informatie voor een schoonmaker toegankelijk is. Hiertoe wordt een intern profiel aangemeten en worden onderzoeksactiviteiten op het scenario afgestemd (bijvoorbeeld fysieke inspecties). In het scenario komt ook tot uitdrukking of de penetratietest op alle organisatieniveaus aangekondigd is (green team) of niet (red team). Wanneer het uitvoerend personeel op de hoogte gebracht wordt, kan teruggevallen worden op kennis en medewerking van het ondersteunend personeel (b.v. systeembeheer). Bij sommige penetratietestopdrachten is dit ook noodzakelijk. Een voorbeeld: een onderzoek


naar de mate waarin gerubriceerde informatie op een netwerk aanwezig en verwerkt wordt, is eenvoudiger uit te voeren indien de volledige toegang tot de fileservers tot op systeembeheerdersniveau geregeld is (green team). Indien de opdracht echter het inschatten van de risico´s voor de toegang tot gerubriceerde informatie behelst, moet de ITauditor de kans inschatten dat deze bedreiging manifest wordt. De bijbehorende kansinschatting kan in dat geval bijvoorbeeld plaatsvinden door de kwetsbaarheid van de betreffende fileserver in kaart te brengen. In dat geval zal de systeembeheerder van de fileserver niet op de hoogte gesteld worden. Hierdoor kan ook een inschatting gemaakt worden van de alertheid van een systeembeheerder (red team). Penetratietesten bij Defensie Sinds 2002 is het testen van de beveiliging van de informatievoorziening door middel van het binnendringen in geautomatiseerde informatiesystemen door de Secretaris Generaal (SG) als taak toegewezen aan de Auditdienst Defensie (ADD). Eisen/randvoorwaarden voor methodiek

De methodiek voor penetratietesten en bijbehorende activiteiten moet voldoen aan een aantal randvoorwaarden. Bij Defensie is een aantal belangrijke randvoorwaarden vastgelegd in een aanwijzing van de SG [SGAA02] die herkenbaar in de penetratietesting-methodiek aanwezig moet zijn. Het betreft: reproduceerbaar. De resultaten van tests dienen reproduceerbaar te zijn. Hiermee wordt bedoeld dat alle onderzoeksactiviteiten en stappen vastgelegd dienen te zijn in die mate dat de tests achteraf op dezelfde wijze uitgevoerd kunnen worden en leiden tot dezelfde resultaten. De verwachte uitwerking van onderzoeksactiviteiten dient vooraf vastgelegd te zijn; doelmatig. De activiteiten mogen alleen uitgevoerd worden voor zover dit voor de beoordeling van de toereikendheid van de beveiligingsmaatregelen en de beantwoording aan de onderzoeksdoelstelling(en) noodzakelijk is. Voorts dienen de te hanteren technieken en middelen representatief te zijn voor de dreiging tegen het desbetreffende informatiesysteem of netwerk; beheersbaar. Onder beheersbaarheid zijn de volgende deeleisen geschaard: a. Schade aan het te onderzoeken informatiesysteem en hieraan gekoppelde systemen dient zoveel mogelijk te worden voorkomen; b. De wijze van uitvoering moet zodanig worden vastgelegd dat eventueel optredende schade op relatief eenvoudige wijze kan worden hersteld; c. Tijdens de activiteiten ontsloten informatie mag niet voor andere dan de vooraf vastgestelde doeleinden worden gebruikt of worden overgedragen aan derden; d. Gegevens en bestanden die gebruikers niet in het kader

van hun functie, maar kennelijk als privé-persoon creëren, worden na herkenning als zodanig niet opgeslagen, reeds opgeslagen gegevens worden dan terstond vernietigd. Indien echter een vermoeden van strafbare feiten bestaat, moeten de gegevens worden overgedragen aan de bevoegde opsporingsinstantie; e. Alle bevindingen dienen voorts vertrouwelijk te worden behandeld en de bevindingen in de rapportages mogen niet te herleiden zijn tot individuele personen. Voorts is vastgelegd dat de methodiek geschikt moet zijn in verschillende omgevingen en inzetbaar moet zijn in verschillende situaties. Bovendien moet de kwaliteit van de penetratietest en bijbehorende werkzaamheden door middel van toezicht en controles zijn gewaarborgd. De organisatorische inrichting en samenstelling van een penetratietestteam moet een onderdeel vormen van de methodiek. Inventarisatiemethodieken In 2003 hebben wij meerdere methodieken voor penetratietesten nader beschouwd op bruikbaarheid binnen het ministerie. Een drietal organisaties had een aanzet gemaakt voor een methodische benadering. Het betreft het National Institute of Standards and Technology (NIST), ISECOM (Institute for Security and Open Methodologies) en de Common Criteria (CC) evaluatiestandaard. Naar onze overtuiging voldeed op dat moment echter geen enkele methodiek volledig aan de eisen die door ons werden gesteld. De voornaamste bezwaren die op dat moment golden waren: - er is in het algemeen weinig aandacht voor de opstart- en afrondingsfase van een penetratietest. Deze fasen zijn met name van belang omdat hierin uitgangspunten en onderzoeksdoelstellingen besproken, afgestemd en vastgelegd worden. Dit vormt de basis van een penetratietest. In de opstartfase van een onderzoek moet bijvoorbeeld een plan van aanpak en werkprogramma worden opgesteld. Deze onderdelen komen niet in de bestaande methodieken aan bod; - in de bestaande methodieken vormt het beperken van de schade geen uitgangspunt. Bij een aantal methodieken wordt geen rekening gehouden met beperkingen ten aanzien van het gebruik van de verkregen evidence en geheimhouding; - in de methodieken zijn geen of onvoldoende afhankelijkheden met interne of externe profielen, red team of green team opdrachten; - de methodieken besteden onvoldoende aandacht aan de vastlegging van penetratietestobjecten, kwaliteitsaspecten en te hanteren normering. Deze randvoorwaarden behoren bij de opstartfase van een penetratietest vastgesteld en bekend te zijn; - kwaliteitsborging, kwaliteitscontroles en toezicht op de penetratietesten vormen geen onderdeel van de bestaande methodieken.


Artikel

6//2"%2%)$).' &ORMULERENOPDRACHT 3TAPABEHANDELINGVERZOEK 3TAPBCONCRETISERINGOPDRACHT 3TAPCACCORDERINGOPDRACHT

5)46/%2).'

!&2/.$).'

5ITVOERINGPENETRATIETEST

!FRONDING

3TAPAINFORMATIEVERGARING 3TAPBANALYSEREN 3TAPCONDERNEMENVERVOLGSTAPPEN

3TAPARAPPORTEREN 3TAPBDOSSIERVORMING 3TAPCEVALUATIE

/PSTELLEN0LANVANAANPAK 3TAPAOPSTELLENPLANVANAANPAK 3TAPBBEPALENBENODIGDERESOURCES 3TAPCACCORDERING PLANVANAANPAK

6OORBEREIDINGPENETRATIETEST 3TAPAFORMATIETEAM 3TAPBACTUALISERENBENODIGDEKENNIS 3TAPCOPSTELLENWERKPROGRAMMA 3TAPD ACCORDERING WERKPROGRAMMA

'

'). "/2

)43 ,)4% ! +7

Methodiek defensie Op basis van literatuuronderzoek, inventarisatie van bestaande methodieken en opgedane ervaring is Defensie tot een eigen methodiek gekomen. In de uitwerking van de stappen zijn in enkele gevallen specifieke Defensiebepalingen opgenomen. Het gedachtegoed achter deze stappen kan echter eenvoudig geprojecteerd worden op andere (overheids)omgevingen. Bij het opstellen van deze methodiek is rekening gehouden met de gestelde eisen en is aansluiting gezocht met faseringen van een ‘standaard’ IT-audit [NORE02]. De nieuw ontwikkelde methodiek bestaat uit een vijftal stappen, zoals op hoofdlijnen in het bovenstaande figuur afgebeeld. Het stappenplan behandelt niet alleen de kern van de uitvoering van een penetratietest maar besteedt ook aandacht aan de opstart- en afrondingsfase. Deze fasen worden in de meeste andere penetratietest methodieken niet benoemd of nader uitgewerkt. De in bovenstaande figuur opgenomen stappen bij de voorbereiding, uitvoering en afronding zijn verdeeld in verdere (sub)activiteiten en nader beschreven in de Defensie-methodiek. In het vervolg van dit artikel beperken wij ons tot enkele belangrijke aandachtspunten en lichten wij deze verder toe. Voorbereiding Stap 1b: concretisering opdracht

Een belangrijke fase in deze stap is het vaststellen van de profielen die gebruikt gaan te worden. De opdrachtgever geeft de insteek van het onderzoek en de te hanteren profielen aan op advies van de opdrachtnemer. In deze profielbe-

schrijvingen komt impliciet een kansinschatting van een bedreiging en daarmee een risico tot uitdrukking. De opdrachtgever zal namelijk aangeven of een bepaald profiel als reële dreiging wordt gezien in de omgeving. Er moet ook bepaald worden of de penetratietest een red team activiteit of een green team activiteit betreft. Met andere woorden: wordt de activiteit aangekondigd of vindt de penetratietest ‘in het diepste geheim’ plaats. Vervolgens werkt de IT auditor de doelstelling uit tot één of meerdere onderzoeksvragen. Bij een opdracht met een extern profiel (black box) stelt de opdrachtgever (diepgaande) achtergrondinformatie in het beginsel niet beschikbaar aan de teamleden. Stap 2a: opstellen concept plan van aanpak

In het concept plan van aanpak legt de opdrachtnemer naast het object/omgeving en de opdracht ook de volgende voor penetratietesten specifieke onderdelen vast: • activiteiten. Als de opdracht helder en afgestemd is kunnen, op basis van profielen en de insteek (red team/green team), activiteiten beschreven worden. Uiteraard worden uit het oogpunt van doelmatigheid alleen die activiteiten ondernomen die noodzakelijk zijn voor de beantwoording van de onderzoeksvraag. De activiteiten in het plan van aanpak worden op hoofdlijnen beschreven. Op hoofdlijnen betekent dat men aangeeft wat de activiteit inhoudt en niet hoe de activiteit inhoudelijk invulling krijgt. De inhoudelijke invulling (hoe) van de activiteiten wordt in het werkprogramma (stap 3c) vastgelegd. Van elk van de activiteiten wordt aangegeven: - het detectierisico en de mate van complexiteit. Deze eigenschappen worden door middel van een laag, midden, hoog aanduiding geclassificeerd. Het detectierisico in deze con-


text is de kans dat de gecontroleerde (bijvoorbeeld beheerders) of andere betrokkenen een activiteit opmerkt. Deze kansinschatting heeft alleen een waarde bij een red team opdracht. Het al dan niet signaleren van activiteiten uitgevoerd door het penetratietestteam is afhankelijk van de expertise en ervaring van de beheerders en de aanwezigheid van technische beveiligingsmechanismen zoals een intrusion detection systeem. Complexiteit is een van de eigenschappen waarmee de kans op misbruik wordt aangeduid. De kans op misbruik bepaalt uiteindelijk weer het risico dat de organisatie loopt; - wat het verwachtte resultaat is. Het doel van het op voorhand vastleggen van het verwachte resultaat is tweeledig. Enerzijds ter controle van de doelmatigheid van de uitgevoerde penetratietesten. Anderzijds biedt dit de mogelijkheid om te leren van fouten door een andere uitwerking dan beoogd (evaluatie). Afhankelijk van de opdracht en insteek van de penetratietest wordt vastgelegd welke afdelingen men binnen de organisatie op de hoogte brengt van de activiteiten. Commitment op het hoogste niveau is in alle gevallen gewenst. Door het commitment van het hoogste management worden mogelijke organisatorische problemen (bijvoorbeeld incidenten) of tegenwerking die tijdens de uitvoering ontstaan in belangrijke mate voorkomen. • risico’s. Er wordt een inschatting gemaakt van de risico’s die men loopt door het uitvoeren van de penetratietestactiviteiten. Er moet een doemscenario aanwezig zijn. Systemen kunnen namelijk uitvallen, data kan verloren raken of naar buiten lekken en de performance kan negatief beïnvloed worden. Al deze aspecten moeten worden onderkend. Zo dient enerzijds voor de opdrachtgever duidelijk te zijn wie van het penetratietestteam te benaderen als problemen ontstaan of gesignaleerd worden. Anderzijds moet het penetratietest team snel de juiste afdelingen in kunnen schakelen zodat een eventueel probleem snel en adequaat afgehandeld kan worden. Wij hebben met de verschillende betrokkenen een protocol opgesteld. Kort gezegd staat hierin: - Het beveiligingsbeheer signaleert bepaalde activiteiten en vraagt bij ons of wij bezig zijn met een onderzoek. Zo niet, dan kan dit duiden op een serieus probleem en een mogelijk veiligheidsincident. Zo ja, dan betekent dit in ieder geval voor een deel: einde red teaming. - Wij signaleren of voorzien een probleem en brengen het beveiligingsbeheer direct op de hoogte. Ook hier geldt: einde red teaming.

Binnen het team zijn een drietal rollen te onderkennen: een coördinerende rol, technisch expert rol (teamlid) en interne toezichthoudende rol. Een penetratietestteam bestaat hierdoor altijd uit tenminste twee personen. De coördinerende en technisch expert rol kan verenigd zijn in één persoon. Deze persoon moet in dat geval wel beschikken over voldoende (technische) kennis van de te onderzoeken objecten. De interne toezichthoudende rol ter waarborging van de kwaliteit van het onderzoek is noodzakelijk vanwege het belang en de gevoeligheid van penetratietesten, waardoor men ook nadrukkelijk achteraf verantwoording levert. De interne toezichthouder bekijkt het plan van aanpak en het werkprogramma kritisch. De toezichthouder treedt bovendien op als klankbord. De coördinator is het aanspreekpunt voor de opdrachtgever en coördineert de penetratietestopdracht. Hij draagt zorg voor de samenstelling van een team van specialisten. Deze specialisten kunnen zowel van binnen als buiten de organisatie van de opdrachtnemer afkomstig zijn (zie ook stap 2b). Elke specialist wordt toegewezen aan één of meerdere activiteiten. Doordat activiteiten zijn afgebakend hoeven de specialisten niet van elkaars werkzaamheden op de hoogte te zijn. De coördinator zorgt er voor dat de activiteiten elkaar tijdens de uitvoering niet belemmeren (planning van activiteiten, wie, wat, wanneer uitvoert). Met de teamleden worden heldere afspraken gemaakt over de te leveren bijdrage, planning van werkzaamheden, rapportagevorm en communicatie. Uitvoering De uitvoeringsfase van de penetratietest is voor wat betreft de detailinvulling in sterke mate afhankelijk van de onderkende benodigde activiteiten uit het plan van aanpak (stap 2) en het werkprogramma (stap 3). Een drietal generieke stappen (zie figuur op blz. 31) zijn echter tijdens de uitvoering van elke penetratietest te onderkennen. Het betreft: - informatievergaring door een verkenning van het object en de bijbehorende omgeving van het object (stap 4a); - het analyseren en interpreteren van deze informatie (stap 4b); - het nemen van vervolgacties (aanval) op basis van de geanalyseerde informatie (stap 4c). Van alle werkzaamheden en resultaten van deze werkzaamheden wordt tijdens de uitvoering verslag gedaan. Evidence, analyseresultaten en interpretaties moeten door de teamleden worden vastgelegd. De coördinator bepaalt welke delen in de rapportage worden opgenomen en welke delen alleen voor het dossier bestemd zijn (zie ook stap 5). Stap 4a: informatievergaring (verkenning)

Stap 3a: formatie team

De samenstelling en omvang van een penetratietestteam is afhankelijk van de onderzoeksdoelstelling, omvang en complexiteit van het onderzoeksobject en benodigde kennis en kunde in relatie tot de onderkende onderzoeksactiviteiten.

Het startpunt van elke penetratietest is een verkenning van het object en de omgeving. De verkenningsfase heeft tot doel zoveel mogelijk informatie over het onderzoeksobject en de omgeving te verkrijgen. Het verkrijgen van deze informatie kan op een actieve (bijvoorbeeld scannen of social


Artikel engineering) en een passieve (publieke informatiebronnen zoals het Internet of foldermateriaal) wijze plaatsvinden. Welke technieken en middelen hiertoe ingezet worden, is mede afhankelijk van het gekozen profiel. Stap 4b: analyseren van informatie

De informatie die tijdens de verkenning (stap 4a) verzameld is, wordt vervolgens geanalyseerd en geïnterpreteerd. De analyse kan leiden tot feiten of een indruk geven van de situatie. De auditor beschrijft het onderscheid in de verslaglegging. Het resultaat van een mapping en scanning activiteit is bijvoorbeeld een overzicht van eigenschappen van systemen en netwerkservices. De IT-auditor kan vervolgens na analyse van de resultaten een indicatie van de kwetsbaarheidspotentie van de geïdentificeerde systemen geven. In een vervolgactiviteit (aanval) worden deze geïdentificeerde kwetsbaarheden gebruikt om toegang te verkrijgen tot systeemfuncties of andere doeleinden. Kwetsbaarheidanalyse De kwetsbaarheidanalyse richt zich op het vaststellen van de kwetsbaarheid van de geïdentificeerde platformen en services. De kwetsbaarheid kan op een tweetal manieren tot uitdrukking komen. Allereerst kan de kwetsbaarheid betrekking hebben op de inrichting (parametrisering). De verantwoordelijkheid voor de parametrisering en configuratie ligt bij de systeem- of applicatie-eigenaar. Een voorbeeld is een te ruime inrichting van toegangsautorisaties. Daarnaast kan de kwetsbaarheid betrekking hebben op het ontwerp of de implementatie van het ontwerp (ontwikkeling) van het platform of applicatie zelf. Een oplossing voor deze kwetsbaarheid kan in de meeste gevallen alleen door de leverancier van het product aangedragen worden. Tijdens een penetratietest in een productieomgeving is het verstandig het vaststellen van kwetsbaarheden te beperken tot bekende kwetsbaarheden. Het is namelijk zeer voor de handliggend dat onderzoek naar nieuwe kwetsbaarheden leidt tot uitval van het systeem, het netwerk of toepassing (Denial of Service). Uitval kan leiden tot grote schade. Stap 4c: ondernemen vervolgstappen en activiteiten De vervolgstappen en activiteiten zijn niet alleen afhankelijk van de onderzoeksdoelstelling maar tevens afhankelijk van de resultaten van de uitgevoerde activiteiten. Zo kunnen door de toepassing van verschillende profielen, tijdens de uitvoering, nieuwe inzichten ontstaan. Beslissingen over te nemen (vervolg)activiteiten worden altijd door de coördinator van het penetration testing team genomen. De coördinator (opdrachtnemer) zal in overleg treden met de opdrachtgever als grote afwijkingen ontstaan ten opzichte van het plan van aanpak. Alle nieuwe of aangepaste stappen die tijdens de penetratietest uitgevoerd worden, moeten op dezelfde wijze gedocumenteerd worden als de beschreven activiteiten uit het werkprogramma (stap 3c).

Aanvallen / binnendringen De IT-auditor kan afhankelijk van zijn of haar opdracht besluiten (in overleg met opdrachtgever) vervolgstappen te ondernemen. Concreet betekent dit dat de IT-auditor gebruik maakt van de tijdens de verkenningsfase en analysefase geïnventariseerde kwetsbaarheden. Een aanval wordt op dat moment op een gecontroleerde wijze gesimuleerd. Ook voor deze activiteit kan de IT-auditor geautomatiseerde tools inzetten. De IT-auditor kan het nemen van deze vervolgstappen op twee manieren motiveren. Allereerst door aantoonbaar te maken dat de geconstateerde kwetsbaarheid niet alleen in een theoretische omstandigheid aanwezig is, maar ook daadwerkelijk in de praktijk aanwezig en uitvoerbaar is. Dit kan de IT-auditor voor een nadere onderbouwing van het oordeel gebruiken omdat het risico op basis van een praktijksituatie beter te duiden is. Daarnaast kan de IT-auditor deze stap ondernemen als opstap binnen het onderzoek om te komen tot de beantwoording aan de onderzoeksdoelstelling. Het gebruikmaken van geïnventariseerde kwetsbaarheden kan namelijk leiden tot: toegang tot informatie, toegang tot faciliteiten en resources, opwaardering van rechten en een aanpassing of toevoeging op het systeem. Met het laatste moet uitermate voorzichtig worden omgegaan. Een aanpassing of toevoeging op het systeem kan leiden tot een instabiel systeem. Hulpmiddelen (tools)

De herkomst van tools die tijdens een penetratietest gebruikt worden kan verschillend zijn. In eigen beheer ontwikkelde tools bieden de meeste mogelijkheden en sluiten, indien juist uitgevoerd, het beste aan op een uit te voeren penetratietest. Het zelf maken van tools vereist wel kennis, tijd en dus geld. Wat meer voor de hand ligt is dat gebruik gemaakt wordt van commercial off-the-shelf (COTS) producten of opensource software. Onafhankelijk van de herkomst moeten alle middelen echter uitgebreid getest worden zodat de werking van het middel en eventuele negatieve gevolgen tijdens de inzet bij een penetratietest op voorhand bekend zijn. Het voordeel van de open-source programmatuur is dat er een grote keuze is in software en dat er geen of lage kosten voor het gebruik gerekend worden. Wel dient het geheel van kosten (incl. evalueren) in kaart gebracht te worden voordat een keuze op basis van kosten gemaakt wordt. Een ander voordeel van deze software is dat vaak de broncode beschikbaar is zodat gecontroleerd kan worden of backdoors of andere ongewenste code opgenomen is. Wanneer de broncode meegeleverd is, heeft dit ook als voordeel dat functionaliteit van de tool door de auditor zelf kan worden uitgebreid of kan worden aangepast, mits dit binnen de licentie mogelijk is. Voor wat betreft de vaststelling van de aanwezigheid van bekende kwetsbaarheden in een systeem of netwerk kan de


IT-auditor gebruik maken van volledig geautomatiseerde tools. Ook hier is een grote keuze aan producten die elk eigen voor- en nadelen hebben. Belangrijk is dat de kwetsbaarhedendatabases waarvan de tools gebruikmaken, up-todate zijn en beschikken over de laatste bekende kwetsbaarheden. Het voordeel van geautomatiseerde tools is dat de kwetsbaarheidinformatie niet beperkt is tot één enkele applicatie of besturingssysteem. Ook is de outputrapportage van de tools overzichtelijk, is geen diepgaande kennis van de onderliggende materie noodzakelijk en geeft de tool een indicatie van het risico en oplossingsrichting aan. Het nadeel van deze tools kan zijn dat het gebruik ervan eenvoudig herkend wordt, doordat vaste patronen onderdeel vormen van de scanactiviteit. Dit maakt dergelijke tools minder geschikt tijdens een red team opdracht. Iets dergelijks geldt ook voor tools die een breed spectrum aan mogelijke bedreigingen gebruiken. Het is effectiever om specifieke tools in te zetten, zoals bijvoorbeeld voor databases of webapplicaties.

van een pentest kunnen daardoor in potentie sneller tot gewenste herstel- of correctieve acties leiden dan een reguliere audit. Overigens heeft de aansprekendheid van de resultaten geleid tot een behoefte aan onderzoeken, waarbij het accent zich lijkt te verleggen van pure netwerk- en systeemonderzoeken naar de kwetsbaarheid van specifieke toepassingen. Hierbij blijft natuurlijk de onderliggende infrastructuur in het vizier.

So far so good… In de afgelopen jaren hebben wij op een aantal objecten, vanuit verschillende invalshoeken en gericht op het beantwoorden van diverse onderzoekvragen, red teaming activiteiten uitgevoerd. Er hebben geen green teaming onderzoeken plaatsgevonden, steeds bleek de voorkeur van de opdrachtgever(s) uit te gaan naar het niet op de hoogte stellen van de organisatie, hooguit op enkele sleutel functionarissen na. De red teaming onderzoeken zijn erg leerzaam geweest, zowel voor ons als IT-auditors maar ook voor IT-beheerders en veiligheidsfunctionarissen. Tot nu toe hebben alle onderzoeken antwoord gegeven op de onderzoeksvragen, met andere woorden: de onderzoeken hebben geleid tot het gewenste resultaat, waarbij in sommige gevallen uiteraard sprake is van een ongewenst resultaat. Hierna volgt een samenvatting van onze belangrijkste ervaringen, ‘leermomenten’ en aandachtspunten, vertaald naar onderkende voordelen, nadelen en enige algemene opmerkingen.

Nadelen Ondanks de aansprekende resultaten is red teaming geen wondermiddel: ook hiermee kun je niet aantonen dat alles 100 procent geregeld is. Het geven van assurance is beperkt tot het duiden op de aanwezigheid en in mindere mate de afwezigheid van kwetsbaarheden. Penetratietesten heeft met name een aanvullende functie ten aanzien van vaststellingen in bestaan. Hierin openbaart zich tevens de beperking dat dit type onderzoek slechts een indirect raakvlak heeft met de output van beheerprocessen. Red teaming is primair gericht op parametrisering, inrichting en eigenschappen van een ICT component. Overigens is achteraf de relatie met beheerprocessen voor een deel te leggen door het opvragen van incident rapportages. Deze kunnen verduidelijken in welke mate de red teaming activiteiten zijn geregistreerd, en hoe beheerders hier eventueel op hebben gereageerd. Een andere beperking is gelegen in het feit dat het aantonen van een nieuwe (ontwerp)fout niet direct leidt tot een oplossing van het probleem. Meestal is alleen de leverancier degene die dit kan verhelpen.

Tenslotte dwingen penetratietesten af dat de IT-auditor omgevingsfactoren in zijn onderzoek betrekt. Waarnemingen vinden namelijk in eerste instantie vanuit de omgeving plaats. Penetratietesten bieden bovendien de mogelijkheid om een accuraat en realistisch beeld van de kwaliteit van de geïmplementeerde beveiligingsinrichting van een geautomatiseerd systeem te verkrijgen. Reële bedreigingen worden namelijk in de praktijk ten uitvoer gebracht.

Voordelen Het eerste voordeel betreft de relatieve snelheid waarmee een dergelijk onderzoek tot resultaat kan leiden ten opzichte van een reguliere audit naar ‘bestaan’. In sommige gevallen is het resultaat zo snel bereikt dat dit een positief effect heeft op de aanvaarding van het risico. Resultaten van red teaming onderzoek worden namelijk soms gebagataliseerd door uit te gaan van de veronderstelling dat alleen tot ‘nerds’ gemuteerde IT-ers dit voor elkaar kunnen krijgen. Snelle resultaten winnen hierbij echter aan overtuigingskracht.

De frequentie van een à twee red teaming onderzoeken per jaar blijkt een zwaar beslag te leggen op de beschikbare capaciteit. Het vastleggen van activiteiten, resultaten, de zorgvuldige dossiervorming en rapportage vergen veel tijd. Dit betekent dat, mede ook door het noodzakelijke op peil houden van kennis en vaardigheden, dergelijke onderzoeken alleen plaats kunnen vinden binnen organisaties met een zekere personeelsomvang en indien nodig aanvullende inhuur van externen.

Daarnaast vervult het onderzoeksresultaat door het aansprekende karakter vaak de rol van breekijzer voor het management. De ‘pentest’ (in het bijzonder hacking) is bovendien een begrip waarbij het gemiddelde management zich een levendige voorstelling van kan maken. Aansprekende bevindingen en voorbeelden dragen daar zeker aan bij. Resultaten

Tot slot De IT-auditor moet zich er van bewust zijn dat bij een penetratietest evidence als het ware wordt gegenereerd. Het genereren (actief) van evidence is een verschil met een ‘standaard’ IT-audit waarbij evidence verzameld wordt. Door tests van de IT-auditor kan namelijk daadwerkelijk een inci-


Artikel dent optreden. Het is hierdoor mogelijk de effectiviteit van de werking van procedures zoals een calamiteitenprocedure, backup/restore, het resetten van wachtwoorden, rapportages te controleren. De penetratietest als activiteit kan dergelijke procedures initiëren.

geautomatiseerde informatiesystemen. 29 juli 2002. Aanwijzing A/882 Secretaris Generaal van het Ministerie van Defensie. [WAAR07] Waarschuwingsdienst tegen virussen, wormen en beveiligingslekken (software), onderdeel van GOVCERT.NL, april 2007. ( http://www. waarschuwingsdienst.nl/)

De aard van de bewijsvoering is ‘hard’. Dit heeft tot gevolg dat fase van hoor- en wederhoor eerder leidt tot het geven van een toelichting door de verantwoordelijke functionarissen over voorgenomen verbeteringen, dan het bijstellen van bevindingen. Tijdens de presentatie van de resultaten moet de IT auditor ervoor waken niet in de (verleidelijke) valkuil te trappen om al te zeer in te gaan op het uitleggen van de gebruikte technieken. Het zijn de blootgelegde risico’s die tellen. Sommige risico’s vragen hierbij wel om enige relativering omdat de organisatie zich daartegen slecht kan wapenen, zoals nieuwe fouten (bugs) in componenten. Een aspect dat in dit artikel niet is behandeld, is de juridische implicatie van penetratietesten. Het gehele spectrum van aansprakelijkheid, wet bescherming persoonsgegevens (WBP) en de wet computercriminaliteit (WCC) kan mogelijk beperkend werken op de uitvoering van penetratietesten. Of deze regelgeving voor onze red teaming onderzoeken mogelijk nog gevolgen heeft, is op dit moment niet geheel duidelijk en vergt onze aandacht. De tijd staat niet stil. Sinds onze inventarisatie, het inrichten en toepassen van de methodiek is er het een en ander aan ontwikkelingen geweest op het gebied van penetratiestesting. Een belangrijke bron voor geïnteresseerden is ISECOM, met de Open Source Security Testing Methodology Manual [OSST07] . In een vervolg op dit artikel gaan we dieper in op (delen van) het in de praktijk toepassen van penetratietesten. Noot 1 Ook [NIST03] koppelt het testen van beveiliging aan het system development life cycle model. In alle fasen kunnen beveiligingstests plaatsvinden. Referenties [MICR07] Microsoft Security Advisories, april 2007 (http://www.microsoft. com/technet/security/advisory/default.mspx) [NIST03] Guideline on Network Security Testing. Recommendations of the National Institute of Standards and Technology. NIST Special Publication 800-42, oktober 2003. [NOREA02] NOREA studierapport nr. 2: Een kwaliteitsmodel voor register EDP-auditors. Juli 1997. [OSST07] Open-Source Security Testing Methodology Manual. versie 2.2, December 2006. (http://www.isecom.org/osstmm/) [RUSS02] Hack proofing your network., Ryan Russel e.a., Syngress, maart 2002. ISBN: 1-928994-15-6. Opgevolgd door digitale versie d.d. 6 april 2006. [SGAA02] Testen beveiliging informatievoorziening door binnendringen in


Artikel. Red en green teaming bij Defensie (deel I) Een methodiek voor preventieve, testgerichte beveiligingsaudits (penetratietesten)

Recommend Documents