WebHID API Geblokkeerd

De WebHID API biedt websites directe toegang tot Human Interface Device-apparaten die op het systeem zijn aangesloten. Deze functionaliteit creëert aanzienlijke beveiligings- en privacyrisico's die organisaties blootstellen aan verschillende vormen van cyberaanvallen. Kwaadaardige websites kunnen keyloggers implementeren door toetsenbord-HID-apparaten te monitoren, waardoor alle toetsaanslagen kunnen worden vastgelegd inclusief wachtwoorden, creditcardnummers en andere gevoelige informatie. Gamepad- en joystick-invoer kan worden onderschept, wat niet alleen privacyproblemen veroorzaakt maar ook kan worden gebruikt voor apparaatfingerprinting en gebruikersvolging. Aangepaste HID-apparaten zoals hardware security keys kunnen worden gemanipuleerd, waardoor de beveiligingsfuncties van deze apparaten worden ondermijnd. De firmware van HID-apparaten kan potentieel worden aangepast, wat kan leiden tot permanente compromittering van hardware-apparaten. Apparaatfingerprinting kan worden gebruikt voor tracking en profilering van gebruikers zonder hun medeweten. BadHID-aanvallen waarbij een apparaat zich voordoet als toetsenbord kunnen worden misbruikt om kwaadaardige commando's uit te voeren. Voor de meeste organisaties is WebHID niet nodig en vormt het een onnodig uitgebreid aanvalsoppervlak. Het blokkeren van de WebHID API is een best practice voor browser hardening en vormt een essentieel onderdeel van een defensieve beveiligingsstrategie.

Implementatie

Deze beveiligingscontrol configureert de DefaultWebHidGuardSetting-beleidsinstelling op waarde 2, wat betekent dat alle websites worden geblokkeerd voor toegang tot HID-apparaten. De configuratie wordt uitgevoerd via het Windows-register op het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge\DefaultWebHidGuardSetting met de waarde 2 als DWORD-registerwaarde. Deze instelling kan worden geconfigureerd via Microsoft Intune voor cloud-gebaseerd apparaatbeheer of via Group Policy Objects voor on-premises Active Directory-omgevingen. Door deze instelling te configureren, wordt ervoor gezorgd dat geen enkele website toegang kan krijgen tot HID-apparaten via de WebHID API, ongeacht of gebruikers expliciet om toegang vragen. Dit voorkomt effectief dat aanvallers toetsenbordinvoer kunnen onderscheppen, gamepad- en joystick-invoer kunnen monitoren, of andere HID-apparaten kunnen manipuleren. De instelling wordt afgedwongen op het niveau van de lokale machine, waardoor eindgebruikers deze niet kunnen wijzigen of omzeilen zonder administratorrechten.

Vereisten

Voor het succesvol implementeren van de WebHID API blokkering zijn verschillende technische en organisatorische vereisten van essentieel belang. Deze vereisten vormen de basis voor een effectieve implementatie die zowel de beveiligingsdoelstellingen bereikt als de bedrijfsvoering niet onnodig verstoort. Organisaties dienen zorgvuldig te evalueren of aan alle vereisten wordt voldaan voordat de implementatie wordt gestart, om te voorkomen dat er problemen ontstaan tijdens of na de implementatie. De eerste en meest fundamentele vereiste betreft de aanwezigheid van de Microsoft Edge browser op alle doelapparaten binnen de organisatie. De WebHID API is een specifieke functionaliteit van moderne webbrowsers, en de beleidsinstellingen die worden gebruikt om deze API te blokkeren zijn specifiek voor Microsoft Edge. Dit betekent dat organisaties die nog werken met oudere browsers zoals Internet Explorer of een gemengde browseromgeving hebben, eerst een migratiestrategie moeten ontwikkelen om ervoor te zorgen dat Edge de standaard browser wordt voor alle gebruikers. Zonder een consistente browseromgeving kan de beveiligingscontrol niet effectief worden toegepast op alle apparaten, wat gaten in de beveiliging kan creëren. Het besturingssysteem vormt een tweede kritieke vereiste. De implementatie van de WebHID API blokkering vereist Windows 10 versie 1809 of hoger, Windows 11, of Windows Server 2016 en nieuwere versies. Deze versievereisten zijn noodzakelijk omdat de onderliggende beleidsondersteuning en registerstructuur pas vanaf deze versies volledig beschikbaar zijn. Organisaties die nog werken met oudere Windows-versies zoals Windows 7 of Windows 8.1 dienen eerst een upgradeplan te ontwikkelen, aangezien beveiligingscontrols zoals deze niet effectief kunnen worden geïmplementeerd op verouderde systemen die de benodigde beleidsondersteuning missen. Het is belangrijk om te begrijpen dat beveiligingscontrols alleen effectief zijn wanneer ze consistent kunnen worden toegepast op alle apparaten binnen de organisatie. Administratorrechten vormen een derde essentiële vereiste voor de implementatie. De beleidsinstellingen moeten worden geconfigureerd via Group Policy Objects (GPO) in een Active Directory omgeving, of via Microsoft Intune voor cloud-gebaseerd apparaatbeheer. In beide gevallen zijn uitgebreide administratorrechten vereist om de registerinstellingen te kunnen wijzigen op het niveau van de lokale machine. Dit betekent dat alleen IT-beheerders met de juiste rechten de implementatie kunnen uitvoeren, en dat eindgebruikers niet in staat moeten zijn om deze instellingen te wijzigen of te omzeilen. Het is belangrijk om te verifiëren dat de toegangscontrole correct is geconfigureerd voordat de implementatie wordt gestart, om te voorkomen dat gebruikers de beveiligingsinstellingen kunnen wijzigen na de implementatie. Een vierde belangrijke vereiste betreft de inventarisatie van bestaande web applicaties binnen de organisatie. Hoewel het gebruik van de WebHID API zeer zeldzaam is in de praktijk, bestaat er een kleine kans dat specifieke interne of externe web applicaties deze functionaliteit legitiem gebruiken. WebHID wordt soms gebruikt in gespecialiseerde applicaties die communiceren met aangepaste hardware-apparaten zoals industriële controllers, medische apparatuur, of gespecialiseerde input devices. Organisaties dienen daarom een grondige inventarisatie uit te voeren van alle web applicaties die binnen de organisatie worden gebruikt, met speciale aandacht voor applicaties die mogelijk communiceren met hardware-apparaten of gespecialiseerde input devices. Deze inventarisatie moet worden uitgevoerd voordat de blokkering wordt geïmplementeerd om te voorkomen dat legitieme bedrijfsprocessen worden verstoord. Ten slotte is een formele bedrijfscasereview vereist voor eventuele legitieme gebruikscases van de WebHID API. Als tijdens de inventarisatie applicaties worden geïdentificeerd die daadwerkelijk afhankelijk zijn van de WebHID API, dient een gedetailleerde risicoanalyse te worden uitgevoerd waarbij de beveiligingsrisico's worden afgewogen tegen de bedrijfsvoordelen. In de meeste gevallen zal blijken dat alternatieve oplossingen beschikbaar zijn die dezelfde functionaliteit bieden zonder de beveiligingsrisico's, maar indien een legitieme bedrijfscase bestaat, kunnen uitzonderingen worden geconfigureerd voor specifieke websites via de beleidsinstellingen. Deze bedrijfscasereview moet worden gedocumenteerd en goedgekeurd door zowel de IT-afdeling als de security officer, om ervoor te zorgen dat uitzonderingen alleen worden verleend wanneer dit echt noodzakelijk is voor de bedrijfsvoering.

Implementatie

De implementatie van de WebHID API blokkering kan worden uitgevoerd via verschillende methoden, afhankelijk van de infrastructuur en beheeromgeving van de organisatie. De meest efficiënte en schaalbare aanpak is het gebruik van geautomatiseerde PowerShell scripts die de benodigde registerinstellingen kunnen configureren op meerdere systemen tegelijkertijd. Deze geautomatiseerde aanpak vermindert niet alleen de kans op menselijke fouten, maar zorgt ook voor consistentie door de gehele organisatie. PowerShell scripts kunnen worden geconfigureerd om automatisch te worden uitgevoerd via Intune, Group Policy, of andere centrale beheeroplossingen, waardoor de implementatie kan worden geschaald naar duizenden apparaten zonder dat handmatige interventie vereist is. Voor organisaties die werken met Microsoft Intune als apparaatbeheeroplossing, biedt het Intune-beheercentrum een gebruiksvriendelijke interface voor het configureren van Edge-beleid. De implementatie begint met het navigeren naar het Microsoft Intune-beheercentrum, waar beheerders toegang hebben tot alle apparaatbeheerfunctionaliteiten. Vanuit het hoofdmenu navigeert men naar de sectie Apparaten, gevolgd door Configuratieprofielen. Hier kan een nieuw profiel worden aangemaakt door te klikken op de optie om een nieuw profiel te creëren. Het is belangrijk om een duidelijke naam te kiezen voor het profiel, zoals "Edge WebHID API Blokkering", zodat het later gemakkelijk kan worden geïdentificeerd en beheerd. Bij het aanmaken van het nieuwe profiel dient men eerst het platform te selecteren. Voor deze implementatie moet Windows 10 en later worden gekozen als het doelplatform. Vervolgens moet het profieltype worden ingesteld op Instellingencatalogus, wat een moderne aanpak is die toegang geeft tot een uitgebreide catalogus van configureerbare instellingen voor Microsoft Edge en andere Microsoft-producten. De Instellingencatalogus biedt een gestructureerde manier om specifieke beleidsinstellingen te vinden en te configureren zonder dat men handmatig registerpaden hoeft te kennen. Dit maakt de implementatie toegankelijker voor beheerders die mogelijk niet volledig vertrouwd zijn met de onderliggende registerstructuur. Binnen de instellingencatalogus moet men zoeken naar Microsoft Edge instellingen, specifiek naar de HID-sectie. Hier vindt men de DefaultWebHidGuardSetting-beleidsinstelling, die de centrale instelling vormt voor het beheren van WebHID API-toegang. Deze beleidsinstelling moet worden geconfigureerd op waarde 2, wat betekent dat HID-toegang wordt geblokkeerd voor alle websites. Deze waarde is de aanbevolen instelling voor de meeste organisaties, omdat het de hoogste beveiligingsstandaard biedt zonder dat gebruikers worden lastiggevallen met prompts of waarschuwingen. Het is belangrijk om te begrijpen dat de DefaultWebHidGuardSetting-beleidsinstelling drie mogelijke waarden kent, elk met verschillende beveiligingsimplicaties. Waarde 1 staat toe dat websites HID-toegang kunnen vragen aan gebruikers, wat niet wordt aanbevolen omdat het gebruikers blootstelt aan potentiële social engineering aanvallen waarbij kwaadaardige websites om toegang vragen. Deze waarde creëert een beveiligingsrisico omdat gebruikers mogelijk niet volledig begrijpen wat de implicaties zijn van het verlenen van HID-toegang aan een website, en omdat kwaadaardige websites kunnen proberen gebruikers te misleiden om toegang te verlenen. Waarde 2 blokkeert HID-toegang voor alle websites volledig, wat de aanbevolen instelling is voor maximale beveiliging. Deze waarde elimineert het risico op HID-gebaseerde aanvallen volledig, zonder dat gebruikers worden lastiggevallen met prompts. Waarde 3 vraagt de gebruiker elke keer om toestemming wanneer een website probeert toegang te krijgen tot een HID-apparaat, wat te permissief is en gebruikers lastigvalt met constante prompts terwijl het nog steeds beveiligingsrisico's met zich meebrengt. Na het configureren van de beleidsinstelling moet het profiel worden toegewezen aan de juiste gebruikersgroepen. Het is belangrijk om een zorgvuldige afweging te maken bij de toewijzing: enerzijds wil men de beveiligingscontrol zo breed mogelijk toepassen om het aanvalsoppervlak te minimaliseren, anderzijds moet men rekening houden met eventuele uitzonderingen die tijdens de vereistenanalyse zijn geïdentificeerd. In de meeste gevallen is het aanbevolen om het profiel toe te wijzen aan alle gebruikersgroepen, maar organisaties met specifieke industriële of operationele technologie-omgevingen kunnen ervoor kiezen om eerst een proefproject uit te voeren met een beperkte groep gebruikers. Deze proeffase kan helpen om eventuele onvoorziene problemen te identificeren voordat de implementatie wordt uitgerold naar de gehele organisatie. Het is belangrijk om te begrijpen dat de WebHID API standaard geblokkeerd is in Microsoft Edge, zelfs zonder expliciete beleidsconfiguratie. Echter, het configureren van deze beleidsinstelling via Intune of GPO zorgt ervoor dat de blokkering expliciet wordt afgedwongen en niet kan worden gewijzigd door eindgebruikers of lokale beheerders. Dit biedt organisaties de garantie dat de beveiligingsinstelling consistent blijft op alle apparaten en niet kan worden omzeild door individuele gebruikers of lokale configuratiewijzigingen. Voor organisaties die werken met Group Policy Objects in plaats van Intune, kan dezelfde beleidsinstelling worden geconfigureerd via de Group Policy Management Console, waarbij de registerwaarde HKLM:\SOFTWARE\Policies\Microsoft\Edge\DefaultWebHidGuardSetting wordt ingesteld op 2 (DWORD).

Gebruik PowerShell-script webhid-api-blocked.ps1 (functie Invoke-Remediation) – PowerShell script voor automatische blokkering van WebHID API.

Monitoring

Effectieve monitoring van de WebHID API blokkering is essentieel om te garanderen dat de beveiligingscontrol daadwerkelijk wordt afgedwongen en niet wordt omzeild door gebruikers of lokale configuratiewijzigingen. Monitoring moet worden uitgevoerd op regelmatige basis, idealiter maandelijks of na belangrijke wijzigingen in de IT-omgeving zoals Windows-updates of Edge-browserupdates die mogelijk de beleidsondersteuning kunnen beïnvloeden. Het doel van monitoring is niet alleen om te verifiëren dat de instellingen correct zijn geconfigureerd, maar ook om trends te identificeren en proactief problemen op te lossen voordat ze tot beveiligingsincidenten leiden. De primaire monitoringactiviteit betreft het verifiëren van de registerinstellingen op doelapparaten. Beheerders dienen regelmatig te controleren of de DefaultWebHidGuardSetting-beleidsinstelling correct is geconfigureerd in het registerpad HKLM:\SOFTWARE\Policies\Microsoft\Edge. De verwachte waarde is 2, wat moet worden opgeslagen als een DWORD-registerwaarde. Deze verificatie kan handmatig worden uitgevoerd via de Register-editor, maar het is veel efficiënter om geautomatiseerde monitoring scripts te gebruiken die deze controle kunnen uitvoeren op meerdere apparaten tegelijkertijd en de resultaten kunnen rapporteren in een centraal controlepaneel. Geautomatiseerde monitoring biedt niet alleen schaalbaarheid, maar ook consistentie in de manier waarop de verificatie wordt uitgevoerd, waardoor de kans op menselijke fouten wordt geminimaliseerd. Naast technische verificatie van de registerinstellingen is het belangrijk om gebruikersklachten en verzoeken te monitoren die betrekking hebben op HID-apparaattoegang. Wanneer gebruikers melden dat bepaalde web applicaties niet meer functioneren of dat ze toegang nodig hebben tot HID-apparaten, dient dit serieus te worden genomen en moet een grondige analyse worden uitgevoerd. In de meeste gevallen zal blijken dat de applicatie niet daadwerkelijk afhankelijk is van de WebHID API, maar in zeldzame gevallen kan een legitieme bedrijfscase bestaan die een uitzondering rechtvaardigt. Het is belangrijk om een gestructureerd proces te hebben voor het behandelen van dergelijke verzoeken, waarbij zowel de technische als de bedrijfsaspecten worden geëvalueerd. Alle verzoeken voor WebHID-toegang moeten worden gedocumenteerd en geëvalueerd volgens een gestructureerd proces. Dit proces moet een formele risicoanalyse omvatten waarbij de beveiligingsrisico's worden afgewogen tegen de bedrijfsvoordelen. De aanvrager moet een gedetailleerde bedrijfsrechtvaardiging kunnen leveren die uitlegt waarom de WebHID API essentieel is voor de bedrijfsvoering en waarom alternatieve oplossingen niet haalbaar zijn. Deze rechtvaardigingen moeten worden beoordeeld door zowel de IT-afdeling als de security officer, en indien goedgekeurd, moeten uitzonderingen worden geconfigureerd op een zo beperkt mogelijke manier, bijvoorbeeld door alleen specifieke websites toe te staan in plaats van de blokkering volledig op te heffen. Het is belangrijk om te begrijpen dat elke uitzondering het aanvalsoppervlak vergroot, en daarom moeten uitzonderingen alleen worden verleend wanneer dit echt noodzakelijk is. Het monitoren van bedrijfsrechtvaardigingen voor uitzonderingen is een continu proces dat niet stopt na de initiële goedkeuring. Uitzonderingen moeten periodiek worden beoordeeld, idealiter elk kwartaal, om te bepalen of ze nog steeds nodig zijn. Technologie evolueert snel, en wat vandaag de dag een legitieme bedrijfscase lijkt, kan morgen al overbodig zijn door nieuwe alternatieve oplossingen. Door regelmatige beoordelingen kunnen organisaties ervoor zorgen dat uitzonderingen worden ingetrokken zodra ze niet meer nodig zijn, waardoor het aanvalsoppervlak wordt geminimaliseerd. Deze periodieke beoordelingen moeten worden gedocumenteerd en de resultaten moeten worden gedeeld met de security officer en andere relevante stakeholders. Geautomatiseerde monitoring tools kunnen een belangrijke rol spelen bij het efficiënt uitvoeren van deze monitoringactiviteiten. PowerShell scripts kunnen worden geconfigureerd om regelmatig de registerinstellingen te controleren op alle apparaten binnen de organisatie, en kunnen automatisch waarschuwingen genereren wanneer afwijkingen worden gedetecteerd. Deze scripts kunnen worden geïntegreerd met bestaande monitoring- en compliance-rapportagesystemen, waardoor beheerders een centraal overzicht krijgen van de compliancestatus van de WebHID API blokkering door de gehele organisatie. Daarnaast kunnen deze scripts worden uitgebreid om ook andere relevante informatie te verzamelen, zoals welke apparaten mogelijk niet-compliant zijn, welke gebruikers verzoeken hebben ingediend voor uitzonderingen, en welke trends zichtbaar zijn in de monitoringdata.

Gebruik PowerShell-script webhid-api-blocked.ps1 (functie Invoke-Monitoring) – Controleert of WebHID API correct is geblokkeerd.

Compliance en Audit

De implementatie van de WebHID API blokkering draagt bij aan de naleving van verschillende belangrijke beveiligings- en compliance frameworks die relevant zijn voor Nederlandse overheidsorganisaties en bedrijven die opereren in kritieke sectoren. Deze control vormt een essentieel onderdeel van een brede beveiligingsstrategie die voldoet aan zowel internationale standaarden als Nederlandse specifieke vereisten. Het is belangrijk voor organisaties om te begrijpen hoe deze control bijdraagt aan hun compliance-doelstellingen, zodat ze deze kunnen documenteren tijdens audits en compliance-beoordelingen. Binnen het CIS Microsoft Edge Benchmark framework valt deze control onder de categorie Hardware API Security. Het CIS Benchmark voor Microsoft Edge bevat specifieke aanbevelingen voor het beveiligen van browser-gebaseerde hardwaretoegang, waarbij de WebHID API wordt geïdentificeerd als een potentieel beveiligingsrisico dat moet worden beperkt. Door deze control te implementeren, voldoen organisaties aan de CIS-aanbevelingen voor het minimaliseren van het aanvalsoppervlak dat wordt blootgesteld door browser APIs die directe hardwaretoegang bieden. De CIS Benchmarks worden algemeen erkend als best practices voor cybersecurity, en het volgen van deze aanbevelingen helpt organisaties om hun beveiligingspostuur te verbeteren en te voldoen aan industrie-standaarden. Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van bijzonder belang. Deze control draagt direct bij aan BIO control 12.06, die betrekking heeft op het beheer van technische kwetsbaarheden. Door de WebHID API te blokkeren, wordt een potentiële technische kwetsbaarheid geëlimineerd die anders zou kunnen worden misbruikt door aanvallers om toegang te krijgen tot kritieke systemen of om gegevens te exfiltreren. Daarnaast voldoet deze control aan BIO control 13.01, die betrekking heeft op apparaattoegangsbeheer. Het blokkeren van ongeautoriseerde toegang tot HID-apparaten via webbrowsers vormt een belangrijk onderdeel van effectief apparaattoegangsbeheer, waarbij organisaties ervoor zorgen dat alleen geautoriseerde processen en applicaties toegang hebben tot hardware-interfaces. Voor Nederlandse overheidsorganisaties is het implementeren van BIO controls niet alleen een best practice, maar ook een wettelijke verplichting. De internationale ISO 27001 standaard voor informatiebeveiligingsmanagement bevat verschillende controls die relevant zijn voor deze implementatie. ISO 27001 control A.12.6.1 richt zich op het beheer van technische kwetsbaarheden, waarbij organisaties worden verplicht om technische kwetsbaarheden te identificeren, te evalueren en te mitigeren. De WebHID API vormt een technische kwetsbaarheid omdat het een onnodig uitgebreid aanvalsoppervlak creëert, en door deze te blokkeren, voldoen organisaties aan de vereisten van deze control. Daarnaast draagt de implementatie bij aan ISO 27001 control A.11.2.6, die betrekking heeft op de beveiliging van apparatuur. Door te voorkomen dat websites directe toegang krijgen tot HID-apparaten, wordt de beveiliging van aangesloten apparatuur verbeterd, wat met name belangrijk is voor organisaties die werken met gespecialiseerde hardware of industriële systemen. ISO 27001 certificering vereist dat organisaties kunnen aantonen dat ze effectieve controls hebben geïmplementeerd voor het beheren van beveiligingsrisico's. De NIS2 richtlijn, die van toepassing is op organisaties in kritieke sectoren zoals energie, transport, en financiële dienstverlening, bevat in Artikel 21 specifieke vereisten voor de beveiliging tegen ongeautoriseerde apparaattoegang. Deze control draagt direct bij aan de naleving van deze vereisten door te voorkomen dat kwaadaardige websites ongeautoriseerde toegang kunnen krijgen tot HID-apparaten die op systemen zijn aangesloten. Voor organisaties die onder de NIS2 richtlijn vallen, is het implementeren van deze control niet alleen een best practice, maar ook een compliance-vereiste die moet worden gedocumenteerd en geaudit. De NIS2 richtlijn verplicht organisaties om passende technische en organisatorische maatregelen te nemen om hun systemen te beveiligen tegen cyberdreigingen, en het blokkeren van onnodige hardware-API's vormt een belangrijk onderdeel van deze maatregelen. Bij het voorbereiden van compliance-audits dienen organisaties documentatie te verzamelen die aantoont dat deze control correct is geïmplementeerd en wordt gemonitord. Dit omvat screenshots van Intune-beleidsconfiguraties, exports van registerinstellingen, compliance-rapporten van monitoring scripts, en gedocumenteerde uitzonderingen indien van toepassing. Deze documentatie moet worden bewaard voor de volledige auditperiode, wat voor de meeste frameworks minimaal zeven jaar is, om te kunnen aantonen dat de organisatie continu heeft voldaan aan de compliance-vereisten. Het is belangrijk om deze documentatie regelmatig te updaten en te verifiëren dat alle benodigde informatie beschikbaar is voor auditors wanneer deze wordt gevraagd.

Remediatie

Wanneer tijdens monitoring wordt vastgesteld dat de WebHID API blokkering niet correct is geconfigureerd of is omzeild, moet onmiddellijk remediatie worden uitgevoerd om de beveiligingscontrol te herstellen. Remediatie kan worden uitgevoerd via verschillende methoden, afhankelijk van hoe de oorspronkelijke implementatie is gedaan en wat de oorzaak is van de niet-naleving. Het is belangrijk om snel te handelen wanneer niet-naleving wordt gedetecteerd, omdat elke periode waarin de WebHID API niet is geblokkeerd, het aanvalsoppervlak vergroot en organisaties blootstelt aan potentiële beveiligingsrisico's zoals keylogging en hardware-gebaseerde aanvallen. Voor apparaten die zijn beheerd via Microsoft Intune, kan remediatie worden uitgevoerd door het Intune-beleid opnieuw toe te passen of door te verifiëren dat het beleid correct is toegewezen aan de betreffende apparaten. In sommige gevallen kan het nodig zijn om het apparaat opnieuw te synchroniseren met Intune, of om de gebruiker te vragen het apparaat opnieuw op te starten zodat de beleidsinstellingen opnieuw worden toegepast. Als het beleid niet correct is geconfigureerd in Intune zelf, moet dit worden gecorrigeerd in het Intune-beheercentrum, waarna de wijzigingen automatisch worden doorgevoerd naar alle toegewezen apparaten. Het is belangrijk om te verifiëren dat de remediatie succesvol is geweest door de registerinstellingen opnieuw te controleren na het uitvoeren van de remediatie-acties. Voor apparaten die zijn beheerd via Group Policy Objects (GPO), kan remediatie worden uitgevoerd door de GPO opnieuw toe te passen via de Group Policy Management Console. Beheerders kunnen handmatig een gpupdate /force commando uitvoeren op het betreffende apparaat, of kunnen wachten tot de volgende automatische Group Policy-vernieuwingscyclus. Als de GPO zelf niet correct is geconfigureerd, moet dit worden gecorrigeerd in de Group Policy Management Console, waarna de wijzigingen worden doorgevoerd bij de volgende beleidsvernieuwing. Het is belangrijk om te begrijpen dat Group Policy-vernieuwingscycli normaal gesproken elke 90 minuten plaatsvinden, maar in geval van urgente remediatie kan het handmatig forceren van een vernieuwing sneller resultaat opleveren. In gevallen waar lokale registerwijzigingen de beleidsinstellingen hebben overschreven, moet de registerwaarde handmatig worden hersteld. Dit kan worden gedaan via de Register-editor, waarbij de DefaultWebHidGuardSetting-waarde in het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge moet worden ingesteld op 2 (DWORD). Echter, als lokale wijzigingen mogelijk zijn, duidt dit op een fundamenteel probleem met de beveiligingsconfiguratie, aangezien eindgebruikers of lokale beheerders niet in staat zouden moeten zijn om deze instellingen te wijzigen. In dergelijke gevallen moet ook de toegangscontrole worden geëvalueerd en verbeterd om te voorkomen dat dit probleem opnieuw optreedt. Het is belangrijk om te onderzoeken hoe de lokale wijziging heeft kunnen plaatsvinden, zodat structurele maatregelen kunnen worden genomen om te voorkomen dat dit in de toekomst opnieuw gebeurt. Geautomatiseerde remediatie via PowerShell scripts biedt de meest efficiënte en betrouwbare methode voor het herstellen van de WebHID API blokkering op meerdere apparaten tegelijkertijd. Deze scripts kunnen worden geconfigureerd om automatisch te worden uitgevoerd wanneer niet-naleving wordt gedetecteerd, of kunnen handmatig worden uitgevoerd door beheerders wanneer nodig. De scripts verifiëren eerst de huidige configuratie, en als deze niet correct is, worden de benodigde registerwijzigingen automatisch doorgevoerd om de beveiligingscontrol te herstellen. Geautomatiseerde remediatie vermindert niet alleen de tijd die nodig is om problemen op te lossen, maar zorgt ook voor consistentie in de manier waarop remediatie wordt uitgevoerd, waardoor de kans op menselijke fouten wordt geminimaliseerd. Na het uitvoeren van remediatie is het belangrijk om te verifiëren dat de remediatie succesvol is geweest. Dit kan worden gedaan door de registerinstellingen opnieuw te controleren, of door gebruik te maken van dezelfde monitoring scripts die worden gebruikt voor reguliere compliance-controles. Als de remediatie niet succesvol is, moet een diepere analyse worden uitgevoerd om te bepalen wat de onderliggende oorzaak is van het probleem, zodat structurele oplossingen kunnen worden geïmplementeerd die voorkomen dat het probleem opnieuw optreedt. Het is belangrijk om alle remediatie-acties te documenteren, inclusief wat het probleem was, welke acties zijn ondernomen om het op te lossen, en of de remediatie succesvol was. Deze documentatie kan waardevol zijn voor toekomstige probleemoplossing en voor compliance-doeleinden.

Gebruik PowerShell-script webhid-api-blocked.ps1 (functie Invoke-Remediation) – Herstelt de WebHID API blokkering wanneer deze niet correct is geconfigureerd.

Compliance & Frameworks

• CIS M365: Control Edge Security - Hardware APIs (L2) - WebHID API moet zijn geblokkeerd om HID device toegang te beperken
• BIO: 12.06.01, 13.01.03 - Kwetsbaarheidsbeheer en apparaattoegangsbeheer
• ISO 27001:2022: A.12.6.1, A.11.2.6 - Technische kwetsbaarheden en apparaatbeveiliging
• NIS2: Artikel - Beveiliging van systemen en toegangsbeheer

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Blokkeer WebHID API om te voorkomen dat websites toegang krijgen tot HID-apparaten zoals toetsenborden en gamepads. WebHID is zelden nodig en vormt een beveiligingsrisico. Standaard geblokkeerd maar beleidsinstelling dwingt dit af. Implementatie: 30 minuten.

• Implementatietijd: 1 uur
• FTE required: 0.01 FTE