- Terence Tao menciona a importância lógica da distinção entre blue team e red team na área de cibersegurança
- A lógica construtiva representa os princípios do blue team, enquanto a lógica coconstrutiva representa os do red team
- Mike Shulman está pesquisando uma nova lógica que combina essas duas bases lógicas
- A interpretação Brouwer–Heyting–Kolmogorov (BHK) é centrada em provas, mas também enfatiza a importância da refutação
- Essa linha de pesquisa pode ser aplicada a várias áreas, incluindo segurança de IA
Discussão sobre a distinção e a combinação de lógicas de LLMs de blue team e red team
- Terence Tao mencionou recentemente que, nas áreas de segurança e algoritmos, os lógicos estão refletindo de forma mais profunda sobre a diferença entre blue team (defesa) e red team (ataque)
- A lógica construtiva se concentra no processo de verificação, isto é, no processo de provar uma afirmação, e define os princípios do blue team
- Em contraste, a lógica coconstrutiva é uma lógica voltada ao processo de refutação, ou seja, à contestação ou ao ataque, vem ganhando atenção recentemente e incorpora os princípios do red team
Pesquisa de Mike Shulman sobre a combinação das lógicas
- Mike Shulman está pesquisando uma forma de lógica que combina esses dois sistemas lógicos
- Segundo um trecho citado em seu artigo, a tradicional interpretação Brouwer–Heyting–Kolmogorov (BHK) tende a se concentrar apenas nos critérios de prova, mas matemáticos que atuam na prática consideram igualmente importantes os critérios de refutação, isto é, de identificar que uma proposição é falsa
- Com isso, ele aponta as limitações de uma forma de pensar centrada apenas em provas nas interpretações lógicas existentes
Necessidade de expandir a interpretação lógica
- Surge a necessidade de explicar, dos dois lados, o que significam prova e refutação para os conectivos lógicos
- A pesquisa em andamento de Mike Shulman explora que tipo de estrutura essa interpretação expandida pode realmente ter
Implicações e possibilidades de aplicação
- Se esse tipo de pesquisa sobre lógica combinada avançar, há grande potencial de uso prático no desenvolvimento de segurança de IA e na evolução de sistemas de verificação e refutação de algoritmos na área de cibersegurança
- Os detalhes do artigo relacionado podem ser consultados no link do arXiv
1 comentários
Opinião no Hacker News
Tenho algumas ideias
(a) a IA é útil tanto para o time "vermelho" quanto para o "azul"
o time azul funciona como uma espécie de brainstorming
(b) o AlphaEvolve é um caso que aplica claramente uma abordagem de 'time vermelho/azul' nesse sentido. Só não usa essa terminologia
Terence Tao também foi consultor desse artigo
(c) isso lembra a divisão de papéis de 'verificador/refutador' na semântica dos jogos
o próprio Tao já comentou publicamente sobre esse tipo de raciocínio, então imagino que ele realmente veja por esse prisma
a expressão "azul/vermelho" provavelmente é uma embalagem voltada para programadores
(d) além disso, não dá para dizer sempre que um sistema de segurança é tão forte quanto seu elo mais fraco
depende se a segurança é em camadas ou em estrutura paralela
se for um corredor com várias portas fortes e fracas em sequência, a força total é determinada pela porta mais forte
e, se você combinar vários classificadores fracos para criar um algoritmo de detecção de fraude, ele pode acabar ficando muito mais poderoso do que o classificador mais fraco
Artigo do AlphaEvolve
Q&A sobre a forma de pensar do Tao
ali o que o LLM faz é só gerar código novo com base em exemplos, e não avaliar o código em si
Senti que o conceito de time vermelho vs. azul é uma boa estrutura para entender até onde LLMs são úteis para especialistas
eu quase sem hesitar deixaria a adição de testes com o LLM
porque testes em geral são baratos, se estiverem errados dá para apagar ou corrigir com facilidade, e se estiverem certos agregam valor
só que, como o LLM frequentemente não testa a funcionalidade central, os testes mais importantes precisam ser escritos por mim para serem confiáveis
por outro lado, corrigir bugs ou adicionar funcionalidades com LLM é mais arriscado
porque o LLM pode apelar para truques ou escrever código que só passa nos testes sem resolver a essência do problema
Trabalhando com uma base de código legada, senti na pele que pensar "se o teste estiver errado, depois a gente corrige" é perigoso
como testes às vezes são uma evidência mais próxima da verdade do que o próprio código, um teste errado pode ser pior do que código errado
especialmente quando se misturam testes inúteis ou de significado ambíguo, aí vira um pesadelo distinguir se aquilo realmente está tentando garantir uma funcionalidade importante
Acho que IA é parecida com uma calculadora
assim como uma calculadora faz bem contas que a maioria das pessoas não consegue fazer, a IA também é uma ferramenta auxiliar que amplia o ser humano com um novo tipo de inteligência
muita gente pensa em "IA substituindo humanos", mas na prática o valor real está em complementar o trabalho humano
Eu penso o contrário
acho que os testes precisam ser escritos por mim e totalmente compreendidos para que eu estabeleça um critério real, e só depois eu possa ficar tranquilo deixando a IA mexer no código à vontade
se os testes também tiverem sido feitos pelo LLM, minha insegurança em confiar o restante do código à IA só aumenta
Já tentei gerar testes com LLM para código Rust, e na prática deu mais prejuízo do que benefício
havia muitos testes, mas era fácil faltar cobertura importante
como o volume de código ficou grande demais, ficou difícil verificar o que não estava sendo coberto
e, quando no futuro a lógica do código mudava, eu precisava ajustar todos aqueles muitos testes gerados
Existe a frase: "ninguém valida testes, então todo mundo assume que eles estão corretos"
foi daí que surgiu o padrão Arrange-Act-Assert
hoje, meus testes unitários preferidos são os que salvam valores de entrada e saídas esperadas, e validam os resultados do código com base nisso
assim fica fácil verificar até casos de borda e confirmar se está realmente funcionando como eu quero
Pelo que entendo, o algoritmo RSA também foi criado assim
segundo "The Code Book", de Simon Singh (tenho em algum lugar, mas não consigo achar), Rivest e Shamir davam as ideias e Adleman fazia o papel de encontrar falhas
Veja a Wikipédia do RSA
é um exemplo de colaboração entre time azul/vermelho também na matemática
um deles tem muitas ideias, fala muito e é desorganizado
o outro é lógico e preciso, então quando um escreve o rascunho do artigo o outro apaga toda a parte inútil
Concordo no geral, mas esse enquadramento pela ótica de infosec me parece um pouco estranho
a visão de que "a segurança é tão forte quanto a parte mais fraca" é simplista demais e perigosa
a estratégia de segurança precisa ser desenhada em várias camadas
como não dá para esperar perfeição em uma única camada, são necessárias várias camadas de defesa
ataque e defesa não são tão diferentes assim, mas muitos atacantes têm pouca responsabilidade mesmo quando erram, enquanto defensores, especialmente em grandes empresas, carregam muita responsabilidade pelos resultados
ainda assim, o defensor tem a vantagem de lutar em casa. Ignorar isso pode trazer problemas sérios
O exemplo de que não adianta trancar a porta se a janela está aberta é uma boa analogia
defesa em várias camadas só faz sentido quando há vários elementos empilhados pelos quais o atacante necessariamente precisa passar para chegar ao objetivo
mas, se forem elementos do mesmo nível, como porta e janela, então a parte mais fraca define o todo
num exemplo web, o login principal pode ser perfeito, mas se um endpoint antigo como
/v1/legacy/external_backofficepermitir acesso à rede interna sem autenticação, toda a defesa desmoronaainda assim, se houver barreiras adicionais internamente, o dano pode ser limitado, então no fim defesa em camadas continua sendo importante
A frase "a defesa é tão forte quanto o elo mais fraco" foi usada num sentido mais abrangente
fui além da formulação do post original e acrescentei a ideia de "esforço defensivo como um todo", mas na prática os dois lados têm razão
como o Terence diz, o elo mais fraco pode de fato ser explorado, e é por isso que várias camadas de defesa são necessárias
houve recentemente um caso real de atendente de helpdesk resetando senha de cliente sem validação
mesmo com VPN, 2FA e outras tecnologias de segurança robustas, um único elo fraco chamado 'recuperação de conta' derrubou tudo
internamente, camadas adicionais detectaram e bloquearam o invasor em 3 horas, mas isso foi 'minimização de dano', não 'prevenção prévia'
no fim, várias camadas são necessárias para impedir que o dano se espalhe
recentemente, aliás, o próprio setor de infosec vem mudando o foco de "prevenção 100%" para "mitigação de danos"
como é difícil prevenir todos os riscos, a estratégia vem mudando para reduzir o risco, minimizar a superfície e diminuir o nível de confiança
Não sou especialista em segurança de forma alguma, mas já ouvi que "uma superfície de ataque extremamente reduzida, com uso de protocolos open source verificados" é a melhor defesa
queria entender em que isso difere do que está sendo discutido aqui
O problema é simplesmente uma analogia mal escolhida
a expressão "elo mais fraco" faz sentido quando é preciso atravessar várias etapas em sequência
se houver várias opções no mesmo nível, faz sentido mirar na mais fraca entre elas
então, como você disse, realmente há margem para interpretação ambígua
Também considero o ataque como outra camada de defesa
como no ditado: 'o melhor ataque é a melhor defesa'
Em cibersegurança, time vermelho e time azul são dois times com forças equivalentes
mas em desenvolvimento de software essa analogia me parece um pouco exagerada
teste também é código, e bugs continuam existindo
isso cria um paradoxo do tipo "Who polices the police?"
Uma frase em inglês repetitiva e cheia de sentido, como a de Buffalo
Isso me lembrou a ideia do John Cleese sobre a mente em "modo aberto vs. modo fechado"
as ideias são geradas com a máxima abertura possível
depois, no modo fechado, as ideias ruins são filtradas e as boas são refinadas
escritores de todas as áreas normalmente também têm editores
no design do jogo de cartas Magic: the Gathering acontece algo parecido: o time de design cria o rascunho de uma coleção e depois o entrega para um time de desenvolvimento totalmente separado fazer a validação
eu gostaria de ouvir mais exemplos de colaborações assim
Na prática, acho que é o oposto do que este texto diz
LLMs são excelentes para criar rascunhos rapidamente, e humanos bem treinados são mais adequados para revisar criticamente o resultado do LLM
então o LLM combina mais com o time azul, e o humano com o time vermelho
acho que o Tao está falando desse cenário mais extremo
Recentemente usei modelos e workflows baseados em agentes, e essa foi a impressão que tive
esses agentes brilham mais quando são usados não só para escrever código, mas também para testes, coordenação e até funções de management
o desenvolvedor passa a virar uma espécie de gerente, ou seja, supervisor
ele supervisiona todo o processo: planejamento das tarefas (escrever prompts, definir escopo), escrita de testes e escrita de código
acabou aumentando muito o volume de revisão, mas por eu fazer diretamente o papel de time vermelho e checar se quebra menos, senti que ganhei mais controle
Achei essa visão impressionante
no mundo dos negócios, também daria para dividir entre 'time azul' (indústrias de infraestrutura social: energia, petróleo, telecomunicações, software, finanças etc.) e 'time vermelho' (indústrias de valor agregado: alimentação, varejo especializado, luxo, turismo etc.)
economicamente, o lado azul é muito mais importante, porque essas indústrias servem de base para toda a economia, têm alta demanda e precisam minimizar erros
já as indústrias do time vermelho não são indispensáveis para a economia funcionar, mas quanto mais existirem, maior tende a ser o ganho de qualidade geral
no exemplo do Tao, o fato de engenheiros de software ganharem mais que QA, e de escrever provas ser visto como economicamente mais valioso que verificá-las, segue a mesma estrutura
quando Sam Altman busca financiamento para treinar LLMs, é mais fácil conseguir investimento se ele enfatizar que "somos úteis como time azul", e isso acaba moldando toda a narrativa da mídia
na prática, LLMs parecem mais adequados para usos de time vermelho, mas como é preciso justificar retorno sobre investimento, as empresas vão empurrá-los como solução de time azul
Google Glasses, VR e dispositivos vestíveis seguem padrão parecido
são tecnologias de time vermelho úteis em nichos, mas como não geram um ecossistema gigante nem grandes receitas, acabam sendo ignoradas pelo capital
(Sou da Microsoft)
eu mesmo opero validação automatizada de red team em amostras de RAG com o SDK
azure-ai-evaluationaqui, um LLM adversarial fora dos trilhos é combinado com o pacote pyrit para gerar automaticamente perguntas bizarras para o app e ainda transformar as próprias perguntas com base64, cifra de César, urldecode etc.
os resultados reais são interessantes, e concordo que LLMs são bastante úteis para atividades de red team
Vídeo demo no YouTube
(desculpem se o tom de voz estiver alto, foi gravado num lugar meio peculiar)