Modellazione delle minacce per i driver
Gli autori di driver e gli architetti devono rendere la modellazione delle minacce parte integrante del processo di progettazione per qualsiasi driver. In questo argomento vengono fornite linee guida per la creazione di modelli di minaccia per i driver di Windows.
La sicurezza deve essere un punto di progettazione fondamentale per qualsiasi driver. Qualsiasi prodotto di successo è un obiettivo. Se si scrive un driver per Windows, è necessario presupporre che in qualche momento, da qualche parte, qualcuno tenterà di usare il driver per compromettere la sicurezza del sistema.
La progettazione di un driver sicuro implica:
- Identificazione dei punti in cui il conducente potrebbe essere vulnerabile a un attacco.
- Analisi dei tipi di attacchi che possono essere montati in ogni punto.
- Garantire che il driver sia progettato in modo da contrastare tali attacchi.
La modellazione delle minacce è un approccio strutturato a queste importanti attività di progettazione. Un modello di minaccia è un modo per categorizzare e analizzare le minacce a un asset. Dal punto di vista di un writer di driver, gli asset sono l'hardware, il software e i dati nel computer o nella rete.
Un modello di minaccia risponde alle domande seguenti:
- Quali asset necessitano di protezione?
- A quali minacce sono vulnerabili le risorse?
- Quanto è importante o probabile che ogni minaccia sia?
- Come è possibile attenuare le minacce?
La modellazione delle minacce è una parte importante della progettazione del software perché garantisce che la sicurezza sia integrata nel prodotto, invece di essere affrontata come un'operazione successiva. Un modello di minaccia valido può aiutare a trovare e prevenire bug durante il processo di progettazione, eliminando quindi le patch potenzialmente costose in un secondo momento e i possibili danni di reputazione all'organizzazione.
Questa sezione applica i principi della modellazione delle minacce alla progettazione dei driver e fornisce esempi di minacce a cui un driver potrebbe essere soggetto. Per una descrizione più completa della modellazione delle minacce per la progettazione del software, vedere queste risorse.
Sito Web Microsoft SDL:
Implementazione semplificata di Microsoft SDL:
Questo post di blog descrive come scaricare una copia gratuita di The Security Development Lifecycle: SDL, di Michael Howard e Steve Lipner:
Creare modelli di minaccia per i driver
La creazione di un modello di minaccia richiede una conoscenza approfondita della progettazione del driver, dei tipi di minacce a cui potrebbe essere esposto il driver e delle conseguenze di un attacco di sicurezza che sfrutta una determinata minaccia. Dopo aver creato il modello di minaccia per un driver, è possibile determinare come attenuare le potenziali minacce.
La modellazione delle minacce è più efficace quando viene eseguita in modo organizzato e strutturato durante la progettazione del driver, anziché in modo casuale durante la codifica. Un approccio strutturato aumenta la probabilità che si rilevino vulnerabilità nella progettazione, contribuendo così a garantire che il modello sia completo.
Un modo per organizzare uno sforzo di modellazione delle minacce consiste nel seguire questa procedura:
- Creare un diagramma strutturato che mostra il flusso di dati attraverso il driver. Includere tutte le attività possibili eseguite dal driver e l'origine e la destinazione di tutti gli input e output del driver. Un diagramma formale del flusso di dati, o un diagramma strutturato simile, consente di analizzare il percorso dei dati tramite il driver e di identificare le interfacce esterne, i limiti e le interazioni del driver.
- Analizzare le potenziali minacce alla sicurezza, in base al diagramma del flusso di dati.
- Valutare le minacce identificate nel passaggio precedente e determinare come attenuarle.
Creare un diagramma del flusso di dati
Un diagramma del flusso di dati mostra in forma concettuale il flusso di dati tra il driver e le entità esterne con cui interagisce, in genere il sistema operativo, un processo utente e il dispositivo. Un diagramma di flusso di dati formale usa i simboli seguenti:
La figura seguente mostra un diagramma di flusso di dati di esempio per un driver Windows Driver Model (WDM) ipotetico in modalità kernel. Indipendentemente dall'architettura per il tipo di driver specifico, il modello concettuale è lo stesso: mostra tutti i percorsi dati e identifica ogni origine di dati che entra o esce dal driver.
Nota La figura precedente mostra il flusso di dati direttamente tra un processo utente e il driver e omette eventuali driver intermedi. Tuttavia, in realtà, tutte le richieste passano attraverso il gestore di I/O e possono attraversare uno o più driver di livello superiore prima di raggiungere un determinato driver. La figura omette questi passaggi intermedi per evidenziare l'importanza dell'origine originale dei dati e il contesto del thread che ha fornito i dati. I driver in modalità kernel devono convalidare i dati originato in modalità utente.
Le informazioni vengono immesse dal driver a causa di richieste provenienti dal sistema operativo, richieste da un processo utente o richieste (in genere interrompe) dal dispositivo.
Il driver nella figura precedente riceve i dati dal sistema operativo in diversi tipi di richieste:
- Richiede di eseguire attività amministrative per il driver e il dispositivo tramite chiamate alle routine DriverEntry, DriverUnload e AddDevice
- richieste Plug and Play (IRP_MJ_PNP)
- Richieste di risparmio energia (IRP_MJ_POWER)
- Richieste di controllo I/O interne del dispositivo (IRP_MJ_INTERNAL_DEVICE_CONTROL)
In risposta a queste richieste, i dati passano di nuovo dal driver al sistema operativo come informazioni sullo stato. Il driver nella figura riceve i dati da un processo utente nei tipi di richieste seguenti:
- Creare, leggere e scrivere richieste (IRP_MJ_CREATE, IRP_MJ_READ o IRP_MJ_WRITE)
- Richieste di controllo di I/O del dispositivo pubblico (IRP_MJ_DEVICE_ CONTROL)
In risposta a queste richieste, i dati di output e le informazioni sullo stato vengono restituiti dal driver al processo utente.
Infine, il driver riceve i dati dal dispositivo a causa di operazioni di I/O del dispositivo o azioni utente (ad esempio l'apertura della barra su un'unità CD) che modificano lo stato del dispositivo. Analogamente, i dati del driver passano al dispositivo durante le operazioni di I/O e cambiano lo stato del dispositivo.
La figura precedente mostra il flusso di dati dei driver a un livello concettuale generale. Ogni cerchio rappresenta un'attività relativamente grande e manca di dettagli. In alcuni casi, un diagramma a un livello, ad esempio l'esempio, è adeguato per comprendere le origini dati e i percorsi. Se il driver gestisce molti tipi diversi di richieste di I/O da origini diverse, potrebbe essere necessario creare uno o più diagrammi aggiuntivi che mostrano più dettagli. Ad esempio, il cerchio con etichetta "Gestisci richieste di I/O" potrebbe essere espanso in un diagramma separato, simile alla figura seguente.
Il secondo diagramma mostra attività separate per ogni tipo di richiesta di I/O nel primo diagramma. Per semplicità, i percorsi dei dati del dispositivo sono stati omessi.
Le entità esterne e i tipi di input e output mostrati nel diagramma possono variare, a seconda del tipo di dispositivo. Ad esempio, Windows fornisce driver di classe per molti tipi di dispositivo comuni. Un driver di classe fornito dal sistema funziona con un minidriver fornito dal fornitore, che in genere è una libreria di collegamento dinamico (DLL) che contiene un set di routine di callback. Le richieste di I/O utente vengono indirizzate al driver di classe, che chiama quindi le routine nel minidriver per eseguire attività specifiche. Il minidriver in genere non riceve l'intero pacchetto di richiesta di I/O come input; Ogni routine di callback riceve invece solo i dati necessari per l'attività specifica.
Quando si creano i diagrammi del flusso di dati, tenere presente la varietà di origini per le richieste di driver. Qualsiasi codice eseguito nel computer di un utente potrebbe generare una richiesta di I/O a un driver, da applicazioni note come Microsoft Office a download freeware, shareware e Web di origine potenzialmente dubbia. A seconda del dispositivo specifico, potrebbe anche essere necessario prendere in considerazione codec multimediali o filtri di terze parti che l'azienda fornisce per supportare il dispositivo. Le origini dati possibili includono:
- IRP_MJ_XXX richiede che il driver gestisca
- IOCTLs definito o gestito dal driver
- API chiamate dal driver
- Routine di callback
- Qualsiasi altra interfaccia esposta dal driver
- File letti o scritti dal driver, inclusi quelli usati durante l'installazione
- Chiavi del Registro di sistema che il driver legge o scrive
- Pagine delle proprietà di configurazione e altre informazioni fornite dall'utente che il driver utilizza
Il modello deve anche trattare le procedure di installazione e aggiornamento del driver. Includere tutti i file, le directory e le voci del Registro di sistema letti o scritti durante l'installazione del driver. Prendere in considerazione anche le interfacce esposte nei programmi di installazione dei dispositivi, nei co-programmi di installazione e nelle pagine delle proprietà.
Qualsiasi punto in cui il driver scambia dati con un'entità esterna è potenzialmente vulnerabile agli attacchi.
Analizzare le potenziali minacce
Dopo aver identificato i punti in cui un driver potrebbe essere vulnerabile, è possibile determinare quali tipi di minacce possono verificarsi a ogni punto. Considerare i tipi di domande seguenti:
- Quali meccanismi di sicurezza sono disponibili per proteggere ogni risorsa?
- Tutte le transizioni e le interfacce sono protette correttamente?
- L'uso improprio di una funzionalità potrebbe compromettere involontariamente la sicurezza?
- L'uso dannoso di una funzionalità potrebbe compromettere la sicurezza?
- Le impostazioni predefinite offrono una sicurezza adeguata?
Approccio STRIDE alla categorizzazione delle minacce
L'acronimo STRIDE descrive sei categorie di minacce al software. Questo acronimo è derivato da:
- Spoofing
- Amperamento T
- Epudiazione R
- Divulgazione dinformation
- Denial of service
- Levazionedei privilegi
Usando STRIDE come guida, è possibile porre domande dettagliate sui tipi di attacchi che potrebbero essere mirati a un driver. L'obiettivo è determinare i tipi di attacchi che possono essere possibili in ogni punto vulnerabile nel driver e quindi creare uno scenario per ogni possibile attacco.
Lo spoofing usa le credenziali di qualcun altro per ottenere l'accesso ad asset altrimenti inaccessibili. Un processo monta un attacco di spoofing passando credenziali contraffatte o rubate.
La manomissione sta modificando i dati per montare un attacco. Ad esempio, un driver potrebbe essere soggetto a manomissioni se i file di driver necessari non sono adeguatamente protetti tramite elenchi di controllo di accesso e firma del driver. In questo caso, un utente malintenzionato potrebbe modificare i file, violando così la sicurezza del sistema.
Il ripudio si verifica quando un utente nega l'esecuzione di un'azione, ma la destinazione dell'azione non è in grado di dimostrare altrimenti. Un driver potrebbe essere soggetto a una minaccia di ripudio se non registra azioni che potrebbero compromettere la sicurezza. Ad esempio, un driver per un dispositivo video potrebbe essere soggetto al ripudio se non registra le richieste di modifica delle caratteristiche del dispositivo, ad esempio lo stato attivo, l'area analizzata, la frequenza di acquisizione delle immagini, la posizione di destinazione delle immagini acquisite e così via. Le immagini risultanti potrebbero essere danneggiate, ma gli amministratori di sistema non avrebbero modo di determinare quale utente ha causato il problema.
Le minacce alla divulgazione di informazioni sono esattamente come implica il nome: la divulgazione di informazioni a un utente che non dispone dell'autorizzazione per visualizzarlo. Qualsiasi driver che passa informazioni a o da un buffer utente è soggetto a minacce alla divulgazione di informazioni. Per evitare minacce alla divulgazione di informazioni, i driver devono convalidare la lunghezza di ogni buffer utente e inizializzare zero i buffer prima di scrivere i dati.
Gli attacchi Denial of Service minacciano la capacità di utenti validi di accedere alle risorse. Le risorse potrebbero essere spazio su disco, connessioni di rete o un dispositivo fisico. Anche gli attacchi che rallentano le prestazioni a livelli inaccettabili sono considerati attacchi Denial of Service. Un driver che consente a un processo utente di monopolizzare inutilmente una risorsa di sistema potrebbe essere soggetto a un attacco Denial of Service se l'utilizzo delle risorse impedisce ad altri utenti validi di eseguire le proprie attività.
Ad esempio, un driver può usare un semaforo per proteggere una struttura di dati durante l'esecuzione in IRQL = PASSIVE_LEVEL. Tuttavia, il driver deve acquisire e rilasciare il semaforo all'interno di una coppia KeEnterCriticalRegion/KeLeaveCriticalRegion , che disabilita e riabilita il recapito di chiamate asincrone alle procedure. Se il driver non usa queste routine, un APC potrebbe causare la sospensione del thread che contiene il semaforo. Di conseguenza, altri processi (inclusi quelli creati da un amministratore) non sarebbero in grado di ottenere l'accesso alla struttura.
Un attacco di elevazione dei privilegi può verificarsi se un utente senza privilegi ottiene lo stato con privilegi. Un driver in modalità kernel che passa un handle in modalità utente a una routine ZwXxx è vulnerabile agli attacchi di elevazione dei privilegi perché le routine ZwXxx ignorano i controlli di sicurezza. I driver in modalità kernel devono convalidare ogni handle ricevuto dai chiamanti in modalità utente.
Gli attacchi di elevazione dei privilegi possono verificarsi anche se un driver in modalità kernel si basa sul valore RequestorMode nell'intestazione IRP per determinare se una richiesta di I/O proviene da un chiamante in modalità kernel o utente. Nei provider di integrazione che arrivano dalla rete o dal servizio Server (SRVSVC), il valore di RequestorMode è KernelMode, indipendentemente dall'origine della richiesta. Per evitare tali attacchi, i driver devono eseguire controlli di controllo di accesso per tali richieste invece di usare semplicemente il valore RequestorMode.
Tecniche di analisi dei driver
Un modo semplice per organizzare l'analisi consiste nell'elencare le aree vulnerabili insieme alle potenziali minacce e a uno o più scenari per ogni tipo di minaccia.
Per eseguire un'analisi approfondita, è necessario esplorare la possibilità di minacce in ogni punto potenzialmente vulnerabile nel driver. A ogni punto vulnerabile, determinare ogni categoria di minaccia (spoofing, manomissione, ripudio, divulgazione di informazioni, denial of service e elevazione dei privilegi) che potrebbero essere possibili. Creare quindi uno o più scenari di attacco per ogni minaccia plausibile.
Si consideri ad esempio il flusso di dati per IRP_MJ_DEVICE_CONTROL richieste, come illustrato nella figura precedente. La tabella seguente illustra due tipi di minacce che un driver potrebbe riscontrare durante l'elaborazione di tali richieste:
| Punto vulnerabile | Potenziale minaccia (STRIDE) | Scenario |
|---|---|---|
| richieste di IRP_MJ_DEVICE_CONTROL | Denial of Service Elevazione dei privilegi |
Il processo utente genera una sequenza di IOCTL che causa l'errore del dispositivo. Il processo utente genera un IOCTL che consente FILE_ANY_ACCESS. |
Gli alberi e le strutture delle minacce possono essere utili per la modellazione di scenari complessi.
Un albero delle minacce è un diagramma che mostra una gerarchia di minacce o vulnerabilità; in sostanza, un albero delle minacce simula i passaggi dell'utente malintenzionato nel montaggio di un attacco. L'obiettivo finale dell'attacco è nella parte superiore dell'albero. Ogni livello subordinato mostra i passaggi necessari per eseguire l'attacco. La figura seguente è un semplice albero delle minacce per lo scenario Denial of Service nell'esempio precedente.
L'albero delle minacce mostra i passaggi necessari per montare un particolare attacco e le relazioni tra i passaggi. Una struttura è un'alternativa a un albero delle minacce.
Una struttura elenca semplicemente in ordine gerarchico i passaggi per attaccare una determinata minaccia. Ad esempio:
1.0 Causa l'interruzione della risposta del dispositivo.
1.1 Problema IOCTLS nella sequenza di errore.
1.1.1 Determinare la sequenza che causa l'errore del dispositivo.
1.1.2 Ottenere privilegi elevati per rilasciare IOCTL interni.
Entrambe le tecniche consentono di comprendere quali minacce sono più pericolose e quali vulnerabilità nella progettazione sono più critiche.
Modellazione rapida delle minacce di percorso
Se le risorse sono limitate, invece di creare un diagramma completo del modello di minaccia, è possibile creare una struttura di riepilogo per valutare i rischi di sicurezza per il driver. Ad esempio, il testo seguente descrive alcune delle aree di superficie illustrate nel driver di esempio descritto nell'esempio precedente.
Il driver riceve i dati dal sistema operativo in diversi tipi di richieste:
- Richiede di eseguire attività amministrative per il driver e il dispositivo tramite chiamate alle routine DriverEntry, DriverUnload e AddDevice
- richieste Plug and Play (IRP_MJ_PNP)
- Richieste di risparmio energia (IRP_MJ_POWER)
- Richieste di controllo I/O interne del dispositivo (IRP_MJ_INTERNAL_DEVICE_CONTROL)
In risposta a queste richieste, i dati passano di nuovo dal driver al sistema operativo come informazioni sullo stato. Il driver riceve i dati da un processo utente nei tipi di richieste seguenti:
- Creare, leggere e scrivere richieste (IRP_MJ_CREATE, IRP_MJ_READ o IRP_MJ_WRITE)
- Richieste di controllo di I/O del dispositivo pubblico (IRP_MJ_DEVICE_ CONTROL)
In risposta a queste richieste, i dati di output e le informazioni sullo stato vengono restituiti dal driver al processo utente.
Usando questa conoscenza di base del flusso di dati al driver, è possibile esaminare ogni area di input e output per individuare possibili minacce.
L'approccio DREAD alla valutazione delle minacce
Determinare come e dove potrebbe essere attaccato un conducente non è sufficiente. È quindi necessario valutare queste potenziali minacce, determinare le priorità relative e definire una strategia di mitigazione.
DREAD è un acronimo che descrive cinque criteri per la valutazione delle minacce al software. DREAD è l'acronimo di:
- Damage
- Eproducibilità R
- Exploitability
- Utentiinfettati
- Discoverability
Per classificare in ordine di priorità le minacce al driver, classificare ogni minaccia da 1 a 10 su tutti i 5 criteri di valutazione DREAD e quindi aggiungere i punteggi e dividere per 5 (il numero di criteri). Il risultato è un punteggio numerico compreso tra 1 e 10 per ogni minaccia. Punteggi elevati indicano minacce gravi.
Danni. La valutazione dei danni che potrebbero derivare da un attacco di sicurezza è ovviamente una parte fondamentale della modellazione delle minacce. I danni possono includere perdita di dati, errore hardware o multimediale, prestazioni secondarie o qualsiasi misura simile applicabile al dispositivo e al relativo ambiente operativo.
La riproducibilità è una misura della frequenza con cui un tipo di attacco specificato avrà esito positivo. Una minaccia facilmente riproducibile è più probabile che venga sfruttata rispetto a una vulnerabilità che si verifica raramente o imprevedibile. Ad esempio, le minacce alle funzionalità installate per impostazione predefinita o usate in ogni percorso di codice potenziale sono altamente riproducibili.
L'exploitbilità valuta lo sforzo e le competenze necessarie per montare un attacco. Una minaccia che può essere attaccata da uno studente universitario relativamente inesperto è altamente sfruttabile. Un attacco che richiede personale altamente qualificato ed è costoso da eseguire è meno sfruttabile.
Nella valutazione dell'exploitbilità, prendere in considerazione anche il numero di potenziali utenti malintenzionati. Una minaccia che può essere sfruttata da qualsiasi utente remoto anonimo è più sfruttabile rispetto a quella che richiede un utente locale altamente autorizzato.
Utenti interessati. Il numero di utenti che potrebbero essere interessati da un attacco è un altro fattore importante nella valutazione di una minaccia. Un attacco che potrebbe influire al massimo su uno o due utenti sarebbe relativamente basso su questa misura. Viceversa, un attacco Denial of Service che arresta un arresto anomalo di un server di rete potrebbe influire su migliaia di utenti e quindi sarebbe molto più elevato.
La individuabilità è la probabilità che una minaccia venga sfruttata. La individuabilità è difficile da stimare in modo accurato. L'approccio più sicuro consiste nel presupporre che eventuali vulnerabilità saranno eventualmente sfruttate e, di conseguenza, di affidarsi alle altre misure per stabilire la classificazione relativa della minaccia.
Esempio: Valutazione delle minacce tramite DREAD
Continuando con l'esempio illustrato in precedenza, la tabella seguente illustra come una finestra di progettazione potrebbe valutare l'ipotetico attacco Denial of Service:
| Criterio DREAD | Punteggio | Commenti |
|---|---|---|
| Danni | 8 | Interrompe temporaneamente il lavoro, ma non causa danni permanenti o perdite di dati. |
| Reproducibility | 10 | Fa sì che il dispositivo non riesca ogni volta. |
| Exploitability | 7 | Richiede uno sforzo mirato per determinare la sequenza di comandi. |
| Affected users | 10 | Influisce su ogni modello di questo dispositivo sul mercato. |
| Individuabilità | 10 | Si supponga che ogni potenziale minaccia venga individuata. |
| Totale: | 9.0 | La mitigazione di questo problema è alta priorità. |
Mitigazione delle minacce
La progettazione del driver deve attenuare tutte le minacce esposte dal modello. Tuttavia, in alcuni casi, la mitigazione potrebbe non essere pratica. Si consideri ad esempio un attacco che potenzialmente interessa pochissimi utenti ed è improbabile che si verifichi una perdita di dati o di usabilità del sistema. Se la mitigazione di una minaccia di questo tipo richiede diversi mesi di impegno aggiuntivo, è possibile scegliere ragionevolmente di dedicare più tempo al test del driver. Tuttavia, tenere presente che alla fine un utente malintenzionato potrebbe individuare la vulnerabilità e montare un attacco e quindi il driver richiederà una patch per il problema.
Inclusione della modellazione delle minacce in un processo più ampio del ciclo di vita dello sviluppo della sicurezza
Prendere in considerazione l'inclusione del processo di modellazione delle minacce in un ciclo di vita di sviluppo sicuro più ampio - SDL.
Il processo Microsoft SDL offre un certo numero di processi di sviluppo software consigliati che possono essere modificati per adattarsi a qualsiasi dimensione dell'organizzazione, incluso un singolo sviluppatore. Prendere in considerazione l'aggiunta di componenti delle raccomandazioni SDL al processo di sviluppo del software.
Per altre informazioni, vedere Microsoft Security Development Lifecycle (SDL) - Indicazioni sui processi.
Formazione e funzionalità organizzative : completare la formazione sulla sicurezza dello sviluppo software per espandere la capacità di riconoscere e correggere le vulnerabilità del software.
Microsoft rende disponibili quattro classi di formazione SDL di base per il download. Classi di formazione di base del ciclo di vita per lo sviluppo della sicurezza Microsoft
Per informazioni più dettagliate sulla formazione SDL, vedere questo white paper. Formazione essenziale sulla sicurezza del software per Microsoft SDL
Requisiti e progettazione : la migliore opportunità di creare software attendibile è durante le fasi iniziali di pianificazione di una nuova versione o di una nuova versione, perché i team di sviluppo possono identificare gli oggetti chiave e integrare sicurezza e privacy, riducendo al minimo le interruzioni dei piani e delle pianificazioni.
Un output chiave in questa fase consiste nell'impostare obiettivi di sicurezza specifici. Ad esempio, decidere che tutto il codice deve passare l'analisi del codice di Visual Studio "Tutte le regole" con zero avvisi.
Implementazione : tutti i team di sviluppo devono definire e pubblicare un elenco di strumenti approvati e i controlli di sicurezza associati, ad esempio opzioni del compilatore/linker e avvisi.
Per uno sviluppatore di driver la maggior parte delle operazioni utili viene eseguita in questa fase. Poiché il codice viene scritto, viene esaminato per individuare eventuali debolezze. Strumenti come l'analisi del codice e il verificatore del driver vengono usati per cercare le aree nel codice che possono essere rafforzate.
Verifica : la verifica è il punto in cui il software è completo dal punto di vista funzionale e viene testato in base agli obiettivi di sicurezza descritti nella fase di progettazione e dei requisiti.
È possibile usare strumenti aggiuntivi come binscope e tester fuzz per verificare che gli obiettivi di progettazione della sicurezza siano stati soddisfatti e che il codice sia pronto per la spedizione
Rilascio e risposta : in preparazione al rilascio di un prodotto, è consigliabile creare un piano di risposta agli eventi imprevisti che descrive cosa fare per rispondere alle nuove minacce e come si gestisce il driver dopo la spedizione. Questo lavoro in anticipo significa che sarà possibile rispondere più velocemente se i problemi di sicurezza vengono identificati nel codice fornito.
Per altre informazioni sul processo SDL, vedere queste risorse aggiuntive:
Questo è il sito Microsoft SDL primario e offre una panoramica di SDL. https://www.microsoft.com/sdl
Questo blog descrive come scaricare una copia gratuita di The Security Development Lifecycle: SDL, di Michael Howard e Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/
Questa pagina contiene collegamenti ad altre pubblicazioni SDL. https://www.microsoft.com/SDL/Resources/publications.aspx
Invito all'azione
Per gli sviluppatori di driver:
- Rendere la modellazione delle minacce parte della progettazione dei driver.
- Eseguire i passaggi per attenuare in modo efficiente le minacce nel codice del driver.
- Acquisire familiarità con i problemi di sicurezza e affidabilità che si applicano al driver e al tipo di dispositivo. Per altre informazioni, vedere le sezioni specifiche del dispositivo windows Device Driver Kit (WDK).
- Comprendere quali controlli il sistema operativo, il gestore di I/O e tutti i driver di livello superiore eseguono prima che le richieste degli utenti raggiungano il driver e quali controlli non eseguono.
- Usare gli strumenti di WDK, ad esempio verifica driver per testare e verificare il driver.
- Esaminare i database pubblici di minacce note e vulnerabilità del software.
Per altre risorse di sicurezza dei driver, vedere Elenco di controllo per la sicurezza dei driver.
Risorse di sicurezza software
Libri
Scrittura di secure code, seconda edizione di Michael Howard e David LeBlanc
24 Peccati mortali della sicurezza del software: difetti di programmazione e come risolverli, prima edizione di Michael Howard, David LeBlanc e John Viega
L'arte della valutazione della sicurezza software: identificazione e prevenzione delle vulnerabilità software, di Mark Dowd, John McDonald e Justin Schuh
Informazioni per sviluppatori di hardware e driver Microsoft
Annullare la logica nel white paper driver di Windows
Modello di sicurezza di Windows: cosa deve sapere ogni writer di driver
Microsoft Windows Driver Development Kit (DDK)
Vedere Tecniche di programmazione dei drivernell'architettura del driver in modalità kernel
Strumenti di test
Vedere Windows Hardware Lab Kit in Test per ottenere prestazioni e compatibilità
Database pubblici di minacce note e vulnerabilità del software
Per espandere la conoscenza delle minacce software, esaminare i database pubblici disponibili di minacce note e vulnerabilità software.
- Vulnerabilità ed esposizioni comuni (CVE): https://cve.mitre.org/
- Enumerazione Punti deboli comuni: https://cwe.mitre.org/
- Enumerazione e classificazione dei criteri di attacco comuni: https://capec.mitre.org/index.html
- NIST gestisce un sito che descrive come vengono catalogate le vulnerabilità: https://samate.nist.gov/BF/