Períodos de suporte de segurança do Regulamento Ciber-Resiliência da UE com ISO 27001

São 08:20 de uma terça-feira e o responsável pelo produto de um gateway B2B conectado recebe uma mensagem de um cliente regulado: “Confirme, por favor, o período de suporte de segurança da versão 4.6 do firmware, o SLA de resposta a vulnerabilidades e se o dispositivo continuará elegível para atualizações de segurança durante o nosso contrato de serviço de cinco anos.”

Às 09:00, a área de Compras já encaminhou um questionário de diligência prévia DORA. Às 10:15, o departamento jurídico pergunta se o período de suporte anunciado é coerente com os contratos de clientes. Às 11:00, o CISO é chamado para uma revisão de risco de fornecedores NIS2 porque o produto é utilizado por um prestador de serviços geridos na UE. Depois do almoço, a equipa de privacidade pergunta se uma biblioteca de API não suportada no produto pode afetar a segurança dos dados pessoais ao abrigo do GDPR.

A verdade desconfortável surge rapidamente. A empresa tem um roteiro, um processo de patching, um calendário de lançamentos e um portal de suporte ao cliente, mas não tem evidência governada dos períodos de suporte de segurança.

Essa lacuna é relevante. Ao abrigo do Regulamento Ciber-Resiliência da UE, o período de suporte de segurança não é apenas uma etiqueta de produto. É um compromisso de ciclo de vida que afeta o tratamento de vulnerabilidades, a disponibilidade de atualizações, a gestão do risco de dependência de fornecedores, a comunicação com clientes, as declarações contratuais e a monitorização pós-comercialização. Para fornecedores SaaS, fabricantes de dispositivos, editores de software, prestadores de serviços cloud e prestadores de serviços de TIC, o período de suporte torna-se um objeto de conformidade que auditores e compradores regulados irão testar.

A resposta prática não é mais uma folha de cálculo de conformidade isolada. A resposta é governar o período de suporte de segurança dentro de um Sistema de Gestão de Segurança da Informação ISO/IEC 27001:2022 e, em seguida, mapear a mesma evidência para NIS2, DORA, GDPR, NIST CSF 2.0 e expectativas de auditoria de tipo COBIT.

Esse é o modelo operacional da Clarysec: usar o SGSI como motor de evidência, usar políticas exigíveis para definir responsabilidades, usar Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para criar rastreabilidade e usar Zenith Controls: The Cross-Compliance Guide Zenith Controls como bússola de conformidade transversal.

Porque é que o período de suporte de segurança é agora um objeto de auditoria

Um período de suporte de segurança responde a uma pergunta simples: durante quanto tempo o fabricante irá fornecer atualizações de segurança, remediação de vulnerabilidades, orientações de mitigação e suporte ao cliente relacionado para um produto ou uma versão de produto?

Na prática, essa resposta depende de muitas partes móveis:

• Arquitetura do produto e capacidade de manutenção
• Suporte de componentes de terceiros e dependências de código aberto
• Compromissos de fornecedores e serviços cloud
• Processos de receção de vulnerabilidades, triagem, remediação e divulgação
• Engenharia de lançamentos e capacidade de testes
• Termos contratuais com clientes e obrigações regulamentares
• Resposta a incidentes e vias de notificação aos destinatários dos serviços
• Retenção de evidência e registos de aprovação

Se um fabricante promete cinco anos de suporte de segurança, mas uma biblioteca criptográfica crítica passa a estado não suportado após três anos, o período de suporte torna-se uma decisão de risco. Se um cliente for uma entidade financeira sujeita ao DORA, o mesmo período de suporte passa a integrar a garantia sobre terceiros de TIC. Se o produto tratar dados pessoais, software não suportado pode integrar a responsabilização pela segurança do tratamento ao abrigo do GDPR. Se o produto apoiar uma entidade essencial ou importante ao abrigo da NIS2, a segurança do ciclo de vida torna-se uma questão de segurança da cadeia de fornecimento.

A NIS2 torna esta dimensão de governação explícita. O Article 20 exige que os órgãos de administração de entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e recebam formação. O Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição segura, desenvolvimento e manutenção seguros, tratamento e divulgação de vulnerabilidades, avaliação da eficácia, higiene cibernética, criptografia, controlo de acesso, gestão de ativos e autenticação. O Article 23 acrescenta obrigações faseadas de comunicação de incidentes significativos.

O DORA cria uma pressão semelhante para as entidades financeiras. Exige gestão do risco das TIC, testes de resiliência operacional digital, gestão de incidentes e governação do risco de terceiros de TIC. O DORA Article 28 abrange os princípios de gestão do risco de terceiros de TIC, e o Article 30 exige acordos contratuais escritos com descrições claras dos serviços, medidas de segurança, assistência em incidentes, direitos de auditoria, direitos de cessação e planos de saída.

O GDPR acrescenta a camada de privacidade. Se o produto tratar dados pessoais, os responsáveis pelo tratamento e os subcontratantes precisam de medidas técnicas e organizativas adequadas nos termos do Article 32, clareza contratual nos termos do Article 28 e preparação para avaliação e notificação de violação de dados pessoais nos termos dos Articles 33 e 34.

É por isso que o período de suporte de segurança do CRA deve ser governado como uma família de controlos do SGSI, e não tratado como um campo isolado de gestão de produto.

ISO 27001 como espinha dorsal de controlos para períodos de suporte de segurança do CRA

A ISO/IEC 27001:2022 é valiosa porque é escalável, baseada no risco e orientada a sistemas de gestão. Exige que a organização defina o contexto, as partes interessadas, o âmbito e os processos que interagem entre si, e que depois traduza requisitos legais, regulamentares e contratuais em avaliação de riscos, tratamento de riscos, controlos operacionais e evidência ISO/IEC 27001:2022.

Para a governação dos períodos de suporte de segurança, isto significa que a organização deve:

1. Identificar produtos, versões, módulos, serviços cloud e dependências no âmbito.
2. Identificar partes interessadas, incluindo clientes, reguladores, distribuidores, importadores, integradores, subcontratantes, subcontratantes subsequentes, parceiros de resposta a incidentes e fornecedores.
3. Registar obrigações legais, regulamentares e contratuais de suporte.
4. Avaliar riscos que possam impedir o cumprimento dos compromissos de suporte.
5. Selecionar controlos para gestão de vulnerabilidades, desenvolvimento seguro, garantia de fornecedores, gestão de incidentes, continuidade de negócio, privacidade e informação documentada.
6. Criar notas da Declaração de Aplicabilidade que expliquem por que razão os controlos se aplicam.
7. Rever o período de suporte quando a arquitetura, as dependências de fornecedores, a exposição a ameaças ou os compromissos com clientes mudarem.

Zenith Controls identifica três controlos ISO/IEC 27002:2022 relacionados com o tema como referências centrais deste problema de governação: 5.31 Requisitos legais, estatutários, regulamentares e contratuais, 8.8 Gestão de vulnerabilidades técnicas e 8.25 Ciclo de vida de desenvolvimento seguro. Não são os únicos controlos envolvidos, mas constituem a espinha dorsal da governação.

A chave é a rastreabilidade. Um período de suporte de produto deve ser rastreável desde a obrigação até ao cenário de risco, do cenário de risco aos controlos selecionados, dos controlos aos requisitos das políticas e dos requisitos das políticas à evidência.

Zenith Blueprint, fase de Gestão de Riscos, Etapa 13, descreve diretamente esta disciplina de rastreabilidade:

“Referencie regulamentos de forma cruzada: se determinados controlos forem implementados especificamente para cumprir o GDPR, NIS2 ou DORA, pode assinalá-lo no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de Gestão de Riscos, Etapa 13: Planeamento do tratamento de riscos e Declaração de Aplicabilidade Zenith Blueprint

Para um período de suporte de segurança do CRA, a Declaração de Aplicabilidade não deve limitar-se a dizer “a gestão de vulnerabilidades aplica-se”. Deve explicar que a gestão de vulnerabilidades se aplica porque a empresa tem compromissos de ciclo de vida CRA, expectativas NIS2 de desenvolvimento seguro e cadeia de fornecimento, exigências DORA de diligência prévia por parte de clientes, obrigações de segurança GDPR quando são tratados dados pessoais e compromissos contratuais de suporte.

Da promessa de suporte ao ciclo de vida governado

Um período de suporte de segurança definido pelo fabricante deve passar por seis testes de governação.

Primeiro, deve ser definido. A organização precisa de uma taxonomia normalizada, como suporte ativo, suporte apenas de segurança, suporte alargado, suporte limitado e não suportado. Cada estado deve explicar a disponibilidade de atualizações, o tratamento de vulnerabilidades, a comunicação com clientes e as vias de escalamento.

Segundo, deve ser sujeito a avaliação de risco. Cinco anos de suporte para um produto SaaS gerido em ambiente cloud com canais de atualização controlados são diferentes de cinco anos para um dispositivo incorporado com restrições no terreno, dependências de chips de terceiros e janelas de implementação geridas pelo cliente.

Terceiro, deve ser aprovado. Produto, segurança, jurídico, privacidade, suporte ao cliente e a gestão com responsabilidade de prestação de contas devem aprovar o período de referência e as exceções.

Quarto, deve ser comunicado. Os clientes devem compreender a data de início do suporte, a data de fim, o método de atualização, o canal de reporte de vulnerabilidades, as expectativas de remediação, as consequências do fim de suporte e as opções de extensão disponíveis.

Quinto, deve ser monitorizado. As dependências mudam. Os fornecedores descontinuam bibliotecas. Surgem vulnerabilidades. Os ambientes dos clientes evoluem. A governação dos períodos de suporte deve incluir monitorização do ciclo de vida dos componentes, revisão de fornecedores, feeds de vulnerabilidades, registos de patches, testes de lançamento e lições aprendidas com incidentes.

Sexto, deve ser evidenciado. Se um auditor, regulador ou cliente regulado pedir evidência, a organização deve apresentar o Registo de Conformidade, o registo de suporte de produto, a avaliação de riscos, o mapeamento da SoA, o registo de vulnerabilidades, os registos de patches, as revisões de fornecedores, as aprovações de lançamentos e as notificações aos clientes.

As políticas da Clarysec tornam isto prático. A Política de Conformidade Legal e Regulamentar Enterprise Política de Conformidade Legal e Regulamentar exige:

“Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e proprietários específicos no Sistema de Gestão de Segurança da Informação (SGSI).”

Fonte: Política de Conformidade Legal e Regulamentar, Requisitos de implementação da política, cláusula 6.2.1 Política de Conformidade Legal e Regulamentar

Para PME, a disciplina equivalente começa com um registo mais simples. A Política de Conformidade Legal e Regulamentar - PME Política de Conformidade Legal e Regulamentar - PME estabelece:

“O GM deve manter um Registo de Conformidade simples e estruturado que liste:”

Fonte: Política de Conformidade Legal e Regulamentar - PME, Requisitos de governação, cláusula 5.1.1 Política de Conformidade Legal e Regulamentar - PME

Um compromisso de período de suporte deve constar do Registo de Conformidade se for determinado por lei, contrato com cliente, regulação setorial ou expectativa de comprador regulado. Não deve existir apenas em notas de versão ou em texto de marketing.

Criar um registo de períodos de suporte de segurança do CRA num único workshop

Imagine um fornecedor SaaS que vende uma appliance de análise conectada a prestadores logísticos da UE e clientes do setor financeiro. O produto inclui um agente incorporado, uma API cloud, uma aplicação móvel de administração e várias bibliotecas de código aberto. A equipa comercial quer prometer cinco anos de suporte de segurança para cada versão principal da appliance.

O CISO pode conduzir um workshop focado com produto, engenharia, jurídico, privacidade e gestão de fornecedores.

Etapa 1: Criar o registo de períodos de suporte

Crie uma linha por versão de produto e inclua:

• Produto e versão
• Data de lançamento
• Data de início do suporte
• Data-padrão de fim do suporte de segurança
• Opção de suporte alargado
• Método de entrega de atualizações
• Canal de divulgação de vulnerabilidades
• Prazo-alvo para aplicação de patch crítico
• Papel no tratamento de dados, como responsável pelo tratamento, subcontratante ou ambos
• Fornecedores e componentes críticos
• Setores de clientes impactados
• Proprietário do risco
• Data de aprovação
• Localização da evidência

Este registo passa a ser informação documentada no SGSI. Zenith Blueprint, fase de Fundação e Liderança do SGSI, Etapa 6, define a expectativa de controlo documental:

“Os documentos devem ter identificação adequada (um título, eventualmente um número de documento ou identificador único, um autor), formato apropriado e revisão e aprovação quanto à adequação antes da utilização.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de Fundação e Liderança do SGSI, Etapa 6: Informação documentada e construção da biblioteca do SGSI Zenith Blueprint

A Política de Gestão de Informação Documentada e Evidência do PIMS Enterprise da Clarysec Política de Gestão de Informação Documentada e Evidência do PIMS aplica princípios de evidência semelhantes à documentação de privacidade:

“[Todos] O Responsável pela Privacidade / Gestor do PIMS DEVE atribuir um identificador documental, proprietário, número da versão, estado de aprovação, data de entrada em vigor e data de revisão em REG12 antes de publicar informação documentada do PIMS.”

Fonte: Política de Gestão de Informação Documentada e Evidência do PIMS, Criação, aprovação, controlo de versões e publicação, cláusula 4.2.1 Política de Gestão de Informação Documentada e Evidência do PIMS

Mesmo que o registo de períodos de suporte não seja, por defeito, um documento de privacidade, aplica-se a mesma disciplina: proprietário, versão, aprovação, data de entrada em vigor e data de revisão.

Etapa 2: Ligar promessas de suporte ao tratamento de riscos

Para cada versão de produto, crie cenários de risco, tais como:

• É descoberta uma vulnerabilidade crítica numa versão suportada, mas não há capacidade de engenharia disponível.
• Um componente de terceiros fica sem suporte antes do fim do período de suporte de segurança declarado.
• Um fornecedor altera a localização do alojamento ou o subcontratante e afeta a entrega de atualizações.
• Uma vulnerabilidade afeta dados pessoais e aciona uma avaliação de violação de dados pessoais.
• Um cliente financeiro regulado exige evidência de resiliência de terceiros de TIC.

As cláusulas 6.1.1 a 6.1.3 da ISO/IEC 27001:2022 fornecem o motor de planeamento: identificar riscos, avaliar probabilidade e consequências, atribuir proprietários do risco, selecionar tratamentos, comparar os controlos selecionados com o Anexo A, produzir a Declaração de Aplicabilidade e obter aprovação do risco residual.

Para o risco “componente sem suporte antes da data de fim de suporte”, o registo de risco deve incluir os controlos ISO/IEC 27002:2022 5.31, 8.8 e 8.25, além de controlos de fornecedores como 5.19 Segurança da informação nas relações com fornecedores, 5.20 Tratamento da segurança da informação em acordos com fornecedores, 5.21 Gestão da segurança da informação na cadeia de fornecimento de TIC e 5.22 Monitorização, revisão e gestão de alterações dos serviços de fornecedores.

Etapa 3: Definir regras de evidência para vulnerabilidades e patches

Um período de suporte só é credível se a gestão de vulnerabilidades funcionar durante esse período.

A Política de Gestão de Vulnerabilidades e Patches - PME Política de Gestão de Vulnerabilidades e Patches - PME estabelece um requisito exigente para exposição urgente:

“Os patches críticos devem ser aplicados no prazo de 3 dias após o lançamento, especialmente em sistemas expostos à Internet”

Fonte: Política de Gestão de Vulnerabilidades e Patches - PME, Requisitos de implementação da política, cláusula 6.1.1 Política de Gestão de Vulnerabilidades e Patches - PME

Também exige registos prontos para auditoria:

“Deve ser mantido um registo de patches e revisto durante auditorias e atividades de resposta a incidentes”

Fonte: Política de Gestão de Vulnerabilidades e Patches - PME, Requisitos de governação, cláusula 5.4.1 Política de Gestão de Vulnerabilidades e Patches - PME

Para ambientes empresariais, a Política de Gestão de Vulnerabilidades e Patches Enterprise Política de Gestão de Vulnerabilidades e Patches exige:

“Deve ser mantido um Registo de Gestão de Vulnerabilidades centralizado pela Equipa de Operações de Segurança e revisto mensalmente pelo CISO ou autoridade delegada.”

Fonte: Política de Gestão de Vulnerabilidades e Patches, Requisitos de governação, cláusula 5.1 Política de Gestão de Vulnerabilidades e Patches

Zenith Blueprint, fase de Controlos em Ação, Etapa 19, explica a expectativa operacional subjacente ao controlo ISO/IEC 27002:2022 8.8:

“Mantenha-se informado sobre novos bugs de segurança (através de alertas de fornecedores, feeds CVE, etc.) relativos ao seu software e hardware. Avalie quais são relevantes (usamos este software? quão crítico é o bug?) e aplique prontamente correções ou mitigações.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de Controlos em Ação, Etapa 19: Controlos tecnológicos I Zenith Blueprint

Cada versão de produto suportada precisa de um trilho de evidência de vulnerabilidades: receção, análise de relevância, severidade, versões afetadas, plano de remediação, lançamento da correção, orientações de mitigação, comunicação ao cliente e aprovação de encerramento.

Etapa 4: Ligar o desenvolvimento seguro à duração do suporte

O suporte de segurança começa antes do lançamento. Depende de práticas de desenvolvimento que tornem o produto manutenível.

A Política de Desenvolvimento Seguro - PME Política de Desenvolvimento Seguro - PME estabelece:

“Os componentes devem ser atualizados regularmente quando forem lançados patches de segurança. Se for identificada uma vulnerabilidade crítica, o componente deve ser atualizado ou substituído de imediato.”

Fonte: Política de Desenvolvimento Seguro - PME, Requisitos de implementação da política, cláusula 6.6.3 Política de Desenvolvimento Seguro - PME

A Política de Requisitos de Segurança das Aplicações - PME Política de Requisitos de Segurança das Aplicações - PME exige que contratos e requisitos:

“especifiquem obrigações de divulgação de vulnerabilidades, tempos de resposta e aplicação de patches.”

Fonte: Política de Requisitos de Segurança das Aplicações - PME, Requisitos de governação, cláusula 5.3.2 Política de Requisitos de Segurança das Aplicações - PME

Se a empresa prometer suporte até 2031, a arquitetura deve suportar atualizações manuteníveis, substituição de dependências, pipelines de build seguros, testes de regressão e lançamentos de emergência. Os controlos ISO/IEC 27002:2022 para desenvolvimento seguro, arquitetura segura, programação segura, testes de segurança, desenvolvimento externalizado, separação de ambientes e gestão de alterações tornam-se facilitadores do período de suporte.

Um único conjunto de evidência para CRA, NIS2, DORA e GDPR

A mesma evidência do período de suporte pode satisfazer diferentes conversas regulamentares, mas cada referencial coloca a pergunta de forma diferente.

A dependência de fornecedores é frequentemente o ponto em que os compromissos de suporte falham. A Política de Gestão do Risco de Dependência de Fornecedores Enterprise Política de Gestão do Risco de Dependência de Fornecedores exige:

“Registo de Dependências de Fornecedores: o VMO deve manter um registo atualizado de todos os fornecedores críticos, incluindo detalhes como serviços/produtos fornecidos; se o fornecedor é de fonte única; fornecedores alternativos disponíveis ou grau de substituibilidade; termos contratuais atuais; e uma avaliação do impacto caso o fornecedor falhe ou seja comprometido.”

Fonte: Política de Gestão do Risco de Dependência de Fornecedores, Requisitos de implementação, cláusula 6.1 Política de Gestão do Risco de Dependência de Fornecedores

Zenith Blueprint, fase de Controlos em Ação, Etapa 23, alerta que os auditores irão inspecionar acordos com fornecedores e evidência de monitorização de fornecedores:

“Os auditores irão rever amostras de contratos ou acordos de serviço. Procuram cláusulas explícitas de segurança da informação, como prazos de notificação de violação, restrições de acesso, obrigações de tratamento de dados, requisitos de cifragem ou direitos de auditoria.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de Controlos em Ação, Etapa 23: Controlos organizacionais Zenith Blueprint

Para clientes DORA, isto é crítico. Os contratos de serviços de TIC que suportam funções críticas ou importantes precisam de descrições claras dos serviços, condições de subcontratação, medidas de segurança, assistência em incidentes, direitos de auditoria e inspeção, direitos de cessação e disposições de transição. Um fornecedor que não consiga suportar esses compromissos pode impedir o fabricante de assumir uma promessa credível de período de suporte.

Mapeamento de controlos para uma governação do período de suporte pronta para auditoria

Este mapeamento permite que as equipas de segurança, jurídico, produto e vendas falem a mesma linguagem. O registo de períodos de suporte não é apenas evidência CRA. É garantia de fornecedores para NIS2, garantia de terceiros para DORA, suporte à segurança do tratamento para GDPR e um artefacto de governação para certificação ISO 27001.

O ângulo da privacidade: quando não suportado se torna inseguro

A governação dos períodos de suporte de segurança não é apenas uma questão de cibersegurança. Se o produto armazena, transmite ou trata dados pessoais, software não suportado pode tornar-se um risco de privacidade.

O GDPR aplica-se ao tratamento no contexto de um estabelecimento na UE e também pode aplicar-se a organizações fora da UE que ofereçam bens ou serviços a indivíduos na UE ou monitorizem o seu comportamento. Define dados pessoais de forma ampla e trata uma violação de dados pessoais como uma violação de segurança que provoca destruição, perda, alteração, divulgação não autorizada ou acesso acidental ou ilícito a dados pessoais tratados.

Para a governação dos períodos de suporte, as equipas de privacidade precisam de saber quais versões de produto tratam informação pessoal identificável (PII), que sistemas ainda são suportados e se as vulnerabilidades afetam a confidencialidade, integridade ou disponibilidade dos dados pessoais.

A Política de Controlo de Acesso e Segurança de PII Enterprise da Clarysec Política de Controlo de Acesso e Segurança de PII exige:

“[Ambos] O Proprietário do Sistema / Responsável pela Aplicação DEVE registar a cobertura de avaliação de vulnerabilidades para sistemas que tratam PII em REG12 pelo menos trimestralmente e após alteração técnica material.”

Fonte: Política de Controlo de Acesso e Segurança de PII, Configuração segura e gestão de vulnerabilidades, cláusula 4.7.4 Política de Controlo de Acesso e Segurança de PII

A Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros Enterprise Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros acrescenta monitorização contínua para relações de privacidade de alto risco:

“[Todos] O Responsável por Fornecedores / Compras DEVE monitorizar trimestralmente as relações ativas de alto risco com subcontratantes e subcontratantes subsequentes e, anualmente, outras relações ativas com subcontratantes e subcontratantes subsequentes de PII, face às condições de diligência prévia, estado contratual, estado da garantia, questões em aberto e datas de revisão em REG08.”

Fonte: Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros, Monitorização contínua, assistência, interface de divulgação e saída, cláusula 4.5.1 Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros

Quando uma vulnerabilidade se torna um incidente, a Política de Gestão de Incidentes e Violações de PII Enterprise Política de Gestão de Incidentes e Violações de PII exige uma avaliação de desencadeadores multirreferencial:

“[Condicional] O Responsável pela Privacidade / Gestor do PIMS DEVE avaliar os desencadeadores de reporte legais, setoriais, do setor financeiro, de cibersegurança, contratuais, de clientes e de destinatários dos serviços aplicáveis a cada incidente de alto impacto relativo a PII e registar o resultado de aplicabilidade em REG01, REG08 e REG10.”

Fonte: Política de Gestão de Incidentes e Violações de PII, Classificação e avaliação da violação de dados pessoais, cláusula 4.2.6 Política de Gestão de Incidentes e Violações de PII

Esta é a sobreposição prática entre compromissos de suporte CRA, comunicação de incidentes NIS2, tratamento de incidentes graves de TIC DORA e responsabilização por violações de dados pessoais GDPR.

Como os auditores testam o mesmo processo de período de suporte

Um processo robusto de governação dos períodos de suporte deve resistir a vários estilos de auditoria. A evidência não muda muito, mas a perspetiva do auditor muda.

O NIST CSF 2.0 é útil como camada de comunicação porque a sua Função GOVERN inclui obrigações legais, regulamentares, contratuais e de privacidade, objetivos de gestão de riscos, apetite ao risco, funções, políticas e supervisão. Os seus resultados relativos à cadeia de fornecimento abrangem estratégia de fornecedores, criticidade, contratos, diligência prévia, monitorização, coordenação de incidentes e disposições de fim de relação.

Auditores de estilo COBIT e ISACA focam-se frequentemente na conceção da governação: quem é proprietário da decisão, que processo está definido, que métricas demonstram desempenho, como são aprovadas as exceções e como é tratada a melhoria contínua.

A Política de Segurança da Informação Enterprise da Clarysec Política de Segurança da Informação capta o princípio da auditabilidade:

“Todos os controlos implementados devem ser auditáveis, suportados por procedimentos documentados e por evidência retida da operação.”

Fonte: Política de Segurança da Informação, Requisitos de implementação da política, cláusula 6.6.1 Política de Segurança da Informação

Essa é a frase que cada período de suporte de segurança deve conseguir satisfazer.

Prolongar, encurtar ou terminar o suporte sem criar falsa garantia

Os momentos de governação mais difíceis não acontecem no lançamento do produto. Acontecem quando a realidade muda.

Pode ser necessário prolongar o suporte porque clientes regulados dependem do produto, a migração não é viável ou um cliente setorial tem necessidades contratuais de continuidade. Pode ser necessário encurtar ou restringir o suporte porque um fornecedor retira a manutenção de segurança, um componente se torna impossível de corrigir, uma plataforma atinge limites técnicos ou a arquitetura do produto não consegue suportar com segurança uma classe de vulnerabilidades.

Uma alteração controlada do período de suporte deve incluir:

• Desencadeador da alteração, como fim de vida de fornecedor, vulnerabilidade crítica, contrato de cliente ou alteração regulamentar
• Produtos, versões, clientes e setores impactados
• Análise de impacto sobre dados pessoais e serviços críticos
• Revisão de viabilidade de fornecedores e componentes
• Avaliação de riscos e decisão de risco residual
• Registo de períodos de suporte atualizado
• Notificação ao cliente e posição contratual atualizadas
• Notas da SoA atualizadas quando controlos ou obrigações mudarem
• Aprovação pela gestão e data de revisão

A Política de Divulgação Coordenada de Vulnerabilidades Enterprise Política de Divulgação Coordenada de Vulnerabilidades é útil quando a alteração é motivada por vulnerabilidades:

“Deve ser desenvolvido um plano de remediação ou mitigação para todas as vulnerabilidades confirmadas. A implementação da correção deve ser priorizada com base na severidade. Por exemplo, vulnerabilidades críticas devem ser corrigidas ou mitigadas no prazo de 14 dias quando viável, ou mais cedo quando for detetada exploração ativa, enquanto questões de menor severidade devem ser tratadas num prazo razoável.”

Fonte: Política de Divulgação Coordenada de Vulnerabilidades, Requisitos de implementação, cláusula 6.6 Política de Divulgação Coordenada de Vulnerabilidades

Se uma correção completa não puder ser entregue imediatamente, controlos compensatórios, funcionalidade desativada, monitorização reforçada ou orientações de configuração para clientes podem ser aceitáveis temporariamente, mas a decisão deve ser documentada e comunicada.

Checklist prática da Clarysec para preparação dos períodos de suporte

Use esta checklist antes de publicar ou renovar qualquer compromisso de período de suporte de segurança do CRA.

• O produto e a versão estão listados no registo de períodos de suporte?
• A data de fim do suporte foi aprovada por produto, segurança e gestão responsável pela prestação de contas?
• Os fatores legais, regulamentares e contratuais estão mapeados no Registo de Conformidade?
• O cenário de risco do período de suporte está incluído no Registo de Riscos?
• Os controlos estão mapeados na Declaração de Aplicabilidade, incluindo 5.31, 8.8 e 8.25 quando aplicável?
• Os fornecedores e componentes críticos estão mapeados no registo de dependências de fornecedores?
• Existe evidência de que os componentes podem ser corrigidos ou substituídos durante o período de suporte?
• Estão definidas as responsabilidades de receção, triagem, remediação e divulgação de vulnerabilidades?
• Os SLA de patches críticos estão alinhados com a política e os contratos de clientes?
• Os registos de patches, registos de lançamento e decisões sobre vulnerabilidades são retidos?
• Os sistemas com dados pessoais estão cobertos por evidência de avaliação de vulnerabilidades quando tratam PII?
• As notificações aos clientes, declarações de suporte e termos contratuais são coerentes?
• Existe um processo para prolongar, encurtar ou terminar o suporte com aprovação de risco?
• As revisões pela gestão recebem inputs sobre risco dos períodos de suporte, fornecedores, vulnerabilidades e incidentes?
• A evidência pode ser produzida no prazo de 48 horas para uma auditoria de cliente ou pedido de esclarecimento regulamentar?

A Política de Monitorização, Auditoria e Melhoria do PIMS Enterprise Política de Monitorização, Auditoria e Melhoria do PIMS reforça a disciplina de revisão pela gestão para programas de privacidade:

“[Ambos] A Alta Direção DEVE rever inputs de não conformidade do PIMS, ação corretiva, resultado de monitorização, resultado de auditoria, risco de privacidade, garantia de fornecedores e alterações de partes interessadas em REG12 durante cada revisão pela gestão.”

Fonte: Política de Monitorização, Auditoria e Melhoria do PIMS, Revisão pela gestão do PIMS, cláusula 4.3.5 Política de Monitorização, Auditoria e Melhoria do PIMS

Para a governação dos períodos de suporte de segurança, deve aplicar-se o mesmo ritmo de revisão em todo o SGSI: vulnerabilidades, desempenho de patches, garantia de fornecedores, compromissos com clientes, incidentes, exceções de suporte e ações corretivas devem alimentar a revisão pela gestão.

Tornar defensável o período de suporte de segurança

O Regulamento Ciber-Resiliência da UE altera a forma de pensar a segurança de produto. Obriga fabricantes e fornecedores de software a pensar para lá do dia de lançamento. O período de suporte de segurança torna-se uma promessa de ciclo de vida que deve ser concebida, governada, monitorizada e evidenciada.

Para os CISO, a lição é clara: não deixem o período de suporte apenas no marketing de produto. Para gestores de conformidade, não criem um silo separado de evidência CRA. Para auditores, testem se os compromissos de suporte são rastreáveis a riscos, controlos, fornecedores, incidentes e aprovações documentadas. Para responsáveis de negócio, lembrem-se de que um período de suporte credível pode tornar-se uma vantagem de mercado, especialmente na venda a setores regulados pela NIS2, entidades financeiras DORA e clientes sensíveis à privacidade.

A Clarysec ajuda as organizações a operacionalizar isto através de:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para criar rastreabilidade do SGSI, informação documentada, mapeamento da SoA e preparação para auditoria
• Zenith Controls: The Cross-Compliance Guide Zenith Controls para mapear controlos ISO/IEC 27002:2022 para NIS2, DORA, GDPR, NIST CSF 2.0 e expectativas de auditoria
• Pacotes de políticas Enterprise e PME para gestão de vulnerabilidades, desenvolvimento seguro, conformidade legal, dependência de fornecedores, evidência de privacidade e resposta a incidentes
• Registos práticos e fluxos de trabalho de evidência que transformam promessas de períodos de suporte em governação auditável

O seu próximo passo é simples: escolha uma versão de produto emblemática e crie o respetivo dossiê de evidências do período de suporte de segurança. Mapeie a obrigação, aprove o período de suporte, teste o processo de vulnerabilidades, valide as dependências de fornecedores, confirme a comunicação ao cliente e retenha os registos.

Se consegue defender um produto, consegue escalar o modelo. Se não consegue defender um produto, a lacuna não é documentação. É governação.

Descarregue o Zenith Blueprint, use Zenith Controls para mapear a sua evidência ou solicite uma avaliação de prontidão da Clarysec para transformar períodos de suporte de segurança CRA em governação ISO 27001 pronta para auditoria.