Windows-beveiligingsmodel voor ontwikkelaars van stuurprogramma's

Het Windows-beveiligingsmodel is gebaseerd op beveiligbare objecten. Elk onderdeel van het besturingssysteem moet de beveiliging garanderen van de objecten waarvoor het verantwoordelijk is. Bestuurders moeten daarom de beveiliging van hun apparaten en device-objecten waarborgen.

In dit onderwerp wordt beschreven hoe het Windows-beveiligingsmodel van toepassing is op stuurprogramma's in de kernelmodus.

Windows-beveiligingsmodel

Het Windows-beveiligingsmodel is voornamelijk gebaseerd op rechten per object, met een klein aantal systeembrede bevoegdheden. Objecten die kunnen worden beveiligd, zijn onder andere processen, threads, gebeurtenissen en andere synchronisatieobjecten, maar ook bestanden, mappen en apparaten, maar niet beperkt tot, processen, threads, gebeurtenissen en andere synchronisatieobjecten.

Voor elk type object worden de algemene lees-, schrijf- en uitvoerrechten omgezet in gedetailleerde objectspecifieke rechten. Voor bestanden en mappen zijn mogelijke rechten bijvoorbeeld het recht om het bestand of de map te lezen of te schrijven, het recht om uitgebreide bestandskenmerken te lezen of te schrijven, het recht om een map te doorlopen en het recht om de beveiligingsdescriptor van een object te schrijven.

Het beveiligingsmodel omvat de volgende concepten:

• Beveiligings-ID's (SIDs)
• Toegangstokens
• Beveiligingsdescriptors
• Toegangsbeheerlijsten (ACL's)
• Privileges

Beveiligings-id's (SIDs)

Een beveiligings-id (SID, ook wel een principalgenoemd) identificeert een gebruiker, een groep of een aanmeldingssessie. Elke gebruiker heeft een unieke SID, die wordt opgehaald door het besturingssysteem bij aanmelding.

SID's worden uitgegeven door een instantie zoals het besturingssysteem of een domeinserver. Sommige SID's zijn bekend en hebben namen en id's. De SID S-1-1-0 identificeert bijvoorbeeld Iedereen (of Wereld).

Toegangstokens

Elk proces heeft een toegangstoken. Het toegangstoken beschrijft de volledige beveiligingscontext van het proces. Het bevat de SID van de gebruiker, de SID van de groepen waartoe de gebruiker behoort, en de SID van de aanmeldingssessie, evenals een lijst met de systeembrede bevoegdheden die aan de gebruiker zijn verleend.

Het systeem gebruikt standaard het primaire toegangstoken voor een proces wanneer een thread van het proces communiceert met een beveiligbaar object. Een thread kan echter een clientaccount imiteren. Wanneer een thread imiteert, heeft deze een imitatietoken naast het eigen primaire token. Het imitatietoken beschrijft de beveiligingscontext van het gebruikersaccount dat de thread nabootst. Imitatie is vooral gebruikelijk bij RPC-verwerking (Remote Procedure Call).

Een toegangstoken dat een beperkte beveiligingscontext voor een thread of proces beschrijft, wordt een beperkt token genoemd. De SID's in een beperkt token kunnen alleen worden ingesteld om toegang te weigeren, niet om toegang toe te staan, voor beveiligbare objecten. Daarnaast kan het token een beperkte set systeembrede bevoegdheden beschrijven. De SID en identiteit van de gebruiker blijven hetzelfde, maar de toegangsrechten van de gebruiker zijn beperkt terwijl het proces het beperkte token gebruikt. Met de functie CreateRestrictedToken maakt u een beperkt token.

Beveiligingsdescriptors

Elk benoemd Windows-object heeft een beveiligingsdescriptor; sommige niet-benoemde objecten doen dat ook. In de beveiligingsdescriptor worden de eigenaar- en groeps-SID's voor het object samen met de ACL's beschreven.

De beveiligingsdescriptor van een object wordt meestal gemaakt door de functie waarmee het object wordt gemaakt. Wanneer een stuurprogramma de IoCreateDevice of IoCreateDeviceSecure-routine aanroept om een apparaatobject te maken, past het systeem een beveiligingsdescriptor toe op het gemaakte apparaatobject en stelt ACL's in voor het object. Voor de meeste apparaten worden ACL's opgegeven in het INF-bestand (Device Information).

Zie de documentatie voor kernelstuurprogramma's voor meer informatie Security Descriptors.

Toegangsbeheerlijsten

Toegangsbeheerlijsten (ACL's) maken fijnmazige controle over toegang tot objecten mogelijk. Een ACL maakt deel uit van de beveiligingsdescriptor voor elk object.

Elke ACL bevat nul of meer toegangsbeheervermeldingen (ACE). Elke ACE bevat op zijn beurt één SID die een gebruiker, groep of computer identificeert en een lijst met rechten die zijn geweigerd of toegestaan voor die SID.

ACL's voor apparaatobjecten

De ACL voor een apparaatobject kan op drie manieren worden ingesteld:

• Instellen in de standaardbeveiligingsdescriptor voor het apparaattype.
• Programmatisch gemaakt door de functie RtlCreateSecurityDescriptor en ingesteld door de functie RtlSetDaclSecurityDescriptor.
• Opgegeven in Security Descriptor Definition Language (SDDL) in het INF-bestand van het apparaat of in een aanroep naar de IoCreateDeviceSecure routine.

Alle stuurprogramma's moeten SDDL in het INF-bestand gebruiken om ACL's voor hun apparaatobjecten op te geven.

SDDL is een uitbreidbare beschrijvingstaal waarmee onderdelen ACL's in een tekenreeksindeling kunnen maken. SDDL wordt gebruikt door zowel gebruikersmodus- als kernelmoduscode. In de volgende afbeelding ziet u de indeling van SDDL-tekenreeksen voor apparaatobjecten.

De access-waarde geeft het type toegang op dat is toegestaan. De SID-waarde geeft een beveiligings-id op die bepaalt aan wie de Access-waarde van toepassing is (bijvoorbeeld een gebruiker of groep).

Met de volgende SDDL-tekenreeks is bijvoorbeeld de systeemtoegang (SY) tot alles toegestaan en staat iedereen (WD) alleen leestoegang toe:

“D:P(A;;GA;;;SY)(A;;GR;;;WD)”

Het headerbestand wdmsec.h bevat ook een set vooraf gedefinieerde SDDL-tekenreeksen die geschikt zijn voor apparaatobjecten. Het headerbestand definieert bijvoorbeeld SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX als volgt:

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"

Met het eerste segment van deze tekenreeks kan de kernel en het besturingssysteem (SY) volledige controle over het apparaat uitvoeren. Met het tweede segment kan iedereen in de ingebouwde groep Administrators (BA) toegang krijgen tot het hele apparaat, maar kan de ACL niet wijzigen. Met het derde segment kan iedereen (WD) naar het apparaat lezen of schrijven en verleent het vierde segment dezelfde rechten aan niet-vertrouwde code (RC). Stuurprogramma's kunnen de vooraf gedefinieerde tekenreeksen als zodanig gebruiken of als modellen voor apparaatobjectspecifieke tekenreeksen.

Alle apparaatobjecten in een stack moeten dezelfde ACL's hebben. Als u de ACL's op één apparaatobject in de stack wijzigt, worden de ACL's op de hele apparaatstack gewijzigd.

Als u echter een nieuw apparaatobject toevoegt aan de stack, worden er geen ACL's gewijzigd, ofwel die van het nieuwe apparaatobject (als het ACL's bevat) of die van bestaande apparaatobjecten in de stack. Wanneer een stuurprogramma een nieuw apparaatobject maakt en het aan de bovenkant van de stack koppelt, moet het stuurprogramma de ACL's voor de stack naar het nieuwe apparaatobject kopiëren door het veld DeviceObject.Characteristics te kopiëren vanaf het volgende lagere stuurprogramma.

De IoCreateDeviceSecure routine ondersteunt een subset van SDDL-tekenreeksen die gebruikmaken van vooraf gedefinieerde SID's zoals WD en SY. API's en INF-bestanden in de gebruikersmodus ondersteunen de volledige SDDL-syntaxis.

Beveiligingscontroles met ACL's

Wanneer een proces toegang tot een object aanvraagt, worden de ACL's voor het object vergeleken met de SID's in het toegangstoken van de aanroeper.

Het systeem vergelijkt de ACE's in een strikt top-down volgorde en stopt bij de eerste relevante overeenkomende entry. Daarom moet u bij het maken van een ACL altijd de ontkennende toegangsbeheerelementen boven de bijbehorende toekennende toegangsbeheerelementen plaatsen. In de volgende voorbeelden ziet u hoe de vergelijking verloopt.

voorbeeld 1: een ACL vergelijken met een toegangstoken

Voorbeeld 1 laat zien hoe het systeem een ACL vergelijkt met het toegangstoken voor het proces van een beller. Stel dat de beller een bestand wil openen met de ACL die wordt weergegeven in de volgende tabel.

ACL-voorbeeldbestand

Toestemming	SID	Toegang
Toestaan	Boekhouding	Schrijven, verwijderen
Toestaan	Verkoop	Toevoegen
Ontkennen	Juridisch	Toevoegen, schrijven, verwijderen
Toestaan	Iedereen	Lezen

Deze ACL heeft vier ACE's, die specifiek van toepassing zijn op de groepen Accounting, Sales, Legal en Iedereen.

Stel vervolgens dat het toegangstoken voor het aanvraagproces SID's bevat voor één gebruiker en drie groepen, in de volgende volgorde:

Gebruiker Jim (S-1-5-21...)

Groepsboekhouding (S-1-5-22...)

Juridische groep (S-1-5-23...)

Groep Iedereen (S-1-1-0)

Wanneer u een bestands-ACL vergelijkt met een toegangstoken, zoekt het systeem eerst naar een ACE voor gebruiker Jim in de ACL van het bestand. Er verschijnt niets, dus vervolgens wordt er gezocht naar een ACE met betrekking tot de groep Accounting. Zoals in de vorige tabel wordt weergegeven, wordt een ACE voor de groep Accounting weergegeven als de eerste vermelding in de ACL van het bestand. Jim's proces krijgt dus het recht om het bestand te schrijven of te verwijderen en de vergelijking stopt. Als de ACE voor de juridische groep in plaats daarvan voorafging aan de ACE voor de groep Accounting in de ACL, wordt het proces geweigerd schrijf-, toevoeg- en verwijdertoegang tot het bestand.

voorbeeld 2: een ACL vergelijken met een beperkt token

Het systeem vergelijkt een ACL met een beperkt token op dezelfde manier als het een ACL vergelijkt met een token dat niet beperkt is. Een denial-SID in een beperkt token kan echter alleen overeenkomen met een Deny-ACE in een ACL.

Voorbeeld 2 laat zien hoe het systeem de ACL van een bestand vergelijkt met een beperkt token. Stel dat het bestand dezelfde ACL heeft die in de vorige tabel wordt weergegeven. In dit voorbeeld heeft het proces echter een beperkt token dat de volgende SID's bevat:

Gebruiker Jim (S-1-5-21...) Weigeren

Groepsboekhouding (S-1-5-22...) Ontkennen

Groep Legal (S-1-5-23...) Weigeren

Groep Iedereen (S-1-1-0)

De ACL van het bestand vermeldt de SID van Jim niet, dus het systeem gaat naar de SID van de Accounting-groep. Hoewel de ACL van het bestand een ACE voor de groep Accounting heeft, biedt deze ACE toegang; Daarom komt deze niet overeen met de SID in het beperkte token van het proces, waardoor de toegang wordt geweigerd. Als gevolg hiervan gaat het systeem naar de SID van de juridische groep. De ACL voor het bestand bevat een ACE voor de juridische groep die de toegang weigert, zodat het proces het bestand niet kan schrijven, toevoegen of verwijderen.

Privileges

Een bevoegdheid is het recht voor een gebruiker om een systeemgerelateerde bewerking uit te voeren op de lokale computer, zoals het laden van een stuurprogramma, het wijzigen van de tijd of het afsluiten van het systeem.

Bevoegdheden verschillen van de toegangsrechten omdat ze van toepassing zijn op systeemgerelateerde taken en resources in plaats van op objecten, en omdat ze worden toegewezen aan een gebruiker of groep door een systeembeheerder, in plaats van door het besturingssysteem.

Het toegangstoken voor elk proces bevat een lijst met de bevoegdheden die aan het proces zijn verleend. Bevoegdheden moeten specifiek zijn ingeschakeld voordat u deze gebruikt. Zie Bevoegdheden in de documentatie van het kernelstuurprogramma voor meer informatie over bevoegdheden.

Beveiligingsgerelateerde foutopsporingsprogramma-opdrachten

De extensie !acl formatteert en geeft de inhoud van een ACL (Access Control List) weer. Zie De ACL van een object en !aclvoor meer informatie.

De extensie !token geeft een opgemaakte weergave van een beveiligingstokenobject weer. Zie !tokenvoor meer informatie.

In de extensie !tokenfields worden de namen en verschuivingen van de velden binnen het toegangstokenobject (de tokenstructuur) weergegeven. Zie !tokenfieldsvoor meer informatie.

De !sid-extensie geeft de beveiligings-id (SID) weer op het opgegeven adres. Zie !sidvoor meer informatie.

De extensie !sd geeft de beveiligingsdescriptor weer op het opgegeven adres. Zie !sdvoor meer informatie.

Windows-beveiligingsmodelscenario: een bestand maken

Het systeem maakt gebruik van de beveiligingsconstructies die worden beschreven in het Windows-beveiligingsmodel wanneer een proces een ingang voor een bestand of object maakt.

In het volgende diagram ziet u de beveiligingsgerelateerde acties die worden geactiveerd wanneer een gebruikersmodusproces probeert een bestand te maken.

In het vorige diagram ziet u hoe het systeem reageert wanneer een toepassing in de gebruikersmodus de CreateFile functie aanroept. De volgende notities verwijzen naar de omcirkelde getallen in de afbeelding:

1. Een toepassing in de gebruikersmodus roept de functie CreateFile aan, waarbij een geldige Microsoft Win32-bestandsnaam wordt doorgegeven.
2. De gebruikersmodus Kernel32.dll de aanvraag doorgeeft aan Ntdll.dll, waarmee de Win32-naam wordt geconverteerd naar een Microsoft Windows NT-bestandsnaam.
3. Ntdll.dll roept de functie NtCreateFile aan met de windows-bestandsnaam. Binnen Ntoskrnl.exeverwerkt de I/O-manager NtCreateFile.
4. De I/O-beheer verpakt de aanvraag opnieuw in een Objectbeheer-aanroep.
5. Objectbeheer lost symbolische koppelingen op en zorgt ervoor dat de gebruiker doorkruisrechten heeft voor het pad waarin het bestand wordt gemaakt. Zie Security-controles in de objectbeheer-voor meer informatie.
6. Objectbeheer roept het systeemonderdeel aan dat eigenaar is van het onderliggende objecttype dat aan de aanvraag is gekoppeld. Voor een aanvraag voor het maken van een bestand is dit onderdeel de I/O-beheerder, die eigenaar is van apparaatobjecten.
7. De I/O-beheerder controleert de beveiligingsdescriptor van het apparaatobject tegen het toegangstoken voor het proces van de gebruiker om ervoor te zorgen dat de gebruiker over de vereiste toegang tot het apparaat beschikt. Voor meer informatie, zie veiligheidscontroles in de I/O Manager.
8. Als het gebruikersproces de vereiste toegang heeft, maakt de I/O-manager een handle en verzendt het een IRP_MJ_CREATE-verzoek naar het stuurprogramma van het apparaat of het bestandssysteem.
9. De bestuurder voert indien nodig extra beveiligingscontroles uit. Als de aanvraag bijvoorbeeld een object opgeeft in de naamruimte van het apparaat, moet het stuurprogramma ervoor zorgen dat de beller over de vereiste toegangsrechten beschikt. Voor meer informatie, zie Beveiligingscontroles in het stuurprogramma.

Beveiligingscontroles in Objectbeheer

De verantwoordelijkheid voor het controleren van toegangsrechten behoort tot het hoogste niveau dat dergelijke controles kan uitvoeren. Als objectbeheer de toegangsrechten van de beller kan verifiëren, doet dit dit. Als dat niet het geval is, wordt de aanvraag doorgegeven aan het onderdeel dat verantwoordelijk is voor het onderliggende objecttype. Dat onderdeel verifieert op zijn beurt de toegang, indien mogelijk; Als dat niet het geval is, wordt de aanvraag doorgegeven aan een nog lager onderdeel, zoals een stuurprogramma.

Objectbeheer controleert ACL's op eenvoudige objecttypen, zoals gebeurtenissen en mutex-vergrendelingen. Voor objecten met een naamruimte voert de eigenaar van het type beveiligingscontroles uit. De I/O-manager wordt bijvoorbeeld beschouwd als de type-eigenaar voor apparaatobjecten en bestandsobjecten. Als objectbeheer de naam van een apparaatobject of een bestandsobject vindt bij het parseren van een naam, geeft het de naam af aan de I/O-beheer, zoals in het bovenstaande scenario voor het maken van bestanden. De I/O-beheer controleert vervolgens de toegangsrechten, indien mogelijk. Als de naam een object in een apparaatruimte specificeert, geeft de I/O Manager de naam door aan het stuurprogramma van het apparaat (of van het bestandssysteem), en dat stuurprogramma is verantwoordelijk voor het controleren van de gevraagde toegang.

Beveiligingscontroles in I/O-beheer

Wanneer de I/O Manager een handle maakt, controleert het de rechten van het object tegen het toegangstoken van het proces en slaat vervolgens de verleende rechten aan de gebruiker samen met de handle op. Wanneer latere I/O-aanvragen binnenkomen, controleert de I/O-beheer de rechten die aan de ingang zijn gekoppeld om ervoor te zorgen dat het proces het recht heeft om de aangevraagde I/O-bewerking uit te voeren. Als het proces later bijvoorbeeld een schrijfbewerking aanvraagt, controleert de I/O-beheer de rechten die aan de ingang zijn gekoppeld om ervoor te zorgen dat de beller schrijftoegang tot het object heeft.

Als het handvat wordt gedupliceerd, kunnen rechten uit de kopie worden verwijderd, maar er kunnen geen rechten aan worden toegevoegd.

Wanneer I/O-beheer een object maakt, worden algemene Win32-toegangsmodi geconverteerd naar objectspecifieke rechten. De volgende rechten zijn bijvoorbeeld van toepassing op bestanden en mappen:

Win32-toegangsmodus	Objectspecifieke rechten
GENERIC_READ	LeesGegevens
ALGEMEEN_SCHRIJVEN	GegevensSchrijven
ALGEMEEN_UITVOEREN	ReadAttributes
GENERIC_ALL	Alle

Om een bestand te maken, moet een proces doorgangsrechten hebben voor de bovenliggende mappen in het doelpad. Als u bijvoorbeeld \Device\CDROM0\Directory\File.txtwilt maken, moet een proces het recht hebben om \Device, \Device\CDROM0 en \Device\CDROM0\Directory te doorlopen. De I/O Manager controleert alleen de traversal-rechten voor deze directories.

I/O Manager controleert traversal-rechten wanneer de bestandsnaam wordt geparseerd. Als de bestandsnaam een symbolische koppeling is, zet de I/O-manager deze om in een volledig pad en controleert de traversal-rechten, te beginnen vanaf de root. Stel dat de symbolische koppeling \DosDevices\D wordt toegewezen aan de windows NT-apparaatnaam \Device\CDROM0. Het proces moet traversierechten hebben voor de directory \Device.

Zie Object handles en Object Securityvoor meer informatie.

Beveiligingscontroles in het stuurprogramma

De kernel van het besturingssysteem behandelt elk stuurprogramma, in feite, als een bestandssysteem met een eigen naamruimte. Wanneer een beller probeert een object te maken in de apparaatnaamruimte, controleert de I/O-manager daardoor of het proces doorkruisrechten heeft voor de mappen in het pad.

Met WDM-stuurprogramma's voert de I/O-manager geen beveiligingscontroles uit op de naamruimte, tenzij het Apparaatobject is aangemaakt met FILE_DEVICE_SECURE_OPEN. Wanneer FILE_DEVICE_SECURE_OPEN niet is ingesteld, is het stuurprogramma verantwoordelijk voor de beveiliging van de naamruimte. Zie Apparaatnaamruimtetoegang beheren en Apparaatobjecten beveiligenvoor meer informatie.

Voor WDF-stuurprogramma's is de vlag FILE_DEVICE_SECURE_OPEN altijd ingesteld, zodat de beveiligingsdescriptor van het apparaat wordt gecontroleerd voordat een toepassing toegang krijgt tot namen binnen de naamruimte van het apparaat. Zie Apparaattoegang beheren in KMDF-stuurprogramma'svoor meer informatie.

Windows-beveiligingsgrenzen

Stuurprogramma's die met elkaar communiceren en gebruikersmodusaanroepen van verschillende bevoegdheidsniveaus kunnen worden beschouwd als het overschrijden van een vertrouwensgrens. Een vertrouwensgrens is een pad voor het uitvoeren van code dat van een lager bevoegd proces naar een proces met hogere bevoegdheden gaat.

Hoe hoger de verschillen in de bevoegdheidsniveaus, hoe interessanter de grens is voor aanvallers die aanvallen willen uitvoeren, zoals een aanval op escalatie van bevoegdheden tegen het beoogde stuurprogramma of proces.

Een onderdeel van het proces voor het maken van een bedreigingsmodel is het onderzoeken van de beveiligingsgrenzen en het zoeken naar onverwachte paden. Zie bedreigingsmodellering voor stuurprogramma'svoor meer informatie.

Alle gegevens die een vertrouwensgrens overschrijden, worden niet vertrouwd en moeten worden gevalideerd.

In dit diagram ziet u drie kernelstuurprogramma's en twee apps, één in een app-container en één app die wordt uitgevoerd met beheerdersrechten. De rode lijnen geven voorbeelden van vertrouwensgrenzen aan.

Omdat de app-container aanvullende beperkingen kan bieden en niet op beheerniveau wordt uitgevoerd, is pad (1) een hoger risicopad voor een escalatieaanval, omdat de grens van een vertrouwensrelatie zich bevindt tussen een app-container (een zeer laag bevoegdheidsproces) en een kernelstuurprogramma.

Pad (2) is een lager risicopad, omdat de app wordt uitgevoerd met beheerdersrechten en rechtstreeks aanroept naar het kernelstuurprogramma. Beheerder heeft al een redelijk hoge bevoegdheid op het systeem, waardoor het aanvalsoppervlak van beheerder naar kernel minder aantrekkelijk is voor aanvallers. Het blijft echter een opmerkelijk vertrouwensgrensgebied.

Pad (3) is een voorbeeld van een codeuitvoeringspad dat meerdere vertrouwensgrenzen overschrijdt die kunnen worden gemist als er geen bedreigingsmodel wordt gemaakt. In dit voorbeeld is er een vertrouwensgrens tussen stuurprogramma 1 en stuurprogramma 3, omdat stuurprogramma 1 invoer van de gebruikersmodus-app neemt en deze rechtstreeks doorgeeft aan stuurprogramma 3.

Alle invoer die afkomstig is van het stuurprogramma van de gebruikersmodus, is niet vertrouwd en moet worden gevalideerd. Invoer afkomstig van andere stuurprogramma's kan ook niet worden vertrouwd, afhankelijk van of het vorige stuurprogramma slechts een eenvoudige passthrough was (bijvoorbeeld gegevens zijn ontvangen door stuurprogramma 1 van app 1, stuurprogramma 1 heeft geen validatie uitgevoerd op de gegevens en deze doorgegeven aan stuurprogramma 3). Zorg ervoor dat u alle kwetsbaarheid voor aanvallen en vertrouwensrelaties identificeert en alle gegevens die deze overschrijden, kunt valideren door een volledig bedreigingsmodel te maken.

Aanbevelingen voor Windows-beveiligingsmodellen

• Stel sterke standaardwaarden voor ACL's in voor oproepen naar de IoCreateDeviceSecure routine.
• Geef ACL's op in het INF-bestand voor elk apparaat. Deze ACL's kunnen zo nodig strakke standaard-ACL's losmaken.
• Stel het kenmerk FILE_DEVICE_SECURE_OPEN in om beveiligingsinstellingen voor apparaatobjecten toe te passen op de apparaatnaamruimte.
• Definieer geen IOCTL's die FILE_ANY_ACCESS toestaan, tenzij dergelijke toegang kwaadwillig kan worden misbruikt.
• Gebruik de IoValidateDeviceIoControlAccess routine om de beveiliging van bestaande IOCTLS aan te scherpen die FILE_ANY_ACCESS toestaan.
• Maak een bedreigingsmodel om de beveiligingsgrenzen te onderzoeken en te zoeken naar onverwachte paden. Zie Threat Modeling voor stuurprogramma'svoor meer informatie.
• Zie controlelijst voor stuurprogrammabeveiliging voor aanvullende aanbevelingen voor stuurprogrammabeveiliging.

Zie ook

apparaatobjecten beveiligen

Chauffeurveiligheidscontrolelijst