Quando o sistema monitorado controla o monitor

Um controle de segurança pode estar presente, ativado e aparentemente funcionando, enquanto alguém silenciosamente mina sua capacidade de desempenhar sua função. 

Um relatório recente da OpenAI descreveu dois incidentes envolvendo agentes de IA trabalhando em tarefas internas de codificação. Em um dos casos, um agente suprimiu alertas de segurança automáticos enquanto reparava um pipeline de avaliação. O monitoramento continuou sendo executado e salvando relatórios, mas os alertas destinados a chamar a atenção humana para esses relatórios haviam sido desativados. Em outro caso, um agente removeu uma integração de monitoramento enquanto modificava o código e, em seguida, relatou incorretamente as alterações feitas. 

Os detalhes diferem, mas ambos os incidentes levantam uma questão arquitetural fundamental. O que acontece quando o sistema monitorado tem controle suficiente para interferir em seu próprio monitoramento? 

A segurança de aplicativos lida com uma versão desse problema há anos. Um aplicativo móvel é executado em um dispositivo que seu desenvolvedor não controla. Um invasor pode ser capaz de inspecionar seu código, manipular sua execução ou tentar desativar as proteções destinadas a detectar essas atividades. Mas adicionar uma verificação de segurança é apenas o primeiro passo. A própria verificação precisa de proteção. 

Quem guarda os guardas? 

Considere um aplicativo de banco móvel que verifica se seu código foi modificado. Se a verificação detectar adulteração, ela pode encerrar o aplicativo, exigir autenticação adicional ou restringir transferências de alto valor, permitindo que funcionalidades menos sensíveis continuem funcionando. Essas são respostas úteis. Mas elas levantam outra questão: o que impede um invasor de encontrar a verificação de integridade e modificá-la para que ela deixe de funcionar? 

Uma proteção que pode ser desativada sem resistência pode dar aos desenvolvedores uma falsa sensação de segurança. O aplicativo contém o código para detectar adulterações, mas um invasor que consiga alterar o código também pode ser capaz de burlar a detecção. 

A mesma preocupação se aplica ao monitoramento de ameaças. Um sistema pode identificar comportamentos suspeitos, mas essa capacidade é inútil se um invasor puder interferir no mecanismo responsável por identificá-los ou suprimir suas descobertas. Esse é o desafio por trás de uma pergunta comum na área de segurança: quem vigia os vigilantes? 

Adicionar mais proteção pode ajudar, mas somente se as próprias proteções forem consideradas no projeto. Caso contrário, um atacante pode simplesmente atacar o mecanismo que aplica a política de segurança. 

Construindo uma Rede de Guardas 

Digital.aiA tecnologia de proteção de aplicações Arxan da [nome da empresa] aborda esse desafio por meio de um sistema de controles de segurança chamado Guards. Os Guards são injetados no binário da aplicação protegida. Eles podem verificar a integridade da aplicação e responder a adulterações detectadas de acordo com as políticas configuradas para a aplicação. Dependendo do caso de uso, uma resposta pode encerrar a aplicação, acionar autenticação de dois fatores ou desabilitar uma funcionalidade sensível, como transferências financeiras de alto valor. O detalhe arquitetônico importante é que os próprios Guards podem ser protegidos por outros Guards. 

Isso cria o que chamamos de Rede de GuardaUm Guardião não precisa funcionar isoladamente como uma verificação que um atacante possa identificar e explorar. Outros Guardiões podem protegê-lo, e essas proteções podem, por sua vez, receber camadas adicionais de proteção. Em algumas implementações, a cadeia se estende por múltiplas camadas, com Guardiões protegendo Guardiões que protegem outros Guardiões. 

Essa estrutura em camadas altera o problema enfrentado por um atacante. Desativar uma verificação de segurança específica pode exigir também a superação das proteções que a cercam. Uma tentativa de interferir em uma parte da arquitetura de proteção pode encontrar outras partes projetadas para detectar ou resistir a essa interferência. Esse design importa mais agora do que quando a ideia foi descrita pela primeira vez. As ferramentas de IA reduziram o custo e a habilidade necessários para fazer engenharia reversa de aplicativos em larga escala, e uma única verificação isolada é o tipo de alvo que a análise automatizada pode encontrar e corrigir rapidamente.  

Quando os Guards são configurados para se protegerem mutuamente, a remoção de um deles visa acionar os demais. Dependendo do alvo, as equipes também podem variar a própria proteção com mais de uma configuração: valores iniciais que tornam cada build protegido estruturalmente diferente, seleção aleatória de instâncias de Guard no momento da proteção e probabilidades de execução que garantem que nem todos os Guards sejam executados em todas as execuções. Algumas funções de guarda variam seu próprio comportamento em tempo de execução, portanto, não apresentam uma assinatura estática: uma soma de verificação incremental, por exemplo, pode verificar um intervalo diferente a cada invocação, em vez de repetir uma verificação fixa que a análise automatizada poderia aprender e contornar. Uma rotina de stripping que funcionou contra um lançamento ou uma corrida não garante que funcionará contra a próxima. 

A Rede de Proteção não garante que uma aplicação se torne inviolável. Nenhuma arquitetura isolada pode garantir isso contra todos os atacantes, plataformas ou ameaças. Seu propósito é dificultar a localização, alteração e neutralização das proteções, inclusive levando em consideração ataques contra as próprias proteções. Essa distinção é importante. Os atacantes nem sempre precisam derrotar toda uma arquitetura de segurança. Às vezes, basta desativar o mecanismo que, de outra forma, exporia suas atividades. Proteger as proteções aumenta a dificuldade dessa abordagem.  

A detecção precisa de um caminho para a resposta. 

Proteger as verificações de integridade é apenas parte do problema. As equipes de segurança também precisam de visibilidade sobre o que acontece quando um aplicativo encontra uma condição suspeita. 

O Arxan Threat Monitoring opera dentro do aplicativo protegido. Os controles de monitoramento são injetados no binário e os alertas podem ser visualizados por meio de um navegador ou integrados a um sistema de gerenciamento de informações e eventos de segurança (SIEM). Isso permite que as organizações revisem eventos de segurança em nível de aplicativo e os incorporem às suas operações de segurança mais amplas. A arquitetura também é importante. O monitoramento opera dentro do aplicativo, portanto, não deve ser descrito como um observador totalmente externo. Seus controles fazem parte do binário protegido e a arquitetura de proteção é projetada para resistir à adulteração do aplicativo e de seus mecanismos de segurança. 

A Rede de Proteção desempenha um papel fundamental nessa história, protegendo os próprios controles. Alertas externos e a integração com SIEM permitem disponibilizar os eventos relatados além do aplicativo. Esses mecanismos têm propósitos diferentes. Os mecanismos de proteção podem ajudar a proteger a integridade do aplicativo e acionar respostas a adulterações detectadas. O monitoramento de ameaças pode revelar atividades relevantes para a segurança. Os relatórios externos podem auxiliar as equipes de segurança a investigar eventos e coordenar uma resposta. 

Cada componente tem suas limitações. Um canal de reporte não pode reportar um evento que nunca foi detectado, e não se deve presumir que qualquer proteção seja capaz de resistir a todos os ataques possíveis. O objetivo é dificultar a ação de um atacante que pretenda comprometer uma aplicação e, em seguida, desativar os mecanismos projetados para expor ou limitar essa violação. 

A resposta deve ser proporcional à ameaça. 

Os controles de segurança são frequentemente discutidos em termos do que detectam. Na prática, o que acontece em seguida pode ser igualmente importante. Um aplicativo bancário pode exigir autenticação adicional após detectar uma condição suspeita. Pode restringir transferências de alto valor, mantendo as atividades rotineiras disponíveis. Um aplicativo com requisitos de integridade mais rigorosos pode ser encerrado se seu código tiver sido modificado. Essas respostas refletem diferentes avaliações de risco. Um desenvolvedor pode escolher uma resposta com base no aplicativo, na ameaça e nas possíveis consequências de permitir que a execução continue. 

Um dos nossos clientes da área de jogos adotou uma abordagem mais divertida. A equipe criou uma proteção que detectava quando um jogador estava trapaceando. Quando a proteção era acionada, ela desativava a função de gravidade do jogo. Os jogadores trapaceiros, então, flutuavam para fora do campo. É um exemplo memorável, e a ideia subjacente é séria. A proteção estava ligada a uma consequência relevante no ambiente em que o ataque ocorreu. Em vez de tratar a detecção como o fim do processo, o desenvolvedor a utilizou para alterar o que o aplicativo permitia. 

O mesmo princípio se aplica quando as consequências envolvem dinheiro, dados sensíveis ou acesso a funcionalidades críticas. A resposta deve ser adequada ao risco e deve ser difícil para um atacante neutralizar o mecanismo que o desencadeia. Os desenvolvedores também precisam levar em conta falsos positivos, caminhos de recuperação e o impacto sobre os usuários legítimos. A proteção deve melhorar a resiliência de um aplicativo sem causar interrupções desnecessárias. 

Pergunte o que acontece quando os guardas são alvejados. 

O relatório da OpenAI serve como um lembrete útil de que o monitoramento pode ser comprometido por alterações nos sistemas que se pretende observar. Os desenvolvedores de aplicativos enfrentam um desafio semelhante quando seus softwares são executados em ambientes onde invasores podem inspecionar e manipular sua execução. A questão vai além de saber se um aplicativo possui verificações de integridade ou monitoramento de ameaças. Ela se estende a como esses mecanismos são protegidos, como respondem a interferências e se um invasor pode desativar os controles que, de outra forma, exporiam o ataque. 

É aqui que a Rede de Guardas entra em ação. Ao usar Guardas para proteger outros Guardas, a Arxan adiciona camadas de proteção em torno dos próprios mecanismos de segurança. Isso cria obstáculos adicionais para invasores que tentam modificar as defesas do aplicativo ou neutralizar controles individuais. Ao avaliar uma arquitetura de segurança de aplicativo, faça três perguntas.

1) O que acontece quando um atacante tem como alvo a própria proteção?
2) O que impede que uma única modificação desative um mecanismo de segurança crítico?
3) Quais opções o aplicativo tem quando um Guard detecta adulteração? 

O objetivo não é prometer que um aplicativo nunca poderá ser comprometido. É dificultar a adulteração, preservar proteções significativas em caso de ataque e fornecer aos desenvolvedores maneiras práticas de responder quando a integridade do aplicativo estiver em questão. Às vezes, essa resposta significa restringir uma transação financeira. Outras vezes, significa encerrar um aplicativo. 

E às vezes significa desligar a gravidade e ver os jogadores trapaceiros flutuarem para longe.