A Bélgica foi o primeiro país europeu a transpor o NIS2 para o direito nacional, em abril, através do seu “Lei NIS2”. Isso os diferenciou, de forma positiva, de seus vizinhos franceses, holandeses e alemães, todos atrasados no processo de transposição devido à instabilidade política.
Paralelamente, o CCB (Centro de Cibersegurança da Bélgica), a agência local responsável por fazer cumprir a conformidade com o NIS2, divulgou o Safeonweb@trabalho iniciativa. Estabelece uma estrutura detalhada e prática de todas as medidas que são exigidas pela lei, com base no tamanho da organização e no setor de atividade.
Após analisar as recomendações do CCB, este artigo analisa os principais requisitos pertinentes segurança de identidade, que todas as entidades belgas “essenciais” e “importantes” precisarão implementar. Também destacaremos como Silverfort pode ajudar essas organizações a atingir a conformidade com essas medidas.
A abordagem do CCB baseia-se principalmente na Estrutura do NIST CSF, que identifica 5 funções principais para proteger sistemas de informação: identificar, proteger, detectar, responder e recuperar. A lei NIS2 na Bélgica exige um investimento em cada função proporcional ao tamanho e importância de cada entidade. Também encontramos na estrutura Safeonweb@work inúmeras referências aos padrões ISO27001 e ISO27002, que estabelecem medidas eficazes para projetar e fortalecer a segurança de sistemas de informação. Esses padrões alcançaram reconhecimento mundial e constituem uma base robusta sobre a qual qualquer organização pode construir um programa de segurança cibernética.
pós-colheita Requisitos do NIS2
Cada uma das 5 funções na estrutura do NIST tem um componente de identidade. Nas recomendações do CCB, no entanto, os capítulos sobre proteção e detecção são claramente os mais relevantes. O primeiro inclui até mesmo uma seção inteira (PR.AC) dedicada ao gerenciamento de identidade, autenticação, e controles de acesso. Especialistas em identidade encontrarão nele as principais medidas pertinentes à segurança de diretórios e usuários.
Vale destacar o fato de que no nível de garantia “básico” no anexo A do documento Safeonweb@work, que se aplica a todas as entidades sujeitas ao NIS2, independentemente de seu tamanho ou nível de importância, mais da metade das medidas “chave” vêm precisamente da seção PR.AC. Portanto, é difícil enfatizar até que ponto a identidade pesa na estrutura do CCB para proteger sistemas de informação.
Encontramos, portanto, nestas principais medidas necessárias para todas as entidades sujeitas ao NIS2:
- Gestão adequada de usuários e credenciais, abrangendo provisionamento e revogação de direitos de acesso, auditorias regulares, forte autenticação em sistemas críticos e detecção de comportamentos suspeitos (PR.AC-1).
- Protegendo acessos remotos e aplicativos SaaS com MFA (PR.AC-3).
- Implementar Ultimo privilégio nos direitos de acesso, especialmente em relação a sistemas sensíveis ou críticos, e na separação de contas pessoais e administrativas (PR.AC-4).
- Segurança de rede e segmentação de sistemas críticos (PR.AC-5).
Medidas adicionais também são obrigatórias para entidades sob o nível de garantia “Importante” ou “Essencial” (nos anexos B e C), incluindo requisitos em torno de identificação e governança para acessos remotos (PR.AC-3), monitoramento mais rigoroso para conexões e comunicações em torno dos principais limites externos e internos (PR-AC-5), uma avaliação de risco documentada e a implementação de controles de acesso proporcionais ao risco de cada transação (PR.AC-7, apenas no nível de garantia “essencial”).
Concretamente falando, o que essas medidas implicam? A resposta varia dependendo do tamanho e do nível de importância de cada entidade. Mas, no geral, a abordagem do CCB é pragmática, exigindo apenas ferramentas que já são comuns em ambientes de negócios (IAM plataformas, firewalls, MFA). Algum investimento adicional provavelmente será necessário para entidades essenciais que operam sistemas legados, uma vez que estes não são nativamente compatíveis com produtos de segurança modernos. Fora isso, apenas empresas retardatárias do ponto de vista da segurança cibernética realmente precisarão adquirir novas tecnologias.
Além da seção PR.AC, os controles de acesso também aparecem em medidas projetadas para proteger dados em repouso (PR.DS-1), evitar a perda, uso indevido, danos ou roubo de ativos organizacionais (PR.DS-3) e vazamentos de dados (PR.DS-5). Auditorias regulares também são recomendadas – com Active Directory explicitamente mencionado (PR.DS-5) – para detectar configurações incorretas de privilégios que poderiam abrir um caminho de ataque.
Por fim, os requisitos em torno da manutenção da integridade de sistemas críticos (PR.DS-6) e da mitigação dos riscos em torno da manutenção remota (PR.MA-2) provavelmente implicam na gravação de sessões para acessos privilegiados.
Detecção Requisitos do NIS2
A função “Detect” na iniciativa Safeonweb@work também inclui vários artigos relacionados ao campo da identidade. Sem surpresa, eles espelham muito bem as recomendações que apareceram na função “Protect”.
Agregar dados de eventos (DE.AE-1 e 3) aparece antes de tudo como uma medida “chave”, com atenção particular dada a sistemas críticos. Esses dados devem emanar de múltiplas fontes, incluindo acessos físicos e relatórios de usuários/administradores.
As organizações são particularmente chamadas a monitorar sistemas críticos para conexões locais, de rede ou remotas não autorizadas (DE.CM-1), tanto de pessoal interno quanto de provedores de serviços externos (DE.CM-3, DE.CM-6 e DE.CM-7). Esses esforços implicam ferramentas de vigilância no nível de rede e endpoint. Alguns podem até sugerir ir um passo além com plataformas de proteção abrangentes abrangendo pontos de acesso e controladores de domínio, combinando assim EDR com ITDR.
No geral, essas medidas refletem os requisitos apresentados na função “Proteção” contra atividades maliciosas (PR.DM e PR.MA), projetadas para bloquear vazamentos ou danos de dados.
Como pode Silverfort ajuda com a conformidade com o NIS2?
Silverfort pode ajudar a cumprir com muitos desses requisitos. Em apenas 1 mês, e sem grandes mudanças em sua infraestrutura, nossa plataforma pode:
- PR.AC-1 :
- Identifique tudo contas privilegiadas dentro de seus vários diretórios
- Audite todos os seus contas de serviço e contas híbridas
- Identifique administradores sombra
- Identificar contas compartilhadas
- Identificar contas obsoletas
- Identificar contas com senhas antigas
- Proteja os acessos a sistemas críticos, incluindo legados ou locais, com MFA (compatível com Microsoft Authenticator, Okta, Ping, Duo, Yubico e mais) ou com políticas dinâmicas baseadas em risco
- PR.AC-3 :
- Alerte ou bloqueie qualquer tentativa suspeita de acesso remoto
- Proteja acessos remotos (RDP, SSH), interfaces de linha de comando (Powershell, PsExec, WMI) e aplicativos SaaS ou locais com MFA
- PR.AC-4 :
- Identificar e monitorar todas as contas genéricas e compartilhadas
- Identifique e monitore todas as autenticações para compartilhamentos de arquivos, servidores, aplicativos, bancos de dados, etc., mesmo quando no local
- Identificar e monitorar todos contas privilegiadas, incluindo administradores sombra e administradores de domínio
- Detectar e/ou bloquear todas as autenticações que violem os princípios de níveis (como contas pessoais ou dispositivos para tarefas administrativas, ou vice-versa)
- Detectar e/ou bloquear todas as autenticações que violem Ultimo privilégio
- Coloque políticas de acesso condicional adaptáveis para contas e ferramentas administrativas que levem em consideração fatores geográficos, temporais ou comportamentais
- PR.DS-5:
- Estabeleça políticas de acesso granulares para todos os sistemas e aplicativos críticos, mesmo no local
- Monitore e bloqueie todos os acessos maliciosos a sistemas críticos, incluindo no local
- Auditoria Active Directory para detectar roubo de privilégios e configurações incorretas
- PR.DS-7:
- Bloqueie autenticações que violem a integridade dos ambientes de produção ou teste
- Restringir privilégios de contas administrativas a ambientes ou aplicativos específicos
- PR.MA-2 :
- Monitorar e restringir os direitos de acesso de provedores externos a ambientes ou aplicativos específicos
- Proteja os acessos remotos de provedores ou parceiros externos com MFA
- Bloqueie todas as tentativas de sequestro de contas de provedores ou parceiros externos ou quaisquer comportamentos incomuns
- DE.AE-1 :
- Registrar tudo Active Directory autenticações, incluindo suas fontes, destinos, protocolos e carimbo de data/hora
- Calcular uma pontuação de risco dinâmico para todos Active Directory contas e autenticações
- DE.CM-1 :
- Detecte e bloqueie qualquer autenticação não autorizada em Active Directory ou em qualquer outro diretório compatível (PAM, RAIO, Entra ID, Okta, Ping…).
- Detectar e alertar quando humano ou contas de serviço exibir comportamento incomum
- DE.CM-7 :
- Detecte e bloqueie qualquer acesso de pessoal não autorizado a sistemas críticos
- Detecte e bloqueie qualquer acesso não autorizado de software a sistemas críticos
Vale a pena superar as expectativas?
Frequentemente, a iniciativa Safeonweb@work sugere medidas adicionais que contribuiriam para proteger os sistemas de informação (através do uso regular da palavra “Considere”), sem necessariamente torná-las obrigatórias. Também omite algumas medidas de higiene simples e comuns que outras agências, como a ANSSI na França, têm insistido com mais força.
Nesta categoria, podemos mencionar a hierarquização de sistemas ou usuários críticos. O CCB exige o uso de contas separadas para tarefas pessoais e administrativas (PR.AC-4), bem como segmentação de rede (PR.AC-5). Mas não exige estações de trabalho dedicadas (PAW) ou sistemas operacionais para ações administrativas, o que ajudaria a evitar certos tipos de ataques, como Pass-the-Hash.
Outro exemplo: o CCB recomenda usar contas de serviço para processos automatizados (PR.AC-1). No entanto, ele não proíbe administradores de executar tarefas automatizadas usando suas próprias contas, nem proíbe usar contas de serviço para ações que se desviem de sua finalidade pretendida.
Estas podem ser oportunidades perdidas para organizações belgas, particularmente entidades “essenciais” sob NIS2, que futuros atacantes podem explorar com sucesso. O CCB tentou claramente pesar os benefícios de segurança, e o financeiro ou custos operacionais envolvidos em cada decisão que tomou. O resultado continua robusto, e claramente eleva o nível para muitas organizações locais que até então negligenciaram sua postura de segurança. No entanto, não imunizará o país contra os ataques cibernéticos mais sofisticados que se multiplicaram nos últimos anos.
Quer saber mais sobre como Silverfort pode ajudá-lo a abordar os aspectos de segurança de identidade do NIS2? Programar uma chamada com um de nossos especialistas ou preencha este formulário para obter uma cotação de preços.