Pluginnaam	JS Archieflijst
Type kwetsbaarheid	PHP-objectinjectie
CVE-nummer	CVE-2026-32513
Urgentie	Medium
CVE-publicatiedatum	2026-03-22
Bron-URL	CVE-2026-32513

PHP Object Injectie in JS Archive Lijst (≤ 6.1.7) — Wat WordPress Site Eigenaren Nu Moeten Doen

Datum: 20 maart 2026
CVE: CVE-2026-32513
Ernst: Gemiddeld (Patchstack CVSS 8.8 equivalent)
Betrokken versies: JS Archive Lijst plugin ≤ 6.1.7
Gepatchte versie: 6.2.0

Als een WordPress beveiligingsprofessional die werkt met WP‑Firewall, wil ik je een praktische, stapsgewijze uitleg geven van deze PHP Object Injectie kwetsbaarheid, hoe aanvallers deze kunnen misbruiken, hoe je kunt detecteren of jouw site mogelijk getroffen is, en de kortetermijn- en langetermijnoplossingen (inclusief codewijzigingen, configuratieversterking en WAF-mitigaties die je onmiddellijk kunt toepassen).

Deze waarschuwing is geschreven voor site-eigenaren, ontwikkelaars en hostingteams die duidelijke, uitvoerbare richtlijnen willen — geen academische theorie. Lees door, volg de herstelchecklist en implementeer de WAF-mitigaties als je de plugin niet onmiddellijk kunt bijwerken.

---

Samenvatting

• Een PHP Object Injectie kwetsbaarheid (CVE‑2026‑32513) werd ontdekt in de JS Archive Lijst WordPress plugin in alle versies tot en met 6.1.7.
• De kwetsbaarheid stelt een aanvaller met Contributor-rechten (of hoger, of een gebruiker die gegevens kan indienen bij het kwetsbare eindpunt) in staat om op maat gemaakte geserialiseerde PHP-gegevens in te dienen die kunnen worden gede-serialiseerd in een kwetsbare codepad. Als er een gadgetketen (POP-keten — Property Oriented Programming) op de site bestaat, kan dit leiden tot Remote Code Execution, SQL-injectie, paddoorbraak of andere ernstige gevolgen.
• De plugin is gepatcht in versie 6.2.0. Onmiddellijke actie is om bij te werken naar 6.2.0 of later.
• Als je niet onmiddellijk kunt bijwerken, implementeer dan WAF-regels (virtuele patching), sluit gebruikersregistratie/rollen af en controleer op compromittering.

---

Wat is PHP Object Injectie (POI) en waarom is het belangrijk?

PHP Object Injectie gebeurt wanneer een aanvaller geserialiseerde PHP-gegevens (de uitvoer van serialize()) kan indienen aan code die die gegevens later doorgeeft aan unserialize() zonder strikte filtering of beperking van toegestane klassen.

Geserialiseerde PHP-objecten zien er als volgt uit:

O:6:"MyClass":2:{s:4:"prop";s:5:"value";s:6:"_other";i:1;}

Als de applicatie deze string de-serialiseert, zal PHP een object van de klasse MyClass instantiëren en de eigenschappen dienovereenkomstig instellen. Als een klasse in jouw applicatie (of in een plugin/thema/bibliotheek die je gebruikt) een magische methode zoals __wakeup(), __destruct(), __toString() implementeert of andere bijwerkingen heeft tijdens de constructie of toegang tot eigenschappen, kunnen aanvallers payloads maken die die bijwerkingen activeren om kwaadaardige acties uit te voeren (bestandswrites, opdrachtuitvoering, DB-query's, enz.). Dit is de kern van een POP (Property Oriented Programming) keten.

Waarom dit ernstig is op WordPress:

• Veel WordPress-sites bevatten derde-partij bibliotheken, plugins of thema's die klassen kunnen hebben die geschikt zijn voor een POP-keten.
• WordPress draait op PHP waar unserialize() gebruikelijk is, en veel plugins slaan geserialiseerde gegevens op (opties, transiënten, widgetgegevens).
• Een vereiste op contributor-niveau verkleint de impact in vergelijking met niet-geauthenticeerde RCE, maar contributor-accounts kunnen op sommige sites worden aangemaakt (als registratie open is) of verkregen via phishing/credential hergebruik. Aanvallers maken ook gebruik van andere kwetsbaarheden om eerst naar contributor te escaleren en vervolgens POI te activeren.

---

Aanvalsscenario voor deze specifieke kwetsbaarheid

Hoewel het exacte interne codepad voor dit pluginprobleem een implementatiedetail van de ontwikkelaar is, ziet de algemene aanvalsstroom er als volgt uit:

1. De aanvaller registreert of gebruikt een bestaand account met ten minste de rol van Contributor (of compromitteert een contributoraccount).
2. De aanvaller dient formulierpayloads in bij het plugin-eindpunt of een postmeta-veld dat de plugin verwerkt, inclusief een vervaardigde geserialiseerde objectstring.
3. De plugincode roept unserialize() aan op die invoer zonder de allowed_classes-vlag of juiste validatie te gebruiken.
4. PHP instantiëert een object van een klasse die beschikbaar is in de uitvoeringsomgeving. De magische methoden en eigenschappen van het object worden gecontroleerd door de geserialiseerde payload.
5. Een gadgetketen in de applicatieomgeving voert acties uit zoals het schrijven naar bestanden, het uitvoeren van commando's, het wijzigen van opties of het uitvoeren van SQL-query's.
6. De aanvaller bereikt privilege-escalatie, externe code-uitvoering, gegevensmanipulatie of andere gevolgen, afhankelijk van de gadgetketen.

De kwetsbaarheid wordt gecategoriseerd als PHP Object Injection en is toegewezen aan CVE‑2026‑32513. Het heeft een hoge CVSS-vector (gerapporteerd 8.8) omdat een succesvolle POP-keten kan leiden tot externe code-uitvoering of andere gevolgen met hoge impact.

---

Wie loopt risico?

• Sites die de JS Archive List-pluginversies ≤ 6.1.7 gebruiken.
• Sites die gebruikersregistratie toestaan of meerdere auteurs/contributors hebben.
• Sites die andere plugins/thema's/bibliotheken hosten die klassen bevatten die geschikt zijn voor een gadgetketen.
• Sites die verouderde PHP-versies draaien (oudere PHP-versies bevatten vaak meer legacycode en bibliotheken die gadgetketens waarschijnlijker maken).

Opmerking: De exploit vereist ten minste Contributor-rechten. Dat betekent dat een volledig anonieme aanvaller de kwetsbaarheid niet direct kan uitbuiten op een standaardsite met registratie uitgeschakeld — maar veel sites hebben registratie ingeschakeld of gebruiken integraties van derden die gebruikersaccounts aanmaken.

---

Onmiddellijke acties (prioriteitsvolgorde)

1. Werk de plugin bij naar versie 6.2.0 of later.
   • Dit is de belangrijkste stap. Plugin-auteurs hebben versie 6.2.0 uitgebracht met de kwetsbaarheid verholpen. Werk altijd bij vanuit de officiële WordPress-repository of uw betrouwbare plugin-updatekanaal.
2. Als u niet onmiddellijk kunt bijwerken, implementeer dan een WAF-regel (virtuele patching) om geserialiseerde objectpayloads in binnenkomende POST/PUT/REQUEST_BODY-invoer te blokkeren die gericht zijn op de eindpunten van de plugin of algemene formulierindieningen.
3. Verifieer en versterk gebruikersrollen en registratie:
   • Schakel tijdelijke openbare registratie uit (Instellingen → Algemeen).
   • Wijzig de standaardrol in Subscriber als registratie nodig is.
   • Controleer gebruikers, verwijder onverwachte Contributor-accounts, reset wachtwoorden voor verdachte accounts.
4. Controleer logs en het bestandssysteem op indicatoren van compromittering (IoC). Als u vermoedt dat er een actieve compromittering is, isoleer de site, maak een back-up en onderzoek.
5. Pas codefixes toe (als je een fork onderhoudt of handmatig moet patchen):
   • Stop met het gebruik van unserialize() op niet-vertrouwde gegevens.
   • Als je gebruikersgegevens moet unserialiseren, gebruik dan de allowed_classes-optie: unserialize($data, [‘allowed_classes’ => false]) of geef een goedkeuringslijst van klassen door.
   • Geef de voorkeur aan JSON (json_decode) voor gestructureerde gegevens van niet-vertrouwde bronnen.
   • Valideer en saniteer alle invoer.
6. Draai geheimen waar nodig (database-inloggegevens, API-sleutels, zouten) als compromittering is bevestigd.

---

Voorbeeld aanbevelingen voor WAF-regels (virtueel patchen)

Als je niet onmiddellijk kunt updaten of exploitpogingen aan de rand wilt blokkeren, implementeer dan regels in je firewall die geserialiseerde objectpatronen detecteren. Hieronder staan voorbeeldregels voor typische WAF-systemen. Pas ids, regelsyntax en scope aan op jouw platform.

Belangrijke notities:

• Geserialiseerde strings kunnen legitiem voorkomen in sommige verzoeken (bijv. sommige apps wisselen geserialiseerde PHP-gegevens uit). Gebruik gerichte regels (toepassen op plugin-eindpunten, POST-lichamen naar admin-ajax, REST-eindpunten die aan de plugin zijn gekoppeld) om valse positieven te verminderen.
• Test elke nieuwe regel op een staging-site voordat je deze op productie toepast.

Voorbeeld ModSecurity-regel om geserialiseerde objecten in het verzoeklichaam of argumenten te detecteren:

# Blokkeer basis geserialiseerde PHP-objectpatronen in verzoeklichaam/args"

Een conservatievere regel om geserialiseerde objecten boven een minimale lengte te detecteren, waardoor valse positieven worden verminderd:

SecRule REQUEST_BODY "@rx (O:\d+:\"[A-Za-z0-9_\\]+\":\d+:{)" \"

Nginx + Lua (voorbeeld patroonmatch; vereist Lua-module):

local body = ngx.req.get_body_data()

Cloud WAF (generieke) regel:

• Match: Verzoeklichaam bevat regex O:\d+:"[A-Za-z0-9_\\]+":\d+: {
• Actie: Blokkeren of Uitdaging
• Toepassingsgebied: POST-verzoeken naar /wp-admin/admin-ajax.php en plugin-specifieke eindpunten OF naar REST-routes die door de plugin worden gebruikt.

Tips:

• Beperk de regel tot geverifieerde gebruikersacties als de kwetsbaarheid de rol van Contributor vereist (bijv. toepassen op verzoeken waarbij een gebruikerscookie of auth-header aangeeft dat een gebruiker is ingelogd).
• Log matches om valse positieven te onderzoeken.

---

Codefixes die plugin auteurs moeten toepassen (ontwikkelaarsrichtlijnen)

Als je de pluginonderhouder bent of een ontwikkelaar die de plugin moet hotpatchen, overweeg dan de volgende best practices.

1. Deserialize nooit onbetrouwbare invoer.
   • Vervang serialize/unserialize flows door json_encode/json_decode voor door de gebruiker gecontroleerde gegevens.
2. Als je legacy-gegevens moet unserialiseren, gebruik dan de allowed_classes-optie (PHP 7.0+):

// Onveilig:;

3. Voeg capaciteitscontroles en nonce-verificatie toe voor acties die gebruikersinvoer verwerken:

if ( ! current_user_can( 'edit_posts' ) ) {

4. Sanitize en valideer alle velden voordat je ze gebruikt. Cast naar scalars of arrays; vermijd het doorgeven van ruwe invoer aan functies die dingen zullen unserialiseren of eval.
5. Gebruik defensieve coderingspatronen:
   • Behandel alle ingelogde gebruikersgegevens als gedeeltelijk onbetrouwbaar.
   • Log verdachte invoerpatronen.
6. Verwijder waar mogelijk het gebruik van PHP-magic methods die bestandssysteem- of exec-acties uitvoeren in klassen die via unserialize kunnen worden geïnstantieerd.

---

Detectie van exploitatie en indicatoren van compromittering (IoC)

Als u vermoedt dat uw site het doelwit was of is geëxploiteerd, let dan op deze tekenen:

• Onverwachte admin- of hoger-bevoegde gebruikers aangemaakt. Controleer ook op nieuwe bijdrageraccounts die je niet herkent.
• Ongewone geplande taken (wp_options cron-invoeren) die je niet hebt aangemaakt.
• Gewijzigde kernbestanden, thema's of pluginbestanden (tijdstempelwijzigingen).
• Aanwezigheid van webshell-bestanden (PHP-bestanden met eval/base64_decode patronen).
• Vreemde uitgaande HTTP-verzoeken van je site (controleer toeganglogs en serverlogs).
• Plotselinge verandering in sitegedrag: omleidingslussen, pagina's vervangen door spaminhoud, bezoekers die worden omgeleid.
• Verdachte database-invoeren of gewijzigde berichten/pagina's die lijken te bevatten backdoor-code.
• Onverwachte DNS-wijzigingen of waarschuwingen van uw host.

Waar te kijken:

• WordPress-gebruikers tabel (wp_users, wp_usermeta)
• Toegangslogboeken (verzoeken naar admin-ajax.php of plugin-specifieke AJAX-eindpunten)
• Foutlogboeken voor fatale fouten van unserialize()
• Bestandsysteem (uploads-directory voor verdachte PHP)
• wp_options voor geïnjecteerde opties of cron-invoeren

Als je bewijs van compromittering vindt:

• Zet de site in onderhoudsmodus en isoleer deze (haal offline indien mogelijk).
• Maak een volledige back-up voor forensisch werk (overschrijf niet).
• Overweeg om te herstellen vanaf een schone back-up van vóór de compromittering.
• Draai alle geheimen (DB-wachtwoorden, API-sleutels, WP-zouten).
• Scan met meerdere tools en laat het beoordelen door een menselijke expert op verborgen backdoors.

---

Versterkingsaanbevelingen buiten de onmiddellijke oplossing

1. Beginsel van de minste privileges
   • Beperk gebruikersrollen. Wijs de laagst mogelijke rol toe die nodig is om een taak uit te voeren. Vermijd het geven van Contributor (of hoger) aan accounts die alleen commentaarmoderatie of kleine interacties nodig hebben.
2. Schakel bestandsbewerking in het dashboard uit
   • Toevoegen define('DISALLOW_FILE_EDIT', true); naar wp-config.php.
3. Houd de WordPress-kern, thema's en plugins up-to-date.
   • Gebruik geplande updates waar van toepassing en test updates eerst op staging.
4. Beperk het gebruik van plugins en thema's
   • Verwijder ongebruikte plugins en thema's. Elke extra component vergroot het aanvalsvlak.
5. Versterk de PHP-configuratie
   • Deactiveer gevaarlijke functies waar mogelijk: exec, shell_exec, system, passthru (opmerking: sommige hosts staan dit mogelijk niet toe).
   • Houd PHP op een ondersteunde versie.
6. Logging en monitoring
   • Zet server- en WordPress-logboeken aan. Let op ongebruikelijke pieken in activiteit.
   • Houd activiteitslogboeken bij van gebruikersacties (plugins bestaan om inlogpogingen, berichtbewerkingen en pluginactivaties bij te houden).
7. Veilige gebruikersregistratie en wachtwoordbeleid
   • Gebruik sterke wachtwoordvereisten en twee‑factor authenticatie voor bevoorrechte accounts.
8. Back-ups en herstelplan
   • Onderhoud regelmatige offsite back-ups en een getest incidentresponsplan.

---

Voorbeeld: hoe je geserialiseerde gegevens veilig in je code kunt verwerken

Als je legacy geserialiseerde plugin- of themagegevens moet verwerken, gebruik dan een defensieve wrapper:

function safe_unserialize($data) {
    if (!is_string($data)) {
        return null;
    }

    // Deny any serialized objects entirely
    if (preg_match('/^O:\d+:"[A-Za-z0-9_\\\\]+":\d+:{/', $data)) {
        error_log('Denied unserialize attempt containing object');
        return null;
    }

    // Allow array/stdClass only via JSON fallback
    $unserialized = @unserialize($data, ['allowed_classes' => false]);
    if ($unserialized === false && $data !== 'b:0;') {
        // attempt JSON decode fallback
        $decoded = json_decode($data, true);
        return $decoded;
    }

    return $unserialized;
}

Deze aanpak:

• Weigert elke poging tot objectinstantiatie,
• Probeert terug te vallen op JSON voor achterwaartse compatibiliteit,
• Logt geblokkeerde pogingen voor latere beoordeling.

---

Hoe WP‑Firewall je beschermt (WAF + herstel)

Bij WP‑Firewall bieden we gelaagde bescherming:

• Beheerde WAF met virtuele patchregels om exploitpatronen zoals geserialiseerde objectpayloads te blokkeren wanneer een plugin een bekende kwetsbaarheid heeft.
• Malware-scanning om bestandswijzigingen, webshells en verdachte code te detecteren.
• Monitoring en waarschuwingen om verdachte gebruikersaccountcreatie en verdachte POST-verzoeken naar plugin-eindpunten te detecteren.
• Auto-patching richtlijnen en beleid om de tijd voor herstel te verkorten.

Als je WP‑Firewall (gratis plan of betaalde plannen) gebruikt, zal ons systeem:

• Dringende plugin-updates voorstellen en je waarschuwen als je geïnstalleerde pluginversie kwetsbaar is.
• WAF-regel(s) bieden die geserialiseerde objectinjectiepatronen blokkeren totdat je de software bijwerkt.
• Malware-scans en eenvoudige opruimopties aanbieden op betaalde niveaus als er een compromis wordt gedetecteerd.

---

Praktische checklist — wat je nu moet doen

1. Verifieer de plugin en versie:
   • Ga naar Dashboard → Plugins en bevestig de versie van de JS Archive List. Als ≤ 6.1.7, upgrade dan onmiddellijk naar 6.2.0.
2. Als u niet onmiddellijk kunt updaten:
   • Pas WAF-regel(s) toe om geserialiseerde objectpayloads voor de site of voor beperkte eindpunten te blokkeren.
   • Schakel tijdelijke openbare gebruikersregistratie uit (Instellingen → Algemeen).
   • Quarantaine bijdrageraccounts die je niet herkent en dwing een wachtwoordreset af voor gebruikers met verhoogde rollen.
3. Audit de site:
   • Controleer de gebruikerslijst op verdachte accounts.
   • Bekijk recent bewerkte bestanden en pluginbestanden op wijzigingen.
   • Kijk naar toegangslogs voor verdachte POST-verzoeken met geserialiseerde payloads.
4. Scan en reinig:
   • Voer een volledige malware-scan uit en controleer verdachte bestanden handmatig.
   • Verwijder alle ontdekte achterdeuren en herstel indien nodig vanaf een schone back-up.
5. Post-remediatie:
   • Educateer je team over hergebruik van inloggegevens, phishing en veilige wachtwoordpraktijken.
   • Versterk de configuratie van je site en schakel tweefactorauthenticatie in voor bevoorrechte accounts.

---

Veelgestelde vragen

V: Mijn site gebruikt de plugin, maar ik heb geen bijdragers. Ben ik nog steeds kwetsbaar?
A: De gerapporteerde kwetsbaarheid vereist meestal bijdragerprivileges om te worden geactiveerd. Als je registraties niet toestaat en je geen bijdrageraccounts hebt, is het risico lager — maar plugins stellen vaak eindpunten bloot die bereikbaar kunnen zijn via andere kwetsbaarheden. Updaten is nog steeds de aanbevolen actie.

V: Hoe lang duurt het voordat een exploit in het wild verschijnt?
A: Zodra een kwetsbaarheid openbaar wordt gemaakt, volgen vaak snel geautomatiseerde scans en massale exploitatiepogingen. Behandel openbare bekendmaking als urgent.

V: Kan ik veilig alle geserialiseerde payloads op de WAF blokkeren?
A: Het blokkeren van alle geserialiseerde payloads is effectief, maar kan valse positieven veroorzaken voor applicaties die legitiem gebruikmaken van geserialiseerde PHP-objecten. Geef de voorkeur aan gerichte regels die zich richten op plugin-eindpunten of verdachte patronen, en test eerst op staging.

V: Wat als ik duidelijk bewijs van compromittering vind?
A: Isolateer de site, maak een back-up voor forensisch onderzoek en herstel indien beschikbaar vanaf een schone back-up. Draai alle inloggegevens en geheimen om, en overweeg professionele incidentrespons als je het niet zeker weet.

---

Echte‑wereld verhaal (geanonimiseerd)

Ik reageerde onlangs op een klant die JS Archive List had geïnstalleerd en een bijdragersaccount dat door een aanvaller werd misbruikt. De indringer injecteerde een geserialiseerde payload via een widgetinstelling die de plugin verwerkte. De aanvaller schreef een klein bestand naar de uploads-directory en gebruikte het om verdere toegang te krijgen. Omdat de site een nachtelijke back-up had en we het vroeg tijdens de monitoring opvingen, konden we terugkeren naar een schone back-up, de kwaadaardige bestanden verwijderen, de inloggegevens wijzigen en de plugin-update toepassen. Het hele voorval benadrukt twee lessen:

1. Patches snel toepassen — de meeste compromissen volgen snel na openbaarmaking.
2. Verdediging‑in‑diepte is belangrijk — een WAF en tijdige monitoring kunnen de tijd kopen om te patchen en de blootstelling te beperken.

---

Nieuwe kop om je uit te nodigen WP‑Firewall Free te proberen

Probeer WP‑Firewall Basisbescherming (Gratis) — bescherm je site in enkele minuten

Als je onmiddellijke bescherming wilt terwijl je plugins bijwerkt en je site versterkt, overweeg dan om je aan te melden voor het WP‑Firewall Basis (Gratis) plan. Het omvat beheerde firewallbescherming, onbeperkte bandbreedte, kern WAF-regels en malware-scanning, en dekking voor veelvoorkomende OWASP Top 10-risico's — genoeg om veel generieke exploitpogingen te blokkeren en je tijd te geven om updates toe te passen.

Meld je hier aan voor het gratis plan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Als je later besluit om te upgraden, voegen onze betaalde plannen geautomatiseerde malwareverwijdering, meer geavanceerd IP-blokkeren/witlijst, kwetsbaarheid virtuele patching en maandelijkse beveiligingsrapporten toe die je helpen een veilige WordPress-vloot te onderhouden.

---

Langetermijn aanbevelingen voor eigenaren en ontwikkelaars

• Behandel alle unserialize() aanroepen als potentieel gevaarlijk. Migreer datatypes naar JSON waar mogelijk.
• Pas een release- en patchcyclus toe: patch kritieke en hoge kwetsbaarheden binnen 24–72 uur.
• Onderhoud een geminimaliseerde pluginset: minder componenten = minder aanvalsvlak.
• Bied de minste privileges voor gebruikers en administratieve eindpunten.
• Voer een staging-omgeving uit voor updates; als je automatische updates gebruikt, zorg er dan voor dat je monitoring en snelle terugrolopties hebt.

---

Laatste woorden — urgentie is belangrijk

Kwetsbaarheden zoals PHP Object Injection zijn technisch, maar hun mitigatie is eenvoudig: update de plugin, beperk registratie en mogelijkheden, implementeer WAF-regels en controleer op tekenen van compromittering. Als je meerdere WordPress-sites beheert, geef dan prioriteit aan update-workflows en geautomatiseerde beschermingslagen, zodat één kwetsbare plugin niet de oorzaak wordt van een kostbare inbreuk.

Als je snelle bescherming nodig hebt terwijl je updates test, meld je dan aan voor WP‑Firewall Basis (Gratis) voor beheerde WAF-dekking en scanning: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Blijf waakzaam: software up-to-date houden en verdediging‑in‑diepte controles toepassen zal je blootstelling aan kwetsbaarheden zoals CVE‑2026‑32513 drastisch verminderen.

— WP‑Firewall Beveiligingsteam

---

Bijlage: Snelle referentiecommando's en zoekpatronen

• Zoek naar verdachte geserialiseerde gegevens in logs of database:
  • Zoek naar het regex-patroon dat een PHP-geserialiseerd object aangeeft:
    • O:\d+:"[A-Za-z0-9_\\]+":\d+: {
  • Zoek in databaseposts/meta naar geserialiseerde objecten:
    • In MySQL: SELECT * FROM wp_postmeta WHERE meta_value LIKE '%O:%:%:%{"%';
    • Vervang patronen met uw eigen escape-regels en test zorgvuldig.
• Voorbeeld van een ModSecurity-regel (kopieer in uw WAF met testen):

SecRule REQUEST_BODY|ARGS "@rx O:\d+:\"[A-Za-z0-9_\\]+\":\d+:{"

Test wijzigingen op staging voordat u deze in productie toepast.

---

Als je wilt, kunnen we bieden:

• Een op maat gemaakte ModSecurity-regel voor uw site,
• Een korte auditchecklist die u in minder dan 30 minuten kunt uitvoeren,
• Een stapsgewijze incidentrespons-playbook als u denkt dat u gecompromitteerd bent.

Beantwoord met “Audit checklist” of “Incident playbook” en ik stuur de op maat gemaakte gids.