Uma Introdução ao Podcast Beyond the Edge de Edgio Episódio 5: Identificando e Atenuando Ameaças do Dia Zero hospedado por Andrew Johnson, Sr. Gerente de Marketing de Produtos – Segurança na Edgio.
Andrew Johnson: Bem-vindo ao Beyond the Edge, onde nos aprofundamos nas tendências que afetam os negócios digitais modernos. Eu sou Andrew Johnson, seu co-piloto para este episódio. E hoje estamos explorando o tema das ameaças de dia zero, especificamente como as identificamos e mitigamos. Junte-se a nós hoje estão Dave Andrews Edgio, vice-presidente de engenharia, e Marcel Flores, cientista de pesquisa líder na Edgio.
Bem-vindo, Dave. E Marcel, é ótimo ter vocês dois aqui. Você pode nos contar um pouco sobre vocês mesmos e seus papéis aqui no Edgio?
Dave Andrews: Claro. Obrigado por nos ter Andrew. É um prazer estar em frente. Então eu sou VP de Engenharia. Eu estive no Edgio por acho que apenas uma sombra ao longo de 11 anos. E eu sou responsável pelas plataformas de borda e muito do tipo de infraestrutura central do ponto de vista da engenharia.
Andrew Johnson: Incrível. Obrigado.
Marcel Flores: Sim. Muito obrigado por nos ter. Como você disse, eu sou Marcel Flores. Eu sou o cientista de pesquisa principal do Edgio Labs, o grupo de pesquisa aqui no Edgio. Minha equipe trabalha para melhorar o desempenho, a confiabilidade e as operações da rede, realizando pesquisa e desenvolvimento rigorosos, bem como se envolver com os sistemas mais amplos e a comunidade de pesquisa em rede.
O que é um Dia Zero?
Andrew Johnson: Incrível. Obrigado novamente por se juntar a nós hoje, pessoal. Então, o tema das ameaças de dia zero, acho importante dar rapidamente ao nosso público um histórico sobre quais são vulnerabilidades e ataques de dia zero. Vou tentar brevemente cobrir isso antes de entrar em algumas de suas experiências protegendo a Edgio e nossos clientes. Então, o que é um dia zero em termos do que estamos falando aqui? Bem, basicamente aplicativos modernos, empresas modernas, serviços modernos são compostos de software, software de código aberto, bases de código comercializado diferentes protocolos, etc. Sabemos que nenhum software é perfeito, e de tempos em tempos, vulnerabilidades serão detetadas nesse código. Basicamente, “dia zero” refere-se ao período de tempo dentro do qual uma vulnerabilidade é descoberta e o tempo para criar um patch ou uma solução alternativa, certo?
Então, os desenvolvedores, uma vez que eles sabem sobre uma vulnerabilidade, eles vão tentar corrigi-la o mais rápido possível ou dar aos clientes e usuários as etapas que eles podem fazer para evitar a exploração. Mas basicamente, como eu mencionei, é um problema que não vai embora. Vemos o número de CVEs ou vulnerabilidades e exposições comuns aumentando a cada ano cerca de 25% em 2022 em comparação com 2021. Não é super surpreendente que mais vulnerabilidades sejam detetadas. Existem ferramentas de IA que podem digitalizar bases de código rapidamente. Há certamente incentivos financeiros para que ambos os bons atores e os maus atores encontrem essas vulnerabilidades no lado bom, o lado bom dos atores. Existem programas de recompensa de bugs.
Você está familiarizado com quando a Apple envia correções de código para o seu iPhone o tempo todo. Os pesquisadores de chapéu branco bom estão enviando exploits a esses desenvolvedores, e então há atores ruins que também estão explorando vulnerabilidades. Então, apenas um pouco de fundo sobre isso. Talvez alguns comuns que você já ouviu falar recentemente. HTTP2/Rapid Reset foi uma coisa muito notável no mundo da segurança de aplicativos recentemente. Talvez você já tenha ouvido falar do Log4j, Spring4Shell ou alguns anos atrás, da vulnerabilidade do Apache Struts 2 que causou enormes violações de dados aqui nos Estados Unidos, na verdade em todo o mundo. Então isso é apenas um pouco de fundo sobre ameaças de dia zero, mas sim, talvez eu vá em frente e comece perguntando a Dave apenas um pouco sobre o que vocês fazem para proteger Edgio e nossos clientes de ameaças de dia zero.
Como a Edgio protege a si mesma e aos seus clientes das ameaças Zero-Day?
Dave Andrews: Sim, absolutamente. Então, a segurança eu acho que é tudo sobre defesa em profundidade, certo? Como, nunca há nenhuma coisa em particular que você faça. É mais sobre ter certeza de que você tem uma série de camadas todas amarradas juntas. A ideia é se uma ou duas camadas são imperfeitas, como todas elas são porque temos humanos muito inteligentes tentando ativamente quebrá-las, o grande número de camadas e com proteções e mitigações sobrepostas é projetado, você sabe, o, todo o ponto aqui é, não importa se uma coisa falha porque há outras cinco coisas que vão te proteger. Então, dar um passo para trás, como o primeiro, e eu acho que, sem dúvida, uma das coisas mais importantes é simplesmente cair no balde da preparação.
Há pelo menos três aspetos separados para isso. O primeiro que me vem à mente é a higiene. Ter uma boa higiene de segurança é absolutamente crítico. E realmente ajuda em grande parte reduzindo sua área de preocupação. Então, o que quero dizer com higiene? Há duas coisas principais. Um deles é manter o software atualizado ou regular patching. Esta é a coisa mais chata do mundo. É também indiscutivelmente uma das melhores e mais críticas linhas de defesa. Isso significa que você tira proveito de todas as divulgações responsáveis de que você estava falando, Andrew, o bom, pesquisadores de chapéu branco, encontrando vulnerabilidades, divulgá-los a fornecedores, corrigi-los e implementar correções.
Você pode aproveitar todos os vetores de ataque basicamente conhecidos no software que você está usando. Só porque é chato não significa necessariamente que é fácil, especialmente quando você está trabalhando na escala que estamos no Edgio, bem como em vários outros lugares, é muito, muito difícil gerenciar o risco que vem com a atualização de todo o seu software em uma base regular. Então, como veremos mais adiante, há muitas coisas que fazemos operacionalmente para tornar isso mais seguro e fácil de fazer. Mas ainda cai bem no balde de higiene, se você quiser. A próxima peça que pousa dentro da higiene é a digitalização. O que todo o ponto aqui está procurando ativamente por coisas que são indicações de que você tem um problema antes que um mau ator o encontre.
Assim, isso toma uma série de formas. Pode ser equipes de segurança interna ou equipes de segurança da informação. Você pode contratar terceiros externos para realizar digitalizações. Pode ser ambos. Muitas vezes, as organizações aproveitam a recompensa de bugs para basicamente incentivar as pessoas a tomar a rota de chapéu branco, encontrar vulnerabilidades divulgá-los para nós ou para a parte em particular para que eles possam ser corrigidos antes de serem ativamente explorados. Então essas coisas caem neste balde de qualquer coisa que você pode consertar, corrigir isso primeiro, certo? Assim, aproveite o bom trabalho que toda a comunidade está fazendo para tornar a internet e o software em geral mais seguros. E então, olhando ativamente para seus próprios aplicativos, tentando encontrar vulnerabilidades e corrigi-las proativamente da melhor maneira que você puder. A próxima seção que eu diria sobre a preparação, eu vou virar para Marcel, é a observabilidade.
Marcel Flores: Sim, obrigado Dave. Então eu acho que outra coisa importante a ser capaz de fazer em muitos desses casos é poder ver o que está acontecendo em sua rede ou com sua infraestrutura. Então, eu acho que esse tipo de se enquadra em duas categorias que são fundamentalmente abordadas da mesma forma, mas eu acho que são importantes para chamar a atenção. A primeira é pensar em comportamentos de nível de aplicação, certo? Certificar-se de que você entende quais solicitações estão entrando em sua rede e tipo de quais são os recursos dessas solicitações, como elas são moldadas e como elas são normalmente e como elas podem parecer durante determinados eventos. Eu acho que também é importante, ter em mente que sempre que você está se comunicando na internet, certo, é uma espécie de operação de pilha completa, certo?
Onde cada solicitação passará pela camada de aplicativo, mas também pelos protocolos de nível inferior. E então é importante ficar de olho no que está acontecendo mais abaixo da pilha, certo? E entenda que pode haver comportamentos complexos e respostas de sistemas de nível inferior que não são bem capturados nesses comportamentos de camada de aplicação. Portanto, é importante manter o controle do tipo de ambos os componentes e ter observabilidade no que está acontecendo em ambos os casos. E eu acho que uma peça chave é ser capaz de entender quando esse tráfego muda, certo? Quando o seu tráfego desafia as expetativa, certo? Você pode começar a ver recursos de solicitações de aplicativos que não são o que você normalmente vê, certo? Por exemplo, um aumento repentino nos posts HTTP em vez de GET, pensando na camada de aplicação, pensando no nível de protocolo, certo?
Isso pode ser algo muito intrincado no protocolo como HTTP2 ou algo ainda menor. E pensar no que está acontecendo com os soquetes TCP e no que está acontecendo com as interações de protocolo nesse nível, especialmente quando você está pensando em coisas como ataques DDoS que podem tentar explorar vulnerabilidades específicas. Acho que a chave para ter essas vulnerabilidades, para essa observabilidade não é apenas ter métricas que permitem que você veja o que está acontecendo, mas também ter a capacidade de investigar esses comportamentos, certo? E segmentá-los de acordo, certo? Para entender se há uma população de usuários específica que está gerando um certo conjunto de tráfego. Existem redes específicas, são clientes específicos, propriedade específica de um determinado cliente, certo? Então você pode entender e restringir onde as coisas estão realmente acontecendo e como elas podem estar acontecendo.
Andrew Johnson: Isso é interessante. Isso é interessante. Então, o que, depois de observar esses diferentes tipos de comportamento ou algo que você acha que pode ser um dia zero, quais são alguns dos passos operacionalmente que você pode tomar?
Que passos você pode tomar para mitigar as ameaças de dia zero?
Dave Andrews: Sim, eu posso pegar aquele, Andrew. Sim. Os dois tipos de elementos que Marcel estava falando são realmente os fundamentos, certo? Como o primeiro é olhar para as coisas, olhar para a tendência, que se resume a partir de uma perspetiva, olhar para as coisas de forma agregada, certo? Como, como é isso em geral? E todo o ponto é que você tem uma visão de alto nível do que está acontecendo, e isso permite que você identifique as mudanças muito, muito rapidamente, como você disse. A segunda parte em termos de mergulho profundo é, na verdade, ser capaz de provocar e desenvolver sua compreensão sobre qual mudança, em que nível está operando, e é um risco, certo? Como, você sabe, a internet é o oeste selvagem, selvagem, certo? Como, as coisas mudam o tempo todo.
Novos comportamentos estão acontecendo o tempo todo. Nem todas essas coisas são um problema de segurança, certo? Assim, a capacidade de ter um conjunto agregado muito mais amplo de informações, mas permite que você escave e faça e observe ou melhor, responda perguntas que são muito mais matizadas, permite que você chegue ao centro do que mudou e por que, e permite que você tome essa decisão. Como, oh minha bondade, como, isso está bem. É um novo cliente fazendo algo. Ou você sabe que isso é realmente um problema, ou nós precisamos ir olhar. Então, afastar-se, você sabe, ver o que aconteceu, e desenvolver algum entendimento sobre isso é um problema. Você entra no reino do tipo, grande, então o quê?
Como, o que você faz sobre isso? E esse balde do que chamamos de agilidade operacional e agilidade. Há alguns temas de alto nível que pensamos quando consideramos a agilidade operacional. Mais uma vez, três, mas essas são capacidade de resposta, segurança e redundância. Então, apenas gastar um pouco de tempo em cada uma dessas respostas é exatamente o que parece, certo? Quando algo está dando errado a partir de uma perspetiva de segurança o tempo é essencial, certo? Como você sabe, você quer ser capaz de fechar problemas de segurança muito, muito rapidamente para dar aos atacantes tempo mínimo para causar estragos e dar-lhe o máximo de tempo para limpar. Então, o que visamos de um sentido muito amplo, não apenas em torno de questões de segurança, mas apenas em torno de todos os tipos de mudanças operacionais que fazemos, visamos cerca de cinco segundos para alcançar 99,99% da infraestrutura.
Esse é o objetivo. Nem sempre chegamos lá porque algumas coisas necessariamente levam mais tempo, mas esse é o alvo. E muitos dos nossos subsistemas cumprem esse objetivo. Segurança é um tipo estranho de tema para pensar com agilidade de operação. Então deixe-me provocar um pouco de parte. Um dos riscos que você tem quando você está tentando fazer algo com um alto nível de resposta, ou seja, muito, muito rapidamente, é que você pode resolver o problema muito, muito rapidamente, assumindo que você tem perfeita observabilidade e uma compreensão perfeita do que está acontecendo, e você pode prever perfeitamente a resposta à mudança que você está prestes a fazer. Isso é ótimo, e muitas vezes esse é o caso. No entanto, há também a chance de que sua compreensão de qualquer uma dessas coisas seja imperfeita, e você pode fazê-lo pior também muito, muito rapidamente.
Ninguém quer isso. Então, o ponto completo sobre segurança é que você coloca sistemas em prática, processos e automação, e muitas outras coisas entram nele para garantir que você não piore, de fato. Isso se resume a um par de coisas muito, muito de alto nível. No início. É como uma modelagem proativa. Isso se aplica muito ao planejamento básico de capacidade, certo? Por exemplo, se você tiver que retirar máquinas da produção por algum motivo para corrigi-las, porque ele requer que os serviços sejam reiniciados por qualquer motivo. Um dos riscos se você tentar fazer isso muito, muito rapidamente é que você tira muitas máquinas da produção para a carga que elas estão enfrentando atualmente. Você pode saber isso antes do tempo, certo?
Então, temos muitos sistemas de modelagem que se integram com sistemas de fluxo de trabalho para que, quando uma solicitação para corrigir tudo o mais rápido possível, ela não retire imediatamente todos os servidores da produção. Assim, existem sistemas de segurança básicos que você pode construir e integrar para evitar que você se atire no pé. E assim, assumindo que não vamos piorar as coisas a partir dessa perspetiva, apenas numa perspetiva de infraestrutura de planejamento de capacidade pura, também queremos saber que a mudança que estamos fazendo tem o efeito pretendido no nível da aplicação ou no nível que quer que seja, aplicação de observabilidade, protocolo, etc. seja o que for que estamos tentando mitigar. Então, o que fazemos para alavancar um sistema que chamamos de mina de carvão. Nós já publicamos sobre isso e falamos sobre isso publicamente antes, mas a ideia de que há basicamente tudo sai como o que chamamos de canário – canários na mina de carvão.
O ponto que não há nada acontece globalmente de uma só vez, não importa o quão terrível seja. Um mínimo de duas fases para algo sair. Então, colocamos isso em um subconjunto de infraestrutura. Normalmente, a infraestrutura que está experimentando o evento mais egregiamente ou é mais visível, validamos que ele faz o que esperamos e, em seguida, o colocamos muito rapidamente mais tarde. Desculpe, roll, roll out out mais amplamente e valide que o problema geral resolve em um nível global. Então, a mina de carvão e os canários fortemente integrados com suas métricas e sistemas de observação para que você possa se correlacionar rapidamente como, o que é isso? O que esse canário está fazendo com as métricas agregadas que estou olhando? Então, recebemos feedback em tempo real que, hey, a mudança que estamos fazendo é, de fato, abordar o problema.
Então isso é muito, muito útil. O que estamos realmente trabalhando no momento e nos preparando para lançar internamente e mais tarde, produziremos isso para os clientes e suas alterações de configuração, é basicamente uma análise métrica totalmente automatizada. Então, atualmente, quando fazemos uma mudança como essa, é necessário que um ser humano se sentar lá e olhar para ela, certifique-se de que a coisa correta está acontecendo e certifique-se de que as métricas que eles estão preocupados estão se movendo na direção certa. E então basicamente avançar o canário, dizer ao sistema como, ótimo, você passou a primeira fase. Tudo parece bom. Vá em frente e vá para a fase global daquele canário. Fazemos isso, aproveitamos o sistema para todas as mudanças, não apenas, você conhece as mudanças operacionais de segurança, mas todas as mudanças que fluem por todo o sistema.
E o que estamos entrando é à medida que construímos cada vez mais visibilidade para o nosso ponto de vendas, mais e mais visibilidade, mais e mais métricas, mais e mais informações sobre o que está acontecendo, há cada vez mais para os seres humanos olharem, certo? E essa carga está chegando ao ponto em que é muito alta. E assim os seres humanos estão começando a cometer erros, certo? Porque há simplesmente muitos gráficos para olhar, muitos gráficos para olhar e as pessoas se cansam e as pessoas são imperfeitas de qualquer maneira. Então, estamos lançando um sistema chamado birdwatcher, o que assiste aos canários basicamente que faz alguma análise estatística sofisticada sobre as métricas, como como as mudanças estão rolando e dá-lhe um polegar para cima ou um polegar para baixo. E isso está integrado com a mina de carvão para que possamos dizer, Ei, de forma automatizada, temos alguma indicação de que canário é bom, está fazendo o que esperamos.
E também separadamente não está fazendo nada de ruim que não esperamos, e isso, esse lançamento irá prosseguir sem qualquer intervenção humana. Tão super empolgado com isso. Isso tornará nossa capacidade de resposta ainda mais rápida e ainda mais segura. Então, essas são as principais coisas que consideramos quando estamos falando de segurança, sendo capazes de fazer o problema desaparecer de forma rápida e segura. O ponto final que mencionei foi a redundância, que é relativamente auto-explicativa. Há um ponto-chave ou filosofia que alavancamos e implantamos que é basicamente um caminho duplo para muitas dessas mudanças, tantas quanto pudermos reunir. Então, o que o caminho duplo significa, os dois caminhos que pensamos são basicamente rápidos, melhores esforços e lentos, confiáveis. A ideia que existe, operamos uma grande quantidade de infraestrutura em lugares muito, muito díspares em todo o mundo.
A capacidade de acertar tudo com uma confiabilidade cem por cento em poucos segundos é um conto de fadas. Como, isso não é algo que seja viável. Algo em algum lugar é sempre meio que ter um problema. E não há realmente nada que você possa fazer sobre isso. Então, o que fazemos é basicamente colocar essas coisas juntas de forma semelhante à segurança, à defesa em profundidade, certo? Como, você coloca essas duas coisas juntas e, e o que isso realmente parece, é alavancar o caminho rápido. Vá bater o máximo que puder. E então qualquer coisa que você perca, temos certeza de que temos um caminho confiável redundante que continuaremos tentando até que ele funcione, que é um pouco mais lento. Então, para colocar alguns números nisso, o caminho rápido vai tocar, vamos fazer uma mudança em aproximadamente 99,9% da nossa infraestrutura em menos de cinco segundos, certo?
Como, e que 99,9% é repetível e confiável. E então o caminho confiável lento corre na ordem de 60 segundos. E esse sistema continuará tentando até que seja bem-sucedido basicamente. Então nós, aproveitando esses dois juntos, obtemos o melhor dos dois mundos. E se um desses subsistemas for completamente para baixo, isso não significa que tudo esteja para baixo, ainda vamos onde precisamos estar no máximo cinco minutos depois. Então, essas duas coisas juntas nos dão essa capacidade de resposta e agilidade com a confiabilidade que estamos procurando. Há outras coisas divertidas para nos certificarmos de que temos redundâncias. Como você começa estes sistemas fora? Como muitos sistemas já sabem, os chatbots integraram-se, por isso é muito, muito fácil.
Qualquer pessoa pode fazê-lo a partir de qualquer lugar do mundo em seu telefone. Muitas outras coisas têm APIs. Há uma CLI para muitos subsistemas. Portanto, garantir que não há apenas uma maneira de iniciar essas tarefas é outro exemplo de como tentamos construir redundância para que possamos sempre ter essa agilidade operacional na ponta dos dedos, independentemente do que está acontecendo ou que sistema específico possa estar enfrentando um problema. Certificamo-nos de que temos o controlo e a capacidade operacional de que precisamos. Muitas dessas coisas, você sabe, são todas de propósito geral, mas como eu disse, nós as alavancamos para o máximo que pudermos. Tudo, desde os nossos próprios fluxos de trabalho de infraestrutura, como tirar uma máquina da produção e aplicar patches até as alterações de configuração do cliente. Tudo isso aproveita o mesmo sistema central que nós alimentamos e nos alavancamos agressivamente. Portanto, o produto que expomos aos nossos clientes é confiável e muito, muito sólido.
Andrew Johnson: Incrível. Incrível. Aprecie que Dave. E Marcel, eu acho que você falou sobre as melhores práticas ou considerações que as equipes de segurança podem aplicar a sua prática. Aprecie essas dicas. Eu sei que vocês definitivamente lidaram com alguns exemplos realmente interessantes de dia zero na natureza para proteger Edgio e nossos clientes. Tenho certeza de que você tem algumas boas histórias e aplicações dessas melhores práticas. Você seria capaz de falar um pouco sobre isso?
Exemplos de dia zero: HTTP2/Reposição rápida
Dave Andrews: Sim, absolutamente. Acho que o que é mais pertinente ou mais recente, acho, e foi um pouco interessante é, você mencionou anteriormente, o ataque HTTP2/Rapid Reset. Essa foi uma experiência muito interessante. Então, apenas para retransmitir da perspetiva de Edgio, há um pequeno blog que escrevemos sobre esse cara como aconteceu. HTTP2/Rapid Reset foi um ataque de dia zero, onde as pessoas perceberam que não só a implementação de bibliotecas de servidor HTTP2 do modo tinha tomado alguma coisa no HTTP2 RFC, a especificação, a especificação do protocolo como uma recomendação geral e basicamente codificou isso nas próprias bibliotecas. E esse foi o número de solicitações simultâneas que foram permitidas, desculpe, os fluxos simultâneos que foram autorizados a estar em voo em uma conexão particular, que estava na especificação, escrito como sendo uma centena.
Isso aliado a uma faceta interessante do H2, que é, você sabe, a ideia de ser o multiplex – lotes e muitas solicitações em um único soquete TCP – e a capacidade de cancelar solicitações levou a essa vulnerabilidade muito, muito interessante ou vulnerabilidade DDoS. Todo o ponto lá o que os atacantes estão procurando é algo que custa uma pequena quantia para o atacante e custa mais para o attackee, para a pessoa do outro lado E eles encontraram isso no HTTP2, reset rápido. O que isso significava basicamente era que o invasor poderia muito, muito, muito rapidamente se colocar em um único pacote iniciando uma solicitação e, em seguida, cancelando-a repetidamente, como centenas daqueles em um único soquete desculpe, em um único pacote e enviá-lo para o servidor.
O servidor então tem que fazer muito mais trabalho do que apenas enviar um único pacote. Temos que criar uma solicitação, muitas vezes temos que iniciar uma conexão proxy. Isso é o que os CDNs fazem para ir buscar qualquer ativo que o invasor estava solicitando. E então, finalmente, temos que registrar que o pedido aconteceu. Assim, o fato de que os atacantes foram capazes de gerar essas iniciações e cancelamento das solicitações é muito, muito rapidamente. Basicamente, a maioria, como qualquer um que veio sob esse ataque, é mais caro. Era mais caro processá-los do que gerá-los. E assim, isso se torna uma vulnerabilidade DDoS. Então, nós gostamos de muitas outras pessoas na indústria, você sabe, foram atacadas por isso.
E todos foram atacados ao mesmo tempo, o que o tornou particularmente interessante. Foi um ataque muito amplo. E eu adoraria entender o que os atacantes estavam pensando quando começaram isso. Porque eles estavam atacando muitos, muitos, muitos provedores ao mesmo tempo. O que descobrimos quando começamos a falar com os outros provedores e ser como, oh, quando você viu isso? OH, é exatamente o mesmo tempo que vimos, no qual tropeçamos porque encontramos o ataque. Identificamos o que estava acontecendo por causa da observabilidade que Marcel está falando. E começamos a construir mitigações, certo? Assim, essa mitigação parece adicionar ainda mais observabilidade para chegar ao centro exatamente do que estava acontecendo e, em seguida, construir controles operacionais que nos permitem ajustar uma resposta a ela.
Então o que realmente parecia era como, manter o controle de quantas vezes qualquer cliente está redefinindo solicitações em um soquete específico, e se a porcentagem lá vai acima de um limite predefinido, encerrar essa conexão. Portanto, a ideia é basicamente não permitir que o invasor envie continuamente essas solicitações para colocar um limite sobre ele e, portanto, ser capaz de mitigar o ataque. Então, publicamos esse blog depois de termos construído essa mitigação, implementado, promulgado e validado que ele estava de fato impedindo que esses ataques se repetiam. Então, nós tivemos pessoas da indústria para fora e gostamos, oh, nós vimos o blog. Na verdade, também fomos impactados por isso e estamos trabalhando em divulgação responsável. Então, nós nos dobramos com um grupo da indústria que trabalhou com como Vince, o que é uma parte do cert para passar pelo fluxo de divulgação responsável, certifique-se de que, neste caso, as pessoas que estavam implementando bibliotecas HTTP2 ou servidores HPD tiveram tempo para gerar patches, implantar esses patches antes do, a vulnerabilidade foi mais amplamente divulgada.
Por isso, foi um fluxo muito, muito interessante e interessante. Fomos capazes de, para virar isso muito rapidamente, certo? Como em parte por causa do trabalho que fazemos na higiene e operação e visibilidade e agilidade operacionais, conseguimos uma espécie de mudança muito pequena para fazer, certo? Como, não foi, você sabe, oh minha bondade, temos que atualizar esta biblioteca e somos como 10 versões atrás porque não atualizamos regularmente. Não era que fosse como, na verdade, nós somos, somos uma versão atrás, certo? Como, porque regularmente corrigimos a atualização de que o risco é reduzido porque é um pequeno salto, o que significa que você pode fazê-lo muito rapidamente, mantendo o limite de baixo risco que temos. Então, fizemos isso muito, muito rapidamente e somos capazes de implementar e mitigar o ataque. E depois colocamos o blog sem saber que o ataque tinha atingido mais pessoas em parte para tentar socializar não só com nossos clientes, mas com a indústria. Como, Hey, isso é algo estranho que vimos que parece que não é nada específico do Edgio e, na verdade, potencialmente mais aplicável. E descobriu-se que era.
Andrew Johnson: Isso é, isso é realmente interessante. É legal ver uma visão interna de você sabe, a comunidade de segurança em todo o mundo trabalhando juntos para, para você saber, melhorar os resultados para todos. Marcel, você queria adicionar alguma coisa em torno disso?
Marcel Flores: Sim, eu só queria acrescentar uma nota que eu, acho que este, este exemplo foi um exemplo interessante em que a observabilidade inicial que tínhamos definitivamente mostrado comportamentos estranhos como Dave estava descrevendo, certo? Essa interação do tipo de recurso de protocolo de nível inferior com os comportamentos de nível superior da CDN criou alguns comportamentos realmente inesperados. E parte disso, parte de descobrir o que estava acontecendo aqui foi entender que havia esse desequilíbrio grave, certo? Que o número de solicitações que estávamos vendo versus o número de solicitações que estávamos realmente entregando de volta aos clientes foi distorcido, certo? E isso se destacou. E mesmo que essas fossem as duas métricas que tínhamos coletado, não as comparávamos exatamente dessa maneira. Então, parte do resultado disso foi sentar e olhar para ele e dizer, Hey, o que, como podemos combinar a visibilidade que já temos em algo que é feito sob medida para detetar esse problema? E conseguimos fazer exatamente isso e melhorar o escopo de nossa visibilidade, observando os dados que já tínhamos através de uma lente um pouco diferente.
Andrew Johnson: Incrível. Incrível. Isso é bom ter em mente. E obrigado por isso, Marcel. Sim, caras, então eu acho que estamos, estamos terminando. Se, se houver alguma recomendação adicional que você queira compartilhar? Acho que cobrimos um alto nível, alguns muito bons.
Recomendações para fortalecer sua postura de segurança
Dave Andrews: Boa pergunta. Acho que uma recomendação geral é higiene é extremamente importante. Focando em sua observabilidade, eu acho que a coisa que eu chamaria é encontrar pessoas que podem ajudar, certo? Como parte do valor de uma proposta crítica de valor que uma empresa como a Edgio fornece é que podemos definitivamente ajudar, certo? Você tem uma equipe inteira de pessoas como eu e Marcel que estão trabalhando nisso e trabalhando proativamente para impedir que classes inteiras de ataques afetem as pessoas. Então encontre pessoas que podem ajudar, certo? Como há um monte de ferramentas e tecnologia que construímos, que a comunidade tem disponível que pode tornar o seu trabalho mais fácil. Quando estamos falando, você sabe, geralmente coisas na internet, um WAF é como, é o mais crítico, como o mais básico também, eu diria o exemplo mais crítico de algo assim.
Ele lhe dá a capacidade se for implementado adequadamente, ele lhe dá a capacidade de combinar a agilidade e os elementos de segurança juntos. Assim, o Edgio WAF funciona em modo duplo, o que significa que você pode implantar novas regras para a produção, para as máquinas reais que estão obtendo, que estão observando o tráfego. E você pode ver o que está acontecendo. Um bom exemplo disso foi com o Log4j, que foi, você sabe, voltar no tempo um pouco. Quando desenvolvemos a resposta a isso, somos capazes de desenvolver a regra muito, muito rapidamente e validá-la muito, muito rapidamente. Como estávamos empurrando atualizações de regras e sendo capaz de implantá-las no modo de alerta nas máquinas reais e ver que elas correspondiam aos ataques, mostre aos nossos clientes que eles não estavam sendo atacados ou estavam sendo atacados. E, em seguida, tome uma decisão muito baseada em dados para permitir que essa regra seja ativada no modo de bloqueio e, na verdade, impedir que esses ataques sejam feitos para nossos clientes. Então ele combina todas essas coisas juntas, certo? Como velocidade de resposta, segurança, redundância e confiabilidade. Obter pessoas que podem ajudar. Eu acho que seria a minha principal recomendação.
Andrew Johnson: Isso faz muito sentido. Eu aprecio isso, Dave. Sim, quero dizer, ao responder a zero dias, o tempo é crítico. Portanto, ter essas soluções especializadas, mas também mais importante, as pessoas que podem ajudá-lo com isso é a chave para fechar essa porta sobre os atacantes. Então, com esses caras muito obrigado por se juntar a nós. Eu gostaria de agradecer ao público também, e nós vamos ver você no próximo episódio. Obrigado.
