Segurança com Base em virtualização (VBS)

A segurança baseada em virtualização, ou VBS, usa recursos de virtualização de hardware para criar e isolar uma região segura de memória do sistema operacional normal. Windows pode usar esse "modo de segurança virtual" para hospedar várias soluções de segurança, fornecendo-lhes uma proteção muito maior contra vulnerabilidades no sistema operacional e impedindo o uso de explorações mal-intencionadas que tentam derrotar proteções.

Um desses exemplos de solução de segurança é Hypervisor-Enforced HVCI (Integridade de Código), comumente conhecida como integridade da memória, que usa o VBS para fortalecer significativamente a imposição da política de integridade do código. A integridade do código do modo kernel verifica todos os drivers e binários do modo kernel antes de serem iniciados e impede que drivers não assinados ou arquivos do sistema sejam carregados na memória do sistema.

O VBS usa o hipervisor Windows para criar esse modo de segurança virtual e para impor restrições que protegem recursos vitais do sistema e do sistema operacional ou para proteger ativos de segurança, como credenciais de usuário autenticadas. Com o aumento das proteções oferecidas pelo VBS, mesmo que o malware ganhe acesso ao kernel do sistema operacional, as possíveis explorações podem ser muito limitadas e contidas, pois o hipervisor pode impedir que o malware execute código ou acesse segredos da plataforma.

Da mesma forma, a política de integridade de código configurável do modo de usuário verifica os aplicativos antes de serem carregados e só iniciará executáveis assinados por signatários conhecidos e aprovados. O HVCI aproveita o VBS para executar o serviço de integridade de código dentro de um ambiente seguro, fornecendo proteções mais fortes contra vírus de kernel e malware. O hipervisor, o nível mais privilegiado de software do sistema, define e impõe permissões de página em toda a memória do sistema. As páginas só são executáveis depois que as verificações de integridade de código dentro da região segura são passadas e as páginas executáveis não são graváveis. Dessa forma, mesmo que haja vulnerabilidades como um estouro de buffer que permitem que o malware tente modificar a memória, as páginas de código não podem ser modificadas e a memória modificada não pode ser executada.

O VBS requer que os componentes a seguir estejam presentes e configurados corretamente.

Observe que o TPM não é um requisito obrigatório, mas é altamente recomendável implementar o TPM.

Requisito de hardware Detalhes
CPU de 64 bits A VBS (segurança baseada em virtualização) requer o hipervisor Windows, que só tem suporte em processadores IA de 64 bits com extensões de virtualização, incluindo Intel VT-X e AMD-v.
SLAT (Conversão de Endereços de Segundo Nível) O VBS também exige que o suporte à virtualização do processador inclua SLAT (Tradução de Endereço de Segundo Nível), Intel VT-X2 com Tabelas de Página Estendida (EPT) ou AMD-v com RVI (Índice de Virtualização Rápida).
IOMMUs ou SMMUs (SMMUs Intel VT-D, AMD-Vi, Arm64) Todos os dispositivos de E/S capazes de DMA devem estar por trás de uma IOMMU ou SMMU. Uma IOMMU pode ser usada para aprimorar a resiliência do sistema contra ataques de memória.
Trusted Platform Module (TPM) 2.0 TPMs, discretos ou firmware, serão suficientes. Para obter mais informações, consulte o TPM (Trusted Platform Module) 2.0.
Suporte de firmware para proteção do SMM O firmware do sistema deve seguir as recomendações para proteger o código SMM descrito na especificação WMST (Tabela de Mitigações de Segurança) do Windows SMM. A especificação WSMT contém detalhes de uma tabela ACPI que foi criada para uso com sistemas operacionais Windows que dão suporte a Windows recursos de segurança baseada em virtualização (VBS). O firmware deve implementar as proteções descritas na especificação WSMT e definir os sinalizadores de proteção correspondentes conforme descrito na especificação para relatar a conformidade com esses requisitos para o sistema operacional.
Relatórios de memória UEFI (Unified Extensible Firmware Interface) O firmware UEFI deve aderir às diretrizes de alocação de memória e formato de relatório de mapa de memória a seguir para que o firmware garanta a compatibilidade com o VBS.

  • TABELA de atributos de memória UEFI v2.6 (MAT) – Para garantir a compatibilidade com o VBS, o firmware deve separar de forma limpa os intervalos de memória de runtime do EFI para código e dados e relatar isso ao sistema operacional. A segregação adequada e o relatório de intervalos de memória de runtime do EFI permitem que o VBS aplique as proteções de página necessárias às páginas de código de serviços de runtime do EFI na região segura do VBS. Transmitir essas informações para o sistema operacional é feito usando o EFI_MEMORY_ATTRIBUTES_TABLE. Para implementar o UEFI MAT, siga estas diretrizes:
    1. Todo o runtime do EFI deve ser descrito por esta tabela.
    2. Todos os atributos apropriados para as páginas EfiRuntimeServicesData e EfiRuntimeServicesCode devem ser marcados.
    3. Esses intervalos devem ser alinhados em limites de página (4KB) e não podem se sobrepor.
  • Proteções de página EFI – Todas as entradas devem incluir atributos EFI_MEMORY_RO, EFI_MEMORY_XP ou ambos. Toda a memória UEFI marcada como executável deve ser somente leitura. Memória marcada como gravável não deve ser executável. As entradas podem não ser deixadas com nenhum dos atributos definidos, indicando a memória executável e gravável.
  • Mor (Solicitação de Substituição de Memória Segura) revisão 2 O MOR v2 seguro é aprimorado para proteger a configuração de bloqueio MOR usando uma variável segura UEFI. Isso ajuda a proteger contra ataques avançados de memória. Para obter detalhes, consulte a implementação do SECURE MOR.
    Drivers compatíveis com HVCI (Integridade de Código do Hipervisor) Verifique se todos os drivers do sistema foram testados e verificados como compatíveis com o HVCI. O Windows Driver Kit e o Verificador de Driver contêm testes para compatibilidade de HVCI do driver. Há quatro etapas para verificar a compatibilidade do driver:
    1. Use o Verificador de Driver com as novas verificações de compatibilidade de integridade de código habilitadas.
    2. Execute o Teste de Preparação de Integridade de Código do Hipervisor no Windows HLK.
    3. Teste o driver em um sistema com VBS e HVCI habilitados. Essa etapa é imperativa para validar o comportamento do driver com o HVCI, pois as ferramentas de análise de código estático simplesmente não são capazes de detectar todas as violações de HVCI possíveis no runtime.
    4. Use a ferramenta DGReadiness.

    O VBS funciona em VMs que têm suporte aninhado para virtualização. Isso inclui todas as VMs Gen2 e VMs Gen1 que dão suporte à virtualização aninhada. Uma lista da série de VMs com suporte é detalhada na tabela abaixo.

    Nome da série VM Virtualização aninhada VM Gen
    Av2 Sim 1 (determinados tamanhos internos dão suporte à gen 2)
    B Não 1 e 2
    Dsv2/Dv2/Dv3/Ev3 Sim 1
    Dsv3/Ddsv3 Sim 1 e 2
    Dsv4/Ddsv4 Sim 1 e 2
    Esv3/Edsv3 Sim 1 e 2
    Esv4/Edsv4 Sim 1 e 2
    Ev4/Edv4 Sim Ev4 – 1 somente
    Edv4 -1&2
    Dv4/Ddv4 Sim 1 e 2
    Dv5/Ddv5/Dsv5/Ddsv5 Sim 1 e 2
    Ev5/Edv5/Esv5/Edsv5 Sim 1 e 2
    Dasv5/Dadsv5/Easv5/ Eadsv5 Sim 1 e 2
    Ebsv5/Edbsv5 Sim 1 e 2
    Fsv2 Sim 1 e 2
    Fx Sim 2
    Lsv2 Sim 1 e 2

    Para obter mais informações sobre o Hyper-V, consulte Hyper-V no Windows Server 2016 ou Introdução ao Hyper-V no Windows 10. Para obter mais informações sobre o hipervisor, consulte Especificações do hipervisor.