Uma Introdução ao Episódio 5 do Podcast Além da Borda de Edgio: Identificando e mitigando 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, o seu co-piloto para este episódio. E hoje estamos a explorar o tema das ameaças de dia zero, especificamente como as identificamos e mitigamos. Hoje, juntam-se a nós Dave Andrews Edgio, vice-presidente de engenharia, e Marcel Flores, cientista de pesquisa líder no Edgio.
Bem-vindo, Dave. E Marcel, é ótimo ter ambos aqui. Podem falar-nos um pouco sobre vocês mesmos e sobre os seus papéis aqui no Edgio?
Dave Andrews: Claro. Obrigado por nos ter Andrew. É um prazer estar em frente. Então eu sou vice-presidente de engenharia. Eu estive no Edgio há 11 anos, penso que só tenho uma sombra. E eu sou responsável pelas plataformas de ponta e por muito do tipo de infraestrutura central do ponto de vista da engenharia.
Andrew Johnson: Fantástico. Obrigado.
Marcel Flores: Sim. Muito obrigado por nos ter. Como você disse, eu sou Marcel Flores. Sou o cientista principal do Edgio Labs, o grupo de pesquisa aqui no Edgio. A minha equipa trabalha para melhorar o desempenho, a fiabilidade e as operações da rede através da realização de investigação e desenvolvimento rigorosos, bem como para se envolver com os sistemas mais amplos e com a comunidade de investigação em rede.
O que é um Dia Zero?
Andrew Johnson: Fantástico. Obrigado novamente por se juntarem a nós hoje, pessoal. Por isso, o tema das ameaças de dia zero, acho que é importante dar rapidamente à nossa audiência um histórico sobre quais são as vulnerabilidades e os ataques de dia zero. Vou brevemente tentar cobrir isso antes de entrarmos em algumas das vossas experiências protegendo a Edgio e os nossos clientes. Então, o que é um dia zero em termos do que estamos a falar aqui? Bem, basicamente aplicativos modernos, negócios modernos, serviços modernos são feitos de software, software a partir de código aberto, bases de código comercializadas de protocolos diferentes, 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?
Assim, os desenvolvedores, depois de saberem sobre uma vulnerabilidade, vão tentar corrigi-la o mais rápido possível ou dar aos clientes e utilizadores as etapas de software que puderem fazer para impedir a exploração. Mas, basicamente, como mencionei, é um problema que não vai desaparecer. Vemos o número de CVEs ou vulnerabilidades e exposições comuns a aumentar todos os anos cerca de 25% em 2022 em comparação com 2021. Não é surpreendente que mais vulnerabilidades sejam detetadas. Existem ferramentas de IA que podem digitalizar bases de código rapidamente. Há certamente incentivos financeiros para os bons atores e os maus atores encontrarem estas vulnerabilidades no lado bom, no lado bom dos atores. Existem programas de recompensas de erros.
Você está familiarizado com quando a Apple envia correções de código para o seu iPhone o tempo todo. Os investigadores do Good White hat estão a enviar explorações a estes programadores, e depois há maus atores que também estão a explorar vulnerabilidades. Então, apenas um pouco de fundo sobre isso. Talvez alguns comuns de que já ouviram falar recentemente. O HTTP2/Rapid Reset foi uma coisa muito notável no mundo da segurança de aplicações recentemente. Talvez já tenham ouvido falar do Log4j, Spring4Shell, ou há alguns anos, da vulnerabilidade do Apache Struts 2 que causou violações massivas de dados aqui nos Estados Unidos, na verdade em todo o mundo. Isso é apenas um pouco de experiência sobre ameaças de dia zero, mas sim, talvez eu vá em frente e comece por perguntar a Dave um pouco sobre o que vocês fazem para proteger o Edgio e os nossos clientes de ameaças de dia zero.
Como é que a Edgio se protege a si mesma e aos seus clientes das ameaças do Dia Zero?
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. A ideia é se uma ou duas camadas são imperfeitas, como todas são porque temos humanos muito inteligentes tentando ativamente quebrá-las, o grande número de camadas e com proteções e atenuações sobrepostas é projetado, sabem, o ponto aqui é, não importa se uma coisa falha porque há outras cinco coisas que vão proteger você. Então, dar um passo atrás, como o primeiro, e eu acho que uma das coisas mais importantes é simplesmente geralmente cai no balde da preparação.
Há, pelo menos, três aspetos distintos. O primeiro que me vem à cabeça é a higiene. Ter uma boa higiene de segurança é absolutamente fundamental. E realmente ajuda em grande parte reduzindo a sua área de preocupação. Então, o que quero dizer com higiene? Há duas coisas principais. Um deles é manter o software atualizado, ou fazer patches regulares. 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 estava falando, Andrew, os bons pesquisadores de chapéu branco, encontrando vulnerabilidades, divulgando-as aos fornecedores, corrigindo-as e implantando correções.
Você pode aproveitar todos os vetores de ataque conhecidos no software que você está usando. Só porque é aborrecido não significa necessariamente que é fácil, especialmente quando estamos a trabalhar à escala que estamos no Edgio, assim como em vários outros locais, é muito, muito difícil gerir o risco que vem com a atualização regular de todo o seu software. Então, como veremos mais tarde, 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 assim o fizer. A próxima peça que cai dentro da higiene é a digitalização. O que todo o ponto aqui está ativamente à procura de coisas que sejam indicações de que você tem um problema antes que um mau ator o encontre.
Portanto, isto assume uma série de formas. Pode ser equipas de segurança internas ou equipas de segurança da informação. Pode contratar entidades externas para realizar digitalizações. Podem ser ambos. Muitas vezes, as organizações aproveitam a recompensa de erros para basicamente encorajar as pessoas a tomar a rota do chapéu branco, encontrar vulnerabilidades revelá-las para nós ou para a parte em particular para que possam ser consertadas antes de serem ativamente exploradas. Então essas coisas caem neste balde de qualquer coisa que você possa consertar, corrigir isso primeiro, certo? Por exemplo, aproveite o bom trabalho que toda a comunidade está a fazer para tornar a Internet e o software em geral mais seguros. E então, olhando ativamente para as suas próprias aplicações, tentando encontrar vulnerabilidades e corrigi-las proativamente da melhor forma que puder. A próxima seção que eu diria sobre preparação, 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 é ser capaz de ver o que está acontecendo na sua rede ou com a sua infraestrutura. Por isso, penso que este tipo de coisas se enquadra em duas categorias que são fundamentalmente abordadas da mesma forma, mas penso 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 compreende quais as solicitações que estão a entrar na sua rede e quais são os recursos dessas solicitações, como elas são moldadas e como elas se parecem normalmente e como elas podem parecer durante certos eventos. Acho que também é importante ter em mente que sempre que estamos a comunicar na internet, certo, é uma espécie de operação de pilha completa, certo?
Onde cada pedido vai passar pela camada de aplicação, mas também pelos protocolos de nível inferior. Por isso, é importante ficar de olho no que se passa 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 captados 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 expetativas, certo? Você pode começar a ver recursos de pedidos de aplicativos que não são o que normalmente vê, certo? Por exemplo, um aumento súbito nos posts de HTTP em vez de GET, pensando na camada de aplicação, pensando no nível de protocolo, certo?
Isto pode ser algo muito intrincado no protocolo como o HTTP2 ou algo ainda mais baixo. E pensar sobre o que está a acontecer com os sockets TCP e o que está a acontecer com as interações de protocolo a esse nível, especialmente quando se pensa em coisas como ataques DDoS que podem tentar explorar vulnerabilidades específicas. Acho que a chave para ter estas vulnerabilidades, para esta observabilidade não é apenas ter métricas que permitem ver o que está a acontecer, mas também ter a capacidade de analisar estes comportamentos, certo? E para segmentá-los de acordo, certo? Para entender se existe uma população de utilizadores em particular que está a gerar um certo conjunto de tráfego. Há redes específicas, são clientes específicos, propriedade específica de um determinado cliente, certo? Assim, podemos entender e restringir onde as coisas estão realmente a acontecer e como elas podem estar a acontecer.
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 operacionais que você pode tomar?
Que medidas podem tomar para mitigar as ameaças do Dia Zero?
Dave Andrews: Sim, eu posso pegar aquele, Andrew. Sim. Os dois tipos de elementos de que Marcel falava são realmente as fundações, certo? Como o primeiro é olhar para as coisas, olhar para a tendência, que se resume a uma perspetiva, olhar para as coisas de forma agregada, certo? Como é que isto se parece em geral? E a questão é que temos uma visão de alto nível do que está a acontecer, e permite identificar as mudanças muito, muito rapidamente, como disse. A segunda parte em termos de mergulho profundo é, na verdade, ser capaz de provocar e desenvolver a sua compreensão sobre que mudança, em que nível está a funcionar, e é um risco, certo? Como, sabem, a internet é o oeste selvagem, selvagem, certo? Como, as coisas mudam o tempo todo.
Novos comportamentos estão a acontecer o tempo todo. Nem todas essas coisas são um problema de segurança, certo? Assim, a capacidade de ter um conjunto de informações agregado muito mais amplo, mas permite que você escave e faça e observe ou melhor, responda a perguntas que são muito mais matizadas, permite que você chegue ao centro do que mudou e porquê, e permite que você tome essa decisão. Tipo, oh minha bondade, tipo, isto está bem. É um novo cliente a fazer algo. Ou vocês sabem que isto é realmente um problema, ou precisamos de ir olhar. Portanto, afastar-se, sabem, de ver o que aconteceu, e desenvolver algum entendimento sobre isso é um problema. Você entra no reino do tipo, ótimo, então o quê?
Tipo, o que é que fazem a respeito disso? E este balde daquilo a que chamamos agilidade operacional e agilidade. Há alguns temas de alto nível que pensamos quando consideramos a agilidade operacional. Mais uma vez, três, mas são responsividade, segurança e redundância. Então, gastar um pouco de tempo em cada uma dessas respostas é exatamente como parece, certo? Quando algo está a correr mal a partir de uma perspetiva de segurança o tempo é essencial, certo? Como vocês sabem, vocês querem ser capazes de fechar problemas de segurança muito, muito rapidamente, para dar aos invasores tempo mínimo para causar estragos e dar-lhe o máximo de tempo para limpar. Portanto, o que visamos de um sentido muito amplo, não apenas em torno de questões de segurança, mas apenas em torno de todo o tipo de mudanças operacionais que fazemos, nós visamos cerca de cinco segundos para alcançar 99,99% da infraestrutura.
Esse é o objetivo. Nem sempre chegamos lá porque algumas coisas levam necessariamente mais tempo, mas esse é o alvo. E muitos dos nossos subsistemas atingem esse alvo. A segurança é um tipo estranho de tema para pensar com agilidade operacional. Então deixe-me provocar um pouco aquele à parte. Um dos riscos que temos quando estamos a tentar fazer algo com um elevado nível de resposta, ou seja, muito, muito rapidamente, é que podemos resolver o problema muito, muito rapidamente, assumindo que temos uma observabilidade perfeita e uma compreensão perfeita do que está a acontecer, e podemos prever perfeitamente a resposta à mudança que estamos prestes a fazer. Isso é ótimo, e muitas vezes é esse o caso. No entanto, há também a possibilidade de que a sua compreensão de qualquer uma dessas coisas seja imperfeita, e você pode muito bem piorar também muito, muito rapidamente.
Ninguém quer isso. Portanto, o ponto sobre segurança é que você coloca os sistemas em prática, os processos, e a automação, e muitas outras coisas entram nele para garantir que você não o torne pior. Isso resume-se a algumas coisas de alto nível. No início. É como uma modelagem proativa. Isto aplica-se muito ao planeamento básico da capacidade, certo? Por exemplo, se você tiver que retirar máquinas da produção por algum motivo para corrigi-las, porque isso requer que os serviços sejam reiniciados por qualquer razão. Um dos riscos se tentarmos fazer isso muito, muito rapidamente é retirar demasiadas máquinas da produção para a carga que estão a sofrer atualmente. Podem saber isso com antecedência, 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, não tire imediatamente todos os servidores da produção. Por isso, existem sistemas básicos de segurança que podem ser construídos e integrados para evitar que se atirem no pé. E assim, assumindo que não vamos piorar as coisas nessa perspetiva, apenas numa perspetiva de infraestrutura de planeamento de capacidade pura, também queremos saber que a mudança que estamos a fazer tem o efeito pretendido ao nível da aplicação ou a qualquer nível, aplicação de observação, protocolo, seja o que for que estamos a tentar mitigar. Então, o que fazemos para alavancar um sistema a que chamamos mina de carvão. Já publicámos e falámos sobre isso publicamente antes, mas a ideia de que existe basicamente tudo se passa como o que chamamos canário – canários na mina de carvão.
A questão que não há nada acontece globalmente de uma só vez, não importa quão terrível seja. Um mínimo de duas fases para algo sair. Por isso, colocamo-lo num subconjunto de infra-estruturas. Normalmente, a infraestrutura que está a experienciar o evento mais egregiamente ou é mais visível, validamos que ele faz o que esperamos e, em seguida, rapidamente o desenrolamos mais tarde. Desculpem, desenrolem, alargem e validem que o problema global resolve a nível global. Então, a mina de carvão e as canárias estão fortemente integradas com as suas métricas e sistemas de observação para que possa correlacionar-se rapidamente como, o que é isto? O que é que este canário está a fazer com as métricas agregadas que estou a observar? Então recebemos feedback em tempo real que, hey, a mudança que estamos fazendo é, de facto, abordar o problema.
Então isso é muito, muito útil. O que estamos a trabalhar neste momento e a preparar-nos para o lançamento interno e mais tarde, produziremos isto para os clientes e as suas alterações de configuração, é basicamente uma análise métrica totalmente automatizada. Então, atualmente, quando fazemos uma mudança como esta, é necessário que um ser humano se sentar lá e olhar para ela, certificar-se de que a coisa correta está a acontecer, e certificar-se de que as métricas com que está preocupado estão a mover-se 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 a dar é que, à medida que construímos cada vez mais visibilidade para o nosso ponto de venda, cada vez mais visibilidade, cada vez mais métricas, cada vez mais informações sobre o que está a acontecer, há cada vez mais para os seres humanos olharem, certo? E essa carga está a chegar ao ponto em que está demasiado alta. E então os seres humanos estão começando a cometer erros, certo? Porque há muitos gráficos para ver, demasiados gráficos para ver e as pessoas cansam-se e as pessoas são imperfeitas de qualquer forma. Por isso, estamos a lançar um sistema chamado birdwatcher, o que observa os canários basicamente que faz uma análise estatística sofisticada sobre as métricas, como quando as mudanças estão a acontecer 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 o canário é bom, está a fazer o que esperamos.
E também separadamente não está a fazer nada de mal que não esperamos, e isso, essa implementação irá prosseguir sem qualquer intervenção humana. Tão super entusiasmado com isso. Isso vai tornar a nossa capacidade de resposta ainda mais rápida e ainda mais segura. Portanto, essas são as principais coisas que consideramos quando estamos a falar de segurança, sendo capazes de fazer o problema desaparecer de forma rápida e segura. O último ponto que mencionei foi a redundância, que é relativamente auto-explicativa. Há um ponto-chave ou filosofia que potenciamos e implantamos que é basicamente um caminho duplo para muitas dessas mudanças, tantas quantas 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 infraestruturas em locais muito, muito díspares em todo o mundo.
A capacidade de atingir tudo com uma confiabilidade de cem por cento em poucos segundos é um conto de fadas. Como, isso não é algo que seja viável. Algo em algum lugar é sempre um problema. E não há realmente nada que você possa fazer sobre isso. Então, o que fazemos é basicamente juntar estas coisas de forma semelhante à segurança, à defesa em profundidade, certo? Por exemplo, juntamos estas duas coisas e, como é que isto realmente se parece, está a alavancar o caminho rápido. Vá bater o máximo que puder. E então tudo o que você perde, nós certificamo-nos de que temos um caminho confiável redundante que vamos continuar a tentar até que funcione, que é um pouco mais lento. Então, para colocar alguns números nisso, o caminho rápido vai tocar Nós vamos fazer uma mudança em aproximadamente 99,9% da nossa infraestrutura em menos de cinco segundos, certo?
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á a tentar até que seja bem-sucedido basicamente. Por isso, ao potenciarmos estes dois juntos, obtemos o melhor dos dois mundos. E se um desses subsistemas for completamente para baixo, 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 procuramos. Há outras coisas divertidas para nos certificarmos de que temos despedimentos. Como é que vocês arranquem estes sistemas? Como muitos sistemas sabem, os chatbots integraram-se, por isso é muito, muito fácil.
Qualquer pessoa pode fazê-lo a partir de qualquer lugar do mundo através do seu telefone. Muitas outras coisas têm APIs. Há uma ILC para muitos dos subsistemas. Portanto, garantir que não há apenas uma forma de iniciar estas tarefas é outro exemplo de como tentamos criar redundância para que possamos ter sempre essa agilidade operacional na ponta dos dedos, independentemente do que está a acontecer ou de que sistema em particular possa estar a ter um problema. Certificamo-nos de que temos controlo e a capacidade operacional de que precisamos. Muitas dessas coisas, sabem, 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 fluxos de trabalho de infraestrutura, como tirar uma máquina da produção e corrigir tudo até as mudanças de configuração do cliente. Tudo isso alavanca o mesmo sistema central que nós alimentamos e nos potenciamos agressivamente. Portanto, o produto que expomos aos nossos clientes é fiável e muito, muito sólido.
Andrew Johnson: Fantástico. Fantástico. Apreciem o Dave. E Marcel, acho que falou sobre as melhores práticas ou considerações que as equipas de segurança podem aplicar à sua prática. Apreciem essas dicas. Eu sei que vocês têm lidado com alguns exemplos realmente interessantes de dia zero na natureza para proteger Edgio e os nossos clientes. Tenho a certeza de que têm boas histórias e aplicações destas melhores práticas. Seria capaz de falar um pouco sobre isso?
Exemplos de Dia Zero: HTTP2/Reinício rápido
Dave Andrews: Sim, absolutamente. Acho que o mais pertinente ou mais recente, e foi interessante, é que, como referiu anteriormente, é o ataque HTTP2/Rapid Reset. Foi uma experiência muito interessante. Então, apenas para retransmitir da perspetiva de Edgio, há um pequeno blog que escrevemos sobre este tipo enquanto isso acontecia. O HTTP2/Rapid Reset foi um ataque de dia zero onde as pessoas perceberam que não só a implementação das bibliotecas de servidores do modo HTTP2 tinha tomado alguma coisa na RFC do HTTP2, a especificação, a especificação do protocolo como uma recomendação geral e basicamente codificava isso nas próprias bibliotecas. E esse foi o número de pedidos simultâneos que foram autorizados a ser, desculpem, os fluxos simultâneos que foram autorizados a estar em voo em uma determinada conexão, que estava na especificação, escrito como sendo uma centena.
Isso, juntamente com uma faceta interessante do h2, que é, sabem, a ideia de ser o multiplex – muitas 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. A questão que os atacantes procuram é algo que custa uma pequena quantia para o atacante e custa mais para o attackee, para a pessoa do outro lado E encontraram-no na reposição rápida do HTTP2. O que isso significava basicamente era que o atacante podia muito, muito rapidamente se enfiar como um único pacote iniciando uma solicitação e cancelando-a uma e outra vez e outra, como centenas daqueles em um único soquete desculpem, 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 que os CDNs fazem para ir buscar qualquer ativo que o invasor estivesse pedindo. E finalmente temos que registar que o pedido aconteceu. Portanto, o facto de os atacantes terem sido capazes de gerar essas iniciações e cancelamento das solicitações é muito, muito rapidamente. Basicamente, a maioria, como qualquer um que tenha sofrido esse ataque, é mais cara. 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 que correram, sabem, 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 fornecedores ao mesmo tempo. O que descobrimos quando começámos a falar com os outros fornecedores e a ser tipo, oh, quando viram isto? OH, foi exatamente o mesmo tempo em que o vimos, em que tropeçámos porque encontrámos o ataque. Identificámos o que estava a acontecer por causa da observabilidade de que Marcel está a falar. E começámos a criar mitigações, certo? Portanto, essa atenuação parece adicionar ainda mais observabilidade para chegar ao centro exatamente do que estava a acontecer e, em seguida, construir controlos operacionais que nos permitem ajustar uma resposta a ela.
Então o que isso realmente parecia foi, acompanhar quantas vezes qualquer cliente está redefinindo solicitações em um socket específico, e se a percentagem lá vai acima de um limiar pré-definido, termine essa conexão. Portanto, a ideia é basicamente não permitir que o atacante envie continuamente esses pedidos para colocar um limite nele 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 estava de facto a impedir que esses ataques se repetiam. Então tivemos pessoas da indústria a chegar e tipo, oh, vimos o blog. Na verdade, também fomos afetados por isso e estamos a trabalhar na divulgação responsável. Então, nós nos dobramos com um grupo da indústria com quem trabalhou como Vince, que faz parte do cert para passar pelo fluxo de divulgação responsável, certifique-se de que, neste caso, as pessoas que estavam a implementar bibliotecas HTTP2 ou servidores HPD tiveram tempo para gerar patches, implantar esses patches antes do, a vulnerabilidade era mais amplamente divulgada.
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, sabem, oh minha bondade, temos que atualizar esta biblioteca e estamos como 10 versões atrás porque não a atualizamos regularmente. Não foi como, na verdade, estamos, somos uma versão atrás, certo? Por exemplo, 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 o 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 os nossos clientes, mas com a indústria. Tipo, ei, isto é algo estranho que vimos que parece que não é nada específico do Edgio e, de facto, potencialmente mais aplicável. E descobriu-se que era.
Andrew Johnson: Isso é muito interessante. É uma espécie de fixe ver uma visão interna de vocês, a comunidade de segurança em todo o mundo trabalhando em conjunto para, para vocês, melhorar os resultados para todos. Marcel, queria acrescentar alguma coisa à volta disto?
Marcel Flores: Sim, eu só queria acrescentar uma nota que eu, penso eu, este exemplo foi interessante em que a observabilidade inicial que tínhamos mostrado com certeza comportamentos estranhos como Dave estava a descrever, certo? Esta interação de um 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 a acontecer aqui foi compreender que havia este desequilíbrio grave, certo? Que o número de pedidos que estávamos a ver versus o número de pedidos que estávamos a entregar aos clientes era distorcido, certo? E isso se destacou. E mesmo que essas fossem as duas métricas que tínhamos recolhido, não as tínhamos comparado exatamente dessa forma. Então, parte do resultado disto foi sentar-se e olhar para ele e dizer: Ei, o que, como podemos combinar a visibilidade que já temos em algo que é feito sob medida para detetar este problema? E conseguimos fazer exatamente isso e melhorar o alcance da nossa visibilidade olhando para os dados que já tínhamos através de uma lente ligeiramente diferente.
Andrew Johnson: Fantástico. Fantástico. É bom ter em mente. E obrigado por isso, Marcel. Sim, pessoal, então acho que estamos, estamos a terminar. Se, se houver alguma recomendação adicional que você queira compartilhar? Penso que cobrimos um nível elevado, alguns muito bons.
Recomendações para fortalecer a sua postura de segurança
Dave Andrews: Boa pergunta. Penso que uma recomendação geral é a higiene que é extremamente importante. Focando na sua observabilidade, acho que a coisa que chamaria é encontrar pessoas que possam 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 para impedir proativamente classes inteiras de ataques de afetar as pessoas. Então, encontrar pessoas que podem ajudar, certo? Como se houvesse um monte de ferramentas e tecnologia que construímos, que a comunidade tem disponível que podem tornar o seu trabalho mais fácil. Quando estamos a falar, sabem, geralmente as coisas na internet, um WAF é como, é o mais crítico, como o mais básico também, eu argumentaria o exemplo mais crítico de algo assim.
Dá-lhe a capacidade, se for implementado de forma adequada, dá-lhe a capacidade de combinar a agilidade e os elementos de segurança em conjunto. Então o Edgio WAF funciona em modo duplo, o que significa que você pode implantar novas regras na produção, nas máquinas reais que estão a obtê-lo, que estão a observar o tráfego. E podem ver o que está a acontecer. Um bom exemplo disso foi com o Log4j, que foi, sabem, voltar um pouco no tempo. Quando desenvolvemos a resposta a isso, somos capazes de desenvolver a regra muito, muito rapidamente e validá-la muito, muito rapidamente. Como estávamos a enviar atualizações de regras e a implementá-las no modo de alerta nas máquinas reais e ver que correspondiam aos ataques, mostrei aos nossos clientes que não estavam a ser atacados ou que estavam a ser atacados. E depois tomar uma decisão muito baseada em dados para permitir que essa regra passe para o modo de bloqueio e, na verdade, impedir que esses ataques o façam aos nossos clientes. Então combina todas essas coisas juntas, certo? Como velocidade de resposta, segurança, redundância e confiabilidade. Consiga pessoas que possam 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 a passar por isso é a chave para fechar essa porta sobre os atacantes. Por isso, com esses rapazes muito obrigado por se juntarem a nós. Eu também gostaria de agradecer ao público, e nós vamos vê-lo no próximo episódio. Obrigado.
