WINDOWS VERKENNER
Door de complexiteit van hedendaagse IT-omgevingen komt er heel wat kijken bij het beheer van kwetsbaarheden. Het uitvoeren van veiligheids-assessments is een populaire methode om bestaande kwetsbaarheden te identificeren en doeltre ende oplossingen te vi
Windows beschermt verschillende onderdelen tegen toegang door onbevoegden. Daar kun je gebruik van maken, als je tenminste weet hoe. Verkenner laat standaard echter niet alles zien zoals het écht op je schijf staat. Maar met de juiste aanpassingen krijg je meer informatie en meer overzicht.
Windows beschermt bestanden, mappen en veel andere objecten van het besturingssysteem tegen toegang door onbevoegden. Als je weet hoe dat systeem werkt en is opgebouwd, kun je daar zelf ook gebruik van maken.
Misschien heb je wel eens geprobeerd om onder Windows een bestand op te slaan of te verwijderen en kreeg je een foutmelding die erop neerkwam dat je onvoldoende rechten had om dat te doen. Toch gebruikte je een administrator-account waarmee je eigenlijk verwacht alle rechten te hebben. Afhankelijk van hoe je het bekijkt, geldt dat helaas – of juist gelukkig – niet altijd, bijvoorbeeld bij systeembestanden.
Als het niet om een systeembestand in de Windows-map gaat, dan kun je die foutmelding doorgaans op twee manieren omzeilen. De eerste mogelijkheid is ervoor zorgen dat je echt administratorrechten hebt. Een andere mogelijkheid is het aanpassen van de beveiligingsinstellingen van de betreffende map of het betreffende bestand. Om dat te doen, open je de
Eigenschappen via Verkenner, ga je naar het tabblad Beveiliging en klik je op Bewerken. Daar kun je dan je eigen gebruikersaccount toevoegen aan de lijst met gebruikers. Als je account al op de lijst staat, hoef je alleen onder Toestaan een vinkje achter de gewenste machtiging te zetten. Bij systeembestanden werkt dat met beide manieren vaak niet. Dat is meestal ook beter zo, omdat je door het achteloos aanpassen van de rechten snel beveiligingslekken introduceert.
Wil je de beveiligingsinstellingen van je systeem en de daardoor beheerde bestanden, mappen en andere objecten toch aanpassen, dan moet je weten wat er achter de schermen gebeurt. In dit artikel leggen we de belangrijkste onderdelen uit van de beveiligingsmechanismen in Windows 10.
OBJECTBEVEILIGING
Bijna alle door het besturingssysteem beheerde objecten zijn onder Windows via toegangsrechten beveiligd. Het bijbehorende mechanisme heet Discretionary Access Control (DAC), wat vertaald zoiets is als ‘door gebruiker bepaalde toegangscontrole’. Bij elke bewerking op een beveiligd object wordt gecontroleerd of de betreffende gebruiker die überhaupt eigenlijk wel mag uitvoeren.
De objecten die op die manier worden beheerd omvatten behalve bestanden en mappen onder andere registersleutels, printers en gedeelde mappen, maar ook systeemobjecten zoals processen, services, gedeelde geheugenbereiken en bureaubladen. Dat is niet bij alle objecten zo duidelijk merkbaar als bij bestanden en mappen. Behalve via dialoogvensters in Verkenner wordt de toegang tot objecten verder
alleen via dialoogvensters geregeld in de Register-editor, voor toegang tot sleutels.
Technisch gezien is het niet het gebruikersaccount dat bepaalt of een bepaalde actie is toegestaan, maar het proces dat de bewerking aanvraagt – om precies te zijn de actieve thread binnen dat proces. Daar maakt Windows bij elke aanmelding een zogeheten access-token voor aan. Dat bevat onder andere een ID voor de gebruiker en een lijst met alle gebruikersgroepen waar hij lid van is. Het systeem hangt dat token aan het eerste proces dat na het aanmelden vanuit de betreffende gebruiker gestart wordt. Normaliter is dat de toepassing userinit.exe. Die start gewoonlijk ook direct of indirect alle andere gebruikersprocessen. Vanaf dat moment erft elk nieuw gestart proces de access-token van de bron, als tenminste een opdracht zoals ‘Uitvoeren als’ of een ander mechanisme dat niet wijzigt. Standaard geven processen de access-token ook door aan de threads die ze genereren.
Objecten die via gebruikersrechten zijn beveiligd, zoals bestanden, registersleutels, processen enzovoort, hebben gemeen dat ze een zogeheten Security Descriptor hebben. De belangrijkste elementen van die datastructuur zijn een verwijzing naar de eigenaar van het object en een lijst met toegangsrechten. Die Discretionary Access Control List (of kortweg DACL) bevat de toegangsrechten voor het object. Elk item bestaat zelf weer uit een gebruikers- of groepsverwijzing, een lijst van rechten en een vlag die bepaalt of het account die rechten krijgt toegewezen (Allow) of wordt ontnomen (Deny).
De mogelijke rechten hangen af van wat voor acties met het object mogelijk zijn. Bestanden kun je bijvoorbeeld lezen, uitvoeren, wijzigen of verwijderen, processen kun je onderbreken, hervatten of beëindigen enzovoort. Het lezen en wijzigen van rechten wordt weer beschermd door andere rechten. Als een thread een beveiligd object wil benaderen, gaat Windows de vermeldingen in de DACL één voor één af en vergelijkt de daarin bewaarde ID met degene die is opgeslagen in de access-token van de thread. Als daarbij een Deny-regel voor de gevraagde bewerking wordt gevonden die betrekking heeft op het account in de access-token, wordt de vergelijking gestopt en de toegang geweigerd. In geval van conflicten heeft een Deny-regel dus voorrang op een Allow-regel voor de gewenste toegang. Alleen als voor de benodigde rechten een expliciete toestemming is gevonden, staat Windows de benadering toe.
ID’S
Als het om toegangsrechten gaat, identificeert Windows gebruikers, groepen en andere accounts niet aan de hand van namen, maar via een SID. Die afkorting staat voor Security IDentifier. Een SID voor een gebruikersaccount is doorgaans een lange cijferreeks in de vorm van S-1-5-21-1234567890-123456789-1234567890-1001
De prefix S geeft daarbij aan dat het om een SID gaat, de 1 is het (tot nu toe enige) revisienummer ervan. De 5 duidt erop dat het om een beveiligingskenmerk van Windows gaat. Andere waarden die je daar onder meer tegen kunt komen zijn 1 voor globale SID’s en 16 voor vertrouwensniveaus (waarover verderop meer). De volgende vier getallen zijn een wereldwijd unieke identificatie voor een Windows-installatie (voor zover we weten) en zijn hetzelfde bij alle SID’s die op dat systeem gemaakt zijn. Het laatste getal is een volgnummer voor de op een pc of in een domein gemaakte gebruikers- en groepsaccounts. Het eerste account krijgt het getal 1001. Bij lagere getallen gaat het om ingebouwde lokale accounts. Bij het lokale administratoraccount hoort bijvoorbeeld het getal 500, bij het gastaccount hoort 501. Of een SID bij een gebruiker of een groep hoort, kun je aan het getal niet zien.
Behalve specifieke ID’s voor een installatie, zijn er ook globaal geldende SID’s. Zo heeft de gebruikersgroep Administrators op elk Windows-systeem de SID S-1-5-32-544. Bovendien is elke aangemelde gebruiker automatisch lid van de groep Iedereen (S-1-1-0). Als je lokaal jezelf aanmeldt en niet via een netwerk, hoor je bij de groep Lokaal (S-1-2-0). Ook de SID’s voor ingebouwde serviceaccounts zijn overal gelijk: dat zijn S-1-5-18 voor het account System, S-1-5-19 voor ‘Local service’ en S-1-5-20 voor ‘Network service’.
Een lijst van alle SID’s die bekend zijn op een systeem, inclusief de bijbehorende accounts, krijg je met het volgende PowerShell-commando: gcim Win32_Account | ft Name, SID
Als je alleen geïnteresseerd bent in de gebruikersaccounts, vervang je Win32_Account door Win32_ UserAccount. Een lijst van gebruikersgroepen vraag je op met Win32_Group.
Normaal gesproken heb je als gebruiker niets te maken met SID’s. Soms krijg je ze echter toch te zien, als je bijvoorbeeld een NTFS-schijf gebruikt vanuit meerdere Windows-installaties. Het maakt daarbij niet uit of het om een externe schijf gaat of een interne die je benadert vanuit parallelle Windows-installaties. In beide gevallen kan het gebeuren dat je bij de Eigenschappen van een bestand of map op het tabblad
Beveiliging tussen de groeps- en gebruikersnamen een vermelding vindt van het type ‘account onbekend (S-1-5-21- … )’. Dat account hoort dan bij een andere Windows-installatie. Als je niet via het lidmaatschap van een globaal gedefinieerde groep toegang hebt tot het bestand, kun je het vanuit dit systeem waarschijnlijk niet lezen of overschrijven.
Het helpt daarbij niet als je op beide systemen dezelfde gebruikersnaam en wachtwoord hebt, want de SID van de twee accounts is anders. Met administratorrechten kun je doorgaans wel je account op het huidige systeem de benodigde rechten geven. Het komt wel vaker voor dat bij de rechten van een bestand SID’s worden vermeld van verschillende systemen. Omgekeerd maakt het niet uit of de naam van een gebruikers- of groepsaccount achteraf wordt aangepast: de SID blijft daarbij hetzelfde.
De SID van je eigen gebruikersaccount waarmee je bent aangemeld, kun je achterhalen met het commando whoami /user via een Opdrachtprompt- of PowerShell-venster. Bij welke groepen dat account hoort, ontdek je met whoami /groups. De uitvoer wordt overzichtelijker als je met de parameter /fo list het lijstformaat specificeert.
PROCESSEN EN BETROUWBAARHEID
Eigenlijk toont de opdracht whoami niet de gebruikersof groeps-SID van de aangemelde gebruiker, maar die van het eigen proces. Daarom verschilt het resultaat ook een beetje als je het commando vanaf een normale prompt geeft of vanaf een met administratorrechten. Het whoami- proces erft namelijk de access-token van het oorspronkelijke proces, in dit geval Opdrachtprompt (cmd.exe). Dat de token er met administratorrechten anders uitziet dan zonder, is het werk van het Gebruikersaccountbeheer (kortweg UAC voor User Account Control).
Normaliter hebben processen alleen de rechten van een beperkte gebruiker, ook als ze worden gestart met een account dat lid is van de groep Administrators. Heeft een programma volledige toegang nodig, dan moet de gebruiker dat bevestigen door te klikken op een melding van het UAC. De enige uitzondering daarop zijn ingebouwde Windows-middelen om systeeminstellingen te wijzigen, zoals de Instellingen-app en Configuratiescherm. Die krijgen volledige toegang zonder extra bevestiging.
De normaal gebruikte access-token en die van een proces met volledige toegang verschillen van elkaar op diverse punten. Het meest opvallend is waarschijnlijk dat de gebruiker bij beperkte processen lid is van de groep ‘Verplicht niveau/Gemiddeld verplicht niveau’, terwijl dat bij administrators ‘Verplicht niveau/ Hoog verplicht niveau’ is. Die namen zijn in Nederlandstalige Windows-versies vertaald uit het Engels. Om te verduidelijken wat ermee wordt bedoeld, moet je weten dat Windows sinds Vista bij toegang tot beveiligde objecten behalve het al beschreven UAC ook nog een verplichte integriteitscontrole (Mandatory Integrity Check, MIC) uitvoert. Dat gebeurt zelfs vooraf. Hiervoor bevat de access-token van elk proces een speciale SID die het Integrity Level, oftewel het vertrouwensniveau aangeeft. Er zijn vijf van die niveaus: Untrusted, Low, Medium, High en System. Normale gebruikersprocessen draaien op het niveau Medium, administratorprocessen op High en services op System. De niveaus Untrusted en Low zijn we in het wild alleen tegengekomen bij browsers. Daarnaast is er nog het niveau AppContainer, dat Windows toewijst aan draaiende UWP-apps. Dat is qua niveau vergelijkbaar met Low.
Elk beveiligd object heeft in zijn Security Descriptor een Mandatory Label waarmee het betrouwbaarheidsniveau wordt aangeduid. Een proces kan alleen schrijftoegang krijgen tot objecten met hetzelfde of een lager niveau (No-Write-Up). Normale bestanden en mappen hebben het integriteitsniveau Medium. Dat geldt impliciet ook voor objecten die geen Mandatory Label hebben.
Een uitzondering zijn processen. Dat zijn namelijk niet alleen uitvoerende instanties met een eigen access-token, maar het zijn ook beveiligde objecten waartoe de toegang moet worden beperkt. Ze zijn daarom ook voorzien van een Security Descriptor, die bijvoorbeeld bepaalt door wie ze kunnen worden gepauzeerd, hervat of gestopt of wie er toegang tot het geheugenbereik krijgt. De MIC controleert al bij het lezen: de inhoud van het hoofdgeheugen is taboe voor processen met een laag vertrouwensniveau (No-Read
Up). De in de DACL vastgelegde rechten blijven desondanks echter gelden.
Zoals gezegd wordt de MIC vooral bij browsers gebruikt, die vaak meerdere processen tegelijk starten. Afhankelijk van welk proces verantwoordelijk is voor het verwerken van code van internet, draait het met het vertrouwensniveau Low – bij Chrome zelfs Untrusted. Daarmee hebben ze in elk geval geen schrijftoegang tot bijna alle bestanden en mappen. Niet vertrouwde code van internet kan dus standaard geen lokale systeeminstellingen wijzigen en geen gebruikersbestanden manipuleren of verwijderen. Om ervoor te zorgen dat de browser toch een cache kan bijhouden of cookies kan bewaren, bevat de map %UserProfile%\AppData de submap LocalLow. Die map heeft slechts het niveau Low en daardoor kunnen browserprocessen met dat niveau er wel in schrijven.
Het vertrouwensniveau van actieve processen kun je bijvoorbeeld bekijken met de tool Process Explorer van Microsofts Sysinternals (zie de link op de laatste pagina van dit artikel). Op de lijst van processen klik je met de rechtermuisknop op een kolomkop en kies je de opdracht ‘Select Columns’. In het dialoogvenster dat opent, activeer je op het tabblad ‘Process Image’ het vinkje ‘Integrity Level’.
Een andere tool uit de Sysinternals Suite is in staat om de Integrity Labels van bestanden, mappen, registersleutels en enkele andere objecten te tonen. Die tool werkt niet grafisch maar vanaf de Opdrachtprompt. Het gaat om het programma accesschk. Een beschrijving van de zeer uitgebreide mogelijkheden ervan voert te ver, maar met accesschk -? kun je alle opties laten weergeven.
HOGER NIVEAU
Ook al lijkt het vertrouwensniveau het meest in het oog springende verschil tussen een proces met beperkte en met administratorrechten, het is in de meeste gevallen niet het belangrijkst. Dat in programmamappen bijvoorbeeld alleen administratorprocessen schrijftoegang hebben, heeft een andere oorzaak. Kijk je in beide gevallen naar de uitvoer van whoami /groups, dan zie je als gebruiker met administratorrechten de groep ‘INGEBOUWD\Administrators’ met daarnaast als attributes ‘Mandatory group, Enabled by default, Enabled group, Owner’. In andere gevallen ontbreekt die groep of staat er ‘Group used for deny only’. In het eerste geval wordt het lidmaatschap van de groep gebruikt om alle regels bij de DACL-items te controleren, in het laatste geval alleen de Deny-regels. Je kunt als beperkte gebruiker dan ook niet schrijven in de programmamap omdat de regel die administrators toegang geeft helemaal niet wordt gecontroleerd. Dan krijg je dus ook geen toegang.
Waarom maakt Windows het zo ingewikkeld en wordt het lidmaatschap van de groep Administrators niet gewoon weggelaten in de security tokens van processen die door een lid van die groep worden gestart met beperkte rechten? Omdat dan het vreemde geval zich zou kunnen voordoen, dat een beperkt proces meer rechten heeft dan een proces met hoger vertrouwensniveau, namelijk als er een regel wordt gevonden die de groep administrators expliciet toegang geeft tot een bepaald object.
Als je benieuwd bent naar de inhoud van access-tokens van allerlei processen, kun je die bekijken met de al genoemde Process Explorer. Dubbelklik op een proces voor de eigenschappen. De access-token staat dan op het tabblad Security. Om kenmerken (flags) zoals ‘Mandatory’ en ‘Deny only’ op de lijst met groepen te zien, moet je naar links scrollen of het venster een stuk breder maken.
PRIVILEGES
Access-tokens bevatten behalve de SID’s van de betreffende gebruikersaccounts en de bijbehorende groepen ook zogeheten privileges. Daarmee regelt Windows niet de toegang tot afzonderlijke objecten, maar bepaalt het wie bepaalde acties binnen het besturingssysteem mag uitvoeren. Denk daarbij bijvoorbeeld aan het wijzigen van de systeemtijd, het debuggen van actieve programma’s of het afsluiten van de pc. Ook de lijst van privileges is anders voor processen die door leden van de administratorsgroep worden gestart met beperkte rechten dan wanneer ze worden gestart met volledige toegang. Je kunt dat controleren met het consolecommando whoami /all of op het tabblad Security van het Properties-venster in Process Explorer.
Een van de privileges van administrators is het recht om eigenaar te worden van een willekeurig beveiligd object ( SeTakeOwnership). Op die manier kunnen beheerders toegang krijgen tot objecten waar ze eigenlijk geen toegang toe hebben, bijvoorbeeld schrijfrechten voor systeembestanden in de Windows-map. Dat is echter alleen in heel speciale gevallen zinvol. Bovendien moet je daarbij heel erg voorzichtig te werk gaan, anders introduceer je veiligheidslekken die bijvoorbeeld door malware gebruikt kunnen worden om het systeem binnen te dringen. Met Windows Verkenner kun je overigens niets aanvangen op dit punt, want dat draait altijd met beperkte rechten. Je hebt een alternatieve bestandsbeheerder nodig (zie het vorige c’t-nummer) die met administratorrechten kan draaien. Als noodoplossing
kun je een met administratorrechten gestart Kladblok (notepad.exe) gebruiken. Het Openen-venster van dat programma kan dan dienen als nood-Verkenner als je daarin het bestandstype wijzigt van ‘Tekstdocumenten (*.txt)’ in ‘Alle bestanden (*.*)’.
Het eigenaarschap van een bestand of map kun je overnemen door in het bijbehorende eigenschappenvenster naar het tabblad Beveiliging te gaan. Klik daar op Geavanceerd en vervolgens bovenin het venster naast Eigenaar op Wijzigen. Om typfouten te vermijden, kun je daarna niet meteen de naam typen van het gebruikersaccount. In plaats daarvan klik je op Geavanceerd en daarna op ‘Nu zoeken’ om de gebruikersnaam in een lijst te selecteren. Wil je de rechten vervolgens aanpassen, dan moet je eerst alle geopende vensters met OK sluiten en opnieuw het eigenschappenvenster van bestand of map openen.
Wie op een systeem welke privileges heeft, kan worden geconfigureerd via het lokale beveiligingsbeleid. Bij de Home-editie van Windows kun je daar normaal gesproken niet bij. De bijbehorende groepsbeleid-editor is eenvoudigweg niet aanwezig. Handige knutselaars hebben echter een manier gevonden om die tool toe te voegen aan Windows 10 Home. Via de link op deze pagina kun je de ‘GPEdit Enabler for Windows 10 Home Edition’ downloaden. Dat is een klein batchbestand dat enkele wel aanwezige, maar niet geïnstalleerde systeemcomponenten opspoort in de krochten van de Windows-mappen en die met de tool dism integreert in het systeem. Dat werkte bij ons wel, maar garanties kunnen we niet geven.
Of het ook nog werkt na een feature-upgrade van Windows is de vraag. Sowieso zul je het batchbestand na zo’n upgrade waarschijnlijk opnieuw moeten uitvoeren. Het risico dat je daar malware mee binnenhaalt is echter niet aanwezig, want de tool laadt geen uitvoerbare bestanden.
Je start de groepsbeleid-editor met de opdracht gpedit.msc op een opdrachtprompt of in het Uitvoeren-venster dat je oproept met Windows+R. De privileges voor gebruikers staan bij de editor onder ‘Computerconfiguratie / Windows-instellingen / Beveiligingsinstellingen / Lokaal beleid / Toewijzing van gebruikersrechten’. Het aanpassen daarvan vereist administratorrechten. Het is niet verstandig om de standaardprivileges in Windows te verwijderen, omdat dat ongewenste bijwerkingen kan hebben. Het enthousiast toevoegen van hele gebruikersgroepen voor bepaalde privileges raden we ook af. Dat kan veiligheidslekken introduceren.
Maar als je bijvoorbeeld graag werkt met symbolische koppelingen in een bestandssysteem, kun je voor je eigen gebruikersaccount het privilege ‘Symbolische koppelingen maken’ toevoegen, zodat je niet steeds een administratorprompt hoeft te gebruiken om symlinks te maken. Wijzigingen in een account worden pas van kracht na het afmelden en opnieuw aanmelden van het account.
NIET OVERDRIJVEN!
We hebben het al aangegeven: bij de instellingen voor de rechten hebben de ontwikkelaars van Windows bewust bepaalde keuzes gemaakt. Elke aanpassing in de rechten voor systeembestanden en andere objecten moet je grondig overwegen. Je kunt er namelijk ongewenste bijwerkingen mee veroorzaken. Dat kan variëren van veiligheidslekken tot het onbruikbaar maken van bepaalde functionaliteit. Met kennis van hoe de veiligheidsmechanismen werken kun je dergelijke beslissingen in elk geval beter overwegen.
Besluiten welk veiligheids-assessment je uitvoert hangt er vanaf hoe volwassen het veiligheidsbeleid van een organisatie is. De beste resultaten haal je door de volgende drie populaire assessmentmethoden uit te voeren: vulnerability-scanning, penetration-testing en red-teaming.
VULNERABILITY-SCANNING
Vulnerability-scanning zou elke organisatie regelmatig moeten uitvoeren. Dit is de eerste en meest basale test bij het beheer van kwetsbaarheden. Het doel is om bekende kwetsbaarheden, fouten in de configuratie en zwakke plekken op te sporen. Vulnerabilityscanners inventariseren de status van patches en controleren of accounts correct zijn geconfigureerd. Moderne scanners kunnen ook authentiseren door data te vergelijken met de gegevens van doelsystemen (inlog). Daarmee kan een scanner geïnstalleerde patches inventariseren en de informatie correleren met de verkregen data uit een scan, zodat valspositieve rapporten kunnen worden beperkt.
De meest bekende netwerk-vulnerabilityscanners zijn Rapid7 Nexpose, Tenable Nessus en Qualys. Er zijn ook gespecialiseerde tools voor scannen op applicatieniveau.
PENETRATION-TESTING
De volgende stap zou penetration-testing of pentests moeten zijn. Het doel hierbij is om alle (of zoveel mogelijk) kwetsbaarheden in een zogenaamde target-scope te vinden. Het is belangrijk die goed vast te stellen. De target-scope kan bestaan uit een set ip-adressen of netwerken (network-penetration-test), een webapplicatie of webservices.
Aangezien een pentest veel tijd in beslag kan nemen (zo'n 5-15 dagen) spreekt het voor zich dat het proces zo e iciënt mogelijk moet zijn. Daarom moet je de scope zo duidelijk mogelijk worden definiëren en potentiele obstakels verwijderen. Als je bijvoorbeeld een mobiele applicatietest, is het handig om een build zonder obfuscatie te gebruiken, zodat je geen tijd verdoet aan deobfuscatie.
Bovendien zal een pentest ook zoeken naar kwetsbaarheden die een vulnerabilityscanner niet kan vinden, zoals logische kwetsbaarheden. Het is praktisch onmogelijk voor een vulnerability-scanner om zakelijk logische kwetsbaarheden te vinden, terwijl de gevolgen groot kunnen zijn. Neem een bank met een applicatie voor internetbankieren. Een aanvaller voert bijvoorbeeld een transactie van -100 euro uit. Het gevolg is dat hij 100 euro krijgt in plaats van dat dit wordt afgeschreven. Een andere veelvoorkomende categorie van kwetsbaarheden is de Direct Object Reference (DOR). Hierbij probeert een aanvaller objecten te benaderen (zoals transactiegegevens) van willekeurige gebruikers door objectreferenties te wijzigen. Omdat die vaak alleen uit cijfers bestaan (ID’s), is het wijzigen daarvan eenvoudig. Alleen detecteren veel scanners zulke kwetsbaarheden niet, omdat ze de context niet begrijpen. Ze zien niet dat een gewijzigde ID waarmee je transacties van andere gebruikers kunt oproepen in feite een kritieke kwetsbaarheid is.
Het resultaat van een penetration-test is een rapport dat alle geïdentificeerde kwetsbaarheden omvat, met adviezen hoe je ze kunt verhelpen. De penetration-tester zou alle genoemde kwetsbaarheden moeten verifiëren – je wilt geen valspositieven!
Pentests vereisen veel handmatig werk. Daarom kosten ze ook veel tijd en zijn ze over het algemeen kostbaarder dan een vulnerabilityassessment.
RED-TEAMING
Een red-team-oefening is de ultieme test. Bij een red-team-oefening handelt één team als aanvaller. Dit team krijgt een specifiek doel en mag dat op elke gewenste manier proberen te bereiken. Dat kan het schrijven zijn van nieuwe exploits, het toepassen van socialengineering, een laterale aanpak enzovoorts.
Het voornaamste verschil tussen een red-team-oefening en een penetration-test is dat je daarbij een ultiem doel stelt, terwijl het doel van een penetration-test is om alle kwetsbaarheden op te sporen (binnen een gedefinieerde scope). Een red-team-oefening zal mogelijk kwetsbaarheden over het hoofd zien en deze niet melden, maar biedt wel een duidelijke indicatie van hoe goed je bestand bent tegen een echte aanval. Een red-team-oefening is veelal een goede test van het blue team binnen een organisatie – het toont aan hoe goed dit team in staat is aanvallen te detecteren en ze af te weren terwijl de aanval plaatsvindt.
ONTWIKKELINGSFASE
Hoewel bovengenoemde het ideale proces is voor het managen van kwetsbaarheden, hangt de uiteindelijke keuze van welk security-assessment wordt toegepast mede af van de ontwikkelingsfase waarin de organisatie zich bevindt. Indien de doelorganisatie bijvoorbeeld niet regelmatig haar servers patcht, hee het geen zin om een penetratietest of red-team-oefening uit te voeren, omdat er geen basis securitybeleid is. Dat moet als eerste worden aangepakt. Pas wanneer de basisbeveiliging op orde is, is het zinvol om een geavanceerdere security-assessment uit te voeren.
Ook is het bijvoorbeeld zinvoller om een penetration-test uit te voeren op het moment dat een organisatie een nieuwe applicatie wil uitbrengen, omdat dan het doel is om alle kwetsbaarheden van de nieuwe applicatie te vinden. En als je de meerderheid van je services hebt getest, en over een getraind blue team beschikt, pas dan zal een red-team-oefening laten zien in welke mate je organisatie bestand is tegen een realworld attack.