Pentest voor een onderneming: wanneer, en wat moet hij echt dekken?

Een penetratietest wordt vaak gevraagd op het moment dat “de security moet gebeuren”: voor een livegang, na een incident, omdat een klant het eist, of omdat een scan een lange lijst teruggaf. De vraag is legitiem. Ze is slecht gesteld als u van de pentest verwacht dat hij een inventaris, een configuratiereview of het correctiewerk vervangt.

De pentest beantwoordt een precieze vraag. Binnen een reikwijdte die u hebt toegestaan, wat kan iemand die echt zoekt verkrijgen, en wat betekent dat voor de business? De rest — de ruwe lijst kwetsbaarheden, het beleid, de opvolging van patches — hoort bij andere oefeningen.

Pentest, kwetsbaarheidsscan, audit: dat is niet hetzelfde

Een scan bevraagt diensten en versies, en signaleert wat op een gekende kwetsbaarheid lijkt. Hij is nuttig om breed te dekken en om de oefening vaak te herhalen. Hij toont niet of het gebrek exploiteerbaar is in uw context, noch wat een keten van stappen kan bereiken.

Een audit vergelijkt wat er is met een referentie of met uw eigen regels: accounts, back-ups, logging, scheiding van omgevingen, rechten. Een groot deel kan op documenten en configuratie. Hij probeert niet binnen te raken.

Een pentest probeert. Binnen het geschreven kader zoekt een tester een pad: een applicatiefout, een zwakke scheiding, een blootgesteld geheim, een keten van te ruime rechten. Het resultaat dat telt is niet het aantal lijnen. Het is het scenario, het bewijs, en de impact als niemand corrigeert.

De drie verwarren geeft verkeerde verwachtingen. Een “rode” scan is geen mislukte pentest. Een pentest die alleen een matig gebrek vindt, was niet noodzakelijk te kort: hij kan hebben getoond dat het gemakkelijke pad er niet is. Dat geldt alleen als de reikwijdte de juiste was.

Wanneer een pentest relevant wordt

De test is de kost waard als het resultaat een beslissing of een volgorde van correcties kan veranderen. Enkele momenten komen terug:

• voor een blootgestelde livegang, eens de applicatie rechtstaat en de reikwijdte niet meer elke dag wijzigt;
• na een belangrijke wijziging: een nieuwe blootgestelde component, een herbouw van authenticatie, openstelling naar partners, samenvoegen van omgevingen;
• als het systeem al bereikbaar is van buitenaf, of vanuit een netwerk waar geprivilegieerde accounts circuleren;
• als een contract, een klant of een verzekeraar een bewijs vraagt van een test op een genoemde reikwijdte, op een genoemde datum;
• periodiek op systemen waarvan stilstand of een lek duur is, in een ritme dat aan die kritikaliteit hangt, niet aan een generieke kalender.

Hij is weinig nuttig heel vroeg, op een maquette die herschreven zal worden, of meteen na een scan waarvan niemand de evidente punten heeft behandeld. Corrigeer eerst wat een tool al toont, test daarna de keten. Dat gebruikt de testtijd beter.

De bredere vraag — wat beschermen, in welke volgorde, voorbij één test — is applicaties en infrastructuur beveiligen.

De reikwijdte bepalen

Zonder reikwijdte is er geen test. Er is een verkenning, en niemand kan zeggen of ze dekte wat telt.

Webapplicaties en API’s

Geauthenticeerde trajecten, niet alleen de startpagina. De echte rollen. De functies die een gegeven wijzigen of een betaling, een verzending, een goedkeuring uitlokken. De API’s zoals ze worden aangeroepen, ook die welke geen interface meer toont maar die nog antwoorden.

Infrastructuur

Extern: wat vanaf het internet bereikbaar is, inclusief testomgevingen die open zijn blijven staan. Intern: wat een post of een account dat al op het netwerk zit kan bereiken. De twee vervangen elkaar niet. Een gezonde applicatie achter een vlak netwerk blijft een probleem. Een zorgvuldig netwerk voor een applicatie die alles vertrouwt wat ze ontvangt ook.

Ter plaatse

Een fysieke passage, of een test op het lokale netwerk, is zinvol als het scenario dat u vreest begint met toegang tot de lokalen, een stopcontact of een toestel. Het is geen automatische aanvulling op een applicatiepentest. Het is een aparte opdracht, met eigen beperkingen: uren, begeleiding, zones die verboden zijn.

De reikwijdte sluit ook af met wat is uitgesloten. Een partner waarvoor u geen toestemming hebt. Een industrieel systeem waarvan stilstand niet aanvaardbaar is. De productie zelf, als u hebt gekozen ze niet aan te vallen. De uitsluiting moet even expliciet zijn als de inclusie.

Rules of engagement

De regels passen op enkele pagina’s, en ze moeten worden getekend door iemand die de organisatie mag verbinden:

• de expliciete toestemming, de reikwijdte, de data;
• de uren, en wat tijdens de werkdag verboden is;
• de technieken die mogen en die niet mogen: denial of service, social engineering, phishing van medewerkers, exploitatie die echte data zou wijzigen;
• de testaccounts die worden gegeven, en de accounts die niet mogen worden geviseerd;
• de contacten die tijdens de test bereikbaar zijn, inclusief een pad als er iets breekt;
• hoe u stopt als er tegelijk een echt incident wordt gemeld;
• wat er gebeurt met data die eventueel worden gezien: bewaring, versleuteling, vernietiging op het einde van de opdracht.

Die regels beschermen beide kanten. De tester weet hoe ver te gaan. De organisatie weet wat werd toegelaten, en kan een testalert onderscheiden van een alert die er geen is.

Productie of een aparte omgeving?

Testen in productie toont de echte configuratie, de data zoals ze blootstaan, en de vergetelheden die een propere kopie niet heeft. Het risico is een dienst te verstoren, accounts te vergrendelen, of een gegeven aan te raken dat niet mocht worden aangeraakt.

Testen op een aparte omgeving beperkt dat risico. Ze is alleen iets waard als die omgeving nog op productie lijkt: dezelfde versies, dezelfde rollen, dezelfde integraties die tellen, realistische data die niet de echte data zijn. Een kopie van zes maanden oud, of een sandbox zonder de blootgestelde component, stelt gerust zonder te concluderen.

Een frequent compromis is een verdeling. Niet-destructieve controles op productie — configuratie, headers, authenticatie, blootstelling — en diepere pogingen op een apart doel waarvan u de afwijking hebt gecontroleerd. Het rapport moet zeggen waar elke vaststelling is verkregen. Een gebrek dat alleen op de kopie is gezien, heeft niet dezelfde status als een gebrek in productie, zolang het verschil niet is uitgelegd.

Het dagelijkse beheer van die omgevingen — wie deployt, wie bewaakt, wie toegangen scheidt — hoort bij cloud en beheer evenzeer als bij de test. Een pentest herstelt geen deployment die niemand kan reproduceren.

Wat het rapport moet mogelijk maken

Een rapport dat fouten opsomt zonder pad naar een correctie wordt opgeborgen. Voor elke vaststelling die telt, moet de lezer kunnen:

• het scenario in één lezing begrijpen, zonder een tool uit elkaar te halen;
• een bewijs zien dat precies genoeg is om de correctie te reproduceren, niet precies genoeg om als publieke handleiding te dienen;
• de impact in zijn context beoordelen, niet alleen een generieke score;
• weten welke correctie het pad sluit, en welke alleen een stap hinderen;
• het werk ordenen: wat nu blootstaat, wat op een evolutie wacht, wat nuttige verharding is maar secundair.

De prioriteit is een gesprek. Een “kritiek” gebrek op een component die onbereikbaar is, is niet de eerste correctie. Een matig gebrek dat klantdossiers vanaf het internet opent, wel. Het rapport moet de elementen van dat oordeel geven, het niet in beslag nemen.

Na het rapport: remediëring en hertest

De test stopt bij de vaststelling. De waarde zit in wat daarna verandert. Elk punt dat u bijhoudt heeft een verantwoordelijke, een termijn gekoppeld aan de blootstelling, en een bewijs van correctie. “We hebben geüpdatet” is een bewijs alleen als het geteste pad niet meer werkt.

De hertest dekt de aangekondigde correcties, niet een nieuwe reikwijdte die onderweg wordt binnengesmokkeld. Hij bevestigt dat het scenario dicht is, en hij signaleert als de correctie een ander heeft geopend. Punten die u niet hebt opgenomen blijven open. Ze verzwijgen in de volgende versie van het rapport geeft een indruk van vooruitgang die er niet was.

Tussen twee tests nemen de scan en de configuratiereview hun rol terug. Ze vangen de gewone drift. De volgende pentest vertrekt van een systeem dat bewogen heeft, in plaats van dezelfde deuren terug te vinden.

Cybersecurity en penetratietesten dekken die reeks: het kader van de test, de uitvoering, een rapport waar u iets mee kunt, en daarna begeleiding van de correctie. Een test zonder vervolg is een document. Een vervolg zonder test is een lijst intenties.

En de Red Team?

Een Red Team-opdracht is geen grotere pentest. De pentest zoekt wat zwak is in een gekende reikwijdte, met de medewerking van de teams die het systeem uitbaten. De Red Team streeft een doel na — een gegeven, een proces, een recht bereiken — over een langere duur, en meet ook of detectie en respons werken.

De regels zijn er nog strenger, omdat niet elk verdedigend team op de hoogte is, en omdat het scenario meerdere systemen kan kruisen. Het is niet de eerste oefening van een organisatie die de resultaten van een scan en een gerichte pentest nog niet heeft verwerkt. Het wordt nuttig als de basis houdt en de vraag wordt: zouden we een aanval zien die haar tijd neemt?

De juiste volgende stap is zelden “de grootste test die beschikbaar is”. Het is de test waarvan de reikwijdte overeenkomt met het risico dat u wilt verkleinen, met een duidelijke toestemming, en een rapport waarvan iemand een volgorde van correcties kan maken.