O que é um SGSI? Ligar o trabalho de segurança às decisões de negócio

O trabalho de segurança pode parecer intenso sem estar coordenado. A engenharia aplica correções aos sistemas, os recursos humanos tratam das saídas, as compras avaliam fornecedores e a gestão aprova exceções. Um sistema de gestão da segurança da informação (SGSI) liga estas atividades a objetivos comuns e a um processo de decisão explícito.

Para um CEO, a questão importante não é se a empresa tem documentos de segurança suficientes. É se a liderança consegue explicar o que precisa de proteção, que riscos importam, quem é responsável e por que razão o nível de proteção atual é aceitável. Um SGSI torna essas respostas repetíveis à medida que o negócio muda.

O que um SGSI realmente gere

Um sistema de gestão da segurança da informação é o sistema organizacional para gerir os riscos de segurança da informação. Inclui responsabilidades, políticas, processos, recursos, controlos e avaliação. O software pode apoiá-lo, mas o software não é o sistema. Uma biblioteca de documentos pode descrevê-lo, mas os documentos, por si só, não demonstram que funciona.

A sua finalidade é proteger três propriedades da informação:

• Confidencialidade: a informação está disponível apenas para pessoas e sistemas autorizados.
• Integridade: a informação mantém-se exata, completa e protegida contra alterações indevidas.
• Disponibilidade: os utilizadores autorizados conseguem obter a informação e utilizar os serviços de suporte quando necessário.

Estas propriedades traduzem-se em preocupações de negócio. Registos de clientes expostos podem minar a confiança e criar obrigações legais. Instruções de pagamento incorretas podem causar perdas financeiras. Uma plataforma de apoio ao cliente indisponível pode impedir a empresa de cumprir os compromissos assumidos com os clientes.

A ISO/IEC 27001 define requisitos reconhecidos para um SGSI com âmbito delimitado. As cláusulas 4 a 10 abordam o contexto da organização, a liderança, o planeamento, o suporte, a operação, a avaliação do desempenho e a melhoria. Uma organização pode desenvolver e operar um SGSI antes de procurar a certificação.

O sistema de gestão estabelece a ligação entre as salvaguardas individuais e as decisões de negócio. Uma cópia de segurança é um controlo. Decidir o que tem de ser recuperável, financiar a capacidade de recuperação, testá-la e agir perante testes falhados é trabalho do sistema de gestão.

Por que razão a liderança precisa destas ligações

As decisões de segurança já são tomadas em toda a empresa, quer esta lhes chame SGSI quer não. Alguém escolhe um fornecedor SaaS, aprova um acesso privilegiado, aceita uma correção adiada ou assume perante um cliente um requisito de recuperação. Sem um processo comum, essas decisões podem assentar em pressupostos diferentes e deixar o seu efeito conjunto sem responsável.

Um SGSI dá à liderança uma base para priorizar recursos limitados. Ajuda também as equipas a responder às perguntas dos clientes a partir de registos mantidos, em vez de reconstruírem as suas práticas em cada avaliação comercial. Isso não garante o sucesso de um processo de compra; torna as afirmações subjacentes mais fáceis de sustentar.

As ligações devem responder a perguntas práticas:

Estas ligações são especialmente importantes durante o crescimento. Práticas informais que funcionam quando todos se conhecem tornam-se pouco fiáveis quando chegam novas equipas, localizações, fornecedores e compromissos com clientes.

Definir um âmbito que reflita o negócio

Comece pelo contexto do negócio, e não por uma lista de controlos. Identifique os serviços que a organização presta, a informação que utilizam, as partes interessadas e os seus requisitos, e as condições internas e externas que afetam a segurança.

O âmbito define a fronteira do SGSI. Deve identificar as atividades abrangidas, as unidades organizacionais, as localizações quando relevante, a tecnologia e as interfaces com outras partes do negócio. Um primeiro âmbito útil pode abranger um produto destinado a clientes e as respetivas operações de prestação, em vez de todas as atividades da empresa.

No entanto, um âmbito focado não pode ignorar as dependências. Se os recursos humanos iniciam o processo de saída de trabalhadores com acesso ao produto, essa interface é relevante. Se um fornecedor de serviços de computação em nuvem aloja o serviço, a subcontratação não faz desaparecer a dependência. Se o apoio ao cliente exporta informação de clientes, o processo de exportação pertence à análise.

Redija uma declaração de âmbito e ponha-a à prova com três perguntas:

• Um cliente conseguiria perceber o que está e o que não está abrangido?
• Incluímos as dependências necessárias para proteger o serviço abrangido?
• Os responsáveis designados conseguem manter o sistema dentro desta fronteira?

Começar pequeno é uma recomendação prática, e não uma autorização para criar uma fronteira enganadora. Um âmbito claro, com responsáveis identificados, é mais sólido do que um registo extenso que ninguém atualiza. Alargue-o de forma deliberada quando novos serviços ou dependências o justificarem.

Atribuir decisões, e não apenas tarefas

A gestão de topo tem de dar orientação e apoio a um SGSI segundo a ISO 27001. Delegar a coordenação num responsável de segurança não transfere a responsabilidade da liderança pelas prioridades, pelos recursos e pelo risco aceitável.

Separe as responsabilidades que muitas vezes acabam concentradas na função de uma só pessoa:

Uma empresa pequena pode atribuir várias responsabilidades a uma só pessoa. Deve, ainda assim, identificar que papel essa pessoa está a exercer e onde é necessário um escrutínio independente, sobretudo na auditoria interna.

Defina limiares de escalada. Um chefe de equipa pode aprovar uma exceção operacional de curta duração dentro de limites acordados; um risco que ameace compromissos importantes com clientes pode exigir aprovação executiva. Registe a fundamentação, as condições, a data de expiração e o gatilho de revisão. «Aceite pela gestão» não chega se ninguém conseguir identificar quem decidiu nem que exposição foi aceite.

Transformar a avaliação de riscos num processo de priorização

A avaliação de riscos deve descrever cenários plausíveis, e não apenas nomear ativos ou enumerar fragilidades. «Base de dados de clientes» é um ativo. «Uma conta de administrador comprometida permite a extração em massa de registos de clientes» é um cenário de risco com causa e consequência.

Estabeleça um método de avaliação documentado e critérios de aceitação do risco. A ISO 27001 não exige uma fórmula de pontuação específica. Como abordagem prática, defina categorias de probabilidade e de impacto numa linguagem que os seus decisores compreendam, incluindo a perturbação operacional, as perdas financeiras, as consequências contratuais e, quando relevante, os danos para as pessoas.

Para cada cenário material, registe:

• O serviço, a informação e as dependências afetados.
• A ameaça ou o evento e as vulnerabilidades relevantes.
• Os controlos existentes e as suas limitações conhecidas.
• A probabilidade, o impacto e a prioridade resultante.
• O responsável pelo risco e o tratamento proposto.

O tratamento pode passar por reduzir a exposição através de controlos, evitar uma atividade, partilhar aspetos do risco através de contratos ou seguros, ou aceitar o risco dentro de critérios aprovados. Um seguro não recupera informação perdida, e um contrato com um fornecedor não elimina as responsabilidades da organização.

Distinga o risco atual do risco residual após o tratamento. Não baixe uma classificação apenas porque há uma tarefa agendada. Reavalie após a implementação e após evidências adequadas de funcionamento. Obtenha, através da autoridade definida, a aprovação do plano de tratamento e a aceitação do risco residual.

O registo de riscos operacionais deve continuar a ser um registo de decisões: o que mudou, por que razão foi escolhido um tratamento e quando a avaliação tem de ser revista.

Selecionar controlos e explicar a sua aplicabilidade

Os controlos são as medidas utilizadas para modificar o risco. Incluem salvaguardas técnicas, como a autenticação multifator, processos organizacionais, como as avaliações de fornecedores, medidas relacionadas com pessoas, como a formação, e proteções físicas de dispositivos e instalações.

O Anexo A da ISO/IEC 27001:2022 contém 93 controlos de referência: 37 organizacionais, 8 de pessoas, 14 físicos e 34 tecnológicos. A seleção baseia-se no risco; uma organização não implementa automaticamente todos os controlos. A ISO/IEC 27002 fornece orientações de implementação, e não um requisito separado de certificação do SGSI.

Para a ISO 27001, determine os controlos necessários ao tratamento dos riscos e compare-os com o Anexo A para verificar que nenhum controlo necessário foi omitido. Os controlos podem também ser necessários devido a requisitos legais ou contratuais e não têm de se limitar ao Anexo A.

A Declaração de Aplicabilidade regista os controlos necessários, a justificação da sua inclusão, o estado de implementação e a justificação para a exclusão de controlos do Anexo A. É distinta do plano de tratamento de riscos: uma explica o conjunto de controlos aplicável; o outro explica as ações necessárias para tratar os riscos. Consulte o guia dos controlos do Anexo A para conhecer essa estrutura de referência.

Para cada controlo selecionado, defina um responsável, o resultado pretendido, a forma como funciona e que evidências demonstrarão a sua eficácia. «Controlo de acessos implementado» é menos útil do que um processo explícito que abranja a aprovação, a atribuição, a revisão e a remoção.

As políticas devem estabelecer regras que as pessoas consigam seguir. Os procedimentos devem explicar a execução. Nenhuns deles devem prometer revisões ou restrições técnicas que a organização não consegue efetivamente manter.

Integrar as evidências nas operações normais

As evidências devem resultar da realização do trabalho, e não da reconstrução de uma história antes de uma auditoria. Uma revisão de acessos pode produzir uma lista de utilizadores datada, as decisões dos revisores, os tickets de remoção e a confirmação de que as alterações foram feitas. Um exercício de recuperação pode produzir as condições do teste, os resultados, as limitações observadas e as ações de seguimento.

Uma captura de ecrã pode mostrar uma definição num dado momento. Não prova necessariamente que essa definição abrange todos os sistemas relevantes nem que se manteve eficaz ao longo de um período. Os revisores devem analisar o âmbito, a data, a origem, a completude e a conclusão que as evidências efetivamente sustentam.

Um conjunto prático de evidências do SGSI inclui:

Nem todas as linhas precisam de um documento separado. Uma organização pequena pode combinar registos, desde que a clareza e a rastreabilidade se mantenham. Proteja as próprias evidências: exportações de utilizadores, registos de incidentes e capturas de ecrã podem conter informação sensível e devem ter regras de acesso e de conservação adequadas.

Exemplo prático: uma plataforma de apoio ao cliente

Considere, a título ilustrativo, uma empresa de software com 30 pessoas que utiliza uma plataforma SaaS de apoio ao cliente. Suponha que a plataforma contém nomes de clientes, contactos, históricos de tickets e, ocasionalmente, anexos de diagnóstico. O pessoal utiliza contas individuais, um prestador externo aloja a aplicação e alguns tickets são exportados para resolução de problemas. Estes são pressupostos do exemplo, e não um modelo de empresa prescrito.

O âmbito do SGSI abrange as operações de apoio ao cliente e as suas dependências: a identidade do pessoal, o fornecedor SaaS, o acesso a partir dos dispositivos, as exportações, a conservação e as disposições de recuperação. O gestor do apoio ao cliente é o responsável pelo serviço; as TI operam os controlos de acesso; as compras coordenam a avaliação do fornecedor; a liderança aprova os riscos que excedem a autoridade delegada.

A avaliação inicial identifica três cenários:

Suponha que uma reconciliação de contas revela que um antigo trabalhador continua a ter acesso. A ação imediata é removê-lo e avaliar se a conta foi utilizada de forma indevida. A ação do sistema de gestão é determinar por que razão a remoção falhou. Talvez os recursos humanos tenham notificado as TI, mas a aplicação de apoio ao cliente não constava da lista de verificação de saídas.

A ação corretiva atualiza então o inventário de aplicações, acrescenta a plataforma de apoio ao cliente ao processo de saída, atribui a responsabilidade pela confirmação e verifica as saídas seguintes. Fechar apenas o ticket de remoção resolveria a situação imediata sem corrigir a sua causa.

Suponha agora que o fornecedor SaaS altera a sua lista de subcontratantes ulteriores. O responsável pelo fornecedor analisa a alteração face aos requisitos contratuais, de segurança e de privacidade relevantes. Regista se afeta o tratamento de dados, as dependências ou o risco aceite e se é necessária uma análise especializada. A alteração tem um responsável e um circuito de revisão, em vez de ficar por ler numa caixa de correio partilhada.

A liderança recebe as decisões por resolver: financiar uma alternativa mais robusta, reduzir a informação recolhida nos anexos ou aceitar uma exposição remanescente definida. É assim que o SGSI liga as constatações operacionais às escolhas de negócio.

Manter uma cadência capaz de detetar mudanças

Agende as revisões de acordo com o risco, a frequência das alterações e as obrigações. Uma revisão semanal de lacunas durante a implementação inicial e uma revisão periódica pela gestão podem ser opções práticas úteis, mas não são intervalos universais impostos pela ISO 27001. A norma exige auditorias internas e revisões pela gestão a intervalos planeados.

Acrescente gatilhos baseados em eventos: incidentes, versões importantes, aquisições, alterações de fornecedores, novas obrigações legais, compromissos significativos com clientes e constatações de auditoria. Um calendário, por si só, deixará escapar alterações importantes entre reuniões agendadas.

A monitorização pergunta se os controlos e os objetivos estão a funcionar como pretendido. A auditoria interna avalia se o SGSI está conforme com os requisitos e se é eficazmente implementado e mantido. A revisão pela gestão considera a pertinência, a adequação e a eficácia do sistema e toma decisões sobre alterações e recursos. Estas atividades alimentam-se mutuamente, mas não são intermutáveis.

A gestão deve receber informação pronta para decisão: riscos materiais, tratamentos em atraso, falhas repetidas, constatações de auditoria, requisitos em mudança e restrições de recursos. Contar tarefas concluídas sem analisar os resultados pode esconder um desempenho fraco. O guia de métricas do SGSI explora medidas úteis.

A gestão de incidentes também pertence a este ciclo. Defina canais de comunicação, critérios de avaliação, responsabilidades de resposta, autoridade de comunicação e disposições de recuperação. Teste os circuitos de contacto e a tomada de decisões através de exercícios. Avalie as obrigações de notificação aplicáveis, em vez de presumir que um único prazo abrange todos os incidentes.

Após um incidente ou uma não conformidade, resolva o problema imediato, investigue as causas, implemente ações corretivas e avalie a sua eficácia. Constatações repetidas são razão para reconsiderar o desenho do processo ou os recursos, e não apenas para repetir o mesmo lembrete.

Separar o SGSI, a certificação e as obrigações legais

O SGSI é o sistema que a organização opera. A ISO 27001 é uma norma face à qual esse sistema pode ser avaliado. A certificação é emitida por um organismo de certificação independente, e não pela ISO nem pelo Secani, e aplica-se ao âmbito declarado.

A certificação pode ser um mecanismo de garantia útil quando os clientes ou outras partes interessadas a exigem. Não prova que todas as atividades da empresa estão abrangidas, que todos os controlos funcionam sempre ou que não podem ocorrer incidentes. Verifique o âmbito e o estado, em vez de tratar um certificado como uma garantia de segurança para toda a empresa.

A aplicabilidade legal exige uma análise separada. O artigo 32.º do RGPD exige medidas técnicas e organizativas de segurança adequadas, com base nos riscos relevantes. A NIS2 trata da supervisão pela gestão, das medidas de gestão de riscos e da notificação de incidentes para as entidades abrangidas, através da transposição nacional.

Um SGSI pode organizar as evidências e as responsabilidades que sustentam essas obrigações, mas a certificação não demonstra a conformidade com o RGPD ou com a NIS2. Também não é correto afirmar que um SGSI nunca pode ser legalmente exigido: as regras nacionais ou setoriais aplicáveis têm de ser verificadas.

Evitar três falhas de implementação previsíveis

Adotar modelos sem os alterar. Os modelos podem dar uma estrutura, mas os responsáveis têm de validar cada compromisso face à prática real. Uma política que exige revisões que ninguém faz cria uma lacuna não gerida.

Traçar uma fronteira que ninguém consegue manter. Um inventário ambicioso não é útil se as responsabilidades e as dependências não forem claras. Comece com uma fronteira de serviço defensável e alargue-a depois através de um plano explícito.

Tratar a certificação como a meta final. O sistema tem de continuar a funcionar perante mudanças de pessoal, mudanças de fornecedores, incidentes e novos produtos. Orçamente a operação, a revisão e a melhoria, e não apenas a documentação inicial.

Um aviso relacionado diz respeito à automatização sem revisão. Os registos recolhidos automaticamente e os resumos gerados por IA podem apoiar o trabalho, mas continua a ser necessário que as pessoas determinem a relevância, avaliem as lacunas e aprovem as conclusões.

Tornar concreta a primeira decisão da liderança

Escolha um serviço representativo e peça ao seu responsável que traga uma declaração de âmbito, um mapa de dependências, os cenários de risco iniciais, os controlos atuais e as decisões por resolver. Acorde quem pode aceitar riscos, que recursos estão disponíveis e quando será revisto o progresso. Isso cria um ponto de partida gerível, sem fingir que toda a organização já está abrangida.

O modelo de espaços de trabalho do Secani suporta este fluxo de trabalho ao modelar serviços e os objetos-alvo que os suportam, ligar as evidências a requisitos, controlos e decisões e atribuir responsáveis e responsabilidades de revisão. As equipas podem transformar evidências em falta ou responsabilidades pouco claras em tarefas. As sugestões assistidas por IA continuam a ser trabalho em rascunho para revisão humana, com as fontes e as aprovações rastreáveis.

A próxima conversa da liderança deve, por isso, ser concreta: que serviço vamos proteger primeiro, que exposição exige uma decisão agora e que evidências mostrarão que a decisão resultou?