Modelagem de ameaças para controladores de software

Os desenvolvedores e arquitetos de driver devem tornar a modelagem de ameaças parte integrante do processo de projeto para qualquer driver. Este tópico fornece diretrizes para a criação de modelos de ameaças para drivers do Windows.

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

Projetar um driver seguro envolve:

• Identificando os pontos em que o motorista pode estar vulnerável a um ataque.
• Analisando os tipos de ataques que podem ser montados em cada um desses pontos.
• Garantindo que o driver seja projetado de forma a bloquear tais ataques.

A modelagem de ameaças é uma abordagem estruturada para essas tarefas de design importantes. Um modelo de ameaça é uma maneira de categorizar e analisar as ameaças a um ativo. Do ponto de vista de um gravador de driver, 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?
• Para quais ameaças os ativos são vulneráveis?
• Quão importante ou provável é cada ameaça?
• Como você pode atenuar 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 tratada como uma reflexão posterior. Um bom modelo de ameaça pode ajudar a localizar e evitar bugs durante o processo de design, eliminando patches potencialmente caros posteriormente e possíveis danos de reputação à 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 esses recursos.

• O site do Microsoft SDL:

  https://www.microsoft.com/sdl

• Implementação simplificada do Microsoft SDL:

  Baixar White Paper

• Esta entrada de blog descreve como baixar uma cópia gratuita do Ciclo de Vida do Desenvolvimento de Segurança: 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 driver, dos tipos de ameaças aos quais o driver pode ser 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 atenuar as possíveis ameaças.

A modelagem de ameaças é mais eficaz quando executada de forma organizada e estruturada durante o design do driver, em vez de acidentalmente 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 por meio do driver. Inclua todas as tarefas possíveis executadas pelo driver 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 por meio do driver e identificar as interfaces externas, os limites e as interações do driver.
2. Analise as possíveis ameaças à segurança, com base no diagrama de fluxo de dados.
3. Avalie as ameaças identificadas na etapa anterior e determine como atenuá-las.

Criar um diagrama de fluxo de dados

Um diagrama de fluxo de dados mostra na 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 hipotético driver WDM (Modelo de Driver do Windows) no modo kernel. Independentemente da arquitetura do 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.

Nota A figura anterior mostra os dados fluindo diretamente entre um processo de usuário e o driver e omite todos os drivers intermediários. No entanto, na realidade, todas as solicitações passam pelo gerente de E/S e podem percorrer um ou mais drivers de nível superior antes de alcançar um driver específico. 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 drivers em modo kernel devem validar os dados que se originam no modo de usuário.

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
• Solicitações de Plug-and-Play (IRP_MJ_PNP)
• Solicitações de gerenciamento de energia (IRP_MJ_POWER)
• Solicitações internas de controle de E/S do dispositivo (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 gravar solicitações (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
• Solicitações de controle de E/S de dispositivos públicos (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.

Por fim, 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 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 não tem detalhes. Em alguns casos, um diagrama de um nível, como o exemplo, é adequado para entender as fontes de dados e os caminhos. Se o driver lidar 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 como "Manipular Solicitações de E/S" pode ser expandido para 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 drivers de classe para muitos tipos comuns de dispositivos. Um driver de classe fornecido pelo sistema funciona com um minidriver fornecido pelo fornecedor, que normalmente é uma DLL (biblioteca de vínculo dinâmico) 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é downloads de freeware, shareware e Web de origem potencialmente duvidosa. Dependendo do dispositivo específico, talvez você também precise considerar codecs de mídia ou filtros de terceiros fornecidos pela sua empresa para dar suporte ao dispositivo. As fontes de dados possíveis incluem:

• IRP_MJ_XXX solicitações que o driver manipula
• IOCTLs que o driver define ou manipula
• APIs que o driver chama
• Rotinas de retorno de chamada
• Quaisquer outras interfaces que o driver expõe
• Arquivos que o driver lê ou grava, incluindo os usados durante a instalação
• Chaves do Registro que o driver lê ou grava
• Páginas de propriedades de configuração e quaisquer outras informações fornecidas pelo usuário que o driver consome

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 dispositivo, co-instaladores e páginas de propriedades.

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

Analisar possíveis ameaças

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:

• Quais mecanismos de segurança estão em vigor para proteger cada recurso?
• Todas as transições e interfaces estão corretamente protegidas?
• O uso inadequado de um recurso sem querer pode comprometer a segurança?
• O uso mal-intencionado de um recurso poderia 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. Esse acrônimo é derivado de:

• Falsificação
• Amplificação de T
• Epudiação R
• Divulgação de Informação
• Negação de serviço
• Elevação de privilégios

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

• Falsificação refere-se ao uso das credenciais de outra pessoa para obter acesso a recursos inacessíveis. Um processo monta um ataque de falsificação passando credenciais forjadas ou roubadas.

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

• O repúdio ocorre quando um usuário nega a execução de uma ação, mas o destino 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 poderá ser suscetível a repúdio se ele não registrar solicitações para alterar as características de seu dispositivo, como foco, área digitalizada, frequência de captura de imagem, localização de destino de imagens capturadas e assim por diante. As imagens resultantes podem 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 implica: a divulgação de informações a um usuário que não tem permissão para vê-las. Qualquer driver que passa informações de ou para um buffer de usuário é suscetível a ameaças de divulgação de informações. 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 escrever dados.

• Ataques de negação de serviço ameaçam a capacidade dos usuários válidos de acessar recursos. Os recursos podem ser espaço em disco, conexões de rede ou um dispositivo físico. Ataques que reduzem o desempenho a 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 dificultar a capacidade de outros usuários válidos executarem 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 em um par KeEnterCriticalRegion/KeLeaveCriticalRegion , que desabilita e habilita novamente a entrega de APCs (chamadas de procedimento assíncrono). Se o driver não usar essas rotinas, um APC poderá fazer com que o sistema operacional suspenda o thread que contém o semáforo. Como resultado, outros processos (incluindo os criados por um administrador) não seriam capazes de obter acesso à estrutura.

• Um ataque de elevação de privilégio pode ocorrer se um usuário sem privilégios obtiver status privilegiado. Um driver no 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 do ZwXxx ignoram verificações de segurança. Os controladores no modo núcleo devem validar cada identificador que recebem dos chamadores do modo de usuário.

  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 no modo kernel ou no modo de usuário. Em IRPs que chegam da rede ou do serviço de servidor (SRVSVC), o valor de RequestorMode é KernelMode, independentemente da origem da solicitação. Para evitar esses ataques, os drivers devem executar verificações de controle de acesso para essas solicitações em vez de simplesmente usar o valor de RequestorMode.

Técnicas de análise de drivers

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 executar uma análise completa, você deve explorar a possibilidade de ameaças em cada ponto potencialmente vulnerável no 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 pode 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 esquemas 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 é 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. Uma estrutura de tópicos é uma alternativa a uma árvore de ameaças.

Uma estrutura de esboço simplesmente lista em ordem hierárquica as etapas para confrontar uma ameaça específica. Por exemplo:

1.0 Fazer com que o dispositivo pare de responder.

1.1 Emitir IOCTLS na sequência de falhas.

1.1.1 Determinar a sequência que faz com que o dispositivo falhe.

1.1.2 Obtenha privilégios elevados para emitir IOCTLs internos.

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

Modelagem de ameaças de caminho rápido

Se os recursos forem limitados, em vez de criar um diagrama de modelo de ameaça completo, uma estrutura de tópicos de resumo poderá ser criada 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
• Solicitações de Plug-and-Play (IRP_MJ_PNP)
• Solicitações de gerenciamento de energia (IRP_MJ_POWER)
• Solicitações internas de controle de E/S do dispositivo (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 gravar solicitações (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
• Solicitações de controle de E/S de dispositivos públicos (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 o driver, você pode examinar cada área de entrada e saída para possíveis ameaças.

A abordagem DREAD para a 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:

• Amage D
• Eprodutibilidade do R
• Exploitability
• Usuários afetados
• Descobribilidade

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

• Danos. 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.

• Reprodutibilidade é uma medida da frequência com que um tipo de ataque especificado terá êxito. Uma ameaça facilmente reproduzível é mais provável de ser explorada do que uma vulnerabilidade que ocorre raramente ou imprevisível. Por exemplo, as ameaças a recursos instalados por padrão ou que são usados em cada caminho de código potencial são altamente reproduzíveis.

• Explorabilidade 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 para realizar é menos explorável.

  Ao avaliar a explorabilidade, considere também o número de possíveis invasores. Uma ameaça que pode ser explorada por qualquer usuário remoto e anônimo é mais explorável do que uma que requer um usuário no local e altamente autorizado.

• Usuários 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 poderia afetar no máximo um ou dois usuários classificaria relativamente baixo nessa medida. Por outro lado, um ataque de negação de serviço que trava um servidor de rede pode afetar milhares de usuários e, portanto, classificaria muito mais alto.

• A identificabilidade é a probabilidade de que uma ameaça seja explorada. A capacidade de descoberta é difícil de estimar com precisão. A abordagem mais segura é assumir que qualquer vulnerabilidade eventualmente será aproveitada e, consequentemente, dependerá das 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:

Mitigando ameaças

O design do driver deve reduzir todas as ameaças expostas pelo modelo. No entanto, em alguns casos, a mitigaçã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 dessa ameaça exigir vários meses de esforço adicional, você poderá optar razoavelmente 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 exigirá 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 SDL de Desenvolvimento Seguro mais amplo.

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

Para obter mais informações, consulte Microsoft Security Development Lifecycle (SDL) – Diretrizes de processo.

Treinamento e funcionalidades organizacionais – Prossiga com o 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 de SDL para download. Classes de Treinamento do Núcleo de Ciclo de Vida do Desenvolvimento de Segurança da Microsoft

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

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

Uma saída importante nesta fase é definir metas de segurança específicas. Por exemplo, decidir que todo o código deve passar na análise de código do Visual Studio "Todas as Regras" sem 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 de compilador/vinculador e avisos.

Para um desenvolvedor de driver, a maior parte do trabalho útil é feita nesta fase. Como 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 do código que podem ser fortalecidas.

Verificação – A verificação é o ponto em que o software está funcionalmente concluído e é testado em relação às metas de segurança descritas nos requisitos e na fase de design.

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

Lançamento e resposta – Em preparação para lançar um produto, é desejável criar um plano de resposta a incidentes que descreva o que você fará para responder a novas ameaças e como você oferecerá suporte contínuo ao driver após o envio. Fazer esse trabalho com antecedência significará que você poderá responder mais rapidamente se os problemas de segurança forem identificados no código fornecido.

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

• Este é o principal site 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 do Ciclo de Vida de Desenvolvimento de Segurança: 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 SDL adicionais. https://www.microsoft.com/SDL/Resources/publications.aspx

Chamada para ação

Para desenvolvedores de drivers:

• Faça da modelagem de ameaças parte do design do driver.
• Tome medidas para mitigar com eficiência as ameaças no código de driver.
• Familiarize-se com os problemas de segurança e confiabilidade que se aplicam ao seu driver e ao 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 gerente de E/S e quaisquer drivers de nível superior realizam antes que as solicitações do usuário cheguem ao seu driver — e quais verificações eles não realizam.
• Use ferramentas do WDK, como o verificador de driver, para testar e verificar o driver.
• Examine bancos de dados públicos de ameaças conhecidas e vulnerabilidades de software.

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

Recursos de segurança de software

Livros

Escrevendo Código Seguro, Segunda Edição por Michael Howard e David LeBlanc

24 Pecados Mortais de Segurança de Software: Falhas de Programação e Como Corrigi-los, 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 do Desenvolvedor de Hardware e Driver da Microsoft

Cancelamento de lógica em drivers do Windows white paper

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

Microsoft Windows Driver Development Kit (DDK)

Consulte Técnicas de Programação de Driver na Arquitetura do DriverKernel-Mode

Ferramentas de Teste

Consulte o Kit de Laboratório de Hardware do Windows em Teste de Desempenho e Compatibilidade

Bancos de dados públicos de ameaças conhecidas e vulnerabilidades de software

Para expandir seu conhecimento sobre ameaças de software, examine os bancos de dados públicos 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 comuns: 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/

Consulte Também

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