Regelmatig vragen wij onze medewerkers om een stukje te schrijven over een bepaald onderwerp. Dit keer heeft één van onze pentesters zich gewaagd aan een blog over de definitie van pentesting. In dit blog worden de verschillen benadrukt tussen een vulnerability assessment en een penetratietest.
Inleiding
Ethische hackers kunnen organisaties helpen bij het inzichtelijk krijgen van potentiële risico’s door de identificatie van aanwezige kwetsbaarheden/zwakheden binnen een overeengekomen scope. Pentesting is een van de mogelijke vormen van een dergelijk assessment.
Helaas worden er in de markt verschillende definities toegepast. Dit heeft als gevolg dat testen door verschillende organisaties verschillend uitgevoerd kunnen worden. Offertes lijken misschien inhoudelijk op elkaar, maar het kan best appels met peren vergelijken zijn. Ook zijn de rapportages vaak inhoudelijk lastig vergelijkbaar door verschil in uitvoer.
Een vulnerability assessment is een fundamenteel andere dienst dan een pentest, maar veelal is er wel enige overlap, waardoor verwarring snel kan ontstaan. Diensten worden daarbij ook soms gecombineerd aangeboden. Om het nog makkelijker te maken zijn er ook nog verschillende testvormen bedacht (blackbox, whitebox, etc.). Deze bepalen hoeveel informatie en welk soort informatie (zoals bijvoorbeeld inloggegevens) vooraf worden gedeeld.
Gelukkig bestaan er wel (internationale) standaarden en handreikingen. Voorbeelden hiervan zijn: Open Source Security Testing Methodology Manual (OSSTMM), Penetration Testing Guidance van de PCI Security Standards Council, Penetration Testing Execution Standard (PTES) en NIST SP 800-115. Dit brengt echter ook uitdagingen met zich mee zoals geïllustreerd in de volgende xkcd comic:
Binnen Access42 hebben wij nog eens goed gekeken naar onze visie op deze diensten. Op hoofdlijnen hanteert Access42 de volgende definities:
Vulnerability Assessment
Bij een vulnerability assessment worden (bekende) kwetsbaarheden/zwakheden geïdentificeerd binnen alle toegankelijke diensten in de overeengekomen scope. Het assessment en de rapportage gaan dus in de breedte en blijven hierdoor oppervlakkig. Bevindingen wordt niet actief geëxploiteerd met het doel om (verder) binnen te dringen. Een dergelijk assessment bestaat uit geautomatiseerde scans (met bijvoorbeeld Nessus) in combinatie met handmatige verificatie (foutpositief reductie), maar zeker ook uit handmatige controles.
Afhankelijk van de wensen, wordt hierbij soms gekozen om beveiligingsmechanismes tijdelijk en doelgericht uit te schakelen om de achterliggende systemen te testen in plaats van de werking van de beveiligingsmechanismes zelf.
Pentesting
Bij een pentest worden ook kwetsbaarheden geïdentificeerd, maar hierbij wordt juist de diepte ingegaan met als doel onderzoeksvragen te beantwoorden. Dat wil zeggen, dat exploits actief worden gebruikt om (verder) binnen te dringen. Voor dit doel wordt ook gekeken of bevindingen gecombineerd ingezet kunnen worden (chaining). De identificatie van kwetsbaarheden aan de oppervlakte stopt zodra lateraal bewogen kan worden. Bevindingen die niet hebben bijgedragen aan het exploitatiepad worden niet (uitgebreid) gerapporteerd.
Deze dienst is het effectiefst als de organisatie een vulnerability managementproces heeft of al eerder security assessments heeft laten uitvoeren.
Verschillen
Belangrijke verschillen tussen de twee diensten zijn dus de balans tussen diepte/breedte en de aanwezigheid van een onderzoeksvraag. Een onderzoeksvraag als “Welke kwetsbaarheden zijn er vanuit ongeautoriseerd perspectief te identificeren“, kan de balans van een onderzoek echter verleggen naar een vulnerability assessment. Met heldere afspraken (over o.a. de gewenste balans) maakt het onder aan de streep niet uit voor welke vorm gekozen wordt. Het Nationaal Cyber Security Centrum (NCSC) heeft in 2020 een (vernieuwde) whitepaper over securitytesten gepubliceerd met handige tips. Zie: Whitepaper Securitytesten
Impopulaire opinie?
Bij het testen van websites en sommige webapplicaties is er vaak geen sprake van een pentest. Een aantal veelvoorkomende webgebaseerde kwetsbaarheden vereist bijvoorbeeld een vorm van social engineering voor succesvolle exploitatie. Denk hierbij aan Phising om credentials te verkrijgen. Dit valt vaak buiten de scope van de opdracht. Deze scope limitatie is begrijpelijk, omdat de opdrachtgever geen vrijwaring kan geven voor aanvallen op (externe) bezoekers van de website. Daarbij kan er ook sprake zijn van een gedeelde infrastructuur dat weer diverse andere aanvallen onwenselijk maakt. In de praktijk blijft het dan ook vaak bij de identificatie van kwetsbaarheden in de breedte. Soms dienen hierbij zelfs bepaalde checklists afgelopen te worden, denk bijvoorbeeld aan de DigiD audit. Hier lijkt de pentester soms in de huid te kruipen van de auditor terwijl de pentest in principe los staat van de audit (behalve de verplichting).
