Bedreigingsmodellering voor stuurprogramma's

Stuurprogrammaschrijvers en architecten moeten bedreigingsmodellering een integraal onderdeel van het ontwerpproces voor elke bestuurder maken. Dit onderwerp bevat richtlijnen voor het maken van bedreigingsmodellen voor Windows-stuurprogramma's.

Beveiliging moet een fundamenteel ontwerppunt zijn voor elk stuurprogramma. Elk succesvol product is een doel. Als u een stuurprogramma voor Windows schrijft, moet u ervan uitgaan dat iemand uw stuurprogramma ergens probeert te gebruiken om de systeembeveiliging in gevaar te komen.

Het ontwerpen van een beveiligd stuurprogramma omvat:

• Het identificeren van de punten waarop de bestuurder kwetsbaar kan zijn voor een aanval.
• Analyseren van de typen aanvallen die op elk van deze punten kunnen worden uitgevoerd.
• Ervoor zorgen dat de bestuurder zodanig is ontworpen dat dergelijke aanvallen worden gewist.

Threat modeling is een gestructureerde benadering van deze belangrijke ontwerptaken. Een bedreigingsmodel is een manier om de bedreigingen voor een asset te categoriseren en te analyseren. Vanuit het perspectief van een stuurprogrammaschrijver zijn de assets de hardware, software en gegevens op de computer of het netwerk.

Een bedreigingsmodel beantwoordt de volgende vragen:

• Welke assets hebben bescherming nodig?
• Voor welke bedreigingen zijn de middelen kwetsbaar?
• Hoe belangrijk of waarschijnlijk is elke bedreiging?
• Hoe kunt u de bedreigingen beperken?

Bedreigingsmodellering is een belangrijk onderdeel van het softwareontwerp, omdat het ervoor zorgt dat beveiliging in het product is ingebouwd, in plaats van te worden aangepakt als een naverdenking. Een goed bedreigingsmodel kan helpen bij het vinden en voorkomen van bugs tijdens het ontwerpproces, waardoor mogelijk kostbare patches later en mogelijke reputatieschade aan uw organisatie worden geëlimineerd.

In deze sectie worden de principes van bedreigingsmodellering toegepast op het ontwerp van stuurprogramma's en worden voorbeelden weergegeven van bedreigingen waarop een stuurprogramma mogelijk vatbaar is. Raadpleeg deze resources voor een uitgebreidere beschrijving van bedreigingsmodellering voor softwareontwerp.

• De Microsoft SDL-website:

  https://www.microsoft.com/sdl

• Vereenvoudigde implementatie van de Microsoft SDL:

  Whitepaper downloaden

• In dit blogbericht wordt beschreven hoe u een gratis kopie van The Security Development Lifecycle: SDL, door Michael Howard en Steve Lipner downloadt:

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

Bedreigingsmodellen maken voor stuurprogramma's

Het maken van een bedreigingsmodel vereist een grondig begrip van het ontwerp van het stuurprogramma, de typen bedreigingen waarop het stuurprogramma kan worden blootgesteld en de gevolgen van een beveiligingsaanval die misbruik maakt van een bepaalde bedreiging. Nadat u het bedreigingsmodel voor een stuurprogramma hebt gemaakt, kunt u bepalen hoe u de mogelijke bedreigingen kunt beperken.

Bedreigingsmodellering is het meest effectief wanneer deze op een georganiseerde, gestructureerde manier wordt uitgevoerd tijdens het ontwerpen van stuurprogramma's, in plaats van lukraak tijdens het coderen. Een gestructureerde benadering verhoogt de kans dat u beveiligingsproblemen in het ontwerp detecteert, waardoor het model uitgebreid is.

U kunt een bedreigingsmodellering organiseren door de volgende stappen uit te voeren:

1. Maak een gestructureerd diagram waarin de gegevensstroom via het stuurprogramma wordt weergegeven. Neem alle mogelijke taken op die het stuurprogramma uitvoert en de bron en bestemming van alle invoer en uitvoer van het stuurprogramma. Een formeel gegevensstroomdiagram of een vergelijkbaar gestructureerd diagram kan u helpen bij het analyseren van het pad van gegevens via uw stuurprogramma en het identificeren van de externe interfaces, grenzen en interacties van het stuurprogramma.
2. Analyseer de mogelijke beveiligingsrisico's op basis van het gegevensstroomdiagram.
3. Evalueer de bedreigingen die u in de vorige stap hebt geïdentificeerd en bepaal hoe u deze kunt beperken.

Een gegevensstroomdiagram maken

Een gegevensstroomdiagram toont in conceptuele vorm de gegevensstroom tussen het stuurprogramma en de externe entiteiten waarmee deze communiceert, meestal het besturingssysteem, een gebruikersproces en het apparaat. In een formeel gegevensstroomdiagram worden de volgende symbolen gebruikt:

In de volgende afbeelding ziet u een voorbeeld van een gegevensstroomdiagram voor een hypothetisch wdm-stuurprogramma (Windows Driver Model) in de kernelmodus. Ongeacht de architectuur voor uw specifieke type stuurprogramma, is het conceptuele model hetzelfde: geef alle gegevenspaden weer en identificeer elke gegevensbron die het stuurprogramma binnenkomt of verlaat.

Notitie In de vorige afbeelding ziet u gegevens die rechtstreeks tussen een gebruikersproces en het stuurprogramma stromen en eventuele tussenliggende stuurprogramma's weglaten. In werkelijkheid passeren alle aanvragen echter de I/O-manager en kunnen een of meer stuurprogramma's op een hoger niveau passeren voordat ze een bepaald stuurprogramma bereiken. In de afbeelding worden deze tussenliggende stappen weggelaten om het belang van de oorspronkelijke bron van de gegevens en de context van de thread die de gegevens heeft geleverd, te benadrukken. Stuurprogramma's in de kernelmodus moeten gegevens valideren die afkomstig zijn uit de gebruikersmodus.

Informatie komt het stuurprogramma binnen vanwege aanvragen van het besturingssysteem, aanvragen van een gebruikersproces of aanvragen (meestal onderbrekingen) van het apparaat.

Het stuurprogramma in de vorige afbeelding ontvangt gegevens van het besturingssysteem in verschillende typen aanvragen:

• Aanvragen voor het uitvoeren van beheertaken voor het stuurprogramma en het bijbehorende apparaat, via aanroepen naar DriverEntry, DriverUnload en AddDevice-routines
• Plug en Play-aanvragen (IRP_MJ_PNP)
• Energiebeheeraanvragen (IRP_MJ_POWER)
• I/O-beheeraanvragen voor intern apparaat (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Als reactie op deze aanvragen stromen gegevens van het stuurprogramma terug naar het besturingssysteem als statusinformatie. Het stuurprogramma in de afbeelding ontvangt gegevens van een gebruikersproces in de volgende typen aanvragen:

• Aanvragen maken, lezen en schrijven (IRP_MJ_CREATE, IRP_MJ_READ of IRP_MJ_WRITE)
• I/O-beheeraanvragen voor openbare apparaten (IRP_MJ_DEVICE_ CONTROL)

Als reactie op deze aanvragen stromen uitvoergegevens en statusinformatie van het stuurprogramma terug naar het gebruikersproces.

Ten slotte ontvangt het stuurprogramma gegevens van het apparaat vanwege I/O-bewerkingen van het apparaat of gebruikersacties (zoals het openen van het systeemvak op een CD-station) die de apparaatstatus wijzigen. Op dezelfde manier stromen gegevens van het stuurprogramma naar het apparaat tijdens I/O-bewerkingen en wijzigingen in de apparaatstatus.

In de vorige afbeelding ziet u de gegevensstroom van stuurprogramma's op een breed conceptueel niveau. Elke cirkel vertegenwoordigt een relatief grote taak en mist details. In sommige gevallen is een diagram op één niveau, zoals het voorbeeld, voldoende om inzicht te krijgen in de gegevensbronnen en paden. Als uw stuurprogramma veel verschillende typen I/O-aanvragen van verschillende bronnen verwerkt, moet u mogelijk een of meer extra diagrammen maken die meer details tonen. De cirkel met het label 'I/O-aanvragen verwerken' kan bijvoorbeeld worden uitgebreid in een afzonderlijk diagram, vergelijkbaar met de volgende afbeelding.

In het tweede diagram ziet u afzonderlijke taken voor elk type I/O-aanvraag in het eerste diagram. (Ter vereenvoudiging zijn gegevenspaden naar het apparaat weggelaten.)

De externe entiteiten en de typen invoer en uitvoer die in het diagram worden weergegeven, kunnen variëren, afhankelijk van het type apparaat. Windows levert bijvoorbeeld klassestuurprogramma's voor veel algemene apparaattypen. Een door het systeem geleverd klassestuurprogramma werkt met een door de leverancier geleverde minidriver, meestal een DLL (Dynamic Link Library) die een set callback-routines bevat. I/O-aanvragen van gebruikers worden omgeleid naar het klassestuurprogramma, dat vervolgens de routines in de minidriver aanroept om specifieke taken uit te voeren. De minidriver ontvangt doorgaans niet het volledige I/O-aanvraagpakket als invoer; In plaats daarvan ontvangt elke callback-routine alleen de gegevens die vereist zijn voor de specifieke taak.

Houd bij het maken van de gegevensstroomdiagrammen rekening met de verschillende bronnen voor stuurprogrammaaanvragen. Elke code die op de computer van een gebruiker wordt uitgevoerd, kan een I/O-aanvraag genereren naar een stuurprogramma, van bekende toepassingen zoals Microsoft Office tot freeware, version en webdownloads van mogelijk dubieuze oorsprong. Afhankelijk van uw specifieke apparaat moet u mogelijk ook mediacodecs of filters van derden overwegen die uw bedrijf verzendt ter ondersteuning van het apparaat. Mogelijke gegevensbronnen zijn:

• IRP_MJ_XXX aanvragen die door het stuurprogramma worden verwerkt
• IOCTL's die het stuurprogramma definieert of verwerkt
• API's die door het stuurprogramma worden aangeroepen
• Terugbelroutines
• Alle andere interfaces die het stuurprogramma beschikbaar maakt
• Bestanden die door het stuurprogramma worden gelezen of geschreven, inclusief bestanden die tijdens de installatie worden gebruikt
• Registersleutels die het stuurprogramma leest of schrijft
• Pagina's met configuratie-eigenschappen en andere informatie die wordt verstrekt door de gebruiker die het stuurprogramma verbruikt

Uw model moet ook betrekking hebben op de installatie- en updateprocedures van het stuurprogramma. Neem alle bestanden, mappen en registervermeldingen op die tijdens de installatie van het stuurprogramma worden gelezen of geschreven. Overweeg ook de interfaces die beschikbaar zijn in apparaatinstallatieprogramma's, co-installatieprogramma's en eigenschappenpagina's.

Elk punt waarop het stuurprogramma gegevens uitwisselt met een externe entiteit, is mogelijk kwetsbaar voor aanvallen.

Potentiële bedreigingen analyseren

Nadat u de punten hebt geïdentificeerd waarop een driver kwetsbaar kan zijn, kunt u bepalen welke soorten bedreigingen op elk punt kunnen optreden. Houd rekening met de volgende typen vragen:

• Welke beveiligingsmechanismen zijn er om elke resource te beveiligen?
• Zijn alle overgangen en interfaces goed beveiligd?
• Kan onjuist gebruik van een functie onbedoeld inbreuk maken op beveiliging?
• Kan kwaadwillend gebruik van een functie inbreuk maken op beveiliging?
• Bieden standaardinstellingen voldoende beveiliging?

De STRIDE-benadering voor bedreigingscategorisatie

De acroniem STRIDE beschrijft zes categorieën bedreigingen voor software. Dit acroniem is afgeleid van:

• Spoofing
• Ampereren
• Repudiation
• Gegevensonthulling
• Denial of service
• Escalatie van bevoegdheden

Met STRIDE als richtlijn kunt u gedetailleerde vragen stellen over de soorten aanvallen die op een chauffeur kunnen worden gericht. Het doel is om de typen aanvallen te bepalen die mogelijk zijn op elk kwetsbaar punt in de driver en vervolgens een scenario te maken voor elke mogelijke aanval.

• Spoofing gebruikt de referenties van iemand anders om toegang te krijgen tot anders ontoegankelijke assets. Een proces voert een spoofing-aanval uit met vervalste of gestolen referenties.

• Manipulatie wijzigt gegevens om een aanval uit te voeren. Een stuurprogramma kan bijvoorbeeld vatbaar zijn voor manipulatie als de vereiste stuurprogrammabestanden niet voldoende worden beveiligd door lijsten voor ondertekening en toegangsbeheer van stuurprogramma's. In deze situatie kan een kwaadwillende gebruiker de bestanden wijzigen, waardoor de systeembeveiliging wordt geschonden.

• Repudiation treedt op wanneer een gebruiker een actie weigert uit te voeren, maar het doel van de actie heeft geen manier om anders te bewijzen. Een stuurprogramma kan vatbaar zijn voor een ontkenningsdreiging als het acties niet registreert die de beveiliging in gevaar kunnen brengen. Een stuurprogramma voor een videoapparaat kan bijvoorbeeld vatbaar zijn voor afkeer als er geen aanvragen worden vastgelegd om de kenmerken van het apparaat te wijzigen, zoals focus, gescand gebied, frequentie van het vastleggen van afbeeldingen, doellocatie van vastgelegde afbeeldingen, enzovoort. De resulterende installatiekopieën kunnen beschadigd zijn, maar systeembeheerders kunnen niet bepalen welke gebruiker het probleem heeft veroorzaakt.

• Bedreigingen voor openbaarmaking van informatie zijn precies zoals de naam al aangeeft: de openbaarmaking van informatie aan een gebruiker die niet gemachtigd is om deze te zien. Elk stuurprogramma dat informatie doorgeeft aan of van een gebruikersbuffer, is vatbaar voor bedreigingen voor openbaarmaking van informatie. Om bedreigingen voor openbaarmaking van informatie te voorkomen, moeten drivers de lengte van elke gebruikersbuffer valideren en de buffers nul initialiseren voordat er gegevens worden geschreven.

• Denial of Service-aanvallen bedreigen de mogelijkheid van geldige gebruikers om toegang te krijgen tot resources. De resources kunnen schijfruimte, netwerkverbindingen of een fysiek apparaat zijn. Aanvallen die de prestaties vertragen tot onaanvaardbare niveaus, worden ook beschouwd als denial-of-service-aanvallen. Een stuurprogramma dat een gebruikersproces toestaat om een systeemresource onnodig te verstoren, kan vatbaar zijn voor een denial-of-service-aanval als het resourceverbruik de mogelijkheid belemmert van andere geldige gebruikers om hun taken uit te voeren.

  Een stuurprogramma kan bijvoorbeeld een semaphore gebruiken om een gegevensstructuur te beveiligen tijdens het uitvoeren op IRQL = PASSIVE_LEVEL. Het stuurprogramma moet echter de semafoor binnen een KeEnterCriticalRegion/KeLeaveCriticalRegion-paar verkrijgen en vrijgeven, waardoor de levering van asynchrone procedureaanroepen (APC's) tijdelijk wordt uitgeschakeld en vervolgens weer ingeschakeld. Als het stuurprogramma deze routines niet gebruikt, kan een APC ertoe leiden dat het besturingssysteem de thread die de semafoor bezit onderbreekt. Als gevolg hiervan kunnen andere processen (inclusief processen die door een beheerder zijn gemaakt) geen toegang krijgen tot de structuur.

• Een aanval op uitbreiding van bevoegdheden kan optreden als een onbevoegde gebruiker de bevoorrechte status krijgt. Een kernelmodusstuurprogramma dat een gebruikersmodushandgreep doorgeeft aan een ZwXxx-routine , is kwetsbaar voor aanvallen met uitbreiding van bevoegdheden omdat ZwXxx-routines beveiligingscontroles omzeilen. Stuurprogramma's in de kernelmodus moeten elke ingang valideren die ze ontvangen van bellers in de gebruikersmodus.

  Aanvallen met uitbreiding van bevoegdheden kunnen ook optreden als een kernelmodusstuurprogramma afhankelijk is van de waarde RequestorMode in de IRP-header om te bepalen of een I/O-aanvraag afkomstig is van een kernelmodus- of gebruikersmodusaanroeper. In IRPs die afkomstig zijn van het netwerk of de Server-service (SRVSVC), is de waarde van RequestorMode KernelMode, ongeacht de oorsprong van de aanvraag. Om dergelijke aanvallen te voorkomen, moeten stuurprogramma's toegangscontrolecontroles uitvoeren op dergelijke aanvragen in plaats van gewoon de waarde van RequestorMode te gebruiken.

Analysetechnieken voor stuurprogramma's

Een eenvoudige manier om de analyse te organiseren, is door de kwetsbare gebieden samen met de mogelijke bedreigingen en een of meer scenario's voor elk type bedreiging weer te geven.

Als u een grondige analyse wilt uitvoeren, moet u de mogelijkheid van bedreigingen op elk potentieel kwetsbaar punt in de driver verkennen. Bepaal op elk kwetsbaar punt elke bedreigingscategorie (spoofing, manipulatie, repudiation, openbaarmaking van informatie, denial of service en uitbreiding van bevoegdheden) die mogelijk zijn. Maak vervolgens een of meer aanvalsscenario's voor elke plausibele bedreiging.

Denk bijvoorbeeld aan de gegevensstroom voor IRP_MJ_DEVICE_CONTROL aanvragen, zoals wordt weergegeven in de voorgaande afbeelding. In de volgende tabel ziet u twee typen bedreigingen die een stuurprogramma kan tegenkomen bij het verwerken van dergelijke aanvragen:

Bedreigingsstructuren en overzichten kunnen nuttig zijn bij het modelleren van dergelijke complexe scenario's.

Een bedreigingsstructuur is een diagram met een hiërarchie van bedreigingen of beveiligingsproblemen; In wezen mimeert een bedreigingsstructuur de stappen van de kwaadwillende gebruiker bij het koppelen van een aanval. Het ultieme doel van de aanval bevindt zich boven aan de boom. Elk ondergeschikt niveau toont de stappen die nodig zijn om de aanval uit te voeren. De volgende afbeelding is een eenvoudige bedreigingsstructuur voor het denial-of-service-scenario in het voorgaande voorbeeld.

De bedreigingsboom toont de vereiste stappen om een specifieke aanval uit te voeren en de relaties tussen de stappen. Een schets is een alternatief voor een bedreigingsboom.

Een overzicht bevat eenvoudigweg in hiërarchische volgorde de stappen om een bepaalde bedreiging aan te vallen. Voorbeeld:

1.0 Ervoor zorgen dat het apparaat niet meer reageert.

1.1 IOCTLS verzenden in de volgorde van fouten.

1.1.1 Bepaal de volgorde die ervoor zorgt dat het apparaat mislukt.

1.1.2 Krijg verhoogde bevoegdheden om interne IOCTL's uit te geven.

Met beide technieken kunt u begrijpen welke bedreigingen het gevaarlijkst zijn en welke beveiligingsproblemen in uw ontwerp het belangrijkst zijn.

Snelle weg bedreigingsmodellering

Als resources beperkt zijn in plaats van een volledig diagram van een bedreigingsmodel te maken, kan er een overzichtsoverzicht worden gemaakt om beveiligingsrisico's voor het stuurprogramma te beoordelen. In de onderstaande tekst worden bijvoorbeeld enkele van de oppervlaktegebieden beschreven in het voorbeeldstuurprogramma dat in het vorige voorbeeld is beschreven.

Het stuurprogramma ontvangt gegevens van het besturingssysteem in verschillende soorten aanvragen:

• Aanvragen voor het uitvoeren van beheertaken voor het stuurprogramma en het bijbehorende apparaat, via aanroepen naar DriverEntry, DriverUnload en AddDevice-routines
• Plug en Play-aanvragen (IRP_MJ_PNP)
• Energiebeheeraanvragen (IRP_MJ_POWER)
• I/O-beheeraanvragen voor intern apparaat (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Als reactie op deze aanvragen stromen gegevens van het stuurprogramma terug naar het besturingssysteem als statusinformatie. Het stuurprogramma ontvangt gegevens van een gebruikersproces in de volgende typen aanvragen:

• Aanvragen maken, lezen en schrijven (IRP_MJ_CREATE, IRP_MJ_READ of IRP_MJ_WRITE)
• I/O-beheeraanvragen voor openbare apparaten (IRP_MJ_DEVICE_ CONTROL)

Als reactie op deze aanvragen stromen uitvoergegevens en statusinformatie van het stuurprogramma terug naar het gebruikersproces.

Met deze basiskennis van de gegevensstroom naar uw stuurprogramma kunt u elk invoer- en uitvoergebied onderzoeken op mogelijke bedreigingen.

De DREAD-benadering voor bedreigingsevaluatie

Het is niet genoeg om te bepalen hoe en waar een stuurprogramma aangevallen kan worden. Vervolgens moet u deze potentiële bedreigingen beoordelen, hun relatieve prioriteiten bepalen en een risicobeperkingsstrategie bedenken.

DREAD is een acroniem dat vijf criteria beschrijft voor het beoordelen van bedreigingen voor software. DREAD staat voor:

• Damage
• Reproduceerbaarheid
• Exploiteerbaarheid
• Aangetaste gebruikers
• Vindbaarheid

Om prioriteit te geven aan de bedreigingen voor uw bestuurder, rangschikt u elke bedreiging van 1 tot 10 op alle 5 DREAD-criteria, voegt u vervolgens de scores bij elkaar en deelt u het totaal door 5 (het aantal criteria). Het resultaat is een numerieke score tussen 1 en 10 voor elke bedreiging. Hoge scores geven ernstige bedreigingen aan.

• Schade. Het beoordelen van de schade die kan ontstaan door een beveiligingsaanval is duidelijk een essentieel onderdeel van bedreigingsmodellering. Schade kan gegevensverlies, hardware- of mediastoringen, substandaardprestaties of vergelijkbare metingen zijn die van toepassing zijn op uw apparaat en de bijbehorende bedrijfsomgeving.

• Reproduceerbaarheid is een meting van hoe vaak een bepaald type aanval slaagt. Een eenvoudig reproduceerbare bedreiging is waarschijnlijker te misbruiken dan een beveiligingsprobleem dat zelden of onvoorspelbaar optreedt. Bedreigingen voor functies die standaard zijn geïnstalleerd of die in elk mogelijk codepad worden gebruikt, zijn bijvoorbeeld zeer reproduceerbaar.

• Exploitability beoordeelt de inspanningen en expertise die nodig zijn om een aanval uit te voeren. Een bedreiging die kan worden aangevallen door een relatief onervaren student is zeer exploiteerbaar. Een aanval die zeer deskundig personeel vereist en duur is om uit te voeren, is minder exploiteerbaar.

  Houd bij het beoordelen van misbruik ook rekening met het aantal potentiële aanvallers. Een bedreiging die kan worden misbruikt door elke externe, anonieme gebruiker is meer exploiteerbaar dan een bedreiging die een on-site, maximaal geautoriseerde gebruiker vereist.

• Betrokken gebruikers. Het aantal gebruikers dat door een aanval kan worden beïnvloed, is een andere belangrijke factor bij het beoordelen van een bedreiging. Een aanval die maximaal één of twee gebruikers kan beïnvloeden, zou relatief laag zijn bij deze meting. Een denial-of-service-aanval die een netwerkserver doet vastlopen, kan daarentegen duizenden gebruikers beïnvloeden en het zou daarom veel ernstiger worden beoordeeld.

• Detectie is de kans dat een bedreiging wordt misbruikt. Vindbaarheid is moeilijk nauwkeurig te schatten. De veiligste benadering is om ervan uit te gaan dat elk beveiligingsprobleem uiteindelijk zal worden benut en dus afhankelijk is van de andere maatregelen om de relatieve rangschikking van de bedreiging vast te stellen.

Voorbeeld: Bedreigingen beoordelen met DREAD

Als u verdergaat met het bovenstaande voorbeeld, ziet u in de volgende tabel hoe een ontwerper de hypothetische denial-of-service-aanval kan beoordelen:

Bedreigingen beperken

Het ontwerp van uw stuurprogramma moet alle bedreigingen die door uw model worden blootgelegd mitigeren. In sommige gevallen is risicobeperking echter mogelijk niet praktisch. Denk bijvoorbeeld aan een aanval die mogelijk zeer weinig gebruikers beïnvloedt en waarschijnlijk niet tot verlies van gegevens of systeem bruikbaarheid leidt. Als het beperken van een dergelijke bedreiging enkele maanden extra inspanning vereist, kunt u ervoor kiezen om met reden in plaats daarvan extra tijd te besteden aan het testen van de driver. Houd er echter rekening mee dat uiteindelijk een kwaadwillende gebruiker waarschijnlijk het beveiligingsprobleem zal vinden en een aanval kan koppelen. Vervolgens vereist het stuurprogramma een patch voor het probleem.

Bedreigingsmodellering opnemen in een breder levenscyclusproces voor security development

Overweeg om het threat modeling-proces op te nemen in een bredere levenscyclus van Secure Development - SDL.

Het Microsoft SDL-proces biedt een aantal aanbevolen softwareontwikkelingsproces dat kan worden aangepast aan elke grootte van de organisatie, inclusief één ontwikkelaar. Overweeg onderdelen van de SDL-aanbevelingen toe te voegen aan uw softwareontwikkelingsproces.

Zie Microsoft Security Development Lifecycle (SDL) – Procesrichtlijnen voor meer informatie.

Trainings- en organisatiemogelijkheden : volg beveiligingstraining voor softwareontwikkeling om uw vermogen om beveiligingsproblemen met software te herkennen en op te heffen.

Microsoft maakt de vier kern-SDL-trainingsklassen beschikbaar om te downloaden. Microsoft Security Development Lifecycle Core-trainingen

Zie dit witboek voor meer gedetailleerde informatie over SDL-training. Essentiële softwarebeveiligingstraining voor de Microsoft SDL

Vereisten en ontwerp : de beste mogelijkheid om vertrouwde software te bouwen, is tijdens de eerste planningsfasen van een nieuwe release of een nieuwe versie, omdat ontwikkelteams belangrijke objecten kunnen identificeren en beveiliging en privacy kunnen integreren, waardoor onderbreking van plannen en planningen wordt geminimaliseerd.

Een belangrijke uitvoer in deze fase is het instellen van specifieke beveiligingsdoelen. Als u bijvoorbeeld besluit dat al uw code de Visual Studio-codeanalyse 'Alle regels' moet doorstaan met nul waarschuwingen.

Implementatie : alle ontwikkelteams moeten een lijst met goedgekeurde hulpprogramma's en de bijbehorende beveiligingscontroles definiëren en publiceren, zoals opties voor compiler/linker en waarschuwingen.

Voor een ontwikkelaar van stuurprogramma's wordt het meeste nuttige werk gedaan in deze fase. Omdat code wordt geschreven, wordt deze beoordeeld op mogelijke zwakke plekken. Hulpprogramma's zoals codeanalyse en stuurprogrammaverificator worden gebruikt om te zoeken naar gebieden in de code die kunnen worden beperkt.

Verificatie - Verificatie is het punt waarop de software functioneel volledig is en wordt getest op basis van beveiligingsdoelen die worden beschreven in de vereisten en ontwerpfase.

Aanvullende hulpprogramma's, zoals binscope- en fuzz-testers, kunnen worden gebruikt om te controleren of aan de doelstellingen van het beveiligingsontwerp is voldaan en de code gereed is om te worden verzonden

Release en reactie : ter voorbereiding op het vrijgeven van een product is het wenselijk om een plan voor incidentrespons te maken dat beschrijft wat u gaat doen om te reageren op nieuwe bedreigingen en hoe u het stuurprogramma gaat onderhouden nadat het is verzonden. Als u dit van tevoren doet, kunt u sneller reageren als er beveiligingsproblemen worden geïdentificeerd in code die is verzonden.

Zie deze aanvullende bronnen voor meer informatie over het SDL-proces:

• Dit is de primaire Microsoft SDL-site en biedt een overzicht van SDL. https://www.microsoft.com/sdl

• In deze blog wordt beschreven hoe u een gratis kopie van The Security Development Lifecycle: SDL, door Michael Howard en Steve Lipner downloadt. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Deze pagina bevat koppelingen naar aanvullende SDL-publicaties. https://www.microsoft.com/SDL/Resources/publications.aspx

Aanroep naar actie

Voor ontwikkelaars van stuurprogramma's:

• Maak threat modeling onderdeel van het ontwerp van het stuurprogramma.
• Voer stappen uit om bedreigingen in uw stuurprogrammacode efficiënt te beperken.
• Raak vertrouwd met de beveiligings- en betrouwbaarheidsproblemen die van toepassing zijn op uw stuurprogramma en apparaattype. Zie de apparaatspecifieke secties van de Windows Device Driver Kit (WDK) voor meer informatie.
• Begrijpen welke controles het besturingssysteem, I/O-beheer en eventuele stuurprogramma's op een hoger niveau uitvoeren voordat gebruikersaanvragen uw stuurprogramma bereiken en welke controles ze niet uitvoeren.
• Gebruik hulpprogramma's van de WDK, zoals stuurprogrammaverifier om uw stuurprogramma te testen en te verifiëren.
• Bekijk openbare databases met bekende bedreigingen en softwareproblemen.

Voor extra beveiligingsmiddelen voor stuurprogramma's, zie Controlelijst voor stuurprogrammabeveiliging.

Softwarebeveiligingsbronnen

Boeken

Secure Code schrijven, Tweede editie van Michael Howard en David LeBlanc

24 Dodelijke zonden van softwarebeveiliging: programmeerfouten en hoe ze te repareren, eerste editie van Michael Howard, David LeBlanc en John Viega

De kunst van softwarebeveiligingsevaluatie: het identificeren en voorkomen van beveiligingsproblemen van software, door Mark Dowd, John McDonald en Justin Schuh

Informatie over ontwikkelaars van Microsoft-hardware en stuurprogramma's

Technisch document over het annuleren van logica in Windows-stuurprogramma's

Windows-beveiligingsmodel: wat elke schrijver van stuurprogramma's moet weten

Microsoft Windows Driver Development Kit (DDK)

Zie Programmeertechnieken voor stuurprogramma's in Kernel-Mode Stuurprogramma-architectuur

Testhulpprogramma's

Zie Windows Hardware Lab Kit in Test voor prestaties en compatibiliteit

Openbare databases met bekende bedreigingen en beveiligingsproblemen met software

Als u uw kennis van softwarebedreigingen wilt uitbreiden, bekijkt u de beschikbare openbare databases van bekende bedreigingen en beveiligingsproblemen met software.

• Veelvoorkomende beveiligingsproblemen en blootstellingen (CVE): https://cve.mitre.org/
• Veelvoorkomende opsomming van zwakke punten: https://cwe.mitre.org/
• Algemene opsomming en classificatie van aanvalspatronen: https://capec.mitre.org/index.html
• NIST onderhoudt een site die beschrijft hoe beveiligingsproblemen worden gecatalogusd: https://samate.nist.gov/BF/

Zie ook

Chauffeurveiligheidscontrolelijst