IBGP Responde – Segurança da informação no setor público

Reunimos as 15 dúvidas mais relevantes sobre a construção de programas eficazes de segurança da informação no setor público — de sistema, programa e risco a cultura, métricas e mentalidade do atacante. Um guia direto para quem quer proteção real.

Qual a diferença entre sistema, programa e plano de segurança?

O sistema de gestão de segurança da informação, tal como definido na família de normas ISO 27000, é o todo integrado: um arcabouço teórico que engloba o contexto da organização, a liderança, o planejamento, a operação, a avaliação de desempenho, a melhoria contínua, a gestão de riscos, as métricas e os controles. É a visão do conjunto.

O programa é um pedaço desse sistema, mais técnico e operacional: reúne os grandes processos de segurança (gestão de incidentes, acessos, mudanças, continuidade, backup) e os controles. Enquanto o sistema define teoricamente tudo o que precisa ser feito, o programa é como isso se materializa na organização. O plano, em algumas literaturas, é a subdivisão que detalha os controles dentro do programa.

O que é o CIS e por que ele é tão usado?

O CIS é um framework de controles de segurança conhecido pela praticidade. Ele é construído por especialistas que observam, no mundo todo, as principais áreas de ataque e de vulnerabilidade das organizações e, a partir daí, desdobram um conjunto objetivo de controles e ações — funcionando como um checklist, inclusive com versão em planilha.

Um de seus grandes atrativos é a priorização embutida: como a lista de controles é extensa, ele os organiza em três grupos de implementação, sugerindo que quem está começando implemente o grupo 1, depois o 2 e o 3. Existem alternativas, como o NIST (muito bom, porém mais complexo) e a ISO (menos prática e menos atualizada para esse fim), mas o CIS costuma ser preferido pela objetividade.

Qual a diferença entre segurança teórica e segurança prática?

A segurança teórica é aquela que existe no papel e nas estruturas formais, mas não necessariamente protege. Ter uma política, estar em conformidade, possuir ferramentas ou orçamento são exemplos de elementos importantes que, sozinhos, não impedem um ataque real.

A segurança prática é a proteção que efetivamente funciona no dia a dia. Um programa eficaz é justamente o que traz proteção real, e não apenas documentos e discursos. Muitas organizações se dizem seguras, mas, na análise dos aspectos práticos, revelam pouca segurança de fato implementada.

Ter uma política de segurança protege a organização?

Ter uma política de segurança é importante, mas o documento da política, por si só, é segurança teórica. Nenhuma política protege objetivamente contra um ransomware, e estar em conformidade com ela significa apenas ter montado estruturas — que não impedem, necessariamente, que um invasor entre na rede.

A política ajuda a organizar papéis, responsabilidades e regras, e por isso continua sendo necessária. Mas ela precisa vir acompanhada de controles que funcionem na prática. Confundir ter a política com estar protegido é um dos equívocos mais comuns na segurança da informação.

Comprar boas ferramentas garante proteção?

Não. É essencial ter certas ferramentas, como um firewall, mas comprá-las e colocá-las em produção não garante proteção. Muitas organizações acumulam um portfólio de ferramentas que, na teoria, é ótimo, mas que não se traduz em segurança real — inclusive porque essas ferramentas muitas vezes não conversam entre si.

Em segurança, mais importante do que ter as melhores ferramentas do mercado é ter ferramentas que se integrem, porque segurança hoje é correlação de eventos: as soluções precisam trocar dados entre si, e rápido. Por isso vale preferir poucas soluções bem operadas e pré-integradas a um conjunto de "melhores" ferramentas que não se comunicam.

Qual a diferença entre compromisso e comprometimento da gestão?

Praticamente toda alta administração afirma que a segurança da informação é importante — ninguém diz o contrário. O problema é que compromisso é diferente de comprometimento. Dizer que apoia a segurança não significa, automaticamente, dedicar a ela recursos, prioridade e esforço reais.

A fábula da galinha e do porco ilustra a diferença: no café da manhã, a galinha tem compromisso ao fornecer o ovo, enquanto o porco tem comprometimento ao entregar um pedaço do próprio bacon. Na segurança, é o comprometimento — e não apenas o discurso de apoio — que efetivamente muda a realidade.

Por que segurança não deve ser tratada como projeto?

Porque projeto tem duração predefinida, e segurança é uma capacidade que se constrói e se mantém ao longo do tempo. Há um mito de que, após um incidente, a área de segurança é punida; na verdade, ela passa a ser vista como a mais importante da organização, ganhando status, recursos e um projeto para evitar a repetição do problema.

O ponto é que, passado o susto, o medo diminui, o projeto perde importância e a organização retorna à situação anterior ao incidente — porque não construiu uma capacidade organizacional contínua. Tratar segurança como projeto pontual, e não como capacidade permanente, é uma das causas de programas ineficazes.

Por que a análise de riscos é o pilar mais importante?

Porque é o risco que subsidia a escolha dos controles. Tentar implementar de uma vez a lista inteira de um framework como o CIS leva ao fracasso, pois é impraticável. E seguir apenas a priorização em grupos do próprio framework é pobre, porque reflete a média do mercado, não a realidade da organização.

A gestão de riscos analisa o impacto no negócio e a probabilidade de ataque, que variam de organização para organização conforme os processos de trabalho, as "joias da coroa" e a maturidade já alcançada. Uma análise de risco mínima é melhor do que nenhuma ou do que uma completa que nunca sai do papel — e é ela que revela quais controles realmente importam.

Por que a priorização do CIS não basta?

A priorização em grupos que o CIS oferece é útil para quem não fez uma análise de risco, mas é pobre porque representa a priorização da média do mercado. Cada organização tem processos de trabalho e bens mais preciosos diferentes, e é isso que deve orientar quais controles vêm primeiro.

A prioridade de segurança de um banco central, por exemplo, difere da de um banco comercial, de uma petrolífera, de uma fabricante de aviões ou de um tribunal. Para uma organização específica, os controles mais relevantes podem estar justamente no grupo que, na média, seria implementado por último. Por isso a priorização precisa derivar do negócio e da maturidade de cada uma.

Como escolher os controles de segurança?

O melhor é partir de um framework, que funciona como um checklist para lembrar o que deveria ser feito — sem obrigar a seguir tudo. O passo decisivo é casar a análise de risco com os controles disponíveis e selecionar aqueles que efetivamente mitigam o risco atual da organização.

Também é importante ser realista: em vez de tentar implementar dezenas de controles de uma vez, o que costuma paralisar as equipes, vale escolher poucos — por exemplo, cinco — e focar neles por um período definido, uma espécie de sprint, reavaliando ao final em uma lógica ágil. Isso mantém as equipes em movimento e evita a frustração de ciclos que prometem muito e entregam pouco.

Por que envolver as outras áreas na escolha dos controles?

Porque quem implementa a maioria dos controles não é a área de segurança, e sim outras áreas — redes, sistemas, nuvem, desenvolvimento —, que têm suas próprias prioridades e entregas. Se a área de segurança escolhe os controles sozinha e chega com uma planilha pronta, dificilmente essas equipes vão parar o que estão fazendo para atender.

O compromisso das outras áreas só vem quando elas participam da seleção dos controles. O resultado pode não ser o ideal segundo o plano de riscos, mas pelo menos há a garantia de que os controles serão de fato implementados. A exceção é o período logo após um incidente, quando todos colaboram — mas essa mobilização é temporária.

Por que a cultura de segurança é decisiva?

Porque a responsabilidade pela segurança não pode ficar só com a equipe de segurança ou com a TI. Quem desenvolve sistemas, configura redes e provisiona nuvem é que precisa aplicar muitos dos controles. Quando essas áreas não têm cultura de segurança, entregam de forma insegura, priorizando a velocidade, e depois é preciso detectar e remendar.

A cultura também alcança o usuário final: o servidor que clica em um phishing ao abrir um e-mail o faz por falta dessa cultura. Muda-se esse cenário com treinamento, conscientização e, sobretudo, simulações, que mostram na prática as consequências das falhas. Não à toa, diz-se que a cultura devora qualquer estratégia no café da manhã, inclusive os esforços de segurança.

Por que as métricas de segurança exigem rigor?

Porque, sem métricas, não se sabe a direção nem se o programa vai bem ou mal. Ao definir um controle, é preciso estabelecer aonde se quer chegar e medir o progresso — por exemplo, quantos sistemas estão fora do suporte de correções hoje e qual a meta em seis meses.

E a avaliação precisa ser rigorosa. Em um plano de entregas comum, concluir 80% e adiar 20% costuma ser aceitável; em segurança, 80% entregue significa 20% de exposição, e o atacante precisa de apenas 1%. Se uma meta não foi atingida, o risco resultante deve ser comunicado à alta gestão com clareza, sem ignorar nem maquiar o que ficou pendente.

O que é o ciclo de vida do NIST CSF?

O Cybersecurity Framework do NIST ajuda a enquadrar os controles de segurança dentro de um ciclo de vida, em vez de tratá-los de forma isolada. Ele organiza a segurança como uma sequência de funções — identificar, proteger, detectar, responder e recuperar —, com a governança permeando todas elas.

Toda ação de segurança se encaixa em algum ponto desse ciclo. Olhar as fases, e não apenas os controles, ajuda a decidir onde agir primeiro: se o ambiente não é resiliente e não se consegue recompô-lo após um incidente, é preciso investir em proteger e identificar rapidamente para evitar que o incidente ocorra.

O que é a "mentalidade do atacante" e por que ela importa?

É a capacidade de pensar como quem ataca, conhecendo o mínimo sobre as técnicas de invasão. Sem ela, o profissional tende a se tornar um "burocrata da segurança", que apenas segue checklist: implementa um controle porque o framework manda, sem entender o quanto a organização está realmente exposta.

Essa mentalidade é essencial para validar os controles. É comum um fornecedor entregar um relatório afirmando que todas as regras foram implementadas e, em um teste de penetração, descobrir-se que foi possível invadir sem que nenhum alerta fosse gerado nem o SOC respondesse. Exercitar essa mentalidade, com um Red Team ou treinamento, é o que garante que as proteções realmente funcionam.

Quer construir um programa de segurança da informação que traga proteção real, e não apenas papel? Conheça nossa formação em segurança da informação no setor público e capacite a sua equipe para focar no que protege de verdade.