Security (b)log: pentest

vrijdag 12 januari 2024

Regenboog

Afbeelding via Pixabay

In de krant stond laatst een artikel over gepantserde personenauto’s. Of liever: over de ‘best beveiligde personenauto ter wereld’. Door alle extra’s weegt het gevaarte zo’n 4.500 kg, waardoor je hem niet met een gewoon B-rijbewijs mag besturen. Een deel van het gewicht zit ‘m in de tot tien centimeter dikke ruiten. Maar er komt natuurlijk ook best wel dik staal aan te pas. Alleen al de portieren wegen 200 kg. Per stuk wel te verstaan. De auto wordt in het Duitse Sindelfingen gemaakt en heet Mercedes S680 Guard.

Maar wees gerust, dit is na de jaarwisseling niet opeens een autoblog geworden. Nee, de trigger om naar aanleiding van dat krantenartikel een blog te schrijven was een Duits woord uit dat artikel: Beschussamt. De kans bestaat dat je niet eens weet hoe je dat uitspreekt (buhsjoes-amt), laat staan wat het betekent. Laten we achteraan beginnen: een ‘Amt’ is zoveel als een dienst of autoriteit. En ‘Beschuss’, dat is beschieting. Je komt dan dus in een letterlijke vertaling uit op zoiets als ‘beschietingsdienst’. De krant vond een nettere vertaling: vuurwapenautoriteit.

Wat heeft een vuurwapenautoriteit te maken met auto’s? Nou, mijn eigen vertaling was wat dat betreft zo gek nog niet: ze schieten letterlijk op die auto’s. Want zo’n auto wil natuurlijk gecertificeerd worden, en die certificering krijg je uiteraard niet omdat in de folder staat dat het voertuig bestand is tegen kogels uit een Kalasjnikov. Dat willen ze bij het Beschussamt wel eens zien, en bovendien bestaan er formele normen voor de beschermingsfactor van een auto. En daarom schieten ze hun wapens leeg op zo’n auto en onderzoeken ze vervolgens wat ze hebben aangericht.

Ik kan nu twee kanten op met m’n blog: ik kan het over certificering gaan hebben, maar ik kan het ook over testen hebben. Weet je wat, we doen dat tweede; gewoon omdat dat leuker is. Bij die auto’s kunnen de kogels van twee kanten komen: van de good guys (het Beschussamt) en van de bad guys (iedereen waartegen degene, die met zo’n auto wordt vervoerd, zich wil beschermen). Je kunt op vergelijkbare wijze naar ICT-systemen kijken. Weliswaar worden daar doorgaans niet letterlijk kogels op afgeschoten, maar er zijn wel twee partijen die geïnteresseerd zijn in de weerstand die het systeem biedt. Aan de goede kant hebben we de eigenaar van het systeem, en aan de foute kant iedereen waartegen die eigenaar zijn systeem wil beschermen.

Maar wacht eens even; er zijn nog meer partijen aan de goede kant. Er is namelijk ook nog een heel leger vrijwilligers die op zoek gaan naar zwaktes in systemen en die, indien gevonden, braaf aan de eigenaar melden, zonder misbruik te maken van de gevonden kwetsbaarheid. Ze worden van oudsher white hat hackers genoemd, naar analogie met de kleur van de hoeden van de goeieriken in spaghettiwesterns. Een modernere term daarvoor is overigens ‘ethisch hacker’. Hoe je ze ook noemt, deze mensen kunnen geheel zonder medeweten van de eigenaar van een systeem proberen om dat systeem binnen te dringen.

Een systeemeigenaar kan natuurlijk ook zelf opdracht geven om zijn systeem aan de tand te voelen. Dat kan hij door eigen medewerkers laten uitvoeren, maar er is ook een hele industrie ontstaan rondom het testen van systemen: je kunt ethische hackers gewoon inhuren (al is het erg prettig en zinvol om er zelf een paar rond te hebben lopen). Wie het ook doet, ze voeren een zogeheten pentest uit. Dat heeft niets met schrijfwaren te maken, maar is de afkorting van penetratietest – ze proberen om je systeem binnen te dringen. Je komt ook wel de benaming A&P-test tegen; dat staat dan weer voor attack & penetration – dat het bij een pentest om een aanval gaat is wel duidelijk.

Daarbij kun je van tevoren afspreken wat hun startpunt is: krijgen ze vooraf vrijwel niets, krijgen ze wat meer informatie en een account, of krijgen ze misschien zelfs volledige toegang en technische en ontwerpinformatie? Zoals alles in dit leven zijn ook de pentesten er in kleurtjes: de eerste noemen we black box (het te testen systeem is grotendeels een zwarte doos voor de hacker, hij weet dus niks en kan niks), de tweede is een grey box pentest en de laatste heet white box of – veel mooier maar geen kleur – crystal box. Waarom zou je die laatste doen? Daar is toch geen bal aan, als de hacker alles al weet én gratis toegang krijgt? Het idee daarachter is dat het systeem getest wordt met kennis die een kwaadwillende buitenstaander niet heeft. Dat kan dus wel degelijk zinvol zijn.

Er zijn nog meer kleurtjes, die worden gebruikt bij het houden van oefeningen. De aanvallers zitten in het red team, de verdedigers in het blue team. En dan is er nog een mengvorm die, jawel, purple team heet; in die samenstelling leren aanvallers en verdedigers van elkaar. Tijdens zo’n oefening kan het red team bijvoorbeeld een crystal box pentest uitvoeren, die hopelijk door het blue team gezien en afgeweerd wordt, waarna ze als purple team bespreken wat ze tegenkwamen. Je ziet het, de industrie heeft een mooie set voor buitenstaanders onbegrijpelijke termen weten te bedenken. En dan heb ik niet eens alle kleuren en alle aspecten belicht.

En in de grote boze buitenwereld …

vrijdag 4 februari 2022

Zelftest

Afbeelding via Pixabay

Een jeugdig familielid heeft momenteel een moeizame verhouding met het testwezen. Als brave scholier doet hij tweemaal per week een zelftest en deze week was het raak: twee streepjes.

Het gezin was even in rep en roer, want dit hadden ze in twee jaar corona nog niet meegemaakt. Welke maatregelen moeten er allemaal getroffen worden? Wie moeten er ingelicht worden? En vooral gauw de officiële test bij de GGD regelen! Nou, dat laatste was een heel gedoe: de GGD zat vol en hij werd doorverwezen naar een commerciële teststraat een stad verderop. Daar kon hij gek genoeg op dezelfde dag nog terecht, wanneer hij maar wilde. Toen hij daar geweest was, werd duidelijk waarom deze teststraat misschien wat minder populair was: ze voerden een sneltest uit en dat deden ze erg slordig. De uitslag was negatief, maar dat vertrouwde deze jongeman niet en daarom deed hij thuis ook nog een zelftest. Hé, ook negatief!

De volgende ochtend voor de zekerheid nog maar een zelftest gedaan. En wat denk je: positief! Dat gezin wist even niet meer waar ze aan toe waren. De geraadpleegde assistente van de huisarts adviseerde, na het aanhoren van het relaas, om toch maar nog een test bij de GGD zelf te doen. Met de kanttekening dat zelftests zelden een false positive geven, met andere woorden: ga er maar van uit dat je corona hebt. ’s Avonds kon de patiënt – die gelukkig slechts milde klachten had – terecht bij de GGD op ruim een halfuur rijden van zijn woonplaats. De uitslag liet een etmaal op zich wachten. Niemand was verbaasd dat die positief was.

Als ICT’er heb ik moeite met dergelijke inconsistenties. Hoewel, ik heb lang geleden al geleerd dat zelfs computers niet altijd consequent zijn. Dertig jaar geleden programmeerde ik in COBOL op het mainframe. Eén van de programma’s, die ik onder mijn hoede had, was het zogenaamde dagwerk, dat – gek genoeg – ’s nachts werd gedraaid (het was batchverwerking; alle invoer van die dag werd ’s nachts in bulk verwerkt). Op een zekere dag ging ’s avonds laat de telefoon: het dagwerk was vastgelopen. Iets dergelijks was lang daarvoor ook al eens gebeurd en toen heb ik, samen met een collega, de hele nacht op kantoor gezeten om de fout op te lossen (nee jongelui, je kon toen nog niet thuis werken). Daar had ik deze keer niet zoveel zin in en daarom zei ik tegen de operator dat hij de verwerking gewoon opnieuw moest starten. Nooit meer iets van gehoord.

In ons beveiligingsbeleid staat dat beveiligingsfuncties van een systeem moeten worden getest, ook na aanpassingen aan dat systeem. Desgevraagd mompelen de mensen die dit zouden moeten doen dat systemen uiteraard worden getest, maar slechts zelden beamen ze volmondig dat ze daarbij expliciet aandacht besteden aan de beveiligingsfuncties. Dat is ook lastig: ze hebben vaak te maken met complexe systemen van diverse leveranciers. Verreweg de meeste van die systemen hebben beveiliging niet als primaire taak; beveiligingsfuncties worden vaak met de verfoeide term ‘non-functionals’ aangeduid. Beste mensen, zonder beveiliging zouden de meeste informatiesystemen niet eens kunnen functioneren, omdat we ze niet zouden kunnen vertrouwen! Beveiliging is dus zo functioneel als maar wat, al zij het, toegegeven, ondergeschikt aan de taken waarvoor het systeem is gebouwd.

Dat testen is echt wel nodig. Je moet je ervan vergewissen dat jouw processen en gegevens veilig zijn voor nieuwsgierige, doch niet-geautoriseerde collega’s, voor hackers, voor criminelen en voor spionnen. Soms volstaat een zelftest, soms moet je een formele test laten doen die in feite een gesimuleerde hackaanval is. Daarvoor gebruiken we mooie termen als attack & penetration test (aanvallen en binnendringen) of het kortere penetratietest (wat dan weer wordt afgekort tot pentest). Dergelijke tests moeten bij ons verplicht worden uitgevoerd bij alle systemen die aan het internet hangen. We hebben zelf pentesters in dienst, maar we hebben ook contracten met externe partijen die dit werk voor ons doen. Bij het inhuren van pentesters is het goed om naar de reputatie van zowel hun werkgever als van de personen zelf te kijken. Je wilt immers niet dat deze ethische hackers iets over het hoofd zien wat door een criminele hacker kan worden misbruikt.

Testen is geen binaire bezigheid: een negatieve uitslag betekent niet per definitie dat er niets aan de hand is en een positieve uitslag kan ook wel eens een vergissing zijn. En dan is het ook nog eens zo dat een negatieve uitslag positief wordt ontvangen en een positieve uitslag slecht nieuws is. Wie heeft dat nou weer verzonnen?