Waarom delen jullie niet altijd informatie over kwetsbaarheden of bypasses?
Een begrijpelijke vraag.
Bij traditionele software leidt openheid over een opgelost beveiligingslek vaak tot een veiliger product. Bij anti-cheatsoftware werkt dat fundamenteel anders.
Daarom zijn wij terughoudend met het delen van informatie over omzeilingsmethoden, of het nu gaat om theoretische scenario's, actuele kwetsbaarheden of methodes uit het verleden die inmiddels zijn opgelost.
In dit artikel leggen we uit waarom, hoe wij onze anti-cheatbeveiliging ontwikkelen en onderhouden, en hoe wij daarin samenwerken met onderwijsinstellingen.
Anti-cheat is een continu kat-en-muisspel
Bij reguliere cybersecurity probeert een aanvaller toegang te krijgen tot een systeem waarop hij geen controle heeft. Denk aan een hacker die een server probeert binnen te dringen.
Bij digitale toetsen op eigen apparatuur (BYOD) is de situatie precies omgekeerd. De student is beheerder van de laptop waarop onze software draait. Onze beveiliging draait dus op het apparaat van degene die mogelijk probeert te frauderen.
Dat betekent dat fraude op een BYOD-apparaat nooit volledig onmogelijk kan worden gemaakt. De kracht van anti-cheat zit daarom in het voortdurend verhogen van de drempel: fraude steeds moeilijker maken, nieuwe technieken zo snel mogelijk blokkeren en voortdurend reageren op veranderende aanvalstechnieken.
Op beheerde apparaten, waar studenten geen beheerdersrechten hebben, is dit risico aanzienlijk kleiner. Toch geldt ook daar dat iedere openbaar gemaakte beschrijving van een omzeilingsmethode of van de beveiligingsmechanismen die wij inzetten, direct bruikbare aanknopingspunten biedt voor nieuwe varianten.
Een gevonden kwetsbaarheid is daarom na een fix niet automatisch "veilig" om te publiceren. Een oplossing neemt de oorspronkelijke methode weg, maar de kennis over de achterliggende werking blijft waardevol voor iedereen die nieuwe manieren zoekt om dezelfde beveiliging te omzeilen.
Anti-cheat is daarom geen product dat je één keer bouwt en vervolgens "af" is. Het is een continu kat-en-muisspel waarin aanvallers en verdedigers zich voortdurend aanpassen.
Preventie in plaats van achteraf detecteren
Safe Exam Workspace is ontworpen om examenfraude zoveel mogelijk te voorkomen, niet om deze achteraf vast te stellen.
Daarmee verschilt onze aanpak fundamenteel van remote proctoring-oplossingen. Waar proctoring software studenten monitort via bijvoorbeeld webcambeelden, schermopnames of gedragsanalyse, richt Safe Exam Workspace zich op het voorkomen dat ongeoorloofde hulpmiddelen überhaupt gebruikt kunnen worden tijdens een toets.
Wij geloven dat voorkomen betrouwbaarder is dan achteraf interpreteren. Een student die geen toegang krijgt tot ongeoorloofde middelen, kan deze tijdens de toets ook niet gebruiken.
Bovendien is deze aanpak privacyvriendelijker. Er zijn geen webcamopnames, gedragsanalyses of AI-beoordelingen nodig om een veilige toetsomgeving te realiseren.
Hoe wij onze anti-cheat continu verbeteren
Effectieve anti-cheat vraagt om voortdurende ontwikkeling. Nieuwe technieken ontstaan continu en onze beveiliging ontwikkelt zich daarin voortdurend mee.
Daarom investeren wij onder meer in:
- jaarlijkse onafhankelijke penetratietesten door gespecialiseerde externe securitypartijen;
- eigen onderzoek naar nieuwe aanvalstechnieken;
- monitoring van publieke en commerciële communities waar nieuwe cheats worden ontwikkeld of gedeeld;
- analyse van concrete klantmeldingen en fraudeonderzoeken;
- het continu verbeteren en aanscherpen van onze beveiligingsmaatregelen.
Onze anti-cheatontwikkelaars zijn dezelfde specialisten die instellingen ondersteunen bij fraudeonderzoeken. Praktijkervaring uit concrete onderzoeken wordt daardoor direct vertaald naar verbeteringen van het platform.
Waarom we beveiligingsonderzoek graag vooraf afstemmen
Een eigen pentest of security-onderzoek kan waardevol zijn, maar brengt bij anti-cheatsoftware ook risico's met zich mee.
Waar een reguliere penetratietest zich meestal richt op het verbeteren van de beveiliging van één organisatie, raakt onderzoek naar anti-cheatmechanismen direct de bescherming van alle instellingen die hetzelfde platform gebruiken.
Tijdens een pentest worden onvermijdelijk inzichten opgedaan over de werking van detectiemechanismen en mogelijke omzeilingsroutes. Zodra dergelijke kennis buiten een zeer beperkte kring terechtkomt, bijvoorbeeld via rapportages, externe leveranciers, student-assistenten of online communities, kan deze worden gebruikt als basis voor nieuwe cheats. Ook commerciële aanbieders van fraude- en exploittools volgen dergelijke informatie actief.
Daarnaast is het voor ons belangrijk om kwetsbaarheden gecontroleerd en zorgvuldig te kunnen verhelpen. Wanneer meerdere partijen onafhankelijk onderzoek uitvoeren zonder afstemming, ontstaat het risico dat dezelfde informatie op verschillende plaatsen circuleert terwijl nog niet overal een oplossing beschikbaar is.
Door onderzoeken vooraf gezamenlijk af te stemmen, kunnen wij bevindingen sneller prioriteren, gecontroleerd oplossingen ontwikkelen en deze gelijktijdig beschikbaar maken voor alle klanten.
Wij realiseren ons dat veel instellingen vanuit hun eigen securitybeleid gewend zijn zelfstandig penetratietesten uit te voeren op applicaties. Voor traditionele software is dat een logische en vaak wenselijke werkwijze. Anti-cheatsoftware vormt hierin echter een uitzondering: het doel is niet alleen het beveiligen van systemen, maar ook het beschermen van kennis over detectie- en omzeilingsmechanismen. Daarom vraagt dit type software om een andere vorm van samenwerking, waarin onafhankelijk onderzoek het meest effectief is wanneer het vooraf wordt afgestemd.
Schoolyear laat daarom jaarlijks onafhankelijke penetratietesten uitvoeren door gespecialiseerde externe securitypartijen. De resultaten van deze onderzoeken delen wij desgewenst graag met onze klanten onder een passende geheimhoudingsovereenkomst (NDA). Zo bieden wij transparantie over de uitgevoerde onderzoeken en de getroffen verbetermaatregelen, terwijl operationeel gevoelige informatie over detectie- en omzeilingsmechanismen beschermd blijft.
Wanneer aanvullend onderzoek vanuit een instelling gewenst is, werken wij daar graag aan mee. Door vooraf gezamenlijk de scope, geheimhouding en opvolging af te stemmen, kunnen bevindingen veilig worden onderzocht én opgelost, zonder onnodige risico's voor de toetsintegriteit van andere instellingen.
Waarom informeren wij niet iedere klant over iedere gevonden bypass?
Wanneer een bypass of omzeilingsmethode wordt bevestigd, volgen wij altijd dezelfde werkwijze:
- de bypass zo snel mogelijk oplossen en beschikbaar stellen aan alle klanten;
- de melder informeren over de voortgang en oplossing;
- beoordelen of aanvullende beveiligingsmaatregelen nodig zijn.
Wij publiceren vervolgens bewust geen technische details over de bypass en sturen hierover ook geen algemene melding naar alle klanten.
Bij reguliere software kan openbaarmaking na een patch systeembeheerders helpen aanvullende maatregelen te nemen. Bij anti-cheatsoftware ligt dat anders. Zodra een oplossing beschikbaar is, hoeven instellingen geen aanvullende acties uit te voeren; de beveiliging is immers al bijgewerkt.
Openbaarmaking van de technische werking van een bypass helpt daarom toekomstige aanvallers meer dan huidige verdedigers. Ook nadat een specifieke methode is opgelost, blijft kennis over de achterliggende techniek bruikbaar voor toekomstige aanvallen.
Wij kiezen er daarom bewust voor om deze informatie niet openbaar te maken. Niet omdat wij transparantie willen beperken, maar omdat wij de toetsintegriteit van álle onderwijsinstellingen die op ons platform vertrouwen willen beschermen.
Ondersteuning bij vermoedens van fraude
Wanneer een onderwijsinstelling vermoedt dat een student onze beveiliging heeft omzeild, ondersteunen wij actief bij het onderzoek.
Onze specialisten analyseren daarbij de beschikbare eventlogs, technische debuglogs en de werking van onze beveiligingsmechanismen tijdens de betreffende toetssessie. Waar relevant proberen wij de situatie bovendien zelf te reproduceren.
Wij delen vervolgens schriftelijk onze technische bevindingen, inclusief informatie die de verdenking ondersteunt én informatie die daar juist tegen spreekt.
Wij trekken echter nooit de conclusie dat een student wel of niet heeft gefraudeerd. Die beoordeling blijft altijd de verantwoordelijkheid van de onderwijsinstelling, die beschikt over aanvullende context en informatie uit bijvoorbeeld het toetsplatform.
Vanwege privacyoverwegingen worden technische debuglogs automatisch na 90 dagen verwijderd. Meld vermoedens van fraude daarom zo snel mogelijk, zodat voldoende gegevens beschikbaar zijn voor een zorgvuldig onderzoek.
Zo beschermen we samen de toetsintegriteit
Wij zien onze klanten als partners in dit voortdurende beveiligingsproces.
Daarom vragen wij onze klanten om:
- gevonden omzeilingsmethoden direct en vertrouwelijk bij Schoolyear te melden;
- informatie over dergelijke methoden zo beperkt mogelijk te verspreiden, ook nadat een oplossing beschikbaar is;
- beveiligingsonderzoek en penetratietesten vooraf met Schoolyear af te stemmen;
- geen hackathons of vergelijkbare onderzoeken te organiseren waarbij studenten of andere onbevoegden inzicht kunnen krijgen in anti-cheatmechanismen;
- signalen of vermoedens van mogelijke fraude direct met ons te delen, zodat wij snel onderzoek kunnen doen.
Goede anti-cheat ontstaat niet door geheimhouding alleen, maar door samenwerking. Meldingen van klanten, onafhankelijk onderzoek en onze eigen ontwikkeling versterken elkaar voortdurend. Door zorgvuldig om te gaan met operationeel gevoelige informatie kunnen we verbeteringen snel doorvoeren zonder nieuwe risico's te creëren voor andere instellingen.
Zo werken we samen aan één doel: betrouwbare en integere digitale toetsing voor alle onderwijsinstellingen.