Estou incomodado esses dias com o tema de Assessment e hoje conversando com um amigo Diretor de Tecnologia de uma grande operação, ouvi uma frase que resume bem o estado atual da nossa comunidade, “Atingimos um score X no framework do CIS”. Sendo assim, será que ele está pronto e totalmente protegido contra os ataques que existem hoje no mercado? O atacante não entra pela porta principal, a análise feita e que resulta em uma nota X, em um determinado framework de mercado, não pode trazer essa certeza. Um atacante pode entrar por um sistema legado que sequer estava no escopo da auditoria.
Este cenário levanta uma provocação fundamental que desejo compartilhar com meus pares e amigos executivos de mercado: um Assessment, hoje, realmente traz tranquilidade? Se formos diretos e honestos com a realidade da operação, a resposta é não.
Claro que essa posição busca fomentar uma discussão necessária para nossa comunidade. frameworks são bússolas excelentes, mas bússolas não evitam naufrágios se o capitão ignorar o resto do oceano.
Para ilustrar esse abismo entre o checklist e a realidade, vamos usar o CIS Controls v8.1.2 como base. Se adentrarmos o domínio de Access Control Management, encontramos oito controles fundamentais. O primeiro ponto parece óbvio e essencial, estabelecer um processo documentado de concessão de acesso. Até aqui, estamos no campo da teoria e das boas intenções que os frameworks de mercado exigem.
O problema ganha corpo no momento da definição de escopo. Na maioria dos casos, o foco recai sobre sistemas críticos, análises de impacto ao negócio (BIA) ou aquilo que a auditoria determinou como prioridade para aquele ciclo. O CIS descreve que devemos seguir um processo preferencialmente automatizado para conceder acessos a ativos da empresa em casos de novas contratações ou mudanças de função, o famoso ciclo de vida do usuário.
Vamos para um teste de mesa, o auditor avalia o escopo definido. Ele percebe que o processo de JML (Joiner, Mover, Leaver) está correto e automatizado para os sistemas “críticos”. O resultado é um selo de compliance garantido e um reporte positivo para o Board. Mas aqui reside a grande falha metodológica, o atacante não respeita o seu escopo de auditoria.
É fisicamente impossível ou estatisticamente improvável que, em uma empresa com dezenas de sistemas e um processo desenhado apenas no papel, tudo esteja sob controle. A implantação de uma ferramenta de IGA e o desenho do JML podem estar perfeitos para o que está automatizado, mas os processos manuais, aqueles que rodam nas “nuances” do dia a dia, continuam sendo o calcanhar de Aquiles da organização.
Vejamos o item oito desse mesmo controle do CIS, que trata da manutenção de uma matriz RBAC (Controle de Acesso Baseado em Funções). Manter um RBAC corporativo funcional para todos os sistemas exige um esforço operacional gigantesco. O que acontece, na prática, é que o Assessment acaba avaliando apenas a matriz daquele pequeno recorte de sistemas selecionados.
Se o controle atende ao escopo, marcamos como “atende”. Mas quão fria e perigosa é essa análise? Em um ambiente onde novos sistemas nascem semanalmente e acessos são concedidos de forma descentralizada, um “sim” no checklist de auditoria pode ser a cortina de fumaça que esconde um risco catastrófico.
A provocação que deixo para reflexão é a seguinte, não deveríamos exigir que o racional de cálculo de risco adicione uma visão de Escopo versus O Todo?
O papel do executivo de segurança não é apenas entregar uma nota alta para o conselho de administração, mas sim ter a clareza absoluta do que ainda precisa ser atacado. O compliance prova que você seguiu a regra, mas a resiliência prova que você conhece seus pontos cegos. Entre um score perfeito e a visibilidade total do risco residual, eu sempre escolherei o segundo e é o que trabalho para entregar aqui. Afinal, a tranquilidade que não sobrevive ao primeiro incidente nunca foi tranquilidade de verdade; era apenas um checklist bem preenchido.
