Disciplina operacional para uma segurança real

Há uma ideia romântica que ainda aparece em demasiadas conversas: as grandes falhas de segurança começam com “hackers geniais”, zero-days e malware feito à medida. A realidade que vejo, ano após ano, é menos cinematográfica e mais desconfortável.

A maioria dos incidentes não começa com tecnologia impossível de travar. Começa com decisões normais. Decisões do dia a dia, feitas com a melhor intenção, para manter a empresa a trabalhar. O problema é que, acumuladas, essas decisões criam dívida. E a dívida, em segurança, cobra juros.

Isto não é um texto para culpar equipas de TI. Pelo contrário: quase sempre o problema é pressão constante, equipas curtas, excesso de ferramentas, exceções que deviam ser temporárias e acabam permanentes. A segurança não falha por falta de inteligência. Falha por falta de disciplina operacional consistente.

Há dias li um post do Spencer (techspence) no X em que me revi totalmente, porque descreve com uma precisão rara estes padrões silenciosos que vão degradando ambientes reais. Recomendo a leitura: https://x.com/techspence/status/2016511700808114234

A partir daqui, sigo com a minha interpretação do referido post, aplicada ao que vejo no terreno.

O que realmente está a acontecer

Quando um ambiente cresce, cresce também a complexidade. Contas, acessos, integrações, fornecedores, projetos urgentes, exceções, atalhos. E, sem darmos por isso, começa a formar-se um padrão: assumimos que o controlo existe, confiamos que está a funcionar e deixamos de verificar com regularidade, porque há sempre outra prioridade.

A diferença entre um ambiente resiliente e um ambiente frágil raramente está numa tecnologia milagrosa. Está na forma como se governa a operação: regras simples, consistentes, verificadas e com dono. Sem isso, a segurança falha muito antes de um atacante aparecer. E quando aparece, limita-se a aproveitar portas que já estavam entreabertas.

Sinais silenciosos de fragilidade

Quando a identidade vira atalho

Se eu tivesse de escolher um único tema para dizer “resolvam isto já”, era identidade. O padrão é conhecido: contas com privilégios a mais para o trabalho do dia a dia, MFA aplicado “quase sempre”, permissões alargadas porque “senão ninguém trabalha”, repositórios onde “toda a gente precisa”.

O cenário clássico é um administrador a fazer tudo com a mesma identidade: e-mail, browser, downloads, scripts, consolas, servidores. Um dia há um clique errado, uma sessão comprometida ou um token reaproveitado, e o atacante não ganha apenas um PC. Ganha uma rampa para escalar.

A minha opinião é simples: separar identidade administrativa e identidade de trabalho diário devia ser tão normal como usar cinto de segurança. E MFA não pode ser uma conversa interminável, tem de ser uma regra aplicada com governança de exceções.

Quando a visibilidade é só um recorte

Alertas não são visibilidade. Alertas são recortes. O que falha, muitas vezes, é o básico: logs incompletos, retenção curta, falta de correlação e processos de resposta que dependem de pessoas específicas.

Quando a investigação começa dias mais tarde, a timeline já não existe ou existe aos bocados. E isso transforma uma resposta rápida numa novela de dias, com dúvidas, suposições e decisões piores.

Em modelos com SOC ou MDR, o risco aumenta quando a fronteira de responsabilidade não está clara. Se o fornecedor deteta mas espera validação, e o cliente assume ação imediata, perde-se tempo no momento errado. Isto não se resolve com mais ferramenta, resolve-se com autoridade, alinhamento e processo.

Quando vulnerabilidades viram ruído

Vulnerability management é essencial, mas pode-se tornar um teatro de números. Relatórios com milhares de findings criam a tentação de gerir por volume, porque baixar o total dá sensação de controlo.

O problema é que o atacante não escolhe pelo vosso dashboard. Escolhe pelo caminho mais fácil até ao impacto maior. Enquanto se fecha volume, ficam por tratar as exposições que realmente abrem portas: perímetro, serviços publicados, exceções antigas em acesso remoto, identidades privilegiadas com controlos inconsistentes.

A minha opinião: a métrica errada destrói prioridades. O objetivo não é ter “poucos CVEs”. É reduzir caminhos de comprometimento nos ativos que interessam.

Quando backups existem mas recuperar é um tema

Quem me conhece sabe: para mim, backups não são negociáveis. Quando tudo o resto falha, é a nossa tábua de salvação. E sim, “temos backups” é daquelas frases que aparece vezes sem conta para tranquilizar a administração. O problema é que backup sem teste é fé — e fé não recupera negócio.

O padrão repete-se: jobs a correr com sucesso, relatórios ok, mas ninguém testa restores. A documentação está desatualizada ou na cabeça de uma só pessoa. No dia do incidente, descobre-se que ativos críticos não estão no backup ou que o procedimento de restore não funciona.

A minha opinião: Recuperar é uma capacidade operacional, não uma feature de produto. Se não é executável e repetível sob pressão, não podemos garantir a continuidade do negócio.

Quando o risco não tem dono

O tipo de falha silenciosa: findings sem proprietário. Recomendações que ficam no limbo. O “vamos tratar” que entra num backlog eterno.

Sem dono e sem prazo, a segurança vira intenção, resolve-se o sintoma, volta a aparecer no próximo assessment e normaliza-se o “é assim mesmo”.

A minha opinião: findings repetidos são, quase sempre, falha de processo, não de pessoas. O processo não dá prioridade, não dá governança. E depois espera-se que nada aconteça..

O meu ponto final é este

Eu não acredito em “segurança perfeita”. Acredito em segurança praticável, aquela que sobrevive ao dia a dia, às urgências e às equipas curtas.

Para isso, há três coisas que, na minha experiência, separam ambientes resilientes de ambientes frágeis.

Primeiro: parar de gerir segurança por suposições. “Temos backups”, “temos logging”, “temos MFA”, “temos SOC”. Tudo isto é ótimo, mas só conta quando é confirmado, testado e repetido. O resto é conforto.

Segundo: parar de aceitar exceções como se fossem inevitáveis. Exceções existem. O problema é quando ficam para sempre e passam a ser tratadas como normal. É assim que a identidade afrouxa, que a partilha fica aberta e que um erro pequeno se transforma num incidente grande.

Terceiro: parar de confundir trabalho com progresso. Fechar milhares de vulnerabilidades dá trabalho, mas não significa, automaticamente, que reduziste risco. Às vezes o risco mais sério está noutro lado: nos acessos, na exposição à internet, na retenção insuficiente e na ausência de plano de recuperação.

Se eu tivesse de resumir isto numa frase: segurança não falha por falta de ferramentas; falha por falta de consistência. E consistência não se compra. Decide-se.