Modelagem de ameaças para drivers
Os autores e arquitetos de driver devem tornar a modelagem de ameaças parte integrante do processo de design para 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 driver. Qualquer produto bem-sucedido é um destino. 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.
A criação de um driver seguro envolve:
- Identificar os pontos em que o motorista pode estar vulnerável a um ataque.
- Analisando os tipos de ataques que podem ser montados em cada ponto.
- Garantir que o driver seja projetado de forma a impedir esses 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. Da perspectiva 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 à 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 esses recursos.
O site do Microsoft SDL:
Implementação simplificada do Microsoft SDL:
Esta entrada de blog descreve como baixar uma cópia gratuita de The Security Development Lifecycle: SDL, de Michael Howard e Steve Lipner:
Criar modelos de ameaça para drivers
A criação de um modelo de ameaça requer uma compreensão completa do design do driver, dos tipos de ameaças às 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:
- Crie um diagrama estruturado mostrando o fluxo de dados por meio 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 por meio do driver e identificar as interfaces externas, os limites e as interações do driver.
- Analise as possíveis ameaças à segurança, com base no diagrama de fluxo de dados.
- 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 em 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 (Modelo de Driver do Windows) no modo kernel hipotético. 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.
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 gerenciador 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 no modo kernel devem validar os dados originados no modo de usuário.
As informações inserem o driver devido a solicitações do sistema operacional, solicitações de um processo do 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 de controle de E/S internas do dispositivo (IRP_MJ_INTERNAL_DEVICE_CONTROL)
Em resposta a essas solicitações, os dados fluem do driver de volta para o sistema operacional à medida que status informações. 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 dispositivo público (IRP_MJ_DEVICE_ CONTROL)
Em resposta a essas solicitações, os dados de saída e status fluxo de informações 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 dispositivo status. Da mesma forma, os dados do driver fluem para o dispositivo durante operações de E/S e alterações no dispositivo status.
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 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 drivers de classe para muitos tipos de dispositivo comuns. 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 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 seu dispositivo específico, talvez você também precise considerar codecs de mídia ou filtros de terceiros que sua empresa envia 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 aqueles 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 protegidas corretamente?
- O uso inadequado de um recurso acidentalmente poderia 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:
- Spoofing
- Tampering
- Epudiação R
- Idivulgação de nformação
- Enial Dde serviço
- Elevation of privilege
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.
A falsificação está usando as credenciais de outra pessoa para obter acesso a ativos 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 poderá ser suscetível a adulteração se os arquivos de driver necessários não estiverem adequadamente protegidos pelas ACLs (listas de assinatura e controle de acesso) do driver. 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 execução de uma ação, mas o destino da ação não tem como provar o contrário. Um driver pode estar 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 de um dispositivo de vídeo poderá ser suscetível a repúdio se ele não registrar solicitações para alterar características de seu dispositivo, como foco, área verificada, frequência de captura de imagem, local 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 zero os buffers antes de gravar dados.
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. 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íncronas). 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 aqueles 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 não privilegiado obtiver privilégios status. Um driver no modo kernel que passa um identificador do modo de usuário para uma rotina ZwXxx é vulnerável a ataques de elevação de privilégio porque as rotinas do ZwXxx ignoram as verificações de segurança. Os drivers no modo kernel devem validar cada identificador que recebem de 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 driver
Uma maneira simples de organizar a análise é listar as áreas vulneráveis junto com as possíveis ameaças 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 todos os pontos potencialmente vulneráveis 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 possam ser possíveis. Em seguida, crie um ou mais cenários de ataque para cada ameaça plausível.
Por exemplo, considere o fluxo de dados para IRP_MJ_DEVICE_CONTROL solicitações, 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:
| Ponto vulnerável | Ameaça potencial (STRIDE) | Cenário |
|---|---|---|
| IRP_MJ_DEVICE_CONTROL solicitações | Negação de serviço Elevação de privilégio |
O processo do usuário emite uma sequência de IOCTLs que faz com que o dispositivo falhe. O processo do usuário emite um IOCTL que permite FILE_ANY_ACCESS. |
Árvores de ameaças e estruturas de tópicos 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 é na parte superior 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 tópicos simplesmente lista em ordem hierárquica as etapas para atacar 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 resumida 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 rotinas DriverEntry, DriverUnload e AddDevice
- Plug and Play solicitações (IRP_MJ_PNP)
- Solicitações de gerenciamento de energia (IRP_MJ_POWER)
- Solicitações de controle de E/S internas 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 status informações. 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 do dispositivo público (IRP_MJ_DEVICE_ CONTROL)
Em resposta a essas solicitações, os dados de saída e status fluxo de informações 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 driver pode ser atacado não é suficiente. Em seguida, você deve avaliar essas ameaças potenciais, determinar suas prioridades relativas e criar uma estratégia de mitigação.
DREAD é um acrônimo que descreve cinco critérios para avaliar ameaças ao software. DREAD significa:
- Damage
- Eprodutibilidade R
- Exploitability
- Usuáriosafetados
- Iscoverabilidade D
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 e 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. As 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 em potencial são altamente reproduzíveis.
A 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 para realizar é menos explorável.
Ao avaliar a exploração, 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 local 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 falha em um servidor de rede pode afetar milhares de usuários e, portanto, classificaria muito mais alto.
A capacidade de descoberta é 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 ataque hipotético de negação de serviço:
| Critério DREAD | Pontuação | Comentários |
|---|---|---|
| Danos | 8 | Interrompe o trabalho temporariamente, mas não causa danos permanentes ou perda de dados. |
| Reprodutibilidade | 10 | Faz com que o dispositivo falhe sempre. |
| Exploração | 7 | Requer um esforço focado para determinar a sequência de comandos. |
| Usuários afetados | 10 | Afeta todos os modelos deste dispositivo no mercado. |
| Detectabilidade | 10 | Pressupõe que todas as possíveis ameaças serão descobertas. |
| Total: | 9.0 | Atenuar esse problema é de alta prioridade. |
Mitigando ameaças
O design do driver deve atenuar todas as ameaças que seu modelo expõe. 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 mais tempo 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 ciclo de vida de desenvolvimento seguro mais amplo – SDL.
O processo 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 recursos organizacionais – busque 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 principais do ciclo de vida de 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 de uma nova versão, pois as equipes de desenvolvimento podem identificar os principais objetos e integrar a segurança e a privacidade, o que minimiza a interrupção dos planos e dos agendamentos.
Uma saída importante nesta fase é definir metas de segurança específicas. Por exemplo, decidir que todo o código deve passar a 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 e avisos do compilador/vinculador.
Para um desenvolvedor de driver, a maior parte do trabalho útil é feita nesta fase. Conforme o código é escrito, ele é revisado quanto a possíveis pontos fracos. 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 concluído e é testado em relação às metas de segurança descritas na fase de design e requisitos.
Ferramentas adicionais, como testadores de binscope e fuzz, podem ser usadas para validar se as metas de design de segurança foram atendidas e o código está pronto para ser enviado
Versão 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ê atenderá o driver depois que ele for enviado. Fazer esse trabalho com antecedência significará que você poderá responder mais rapidamente se os problemas de segurança forem identificados no código que foi enviado.
Para obter mais informações sobre o processo de 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 SDL adicionais. https://www.microsoft.com/SDL/Resources/publications.aspx
Chamada para ação
Para desenvolvedores de driver:
- Torne a modelagem de ameaças parte do design do driver.
- Execute as etapas para atenuar com eficiência as ameaças no código do 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 WDK (Kit de Driver de Dispositivo) do Windows.
- Entenda quais verificam o sistema operacional, o gerente de E/S e os drivers de nível superior executados antes que as solicitações do usuário cheguem ao driver e quais verificações não são executadas.
- 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 Lista de verificação de segurança do driver.
Recursos de segurança de software
Manuais
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
Cancelar Lógica no white paper drivers do Windows
Modelo de segurança do Windows: o que todo gravador de driver precisa saber
DDK (Microsoft Windows Driver Development Kit)
Consulte Técnicas de programação de driver na arquitetura do driver no modo Kernel
Ferramentas de teste
Confira Kit de Laboratório de Hardware do Windows em Teste para obter 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.
- CVE (Vulnerabilidades e Exposições Comuns): https://cve.mitre.org/
- Enumeração de Fraqueza Comum: https://cwe.mitre.org/
- Enumeração e classificação de padrões 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
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de