Cibersegurança não pode continuar sendo exercício de conformidade

Escrevemos na Carta de Fundação que um controle que não muda o comportamento do sistema no dia do incidente é papel. A frase é fácil de aplaudir e difícil de aplicar, porque quase nenhum controle numa empresa real é obviamente falso. Eles existem. Estão contratados, configurados, aparecem no relatório e têm um responsável nomeado. A pergunta não é se estão lá.

A diferença entre um controle que opera e um que apenas existe não é visível em evidência documental. Uma captura de tela de configuração prova existência; não prova que o controle já negou alguma coisa, que a negativa foi notada por alguém e que essa pessoa fez algo a respeito. Este texto é sobre como distinguir os dois — e sobre por que a distinção não é um problema de auditoria, mas de engenharia.

Existência, configuração e operação

Um controle passa por três estados distintos, e quase todo programa mede só o primeiro. Ele existe: foi adquirido e implantado. Ele está configurado: as regras correspondem à intenção de quem as escreveu. E ele opera: interfere no fluxo real, e a interferência chega a alguém com autoridade para agir. Entre o segundo e o terceiro estado mora a maior parte do risco que as empresas acreditam ter tratado — a ferramenta ligada em modo de observação desde a implantação porque bloquear assustava, a regra correta aplicada a um ambiente que deixou de ser o principal, a proteção que dispara para uma caixa de correio compartilhada que ninguém lê desde a última reorganização.

A degradação é estrutural, não negligente. Sistemas mudam continuamente, e controles ficam presos à descrição do sistema que era verdadeira no dia da instalação. Um ambiente novo, um caminho de implantação novo, uma integração nova: cada um é uma mudança legítima, feita por gente competente, e cada um pode passar ao lado de um controle que ninguém lembrou de estender. Ninguém desligou nada. O sistema simplesmente andou, e o controle ficou onde estava.

O registro de exceções é a configuração real

Toda política séria tem exceções, e exceções são legítimas: o negócio às vezes precisa mesmo daquilo, e uma política sem válvula é uma política que será contornada em silêncio. O problema é outro. Exceções nascem com prazo e morrem sem ele. Depois de alguns anos, a política vigente é o documento menos a lista de exceções acumuladas, e essa lista raramente existe consolidada em algum lugar — está espalhada por bilhetes de aprovação, mensagens e memória de quem estava presente.

A política de uma empresa não é o documento. É o documento menos a lista de exceções que ninguém revisa.

Uma exceção sem data de expiração é uma alteração permanente na política, feita por quem a pediu e não por quem responde por ela. A correção é barata em mecanismo e cara em disciplina: exceções expiram por construção, e renovar é uma decisão que alguém precisa tomar de novo, com o nome junto. O efeito colateral é o mais valioso — quando renovar custa uma assinatura, a organização descobre quantas exceções ainda são necessárias, e a resposta costuma ser bem menor do que a lista.

Quatro perguntas que separam papel de controle

Não é preciso um programa para fazer essa distinção. Quatro perguntas bastam, elas se respondem numa tarde por controle e o que custam não é dinheiro:

• —Quando este controle negou alguma coisa pela última vez, e a quem? Um controle que nunca negou nada ou está protegendo algo que ninguém tenta fazer, ou não está no caminho.
• —Existe um caminho legítimo que passa ao lado dele? Um acesso de emergência, uma automação com credencial própria, um ambiente que não foi incluído na implantação.
• —Quem recebe o resultado, e o que essa pessoa tem autoridade para fazer sozinha? Um alerta sem destinatário com autoridade é registro histórico, não controle.
• —Como saberemos que ele ainda está lá no mês que vem? Um controle que depende de ninguém mudar nada é uma fotografia, não um mecanismo.

O que essas quatro perguntas substituem é uma suposição silenciosa: a de que um controle observado uma vez continua operando. Nenhum sistema mantém essa propriedade sozinho, e nenhuma evidência documental a testa. Elas também mudam o tipo de conversa, porque uma delas obriga a olhar o sistema como um adversário olharia — pelo caminho que não foi coberto, e não pela lista do que foi.

O que a conformidade faz bem, e onde ela para

Vale ser justo com o assunto. Um arcabouço de conformidade dá vocabulário comum, estabelece um piso, torna organizações comparáveis e força uma conversa que a empresa adiaria indefinidamente por conta própria. Isso é valor real, e argumentar contra ter um piso é uma posição que não se sustenta. O que precisa ficar claro é onde ele para: um arcabouço pergunta se o controle existe na forma esperada, e não pode perguntar o que o seu sistema específico, com a sua história específica, faz no dia ruim. Além disso, sua cadência é anual enquanto o sistema muda toda semana — e o intervalo entre as duas coisas é exatamente onde os incidentes moram.

Conformidade responde se o controle existe na forma esperada. A engenharia responde o que ele faz no dia em que alguém tenta.

A razão pela qual insistimos nisso é econômica antes de ser moral. Papel é caro: consome o orçamento que teria comprado um controle de verdade e, pior, entrega junto a confiança de quem acredita estar protegido. Uma organização que sabe estar exposta se comporta com prudência — restringe, verifica, ensaia. Uma organização que acredita estar coberta não faz nada disso, e descobre a diferença pelo único canal que resta. Por isso o teste que aplicamos é sempre comportamental e sempre o mesmo: o que muda, no comportamento deste sistema, no dia em que alguém tentar. Se a resposta for nada, o controle é um documento, por melhor que esteja escrito.