Toda solução tecnológica tem um efeito colateral

‍Da arquitetura da Internet à criptografia, computação em nuvem e HTTP/3, cada avanço resolve problemas reais enquanto cria novos para que outra pessoa os gerencie.

‍

A medicina oferece uma lição útil sobre o progresso. Um novo tratamento pode curar uma condição enquanto introduz efeitos colaterais em outra parte. Os antibióticos transformaram a saúde moderna, mas seu sucesso também criou as condições para a resistência antimicrobiana. A conclusão não é que os antibióticos foram um erro. É que resolver um problema altera o sistema ao seu redor, e o sistema alterado cria novos problemas por conta própria.

‍

A tecnologia funciona da mesma maneira. Gostamos de descrever o progresso como uma linha reta: as redes tornam-se mais rápidas, as plataformas de nuvem mais escaláveis, a criptografia mais forte e a IA mais capaz. Cada geração corrige algo que frustrava a geração anterior. No entanto, o progresso raramente elimina o risco por completo. Mais frequentemente, ele desloca o risco para outro lugar, muda sua forma ou expõe fraquezas que antes não importavam.

‍

Isso não torna o progresso ruim. Significa apenas que cada melhoria altera as premissas sobre as quais o restante do sistema foi construído, e essas premissas raramente mudam em todos os lugares ao mesmo tempo. Tecnologias antigas e novas coexistem, às vezes por décadas, e é frequentemente nessa sobreposição que surgem problemas de segurança inesperados.

‍

Um estudo recente sobre um ataque chamado CDN Tsunami é um bom exemplo.

‍

Quando a eficiência cria uma fraqueza

‍

HTTP/3 foi criado para melhorar o funcionamento da web. Construído sobre QUIC em vez de TCP, ele reduz a sobrecarga de conexão, lida melhor com a perda de pacotes em fluxos simultâneos e é particularmente útil em redes móveis e menos confiáveis. Ele também usa QPACK para compactar cabeçalhos HTTP com mais eficiência. Essas são melhorias genuínas, e o HTTP/3 agora é suportado em aproximadamente 40% das solicitações da web medidas pelo HTTP Archive.

‍

O problema é que a Internet não se atualiza toda de uma vez. Um navegador pode falar HTTP/3 com uma CDN, enquanto a CDN continua falando HTTP/1.1 com o servidor de origem por trás dela. Esta é uma arquitetura perfeitamente normal, e muitas vezes prática, porque permite que a borda da Internet adote protocolos mais novos sem forçar todos os servidores de aplicação, firewalls e balanceadores de carga a serem atualizados simultaneamente.

‍

O CDN Tsunami mostra o que pode acontecer nessa transição. Pesquisadores demonstraram que uma solicitação HTTP/3 compacta e eficientemente comprimida pode se expandir significativamente quando a CDN a traduz para HTTP/1.1 para a origem. Eles também mostraram que múltiplos fluxos HTTP/3 transportados eficientemente dentro de uma conexão QUIC podem se traduzir em um uso desproporcional de conexões de backend. Sob condições experimentais específicas, a amplificação de largura de banda relatada atingiu aproximadamente 350 vezes.

‍

O ponto importante é que nenhuma das tecnologias individuais precisa estar quebrada. O QPACK pode estar comprimindo cabeçalhos exatamente como projetado, o QUIC pode estar multiplexando fluxos exatamente como projetado, e o HTTP/1.1 pode estar recebendo HTTP comum exatamente como projetado. A fraqueza aparece na relação entre esses componentes, quando a eficiência de um lado é convertida em um consumo de recursos muito maior do outro.

‍

A Internet sempre carregou os efeitos colaterais do seu próprio sucesso

‍

O próprio DDoS segue o mesmo padrão. Uma das conquistas marcantes da Internet é que milhões de dispositivos e redes operados de forma independente podem se comunicar uns com os outros. Sua abertura, interoperabilidade e descentralização são precisamente o que permitiu que ela se tornasse global, mas essas mesmas características também tornam possíveis os ataques distribuídos.

‍

Se milhões de máquinas legítimas podem se comunicar com o mesmo serviço, então milhões de máquinas comprometidas podem fazer a mesma coisa. Ataques de reflexão exploram protocolos que foram projetados para responder a solicitações. Botnets exploram a conectividade barata e onipresenteAtaques na camada de aplicação exploram o fato de que uma pequena solicitação pode, às vezes, fazer com que um servidor execute um trabalho substancial.

‍

Este é um dos motivos pelos quais é improvável que o DDoS simplesmente desapareça por meio de alguma solução técnica definitiva. Muitas técnicas de DDoS são abusos de capacidades que a Internet realmente precisa. Poderíamos imaginar uma rede na qual cada caminho de comunicação fosse rigidamente controlado, cada identidade verificada centralmente e cada solicitação pré-autorizada, mas ela não se pareceria mais com a Internet aberta que se tornou bem-sucedida em primeiro lugar.

‍

O problema não é simplesmente que a Internet foi mal projetada. Ela foi projetada para um ambiente diferente, com premissas e prioridades diferentes. O progresso mudou o ambiente, e os invasores aprenderam a explorar a lacuna entre essas premissas originais e a realidade atual.

‍

A criptografia nos deu proteção — e os invasores aprenderam a transformá-la em arma

‍

A criptografia pode ser um exemplo ainda mais claro de tecnologia que se torna uma faca de dois gumes. Passamos décadas aprimorando a criptografia justamente porque queríamos que ela fosse difícil, idealmente impossível, de ser quebrada sem a chave correta. A criptografia forte protege bancos, comunicações governamentais, mensagens pessoais, propriedade intelectual e quase todas as transações digitais significativas.

‍

O ransomware volta esse sucesso contra nós. Os invasores não precisam derrotar a criptografia forte; eles a utilizam. A mesma propriedade matemática que impede que uma pessoa não autorizada leia dados protegidos pode ser usada para impedir que o legítimo proprietário acesse seus próprios arquivos. Nesse sentido, uma das maiores conquistas defensivas da cibersegurança tornou-se uma ferramenta ofensiva altamente eficaz.

‍

A resposta, obviamente, não é uma criptografia mais fraca. Ainda precisamos que a criptografia seja forte. Em vez disso, o problema de segurança muda de lugar: para a proteção de endpoints, controles de identidade, gerenciamento de privilégios, backups, arquitetura de recuperação e a capacidade de deter um invasor antes que ele tenha a oportunidade de criptografar dados valiosos.

‍

Esse é o padrão recorrente. A tecnologia resolve o problema para o qual foi projetada, enquanto muda simultaneamente o local onde o próximo problema aparecerá.

‍

Toda nova capacidade tem um caso de uso inverso

‍

O mesmo princípio pode ser observado em grande parte da tecnologia moderna. As APIs tornam o software mais fácil de integrar e automatizar, mas também permitem que os invasores interajam com as aplicações na velocidade da máquina. A automação reduz o custo do trabalho repetitivo para defensores e empresas, ao mesmo tempo em que o reduz também para os invasores. A IA torna a análise, a escrita e o desenvolvimento de software mais baratos e rápidos, mas também pode reduzir o custo de reconhecimento, falsificação de identidade e automação de ataques.

‍

O cache reduz a carga de trabalho da infraestrutura, ao mesmo tempo em que introduz questões sobre envenenamento de cache e consistência. A federação de identidades torna mais fácil para as pessoas acessarem vários sistemas, ao mesmo tempo em que torna uma identidade comprometida potencialmente mais valiosa. Até mesmo a observabilidade e a telemetria, projetadas para dar às organizações mais visibilidade sobre sua infraestrutura, podem se tornar fontes sensíveis de informação se expostas à parte errada.

‍

O fio condutor não é que a nova tecnologia seja insegura. É que cada capacidade altera a economia e as premissas do sistema ao seu redor.

‍

As equipes de segurança, portanto, precisam fazer uma segunda pergunta sempre que celebramos uma melhoria. A primeira pergunta é óbvia: o que essa tecnologia pode fazer agora? A segunda é menos confortável: qual nova assimetria acabamos de criar?

‍

O verdadeiro problema costuma ser a transição

‍

Talvez a coisa mais interessante sobre o CDN Tsunami não seja o HTTP/3 em si, mas a coexistência de gerações tecnológicas. A tecnologia raramente evolui substituindo um sistema por outro de forma limpa. Na prática, acabamos com um novo sistema conectado a um sistema antigo por meio de uma camada de tradução, requisito de compatibilidade ou dependência legada.

‍

Clientes HTTP/3 coexistem com origens HTTP/1.1. Aplicações nativas da nuvem dependem de sistemas de identidade legados. APIs modernas ficam à frente de bancos de dados projetados há décadas. Agentes de IA estão começando a interagir com sistemas criados sob a premissa de que toda solicitação se origina de uma aplicação operada por humanos. Cada geração adiciona uma nova camada em vez de remover completamente a anterior.

‍

Essas interfaces merecem mais atenção à segurança do que costumam receber. Camadas de compatibilidade, gateways, tradutores de protocolo e proxies existem para fazer com que diferentes gerações de tecnologia se entendam, mas eles também traduzem custo, estado e consumo de recursos de um lado para o outro. É precisamente aí que a assimetria pode surgir.

‍

O CDN Tsunami ilustra isso vividamente, pois o atacante não precisa necessariamente gerar grandes volumes de tráfego diretamente. O atacante precisa encontrar uma situação em que uma pequena quantidade de atividade faça com que um intermediário realize muito mais trabalho a jusante.

‍

Uma vez que olhamos para a segurança dessa forma, a amplificação se torna um conceito muito mais amplo do que largura de banda. Pode significar tempo de CPU, memória, gastos com nuvem, consultas a banco de dados, workers de aplicação, tabelas de conexão ou até mesmo atenção humana. Qualquer sistema onde uma entrada barata possa desencadear uma saída desproporcionalmente cara cria uma oportunidade que vale a pena examinar.

‍

O progresso precisa de guardiões

‍

Nada disso é um argumento para desacelerar a tecnologia. O HTTP/3 deve continuar melhorando a Internet. A infraestrutura em nuvem deve se tornar mais elástica. A criptografia deve se tornar mais forte. A IA deve se tornar mais capaz. O progresso ainda é progresso, mesmo quando cria novos problemas.

‍

Mas se aceitarmos que o progresso inevitavelmente cria efeitos colaterais, a inovação não pode ser responsabilidade apenas de quem a constrói. A medicina não para na descoberta de um novo tratamento. Clínicos, farmacologistas, pesquisadores, reguladores e sistemas de saúde pública existem para entender o que acontece depois que esse tratamento entra no mundo real, incluindo seus efeitos colaterais, interações e consequências não intencionais.

‍

A tecnologia precisa de seu próprio equivalente. Órgãos de padronização, pesquisadores de segurança, operadores de infraestrutura, profissionais de cibersegurança e provedores de tecnologia têm um papel a desempenhar na compreensão do que mudou, na identificação das fraquezas que surgiram com isso e na construção das salvaguardas que permitem que todos os outros continuem avançando.

‍

Esse papel se torna mais importante à medida que os sistemas se tornam mais complexos, porque a complexidade raramente desaparece; ela se acumula. Cada nova camada se assenta sobre algo mais antigo, e cada conexão entre elas cria outro ponto onde as premissas podem divergir. Portanto, precisamos de pessoas e organizações cujo propósito não seja simplesmente inventar a próxima capacidade, mas examinar continuamente o que essa capacidade altera ao seu redor.

‍

O progresso não elimina o risco. Ele o redistribui.

‍

A tarefa não é evitar essa realidade, mas garantir que alguém esteja atento para onde o risco foi. Os inovadores continuarão a expandir a fronteira; o trabalho igualmente importante dos guardiões da tecnologia é garantir que essa fronteira permaneça habitável.