Linhas de base de configuração segura para NIS2 e DORA

A má configuração de sexta-feira à tarde que se tornou um problema para o conselho de administração

Às 16:40 de uma sexta-feira, o responsável de engenharia de uma plataforma fintech aprovou aquilo que parecia ser uma alteração de firewall de rotina. Foi aberta uma regra temporária para resolver problemas numa integração com um fornecedor de análise de pagamentos. O ticket dizia: “remover após os testes”. O teste foi concluído com sucesso. A regra permaneceu.

Três semanas depois, um varrimento externo encontrou uma interface administrativa acessível a partir da Internet. O servidor tinha patches aplicados. Existia MFA para utilizadores normais. O scanner de vulnerabilidades não assinalou nenhum CVE crítico. Mas o sistema continuava inseguro, porque a sua configuração se tinha desviado do estado reforçado aprovado pela organização.

Na segunda-feira de manhã, o Diretor de Segurança da Informação tinha quatro conversas a decorrer em paralelo:

1. O regulador queria saber se a resiliência operacional tinha sido afetada.
2. O Encarregado da Proteção de Dados queria saber se tinham sido expostos dados pessoais.
3. O conselho de administração queria saber por que motivo as alterações “temporárias” não estavam a ser detetadas.
4. O auditor interno da ISO/IEC 27001:2022 queria evidência de que as linhas de base de configuração segura estavam definidas, aprovadas, implementadas e monitorizadas.

É aqui que muitos programas de segurança descobrem uma verdade desconfortável. A configuração segura não é apenas uma checklist técnica de hardening. Em 2026, as linhas de base de configuração segura são uma questão de governação, uma questão de higiene de cibersegurança, uma questão de risco das TIC, uma questão de evidência de auditoria e uma questão de responsabilização do conselho de administração.

Uma segunda versão do mesmo problema ocorre em muitas organizações reguladas. Maria, CISO de um processador de pagamentos B2B em crescimento, tem engenheiros competentes, sistemas com patches aplicados e boas práticas de cloud. Mas uma avaliação de preparação para NIS2 e DORA destaca uma constatação crítica: ausência de linhas de base de configuração segura formalizadas. A sua equipa sabe como reforçar servidores, mas grande parte desse conhecimento está na cabeça dos engenheiros, não em normas aprovadas, verificações automatizadas ou pacotes de evidência.

Essa lacuna deixou de ser defensável. A NIS2 exige que os órgãos de gestão aprovem e supervisionem medidas de gestão de riscos de cibersegurança. A DORA exige um quadro de gestão do risco das TIC documentado e operações de TIC resilientes. O RGPD da UE exige medidas técnicas e organizativas adequadas. A ISO/IEC 27001:2022 exige seleção de controlos baseada no risco, implementação, monitorização, auditoria e melhoria contínua.

As linhas de base de configuração segura ligam todas estas obrigações num sistema de controlo prático: definir a linha de base, atribuir propriedade, aplicá-la durante o provisionamento, gerir exceções, detetar desvios de configuração, demonstrar evidência e melhorar após auditorias ou incidentes.

Como o Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec descreve na fase Controlos em Ação, Passo 19, Controlos Tecnológicos I:

“Muitas violações não resultam de falhas de software; resultam de más decisões de configuração. Palavras-passe predefinidas que não são alteradas, serviços inseguros ativados, portas desnecessárias abertas ou sistemas expostos à Internet sem justificação.”

Esta frase explica por que motivo as linhas de base de configuração segura são agora um controlo essencial de resiliência. Definem o que significa “seguro” antes de um auditor, regulador, cliente ou atacante o perguntar.

O que é realmente uma linha de base de configuração segura

Uma linha de base de configuração segura é o conjunto aprovado, documentado e repetível de definições de segurança para um tipo de sistema. Pode aplicar-se a servidores Windows, hosts Linux, dispositivos de rede, tenants de SaaS, armazenamento na cloud, clusters Kubernetes, bases de dados, firewalls, dispositivos endpoint, plataformas de identidade, dispositivos IoT e tecnologia operacional.

Uma linha de base de configuração robusta responde a perguntas práticas:

• Que serviços estão desativados por predefinição?
• Que portas podem estar expostas externamente?
• Que definições de autenticação e MFA são obrigatórias?
• Que definições de registo de eventos devem estar ativadas?
• Que definições de cifragem são exigidas?
• Que interfaces administrativas estão restringidas?
• Que recursos cloud podem ser públicos e mediante que aprovação?
• Que desvios exigem aceitação do risco?
• Com que frequência verificamos desvios de configuração?
• Que evidência demonstra que a linha de base de configuração está operacional?

A falha mais comum é tratar linhas de base de configuração como preferências de engenharia, em vez de controlos governados. A checklist de um administrador Linux, a página wiki de um arquiteto cloud e a convenção de firewall de um engenheiro de rede podem ser úteis, mas só se tornam auditáveis quando são aprovadas, mapeadas para o risco, aplicadas de forma consistente e monitorizadas.

É por isso que a ISO/IEC 27001:2022 é uma âncora tão útil. As cláusulas 4.1 a 4.3 exigem que as organizações compreendam questões internas e externas, partes interessadas e o âmbito do SGSI, incluindo requisitos legais, regulamentares, contratuais e de terceiros. As cláusulas 6.1.2 e 6.1.3 exigem avaliação de riscos de segurança da informação, tratamento de riscos, seleção de controlos, uma Declaração de Aplicabilidade e aprovação pelo proprietário do risco. As cláusulas 8.2 e 8.3 exigem que as avaliações de risco e o tratamento de riscos sejam repetidos em intervalos planeados ou após alterações significativas.

O Anexo A torna depois a expectativa técnica concreta através do A.8.9 Gestão da configuração, suportado por inventário de ativos, gestão de vulnerabilidades, gestão de alterações, registo de eventos, monitorização, controlo de acesso, criptografia, utilização da cloud e procedimentos operacionais documentados.

O resultado é uma afirmação de governação simples, mas poderosa: se a sua organização não consegue demonstrar o que significa “seguro” para cada tipo principal de sistema, não consegue provar de forma convincente higiene de cibersegurança ao abrigo da NIS2, controlo do risco das TIC ao abrigo da DORA, responsabilização ao abrigo do RGPD da UE ou eficácia dos controlos ao abrigo da ISO/IEC 27001:2022.

Por que razão NIS2, DORA e RGPD da UE tornam as linhas de base de configuração inevitáveis

NIS2, DORA e RGPD da UE usam linguagens diferentes, mas convergem no mesmo requisito operacional: os sistemas devem ser configurados de forma segura, monitorizados continuamente e governados através de uma gestão de riscos responsável.

O Article 20 da NIS2 exige que os órgãos de gestão das entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e recebam formação em cibersegurança. O Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionais. As linhas de base de configuração segura apoiam o Article 21(2)(a) relativo a políticas de análise de riscos e segurança dos sistemas de informação, o Article 21(2)(e) relativo à segurança na aquisição, desenvolvimento e manutenção de sistemas de rede e de informação, incluindo tratamento de vulnerabilidades, o Article 21(2)(f) relativo a políticas e procedimentos para avaliar a eficácia, o Article 21(2)(g) relativo a higiene básica de cibersegurança e formação em cibersegurança, o Article 21(2)(h) relativo a criptografia, o Article 21(2)(i) relativo a controlo de acesso e gestão de ativos, e o Article 21(2)(j) relativo a autenticação multifator e comunicações seguras.

A DORA aplica-se desde 17 de janeiro de 2025 e funciona como o manual setorial de resiliência operacional para as entidades financeiras abrangidas. Os Articles 5 e 6 exigem governação e um quadro de gestão do risco das TIC documentado. O Article 8 exige a identificação de ativos de TIC, ativos de informação, funções de negócio suportadas por TIC e dependências. O Article 9 exige medidas de proteção e prevenção, incluindo políticas, procedimentos, protocolos e ferramentas de segurança para sistemas de TIC, transferência segura de dados, controlo de acesso, autenticação forte, proteção de chaves criptográficas, gestão de alterações, aplicação de patches e atualizações. Os Articles 10 a 14 estendem o modelo à deteção, resposta, recuperação, cópia de segurança, restauro, aprendizagem e comunicação.

O RGPD da UE acrescenta a perspetiva da privacidade. Os Articles 5 e 32 exigem integridade, confidencialidade, segurança do tratamento e responsabilização através de medidas técnicas e organizativas adequadas. Buckets de cloud pública, bases de dados excessivamente expostas, predefinições inseguras e acesso administrativo excessivo não são apenas fragilidades de infraestrutura. Podem tornar-se falhas de proteção de dados pessoais.

Um único programa de linhas de base de configuração segura pode apoiar os três regimes sem criar fluxos de evidência duplicados.

O modelo de linha de base de configuração da Clarysec: política, procedimento e evidência da plataforma

A Clarysec trata a configuração segura como um sistema de controlo repetível, não como um projeto pontual de hardening. A linha de base de configuração deve ser autorizada por uma política, traduzida em procedimentos, implementada através de controlos técnicos e comprovada com evidência.

A Política de Segurança da Informação estabelece esta expectativa ao nível da organização:

“A organização deve manter uma linha de base mínima de controlos derivada do Anexo A da ISO/IEC 27001, complementada, quando adequado, por controlos da ISO/IEC 27002, NIST SP 800-53 e COBIT 2019.”
Da secção “Tratamento do risco e exceções”, cláusula da política 7.2.1.

Esta cláusula impede que o hardening de configuração se transforme numa coleção de preferências pessoais. Ancora a linha de base mínima de controlos em frameworks reconhecidas.

Para ambientes cloud, a Política de Utilização da Cloud especifica o requisito:

“Todos os ambientes cloud devem cumprir uma linha de base de configuração documentada e aprovada pelo Arquiteto de Segurança Cloud.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.3.1.

A Política de Auditoria e Monitorização da Conformidade transforma então a linha de base de configuração num controlo monitorizado:

“Devem ser implementadas ferramentas automatizadas para monitorizar a conformidade da configuração, a gestão de vulnerabilidades, o estado dos patches e o acesso privilegiado.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.4.1.

A configuração também é inseparável da gestão de vulnerabilidades e patches. A Política de Gestão de Vulnerabilidades e Patches estabelece:

“A remediação de vulnerabilidades deve estar alinhada com a linha de base de configuração e as normas de hardening dos sistemas.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.4.1.

Este ponto é importante. Um sistema pode ter patches aplicados e continuar inseguro se o SMBv1 estiver ativado, se interfaces administrativas estiverem expostas, se o registo de eventos estiver desativado ou se definições fracas de autenticação permanecerem em vigor. Em Zenith Controls: o guia de conformidade cruzada, a gestão da configuração é tratada como um controlo preventivo que protege a confidencialidade, integridade e disponibilidade, com capacidade operacional em configuração segura. O Zenith Controls também explica a dependência entre gestão da configuração e gestão de vulnerabilidades:

“A gestão de vulnerabilidades depende de configurações conhecidas. Sem uma linha de base de configuração definida, é impossível garantir que os patches são aplicados de forma consistente.”

Esta é a narrativa de evidência que auditores e reguladores esperam cada vez mais: um sistema de controlo, não tarefas técnicas isoladas.

Mapeamento do A.8.9 da ISO/IEC 27001:2022 para controlos de suporte

O controlo A.8.9 Gestão da configuração do Anexo A da ISO/IEC 27001:2022 é a âncora, mas não deve ser tratado como um pequeno documento autónomo. Depende de uma família de controlos mais ampla.

Esta relação entre controlos explica por que razão a Clarysec recomenda gerir a configuração segura como uma capacidade do SGSI com proprietários, evidência, métricas e reporte à gestão.

Uma matriz de correspondência mais ampla ajuda a traduzir o mesmo programa de linhas de base de configuração para outros referenciais.

Uma estrutura prática de linha de base de configuração que pode implementar este mês

O erro mais comum é tentar escrever uma norma perfeita de hardening com 80 páginas antes de aplicar qualquer coisa. Comece com uma linha de base mínima, mas auditável, para cada grande família tecnológica e depois aumente a maturidade através de automatização e revisão.

Para uma linha de base de configuração de armazenamento na cloud, a primeira versão pode incluir acesso público desativado por predefinição, cifragem em repouso ativada, registo de acessos ativado, acesso administrativo limitado a grupos aprovados, MFA exigida para acesso privilegiado à consola, controlo de versões ativado quando os requisitos de recuperação o exigem, replicação restrita a regiões aprovadas e alterações efetuadas apenas através de pipelines de infraestrutura como código aprovadas.

Para uma linha de base de configuração Windows Server 2022 que suporte processamento de pagamentos, a primeira versão pode incluir SMBv1 desativado, serviços não essenciais desativados, RDP restrito a um servidor bastião reforçado, Windows Defender Firewall ativado com regras de negação por predefinição, contas de administrador local controladas, logs de eventos encaminhados para o SIEM, proteção de endpoint ativada e alterações administrativas ligadas a tickets aprovados.

Para cada linha de base de configuração, construa um pequeno pacote de evidência:

1. O documento de linha de base de configuração aprovado.
2. Uma captura de ecrã ou política exportada que demonstre a configuração aplicada.
3. Uma lista dos ativos abrangidos pela linha de base de configuração.
4. Um ticket de alteração que demonstre como as atualizações são aprovadas.
5. Um relatório de conformidade da configuração ou registo de revisão manual.

Isto alinha diretamente com o Zenith Blueprint, fase Controlos em Ação, Passo 19, onde a Clarysec aconselha as organizações a estabelecerem checklists de configuração para os principais tipos de sistemas, aplicarem definições de forma consistente no provisionamento através de automatização sempre que possível e auditarem rotineiramente os sistemas implementados. O Blueprint também fornece um método prático de auditoria:

“Escolha alguns sistemas representativos (por exemplo, um servidor, um switch, um PC de utilizador final) e valide se a respetiva configuração corresponde à sua linha de base de configuração segura. Documente desvios e remediação.”

Para PME, esta abordagem de amostragem representativa é frequentemente o caminho mais rápido desde o hardening informal até evidência pronta para auditoria.

Exemplos de hardening para PME que reduzem rapidamente o risco

A configuração segura não é apenas uma questão de cloud empresarial. As PME obtêm frequentemente a maior redução de risco com algumas regras claras de linha de base de configuração.

A Política de Segurança de Redes - PME estabelece:

“Apenas portas essenciais (por exemplo, HTTPS, VPN) podem estar expostas à Internet pública; todas as outras devem estar fechadas ou filtradas”
Da secção “Requisitos de implementação da política”, cláusula da política 6.1.3.

Também exige disciplina na gestão de alterações:

“Todas as alterações às configurações de rede (regras de firewall, ACLs de switches, tabelas de encaminhamento) devem seguir um processo de gestão de alterações documentado”
Da secção “Requisitos de implementação da política”, cláusula da política 6.9.1.

E estabelece uma cadência de revisão:

“O Prestador de Suporte de TI deve realizar uma revisão anual das regras de firewall, da arquitetura de rede e das configurações sem fios”
Da secção “Requisitos de governação”, cláusula da política 5.6.1.

As linhas de base de configuração de endpoints exigem a mesma atenção. A Política de Proteção de Endpoints contra Malware - PME da Clarysec estabelece:

“Os dispositivos devem desativar protocolos desatualizados (por exemplo, SMBv1) que possam ser explorados por malware”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.3.

Em ambientes IoT e OT, as predefinições inseguras continuam a ser uma exposição recorrente. A Política de Segurança da Internet das Coisas (IoT) / Tecnologia Operacional (OT) - PME estabelece:

“Palavras-passe predefinidas ou codificadas devem ser alteradas antes da ativação dos dispositivos”
Da secção “Requisitos de governação”, cláusula da política 5.3.2.

Estas cláusulas de política não são afirmações abstratas. São requisitos de linha de base de configuração que podem ser testados, evidenciados e acompanhados. Para uma PME que se prepara para diligência prévia de clientes, avaliações de fornecedores NIS2, seguro cibernético ou certificação ISO/IEC 27001:2022, criam valor imediato.

Tratamento de exceções: o controlo que separa maturidade de mera documentação

Todas as linhas de base de configuração terão exceções. Uma aplicação legada pode exigir um protocolo antigo. Uma appliance de fornecedor pode não suportar a definição de cifragem preferida. Pode ser necessária uma abertura temporária de firewall para uma migração. A questão não é saber se existem exceções. A questão é saber se são governadas.

Um registo de exceção maduro inclui:

• O requisito da linha de base de configuração que está a ser violado.
• A justificação de negócio.
• O ativo afetado e o respetivo proprietário.
• A avaliação de riscos.
• Os controlos compensatórios.
• A autoridade de aprovação.
• A data de expiração.
• O requisito de monitorização.
• O plano de remediação.

É aqui que o tratamento de riscos da ISO/IEC 27001:2022 e a proporcionalidade da DORA funcionam em conjunto. A ISO/IEC 27001:2022 exige que as decisões de controlo sejam justificadas através de avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade e aprovação pelo proprietário do risco. A DORA permite uma implementação proporcional com base na dimensão, no perfil de risco e na natureza, escala e complexidade dos serviços, mas continua a esperar governação do risco das TIC, monitorização, continuidade, testes e sensibilização documentados.

A proporcionalidade não é uma permissão para ignorar linhas de base de configuração. É um requisito para as dimensionar de forma inteligente.

Para uma microentidade ou entidade financeira de menor dimensão ao abrigo de um quadro simplificado de risco das TIC, a linha de base de configuração pode ser concisa e suportada por amostragem manual. Para uma entidade financeira maior, o mesmo domínio provavelmente exigirá verificificações automatizadas de configuração, envolvimento da auditoria interna, testes anuais e reporte ao órgão de gestão.

A Política de Gestão de Alterações também lembra as organizações de que devem estar atentas a:

“Desvios de configuração ou adulteração após alterações aprovadas”
Da secção “Aplicação e cumprimento”, cláusula da política 8.1.2.3.

Esta frase liga o controlo de alterações à deteção de desvios de configuração. Uma alteração pode ser aprovada e ainda assim criar risco se o estado implementado diferir do estado aprovado, ou se uma definição temporária permanecer após o encerramento da janela de alteração.

Construir um único trilho de evidência para muitas obrigações de conformidade

Uma linha de base de configuração segura não deve criar cinco fluxos de trabalho de conformidade separados. O modelo da Clarysec usa um único trilho de evidência mapeado para múltiplas obrigações.

A chave é a rastreabilidade. O Zenith Blueprint, fase Auditoria, Revisão e Melhoria, Passo 24, instrui as organizações a atualizar a Declaração de Aplicabilidade e a verificá-la face ao plano de tratamento de riscos. Se um controlo for aplicável, é necessária uma justificação. Essa justificação deve ligar-se ao risco, obrigação legal, requisito contratual ou necessidade do negócio.

Para a configuração segura, a entrada da SoA relativa ao A.8.9 deve referenciar a norma de linhas de base de configuração segura, as categorias de ativos abrangidas, os proprietários das linhas de base de configuração, o procedimento de gestão de alterações, o método de monitorização, o processo de exceções, a cadência de revisão e as obrigações de conformidade cruzada, como NIS2 Article 21, DORA Articles 6, 8 e 9, RGPD da UE Article 32 e compromissos com clientes.

Como os auditores irão testar linhas de base de configuração segura

A configuração segura é atrativa para os auditores porque é rica em evidência. Pode ser testada através de documentos, entrevistas, amostragem e inspeção técnica.

As perguntas práticas são previsíveis:

• Usa uma checklist de hardening ao instalar novos servidores?
• Como impede que serviços inseguros, como Telnet, sejam executados em routers?
• Os recursos de armazenamento na cloud são privados por predefinição?
• Quem pode aprovar um desvio face à linha de base de configuração?
• Como deteta desvios de configuração após uma alteração?
• Consegue apresentar uma revisão de configuração recente?
• Consegue demonstrar que um desvio detetado foi corrigido?
• As configurações de rede e cloud têm cópias de segurança e controlo de versões?
• Os procedimentos de reversão estão documentados e testados?

As organizações mais robustas mantêm um pacote de evidência de linha de base de configuração para cada categoria principal de sistemas. Isto encurta auditorias, melhora respostas a diligência prévia de clientes e ajuda a gestão a compreender o desempenho real dos controlos.

Transformar desvios de configuração numa métrica de higiene de cibersegurança para o conselho de administração

Os conselhos de administração não precisam de conhecer todas as regras de firewall. Precisam de saber se a higiene de cibersegurança está a melhorar ou a deteriorar-se.

Um painel útil de configuração segura inclui:

• Percentagem de ativos mapeados para uma linha de base de configuração aprovada.
• Percentagem de ativos que passam nas verificações da linha de base de configuração.
• Número de desvios críticos face à linha de base de configuração.
• Idade média dos desvios em aberto.
• Número de exceções expiradas.
• Número de alterações de configuração não autorizadas detetadas.
• Percentagem de alterações de configuração privilegiadas com tickets aprovados.
• Exceções de exposição pública em cloud.
• Estado de revisão da linha de base de configuração por família tecnológica.

Estas métricas suportam a avaliação de desempenho da ISO/IEC 27001:2022, a supervisão pela gestão exigida pela NIS2 e o reporte de risco das TIC no âmbito da DORA. Também se mapeiam naturalmente para resultados de governação do NIST CSF 2.0 e objetivos de monitorização e conformidade do COBIT 2019.

Uma regra executiva simples ajuda: nenhum sistema crítico entra em produção sem evidência da linha de base de configuração. Isto pode ser aplicado através de gestão de alterações, gates de CI/CD, verificações de políticas cloud, revisão de infraestrutura como código, conformidade MDM, aplicação de GPO ou revisão de configuração de rede. O nível de maturidade pode variar, mas a lógica de controlo não deve variar.

O playbook de 90 dias para linhas de base de configuração segura

Se está a começar do zero, não tente resolver todos os problemas de configuração de uma só vez. Use um plano de 90 dias.

Dias 1 a 30: definir a linha de base mínima

Identifique categorias de ativos críticos. Para cada uma, atribua um proprietário técnico, um proprietário do risco e uma autoridade de aprovação. Crie uma primeira linha de base de configuração para as definições mais relevantes para resiliência a ransomware, exposição cloud, acesso privilegiado, registo de eventos, cifragem e proteção de dados.

Crie o registo de linhas de base de configuração e mapeie-o para o âmbito do SGSI, o Registo de Riscos e a Declaração de Aplicabilidade. Se estiver sujeito à NIS2, identifique se é uma entidade essencial ou importante, ou se os clientes esperam higiene de cibersegurança alinhada com a NIS2. Se for uma entidade financeira abrangida pela DORA, identifique que ativos de TIC suportam funções críticas ou importantes. Se tratar dados pessoais, mapeie os sistemas para atividades de tratamento e categorias de dados do RGPD da UE.

Dias 31 a 60: aplicar e recolher evidência

Aplique a linha de base de configuração a uma amostra de sistemas de alto risco. Use automatização sempre que possível, mas não espere por ferramentas perfeitas. Exporte configurações, capture ecrãs, guarde definições de políticas e registe tickets de alteração.

Para cada exceção, crie um registo de risco com uma data de expiração. Para cada desvio, crie um ticket de remediação.

Dias 61 a 90: monitorizar, reportar e melhorar

Execute uma revisão de configuração. Faça amostragem de um servidor, um endpoint, um dispositivo de rede e um ambiente cloud. Compare as definições reais com a linha de base de configuração aprovada. Documente desvios e ações corretivas.

Reporte a conformidade da linha de base de configuração à gestão. Atualize a Declaração de Aplicabilidade e o plano de tratamento de riscos. Integre desvios recorrentes na análise de causa raiz. Se uma má configuração causou ou contribuiu para um incidente, atualize a linha de base de configuração relevante como parte das lições aprendidas.

Isto dá aos auditores algo testável, aos reguladores algo compreensível e à gestão algo governável.

Consideração final: configuração segura é higiene de cibersegurança com evidência

A NIS2 usa a linguagem das medidas de gestão de riscos de cibersegurança e da higiene básica de cibersegurança. A DORA usa a linguagem do risco das TIC, resiliência, monitorização, continuidade e testes. O RGPD da UE usa a linguagem das medidas adequadas e da responsabilização. A ISO/IEC 27001:2022 usa a linguagem do tratamento de riscos, controlos, informação documentada, avaliação de desempenho e melhoria contínua.

As linhas de base de configuração segura ligam todas estas dimensões.

Demonstram que os sistemas não são implementados com predefinições inseguras. Demonstram que as alterações são controladas. Demonstram que os desvios de configuração são detetados. Demonstram que as exceções são aceites com base no risco. Demonstram que existe evidência antes de o auditor a solicitar.

Mais importante ainda, reduzem risco operacional real. A regra de firewall de sexta-feira à tarde, o bucket de cloud público, a definição SMBv1 esquecida, a palavra-passe predefinida de IoT e a consola administrativa sem logs não são constatações de auditoria teóricas. São pontos práticos de falha.

A Clarysec ajuda as organizações a transformar esses pontos de falha em linhas de base de configuração controladas, monitorizadas e auditáveis.

Próximos passos

Se a sua organização precisa de comprovar configuração segura para ISO/IEC 27001:2022, higiene de cibersegurança NIS2, gestão do risco das TIC DORA, responsabilização no âmbito do RGPD da UE ou garantia para clientes, comece pelo toolkit da Clarysec:

• Use o Zenith Blueprint: roteiro de 30 passos para auditores para implementar a gestão da configuração na fase Controlos em Ação, Passo 19, e validá-la através da fase Auditoria, Revisão e Melhoria, Passo 24.
• Use o Zenith Controls: o guia de conformidade cruzada para mapear a gestão da configuração para controlos de suporte da ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE, NIST SP 800-53, COBIT 2019 e metodologias de auditoria.
• Use políticas da Clarysec como a Política de Segurança da Informação, Política de Utilização da Cloud, Política de Auditoria e Monitorização da Conformidade, Política de Gestão de Vulnerabilidades e Patches, Política de Segurança de Redes - PME, Política de Proteção de Endpoints contra Malware - PME e Política de Segurança da Internet das Coisas (IoT) / Tecnologia Operacional (OT) - PME para definir, aplicar e evidenciar os seus requisitos de linha de base de configuração.

Uma linha de base de configuração segura não é apenas uma checklist de hardening. É a prova de que a sua organização sabe como deve ser um estado seguro, aplica-o de forma consistente e consegue demonstrá-lo quando é necessário.