Por que a segurança exige transparência

Todo fornecedor afirma que seu produto é “seguro” até certo ponto, mas a palavra perdeu o significado. Segurança virou um descritor de marketing, e não uma propriedade mensurável. Em sistemas de backup e armazenamento, onde o risco é máximo, a transparência é a única forma de transformar segurança de um slogan em algo que as organizações possam avaliar.  

Administradores precisam entender não apenas o que um fornecedor afirma, mas em quais premissas essas afirmações se apoiam, para o que a arquitetura foi projetada para resistir e como esses objetivos foram validados. 

Para avaliar arquiteturas de Zero Trust e Zero Trust Data Resilience, os fornecedores precisam explicitar o que assumem que acontecerá durante um ataque, o que assumem que não acontecerá e como o sistema se comporta quando essas premissas são colocadas à prova. Sem essa clareza, as organizações ficam tentando interpretar garantias vagas em vez de evidências concretas. 

Quando os fornecedores não são transparentes, os clientes são obrigados a separar a realidade do ruído. A transparência é o que permite entender o que de fato é verdade. 

Zero Trust começa assumindo que uma violação vai acontecer.

Zero Trust muitas vezes é reduzido a um conjunto de recursos de hardening, como MFA, TLS e controle de acesso baseado em funções; porém, o princípio abrangente mais importante é a mentalidade de Assume Breach. Isso significa assumir comprometimento não apenas do ambiente de rede, mas do próprio produto do fornecedor. Se um atacante obtiver acesso administrativo, roubar credenciais ou se passar por um operador, o sistema de armazenamento ainda precisa proteger os dados de backup. Um design Zero Trust não pode ter sucesso quando todas as partes não adotam a mentalidade de “Assume Breach”.  

Se você aceita que não é uma questão de se, mas de quando, então precisa estar preparado para se recuperar de um ataque no pior cenário possível — não apenas do esperado. 

É por isso que decisões arquiteturais importam mais do que checklists de hardening. O princípio do menor privilégio deve ser aplicado para que nenhum indivíduo sozinho consiga destruir os dados de backup de uma empresa. A segmentação de funções garante que o software de backup e o armazenamento de backup não façam parte do mesmo domínio de confiança.  

A segmentação de domínios de autenticação impede que um comprometimento em um plano de identidade se propague para outro. E a segmentação de rede reduz os caminhos que um atacante pode usar para alcançar sistemas críticos. 

Recursos de hardening não respondem à pergunta central: O que acontece quando o atacante já tem as chaves?  

É por isso que Object First é fervoroso defensor de Zero Trust e demonstra isso por meio de testes independentes que comprovam que o sistema se comporta conforme projetado, mesmo quando todos os segredos são conhecidos. 

Por que a transparência historicamente foi desencorajada 

Testes de segurança significativos exigem independência, transparência e repetibilidade. Testes internos do fornecedor por si só são insuficientes, porque não podem ser dissociados de pressões e incentivos internos.  

Testes independentes de terceiros fornecem uma avaliação externa sobre se o sistema se comporta como alegado, especialmente sob condições adversariais. Esses relatórios precisam ser publicados na íntegra, e não com trechos selecionados para criar uma fachada positiva construída de forma incorreta. 

As organizações também devem ter a opção de testar o sistema por conta própria ou contratar um terceiro para fazê-lo. Muitas organizações não terão tempo ou recursos para realizar esse tipo de teste, mas a possibilidade de fazê-lo é essencial. Se o contrato de licença de um fornecedor proíbe testes, essa restrição deve ser tratada como um sinal de alerta. Um sistema que não pode ser testado não pode ser confiável. 

A maioria das organizações não tem tempo nem especialização para validar cada alegação de segurança. Por isso os fornecedores precisam apresentar evidências e conquistar confiança, não presumir que ela existe. 

Object First faz o que prega 

Testes independentes também são a única forma confiável de validar alegações sobre imutabilidade, Zero Access e segmentação. Esses não são recursos que podem ser avaliados apenas por documentação; eles precisam ser demonstrados por meio de testes de intrusão externos que simulem condições encontradas durante um ataque ativo de ransomware. Isso é especialmente importante para a Imutabilidade Absoluta, que pressupõe que o atacante sabe tudo o que o administrador sabe e, ainda assim, não consegue alterar nem excluir dados de backup. 

O armazenamento Backup deve servir como a última linha de defesa quando todos os demais controles falham e como a primeira linha de recuperação quando a organização precisa de seus dados de volta. 

Documentação aberta e definição da superfície de ataque 

Um fornecedor também precisa ser capaz de definir claramente sua superfície de ataque. Sem essa definição, nem testes internos nem externos podem ser significativos. Um sistema de armazenamento de backup bem projetado tem uma superfície de ataque pequena, com escopo rigorosamente delimitado, com limites, protocolos e comportamentos claramente documentados. 

Um fornecedor que não documenta esses componentes está pedindo que as organizações confiem em uma caixa-preta. Sem documentação, as organizações não conseguem entender como o sistema funciona, o que ele expõe ou como deve ser avaliado. Quando fornecedores evitam documentação, eles efetivamente mantêm as organizações “no escuro” sobre como o sistema foi projetado e se comporta. 

Documentação oculta ou incompleta cria um risco simples, porém grave: as organizações não sabem do que estão dependendo. Elas não conseguem testar o que não conseguem ver e não conseguem avaliar o que não conseguem definir. Transparência não exige sobrecarregar equipes de TI e segurança com detalhes desnecessários; exige documentar a superfície de ataque real e manter essa documentação alinhada a padrões de implantação plausíveis e a modelos de ameaça. 

Como compradores devem avaliar alegações de segurança de fornecedores 

Todo fornecedor no fim das contas está pedindo que os clientes confiem nele. A questão é se essa confiança é conquistada. Equipes de TI e segurança devem buscar explicações claras da arquitetura de segurança do fornecedor, incluindo o que o fornecedor assume que vai e que não vai acontecer durante um ataque. Devem esperar uma definição da superfície de ataque, documentação que reflita o uso no mundo real e termos de licença que permitam testes independentes. 

Mais importante, os clientes devem exigir testes independentes de terceiros que validem a imutabilidade do sistema, os controles de Zero Access e a segmentação sob condições adversariais. Também devem procurar o compromisso do fornecedor com o compromisso CISA Seguro by Design, que sinaliza disposição para enfrentar desafios de segurança de forma aberta. 

As alegações de um fornecedor devem ser sustentadas por ações, não por palavras. A transparência é o que transforma essas alegações em algo verificável.