Políticas de segurança perfeitas não existem — não porque sejam difíceis de escrever, mas porque refletem mal a realidade. Há uma grande diferença entre uma política escrita e uma política escrita que dá para aplicar.
A maioria das políticas não foi feita para resistir ao cenário acelerado e em constante mudança em que vivemos. São políticas escritas com boa intenção, mas que desmoronam porque foram pensadas para estados “ideais” e cenários perfeitos.
Por que políticas boas falham na prática
Quando eu era sysadmin e cuidava do gerenciamento de patches, caí exatamente nessa armadilha. Tinha implementado o que parecia uma política bem simples: todos os patches críticos devem ser implantados em até 30 dias após o lançamento. Era uma métrica clara, fácil de medir e, principalmente, atendia aos requisitos regulatórios e de conformidade que precisávamos cumprir.
No papel, era ótimo e exatamente o que boa segurança deveria ser. Será? Na prática, desmoronou quase de imediato.
Como eu também fazia parte do time responsável por acompanhar e instalar os patches em todos os endpoints e servidores, acabei consumindo sem perceber todo o meu tempo livre. Entre identificar o que precisava de patch e quando, testar dentro de TI (éramos sempre as cobaias), agendar janelas de manutenção para o resto da organização e, enfim, implantar os patches, quase 30 dias já tinham passado. Aí o ciclo recomeçava. E não sobrava tempo para nada além de ficar de babá dos patches.
Para piorar, fizemos um teste de invasão, e os achados do pentest eram bem diferentes dos nossos escaneamentos de vulnerabilidades. Os pentesters insistiam para corrigirmos o que encontraram, mas parte disso não estava classificada como “Crítica”. Então esses achados de alto risco só foram remediados bem depois dos críticos.
Não foi uma falha de intenção. Querer patches em dia não era errado. A política falhou porque não considerava o ambiente real, o risco verdadeiro para a organização nem as prioridades concorrentes. É aí que a maioria das políticas de segurança quebra. Elas são feitas para condições perfeitas que não existem em ambientes de TI reais e, muitas vezes, não têm decisões baseadas em risco. No fim, políticas assim não são seguidas: são contornadas ou simplesmente ignoradas.
E não são só as políticas caseiras que caem nessa armadilha. Até padrões de mercado amplamente aceitos podem falhar quando aplicados sem entender as particularidades da sua organização e do seu ambiente.
Quando o “padrão de mercado” deixa de ser útil
Os padrões de mercado existem por bons motivos. Nascem de lições aprendidas com incidentes de segurança e violações de dados e reúnem a experiência coletiva de profissionais de segurança. Eles dão uma base que funciona para a maioria das organizações na maior parte do tempo. O problema é que “a maioria das organizações na maior parte do tempo” ainda deixa muito espaço para falhas.
Um time de TI de uma indústria aprendeu isso do jeito difícil ao decidir reforçar seus servidores Windows com os benchmarks CIS Nível 1. Os CIS Benchmarks são ótimos pontos de partida. São respeitados, atualizados com frequência e recomendados por auditores e profissionais de segurança. Esse não era o problema.
O problema foi achar que dava para aplicá-los de forma uniforme a todos os sistemas do ambiente. Só que os sistemas de controle do chão de fábrica não são sistemas típicos de usuário final. Têm uma finalidade específica e requisitos específicos, diferentes de áreas como contabilidade, por exemplo.
Os benchmarks desativaram vários protocolos e serviços legados dos quais os equipamentos industriais de 15 anos dependiam para se comunicar com o servidor. O resultado: produção parada por boa parte do dia (6 horas) enquanto o time revertia as mudanças às pressas. O impacto financeiro não foi pequeno. Não a ponto de quebrar a empresa, mas gerou bastante preocupação e caos nos times de TI e de produção.
Aplicar os benchmarks CIS não era a abordagem errada. Eles foram feitos para ambientes de TI modernos, com sistemas operacionais atuais e equipamentos atualizados. Mas são um ponto de partida, e nem toda configuração do benchmark é ideal para um ambiente de tecnologia operacional, onde atualizar é muito mais difícil e a indisponibilidade pode causar impacto financeiro sério.
É aqui que seguir “padrões de mercado” às cegas pode prejudicar. Esses benchmarks partem de premissas sobre o seu ambiente, seus recursos e suas operações. Quando essas premissas não batem com a sua realidade — seja porque você roda sistemas legados, atua em um setor especializado ou lida com outras restrições que os benchmarks não preveem — seguir boas práticas cegamente cria mais problemas do que resolve.
Benchmarks são uma ferramenta útil e devem ser usados. Mas, com frequência demais, as políticas exigem o uso desses benchmarks só para marcar uma caixinha de conformidade, sem antes entender os requisitos específicos do ambiente.
Como desenhar políticas que funcionam no mundo real
Depois que minha política original de 30 dias falhou, eu e meu time a redesenhamos em torno de resultados, não de prazos. A nova política era focada em risco. Havia vários adendos, mas este resume bem a ideia:
“Vulnerabilidades críticas que afetem ativos expostos à internet com evidência de exploração ativa devem ser mitigadas em até 72 horas. Vulnerabilidades críticas com código de prova de conceito disponível devem receber patch em até 7 dias. A mitigação pode incluir patch, controles compensatórios ou isolamento temporário do serviço. Todas as ações e exceções devem ser documentadas com aceitação de risco pelo CISO.”
A mudança real não foi só nos prazos. Passamos a priorizar vulnerabilidades e patches pela exposição real: se os sistemas estavam expostos à internet, se havia exploits circulando e quais dados esses sistemas tocavam.
Mas, igualmente importante, entendemos que visibilidade é essencial para TI. Implantamos escaneamento automatizado de vulnerabilidades que alimentava diretamente nosso painel de gerenciamento de patches. Quando um sistema saía da conformidade e ficava sem patches críticos, sabíamos na hora. Passamos a acompanhar métricas ao longo do tempo para ver o quanto estávamos indo bem (ou não) e o que precisava melhorar.
Também reconhecemos que, às vezes, aplicar o patch dentro do prazo não era possível, por vários motivos. Nesses casos, precisávamos de controles compensatórios, de documentação e de aprovação da liderança.
No caso da política dos CIS Benchmarks, a lição foi parecida, mas o time de TI chegou lá por outro caminho. Eles não abandonaram os benchmarks nem os tiraram da política. Em vez disso, atualizaram a política para exigir avaliações de hardening CIS para cada tipo de sistema da organização, criando uma base do que quebraria ou não componentes de produção. O time documentou quais benchmarks se aplicavam a cada tipo de sistema, quais conflitavam com os requisitos daquele tipo e quais controles compensatórios foram usados. Os sistemas de produção ganharam sua própria base de hardening, os sistemas de usuário final ganharam a deles e os servidores também.
Por onde seguir daqui
Como sabemos, quase nada em TI e segurança é ideal. Inovação e avanço tecnológico sempre vão correr na frente da segurança.
Nosso trabalho como profissionais de TI e segurança é tirar o máximo do que temos em mãos, desenhando sistemas, processos e políticas seguros o bastante para que usuários, departamentos e áreas do negócio operem com a maior segurança possível, sem travar demais essas operações.
Temos que aceitar que segurança perfeita não existe e entender que políticas que exigem perfeição vão falhar.
Segurança funciona melhor quando faz parte do dia a dia da TI, e não quando é acoplada depois. Funciona melhor quando é a opção mais eficiente e mais prática. Quando atrapalha o mínimo possível.
Se o seu time precisar escolher entre entregar o trabalho e seguir uma política de segurança, vai escolher entregar o trabalho todas as vezes. Desenhe suas políticas para que essas duas coisas sejam a mesma escolha.
