Modelação de ameaças para controladores

Os programadores e arquitetos de drivers devem integrar a modelação de ameaças como uma parte essencial do processo de design de qualquer driver. Este tópico fornece diretrizes para a criação de modelos de ameaça para drivers do Windows.

A segurança deve ser um ponto de design fundamental para qualquer motorista. Qualquer produto de sucesso é um alvo. Se você estiver escrevendo um driver para Windows, você deve assumir que em algum momento, em algum lugar, alguém tentará usar seu driver para comprometer a segurança do sistema.

Projetar um driver seguro envolve:

• Identificar os pontos em que o condutor pode estar vulnerável a um ataque.
• Analisar os tipos de ataques que poderiam ser montados em cada um desses pontos.
• Garantir que o condutor foi concebido de forma a impedir tais ataques.

A modelagem de ameaças é uma abordagem estruturada para essas importantes tarefas de design. Um modelo de ameaça é uma forma de categorizar e analisar as ameaças a um ativo. Do ponto de vista de um gravador de drivers, os ativos são o hardware, o software e os dados no computador ou na rede.

Um modelo de ameaça responde às seguintes perguntas:

• Quais ativos precisam de proteção?
• A que ameaças são vulneráveis os ativos?
• Qual é a importância ou a probabilidade de cada ameaça?
• Como você pode mitigar as ameaças?

A modelagem de ameaças é uma parte importante do design de software porque garante que a segurança seja incorporada ao produto, em vez de ser tratada como uma reflexão posterior. Um bom modelo de ameaça pode ajudar a encontrar e prevenir bugs durante o processo de design, eliminando patches potencialmente caros mais tarde e possíveis danos à reputação da sua organização.

Esta seção aplica os princípios da modelagem de ameaças ao design do driver e fornece exemplos de ameaças às quais um driver pode ser suscetível. Para obter uma descrição mais completa da modelagem de ameaças para design de software, consulte estes recursos.

• O site da Microsoft SDL:

  https://www.microsoft.com/sdl

• Implementação simplificada do Microsoft SDL:

  Download do Livro Branco

• Esta entrada de blog descreve como baixar uma cópia gratuita de The Security Development Lifecycle: SDL, de Michael Howard e Steve Lipner:

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

Criar modelos de ameaça para drivers de software

A criação de um modelo de ameaça requer uma compreensão completa do design do motorista, dos tipos de ameaças aos quais o motorista pode estar exposto e das consequências de um ataque de segurança que explora uma ameaça específica. Depois de criar o modelo de ameaça para um driver, você pode determinar como mitigar as ameaças potenciais.

A modelagem de ameaças é mais eficaz quando executada de forma organizada e estruturada durante o projeto do driver, em vez de aleatoriamente durante a codificação. Uma abordagem estruturada aumenta a probabilidade de você descobrir vulnerabilidades no design, ajudando assim a garantir que o modelo seja abrangente.

Uma maneira de organizar um esforço de modelagem de ameaças é seguir estas etapas:

1. Crie um diagrama estruturado mostrando o fluxo de dados através do driver. Inclua todas as tarefas possíveis que o driver executa e a origem e o destino de todas as entradas e saídas do driver. Um diagrama de fluxo de dados formal, ou diagrama estruturado semelhante, pode ajudá-lo a analisar o caminho dos dados através do seu driver e identificar as interfaces, limites e interações externas do driver.
2. Analise as potenciais ameaças à segurança, com base no diagrama de fluxo de dados.
3. Avalie as ameaças identificadas na etapa anterior e determine como mitigá-las.

Criar um diagrama de fluxo de dados

Um diagrama de fluxo de dados mostra de forma conceitual o fluxo de dados entre o driver e as entidades externas com as quais ele interage — normalmente o sistema operacional, um processo de usuário e o dispositivo. Um diagrama de fluxo de dados formal usa os seguintes símbolos:

A figura a seguir mostra um diagrama de fluxo de dados de exemplo para um driver WDM (Windows Driver Model) hipotético de modo kernel. Independentemente da arquitetura para seu tipo específico de driver, o modelo conceitual é o mesmo: mostrar todos os caminhos de dados e identificar cada fonte de dados que entra ou sai do driver.

Observação A figura anterior mostra os dados fluindo diretamente entre um processo do usuário e o driver e omite quaisquer drivers intermediários. No entanto, na realidade, todos os pedidos passam pelo gestor de E/S e podem atravessar um ou mais condutores de nível superior antes de chegarem a um determinado condutor. A figura omite essas etapas intermediárias para enfatizar a importância da fonte original dos dados e o contexto do thread que forneceu os dados. Os controladores em modo kernel devem validar os dados que se originam no modo de utilizador.

As informações entram no driver devido a solicitações do sistema operacional, solicitações de um processo de usuário ou solicitações (normalmente interrupções) do dispositivo.

O driver na figura anterior recebe dados do sistema operacional em vários tipos de solicitações:

• Solicitações para executar tarefas administrativas para o driver e seu dispositivo, por meio de chamadas para as rotinas DriverEntry, DriverUnload e AddDevice
• Pedidos Plug and Play (IRP_MJ_PNP)
• Solicitações de gerenciamento de energia (IRP_MJ_POWER)
• Solicitações de controle de E/S do dispositivo interno (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Em resposta a essas solicitações, os dados fluem do driver de volta para o sistema operacional como informações de status. O driver na figura recebe dados de um processo de usuário nos seguintes tipos de solicitações:

• Criar, ler e escrever pedidos (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
• Solicitações de controle de E/S de dispositivo público (IRP_MJ_DEVICE_ CONTROL)

Em resposta a essas solicitações, os dados de saída e as informações de status fluem do driver de volta para o processo do usuário.

Finalmente, o driver recebe dados do dispositivo devido a operações de E/S do dispositivo ou ações do usuário (como abrir a bandeja em uma unidade de CD) que alteram o status do dispositivo. Da mesma forma, os dados do driver fluem para o dispositivo durante as operações de E/S e alterações no status do dispositivo.

A figura anterior mostra o fluxo de dados do driver em um nível conceitual amplo. Cada círculo representa uma tarefa relativamente grande e carece de detalhes. Em alguns casos, um diagrama de um nível, como o exemplo, é adequado para compreender as fontes de dados e caminhos. Se o driver lida com muitos tipos diferentes de solicitações de E/S de fontes variadas, talvez seja necessário criar um ou mais diagramas adicionais que mostrem mais detalhes. Por exemplo, o círculo rotulado "Manipular solicitações de E/S" pode ser expandido em um diagrama separado, semelhante à figura a seguir.

O segundo diagrama mostra tarefas separadas para cada tipo de solicitação de E/S no primeiro diagrama. (Para simplificar, os caminhos de dados para o dispositivo foram omitidos.)

As entidades externas e os tipos de entrada e saída mostrados no diagrama podem variar, dependendo do tipo de dispositivo. Por exemplo, o Windows fornece controladores de classe para muitos tipos de dispositivos comuns. Um driver de classe fornecido pelo sistema funciona com um minidriver fornecido pelo fornecedor, que normalmente é uma biblioteca de vínculo dinâmico (DLL) que contém um conjunto de rotinas de retorno de chamada. As solicitações de E/S do usuário são direcionadas para o driver de classe, que então chama as rotinas no minidriver para executar tarefas específicas. O minidriver normalmente não recebe todo o pacote de solicitação de E/S como entrada; Em vez disso, cada rotina de retorno de chamada recebe apenas os dados necessários para sua tarefa específica.

Ao criar os diagramas de fluxo de dados, lembre-se da variedade de fontes para solicitações de driver. Qualquer código executado no computador de um usuário pode gerar uma solicitação de E/S para um driver, desde aplicativos conhecidos, como o Microsoft Office, até freeware, shareware e downloads da Web de origem potencialmente duvidosa. Dependendo do seu dispositivo específico, você também pode precisar considerar codecs de mídia ou filtros de terceiros que sua empresa envia para oferecer suporte ao dispositivo. As possíveis fontes de dados incluem:

• IRP_MJ_XXX solicita que o motorista manipule
• IOCTLs que o driver define ou manipula
• APIs chamadas pelo driver
• Rotinas de callback
• Quaisquer outras interfaces que o driver expõe
• Arquivos que o driver lê ou grava, incluindo aqueles usados durante a instalação
• Chaves do Registro que o driver lê ou grava
• Páginas de configuração de propriedades e quaisquer outras informações fornecidas pelo utilizador que são utilizadas pelo driver

Seu modelo também deve abranger os procedimentos de instalação e atualização do driver. Inclua todos os arquivos, diretórios e entradas do Registro que são lidos ou gravados durante a instalação do driver. Considere também as interfaces expostas em instaladores de dispositivos, coinstaladores e páginas de propriedades.

Qualquer ponto em que o driver troca dados com uma entidade externa é potencialmente vulnerável a ataques.

Analise ameaças potenciais

Depois de identificar os pontos em que um driver pode estar vulnerável, você pode determinar quais tipos de ameaças podem ocorrer em cada ponto. Considere os seguintes tipos de perguntas:

• Que mecanismos de segurança estão em vigor para proteger cada recurso?
• Todas as transições e interfaces estão devidamente protegidas?
• O uso indevido de um recurso pode comprometer involuntariamente a segurança?
• O uso mal-intencionado de um recurso pode comprometer a segurança?
• As configurações padrão fornecem segurança adequada?

A abordagem STRIDE para categorização de ameaças

O acrónimo STRIDE descreve seis categorias de ameaças ao software. Este acrónimo deriva de:

• Manipulação de Identidade
• Tampering
• Repudiação
• IDivulgação de informações
• Denial de serviço
• Levantamentodo privilégio

Usando o STRIDE como guia, você pode fazer perguntas detalhadas sobre os tipos de ataques que podem ser direcionados a um motorista. O objetivo é determinar os tipos de ataques que podem ser possíveis em cada ponto vulnerável do driver e, em seguida, criar um cenário para cada possível ataque.

• Falsificação é usar as credenciais de outra pessoa para obter acesso a ativos inacessíveis de outra forma. Um processo monta um ataque de falsificação passando credenciais falsificadas ou roubadas.

• Adulteração é alterar dados para montar um ataque. Por exemplo, um controlador pode ser suscetível a adulteração se os arquivos de controlador necessários não estiverem adequadamente protegidos por assinatura de controladores e listas de controle de acesso (ACLs). Nessa situação, um usuário mal-intencionado pode alterar os arquivos, violando assim a segurança do sistema.

• O repúdio ocorre quando um usuário nega a realização de uma ação, mas o alvo da ação não tem como provar o contrário. Um driver pode ser suscetível a uma ameaça de repúdio se não registrar ações que possam comprometer a segurança. Por exemplo, um driver para um dispositivo de vídeo pode ser suscetível a repúdio se não registrar solicitações para alterar características de seu dispositivo, como foco, área digitalizada, frequência de captura de imagem, localização de destino das imagens capturadas e assim por diante. As imagens resultantes poderiam estar corrompidas, mas os administradores do sistema não teriam como determinar qual usuário causou o problema.

• As ameaças de divulgação de informações são exatamente como o nome indica: a divulgação de informações a um usuário que não tem permissão para vê-las. Qualquer driver que passe informações de ou para uma memória intermédia do utilizador é suscetível a ameaças de divulgação de dados. Para evitar ameaças de divulgação de informações, os drivers devem validar o comprimento de cada buffer de usuário e inicializar os buffers com zero antes de gravar dados.

• Os ataques de negação de serviço ameaçam a capacidade de usuários válidos acessarem recursos. Os recursos podem ser espaço em disco, conexões de rede ou um dispositivo físico. Os ataques que diminuem o desempenho para níveis inaceitáveis também são considerados ataques de negação de serviço. Um driver que permite que um processo de usuário monopolize um recurso do sistema desnecessariamente pode ser suscetível a um ataque de negação de serviço se o consumo de recursos prejudicar a capacidade de outros usuários válidos de executar suas tarefas.

  Por exemplo, um driver pode usar um semáforo para proteger uma estrutura de dados durante a execução em IRQL = PASSIVE_LEVEL. No entanto, o driver deve adquirir e liberar o semáforo dentro de um par KeEnterCriticalRegion/KeLeaveCriticalRegion , que desativa e rehabilita a entrega de chamadas de procedimento assíncronas (APCs). Se o driver não conseguir usar essas rotinas, um APC pode fazer com que o sistema operacional suspenda o thread que contém o semáforo. Como resultado, outros processos (incluindo aqueles criados por um administrador) seriam incapazes de obter acesso à estrutura.

• Um ataque de elevação de privilégio pode ocorrer se um usuário sem privilégios ganhar status privilegiado. Um driver de modo kernel que passa um identificador de modo de usuário para uma rotina ZwXxx é vulnerável a ataques de elevação de privilégio porque as rotinas ZwXxx ignoram as verificações de segurança. Os controladores em modo kernel devem validar cada identificador que recebem de chamadores em modo de utilizador.

  Ataques de elevação de privilégio também podem ocorrer se um driver de modo kernel depender do valor RequestorMode no cabeçalho IRP para determinar se uma solicitação de E/S vem de um chamador de modo kernel ou de modo de usuário. Em IRPs que chegam da rede ou do serviço do servidor (SRVSVC), o valor de RequestorMode é KernelMode, independentemente da origem da solicitação. Para evitar tais ataques, os drivers devem executar verificações de controle de acesso para tais solicitações, em vez de simplesmente usar o valor de RequestorMode.

Técnicas de análise de motoristas

Uma maneira simples de organizar a análise é listar as áreas vulneráveis, juntamente com as ameaças potenciais e um ou mais cenários para cada tipo de ameaça.

Para realizar uma análise completa, você deve explorar a possibilidade de ameaças em todos os pontos potencialmente vulneráveis do driver. Em cada ponto vulnerável, determine cada categoria de ameaça (falsificação, adulteração, repúdio, divulgação de informações, negação de serviço e elevação de privilégio) que possa ser possível. Em seguida, crie um ou mais cenários de ataque para cada ameaça plausível.

Por exemplo, considere o fluxo de dados para solicitações de IRP_MJ_DEVICE_CONTROL, conforme mostrado na figura anterior. A tabela a seguir mostra dois tipos de ameaças que um driver pode encontrar ao processar essas solicitações:

Árvores de ameaças e esboços podem ser úteis na modelagem de cenários tão complexos.

Uma árvore de ameaças é um diagrama que mostra uma hierarquia de ameaças ou vulnerabilidades; Em essência, uma árvore de ameaças imita as etapas do usuário mal-intencionado na montagem de um ataque. O objetivo final do ataque está no topo da árvore. Cada nível subordinado mostra as etapas necessárias para realizar o ataque. A figura a seguir é uma árvore de ameaças simples para o cenário de negação de serviço no exemplo anterior.

A árvore de ameaças mostra as etapas necessárias para montar um ataque específico e as relações entre as etapas. Um esquema é uma alternativa a uma árvore de ameaças.

Um esboço simplesmente lista em ordem hierárquica as etapas para atacar uma ameaça específica. Por exemplo:

1.0 Faça com que o dispositivo pare de responder.

1.1 Emitir IOCTLS em sequência de falhas.

1.1.1 Determinar a sequência que causa a falha do dispositivo.

1.1.2 Obter privilégios elevados para emitir IOCTLs internos.

Qualquer uma das técnicas pode ajudá-lo a entender quais ameaças são mais perigosas e quais vulnerabilidades em seu design são mais críticas.

Modelagem rápida de ameaças de caminho

Se os recursos forem limitados, em vez de criar um diagrama de modelo de ameaça completo, um esboço de resumo pode ser criado para ajudar a avaliar os riscos de segurança para o driver. Por exemplo, o texto abaixo descreve algumas das áreas de superfície diagramadas no driver de exemplo descrito no exemplo anterior.

O driver recebe dados do sistema operacional em vários tipos de solicitações:

• Solicitações para executar tarefas administrativas para o driver e seu dispositivo, por meio de chamadas para as rotinas DriverEntry, DriverUnload e AddDevice
• Pedidos Plug and Play (IRP_MJ_PNP)
• Solicitações de gerenciamento de energia (IRP_MJ_POWER)
• Solicitações de controle de E/S do dispositivo interno (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Em resposta a essas solicitações, os dados fluem do driver de volta para o sistema operacional como informações de status. O driver recebe dados de um processo de usuário nos seguintes tipos de solicitações:

• Criar, ler e escrever pedidos (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
• Solicitações de controle de E/S de dispositivo público (IRP_MJ_DEVICE_ CONTROL)

Em resposta a essas solicitações, os dados de saída e as informações de status fluem do driver de volta para o processo do usuário.

Usando essa compreensão básica do fluxo de dados para seu driver, você pode examinar cada área de entrada e saída em busca de possíveis ameaças.

A abordagem DREAD à avaliação de ameaças

Determinar como e onde um motorista pode ser atacado não é suficiente. Em seguida, você deve avaliar essas ameaças potenciais, determinar suas prioridades relativas e elaborar uma estratégia de mitigação.

DREAD é um acrónimo que descreve cinco critérios para avaliar ameaças ao software. DREAD significa:

• Damagem
• Reprodutibilidade
• Exploitability
• Usuários afetados
• Descobribilidade

Para priorizar as ameaças ao seu motorista, classifique cada ameaça de 1 a 10 em todos os 5 critérios de avaliação DREAD e, em seguida, adicione as pontuações e divida por 5 (o número de critérios). O resultado é uma pontuação numérica entre 1 e 10 para cada ameaça. Pontuações altas indicam ameaças graves.

• Dano. Avaliar os danos que podem resultar de um ataque de segurança é, obviamente, uma parte crítica da modelagem de ameaças. Os danos podem incluir perda de dados, falha de hardware ou mídia, desempenho abaixo do padrão ou qualquer medida semelhante que se aplique ao seu dispositivo e seu ambiente operacional.

• A reprodutibilidade é uma medida da frequência com que um tipo especificado de ataque será bem-sucedido. Uma ameaça facilmente reproduzível tem mais probabilidade de ser explorada do que uma vulnerabilidade que ocorre raramente ou é imprevisível. Por exemplo, ameaças a recursos instalados por padrão ou usados em todos os caminhos de código potenciais são altamente reproduzíveis.

• A capacidade de exploração avalia o esforço e a experiência necessários para montar um ataque. Uma ameaça que pode ser atacada por um estudante universitário relativamente inexperiente é altamente explorável. Um ataque que requer pessoal altamente qualificado e é caro de realizar é menos explorável.

  Ao avaliar a capacidade de exploração, considere também o número de potenciais atacantes. Uma ameaça que pode ser explorada por qualquer utilizador remoto e anónimo é mais explorável do que uma que requer um utilizador no local altamente autorizado.

• Utilizadores afetados. O número de usuários que podem ser afetados por um ataque é outro fator importante na avaliação de uma ameaça. Um ataque que pudesse afetar no máximo um ou dois usuários teria uma taxa relativamente baixa nessa medida. Por outro lado, um ataque de recusa de serviço que cause a interrupção de um servidor de rede pode afetar milhares de utilizadores e, portanto, seria classificado muito mais alto.

• A capacidade de descoberta é a probabilidade de uma ameaça ser explorada. A capacidade de descoberta é difícil de estimar com precisão. A abordagem mais segura é assumir que qualquer vulnerabilidade acabará por ser aproveitada e, consequentemente, confiar nas outras medidas para estabelecer a classificação relativa da ameaça.

Exemplo: Avaliando ameaças usando DREAD

Continuando com o exemplo discutido acima, a tabela a seguir mostra como um designer pode avaliar o hipotético ataque de negação de serviço:

Mitigação de ameaças

O design do seu driver deve mitigar todas as ameaças que o seu modelo expõe. No entanto, em alguns casos, a atenuação pode não ser prática. Por exemplo, considere um ataque que potencialmente afeta muito poucos usuários e é improvável que resulte em perda de dados ou usabilidade do sistema. Se a mitigação de tal ameaça exigir vários meses de esforço adicional, você pode razoavelmente optar por gastar tempo adicional testando o driver. No entanto, lembre-se de que, eventualmente, um usuário mal-intencionado provavelmente encontrará a vulnerabilidade e montará um ataque e, em seguida, o driver precisará de um patch para o problema.

Incluindo a modelagem de ameaças em um processo mais amplo de ciclo de vida de desenvolvimento de segurança

Considere incluir o processo de modelagem de ameaças em um ciclo de vida de desenvolvimento seguro - SDL mais amplo.

O processo Microsoft SDL fornece uma série de processos de desenvolvimento de software recomendados que podem ser modificados para se adequar a qualquer tamanho de organização - incluindo um único desenvolvedor. Considere adicionar componentes das recomendações SDL ao seu processo de desenvolvimento de software.

Para obter mais informações, consulte Microsoft Security Development Lifecycle (SDL) – Process Guidance.

Treinamento e capacidades organizacionais - Realize treinamento de segurança de desenvolvimento de software para expandir sua capacidade de reconhecer e corrigir vulnerabilidades de software.

A Microsoft disponibiliza suas quatro classes principais de treinamento SDL para download. Classes de treinamento básico do ciclo de vida do desenvolvimento de segurança da Microsoft

Para obter informações mais detalhadas sobre o treinamento SDL, consulte este white paper. Treinamento essencial de segurança de software para o Microsoft SDL

Requisitos e design - A melhor oportunidade para criar software confiável é durante os estágios iniciais de planejamento de uma nova versão ou de uma nova versão, porque as equipes de desenvolvimento podem identificar objetos-chave e integrar segurança e privacidade, o que minimiza a interrupção de planos e cronogramas.

Uma saída fundamental nesta fase é definir metas de segurança específicas. Por exemplo, decidir que todo o seu código deve passar na análise de código do Visual Studio "Todas as regras" com zero avisos.

Implementação - Todas as equipes de desenvolvimento devem definir e publicar uma lista de ferramentas aprovadas e suas verificações de segurança associadas, como opções e avisos do compilador/vinculador.

Para um desenvolvedor de driver a maior parte do trabalho útil é feito nesta fase. À medida que o código é escrito, ele é revisado para possíveis fraquezas. Ferramentas como análise de código e verificador de driver são usadas para procurar áreas no código que podem ser protegidas.

Verificação - A verificação é o ponto em que o software está funcionalmente completo e é testado em relação aos objetivos de segurança descritos na fase de requisitos e projeto.

Ferramentas adicionais, como binscope e fuzz testers, podem ser usadas para validar que as metas de design de segurança foram atingidas e que o código está pronto para ser enviado

Lançamento e resposta - Na preparação para o lançamento de um produto, é desejável criar um plano de resposta a incidentes que descreva as ações a tomar para responder a novas ameaças e como proceder à manutenção do controlador após o seu envio. Fazer esse trabalho com antecedência significa que você será capaz de responder mais rapidamente se problemas de segurança forem identificados no código que foi enviado.

Para obter mais informações sobre o processo SDL, consulte estes recursos adicionais:

• Este é o site principal do Microsoft SDL e fornece uma visão geral do SDL. https://www.microsoft.com/sdl

• Este blog descreve como baixar uma cópia gratuita de The Security Development Lifecycle: SDL, de Michael Howard e Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Esta página fornece links para publicações adicionais do SDL. https://www.microsoft.com/SDL/Resources/publications.aspx

Apelo à ação

Para desenvolvedores de drivers:

• Integre a modelagem de ameaças no design do driver.
• Tome medidas para mitigar eficientemente as ameaças no seu código de driver.
• Familiarize-se com os problemas de segurança e confiabilidade que se aplicam ao seu driver e tipo de dispositivo. Para obter mais informações, consulte as seções específicas do dispositivo do Windows Device Driver Kit (WDK).
• Entenda quais verificações o sistema operacional, o gerenciador de E/S e quaisquer drivers de nível superior executam antes que as solicitações do usuário cheguem ao seu driver — e quais verificações eles não executam.
• Use ferramentas do WDK, como verificador de driver para testar e verificar seu driver.
• Analise bancos de dados públicos de ameaças conhecidas e vulnerabilidades de software.

Para obter recursos de segurança de driver adicionais, consulte Lista de verificação de segurança do driver.

Recursos de segurança de software

Livros

Writing Secure Code, Segunda Edição por Michael Howard e David LeBlanc

24 Pecados Mortais da Segurança de Software: Falhas de Programação e Como Corrigi-las, Primeira Edição por Michael Howard, David LeBlanc e John Viega

A arte da avaliação de segurança de software: identificar e prevenir vulnerabilidades de software, por Mark Dowd, John McDonald e Justin Schuh

Informações da Microsoft sobre desenvolvedores de hardware e drivers

Cancelar a lógica nos drivers do Windows - Livro branco

Modelo de segurança do Windows: o que todo gravador de driver precisa saber

Kit de Desenvolvimento de Driver do Microsoft Windows (DDK)

Consulte Técnicas de Programação de Driver em Kernel-Mode Arquitetura de Driver

Ferramentas de teste

Consulte Windows Hardware Lab Kit em Teste para desempenho e compatibilidade

Bases de dados públicas de ameaças conhecidas e vulnerabilidades de software

Para expandir o seu conhecimento sobre ameaças de software, reveja as bases de dados públicas disponíveis de ameaças conhecidas e vulnerabilidades de software.

• Vulnerabilidades e exposições comuns (CVE): https://cve.mitre.org/
• Enumeração de fraqueza comum: https://cwe.mitre.org/
• Enumeração e classificação de padrão de ataque comum: https://capec.mitre.org/index.html
• O NIST mantém um site que descreve como as vulnerabilidades são catalogadas: https://samate.nist.gov/BF/

Ver também

Lista de verificação de segurança do condutor