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 doeltreffende oplossingen te vinden.
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. Vulnerability-scanners 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-vulnerability-scanners 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 efficiënt mogelijk moet zijn. Daarom moet je de scope zo duidelijk mogelijk worden definiëren en potentiële 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 vulnerability-scanner 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 social-engineering, 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, heeft 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 real-world attack.
Bojan Zdrjnja
Bojan Zdrnja is SANS Certified Instructor en CTO van INFIGO IS. Voor meer informatie zie de SANS-website (sans.org/trainwithSANS).
