ThreatTank – Episódio 2 – Tendências de Ataque Trimestral

Uma Introdução ao ThreatTank – Episódio 2: Tendências de Ataque Trimestral

Tom Gorip: Bem-vindo ao ThreatTank, um podcast que aborda a mais recente inteligência sobre ameaças. Resposta a ameaças e insights sobre o cenário de segurança em todo o mundo. Sou o seu anfitrião, Tom Gorip, Vice-Presidente de Serviços de Segurança da Edgio, e hoje estou a juntar-me Richard Yew, diretor sénior de Gestão de Produto da Edgio Security Solutions, e Michael Grigshaw, diretor de Engenharia de Plataforma da Edgio.

Tom Gorip: Bem-vindo, Richard, Michael.

Richard Yew: Obrigado por me ter aqui novamente.

Tom Gorip: Este pode tornar-se um tema recorrente, Richard. Então, da última vez que me abri com uma pergunta sobre quebra-gelo e senti que tínhamos que continuar, mas encontrar uma não é fácil, certo?

Porque acho que estabelecemos uma barra sólida da última vez. Então, aqui está o meu quebra-gelo. E pelo que vale a pena, também não dei tempo para pensar nisso. Então, vou juntar-me a este. Mas aqui está uma pergunta. Vou perguntar-te primeiro, Michael. Vou colocá-los no local. Se tivessem de ficar presos num programa de televisão durante um mês, um mês inteiro, que programa escolheriam e porquê?

Michael Grimshaw – Tenho de admitir a primeira coisa que me vem à cabeça e nem sequer estava vivo na primeira execução disto seria provavelmente a Ilha de Gilligan porque a ideia de passar um mês inteiro numa ilha tropical, mesmo que tenha de usar o professor para descobrir como obter água corrente ou qualquer outra coisa assim. Uma ilha tropical agradável durante um mês não soa muito mal.

Tom Gorip: Que resposta. Adoro. Não, eu não vi a Ilha de Gilligan há muito tempo, e nem vou dizer isso em voz alta já faz muito tempo desde que assisti. É uma boa resposta. E vocês?

Richard Yew: OH, uau, isso é difícil. Sabem, tenho pensado bem, quero dizer, disse uma Peppa Pig como há qualquer outro programa de TV que tenha porcos, vocês sabem que vou manter o mesmo tema de porco, mas acho que vou parar com isso.

Acho que para mim, como o Hands Down Game of Thrones, como, quer dizer, eu estaria preso dentro de Game of Thrones, mas talvez eu tenha o primeiro dia ou o último dia, quem sabe? Mas, sim, quero dizer, vamos com isso.

Tom Gorip: É isso. Sim. Isso é corajoso.

Richard Yew: Sim. Isso é muito corajoso. Sim. Sou bastante audaz, cara.

Richard Yew: Provavelmente vou colocar a minha capa preta e ficar de pé numa parede e ver o que acontece.

Michael Grimshaw: Bem, Tom, deixem-me também dar-vos o inverso. Qualquer Game of Thrones e qualquer programa de cinema com tema de zombies estaria na minha não fazer parte de uma lista.

Tom Gorip: É uma boa resposta. Queres sobreviver, certo? Isso é justo.

Richard, homem, corajoso. A Guerra dos Tronos. Por isso, fiquei doente na semana passada, infelizmente. Tive a Covid, que era miserável. Mas eu cheguei a algumas reruns da Casa antiga. Então eu acho que sim, eu escolheria House. Eu definitivamente quero me sentar em algum diagnóstico e provavelmente dizer que não é lúpus. Só preciso de o dizer pelo menos uma vez.

Não é lúpus. Nunca é lúpus. Esse seria o meu programa durante um mês. Acho que seria um bom momento, pelo menos sei que a minha taxa de sobrevivência seria bastante elevada em comparação com a escolha de Richard ali.

Tom Gorip: Tudo bem. Por isso, não estamos aqui para falar de programas de TV.

Estamos aqui para falar de um novo relatório de tendências com o qual o Edgio está a sair, com o qual estou super entusiasmado. Estou a tirar um instantâneo do quarto trimestre e a olhar para todo o tipo de tendências. Esta é a primeira vez em muito tempo, em anos, eu diria que é uma espécie de renascimento deste relatório.

E estamos cobrindo todo o tipo de dados de métodos de solicitação, tendências ao longo do tempo, uh, tipos de mímica, todo o tipo de geolocalização, uh, e isso é bem, eu meio que trouxe vocês aqui hoje para falar, porque eu acho que há muitos insights interessantes de olhar para os dados desta maneira, acho que às vezes você pode olhar para conjuntos de dados.

Você é tipo, bem, então e? O que é que importa? Porquê? Porque é que estou a olhar para isto? Como podemos olhar para esta informação e extrapolar algum valor a partir dela? E então estou muito entusiasmado por conseguir o seu trabalho. Percepções. Então, para um tipo de categorias de alto nível de tópicos que tipo de vieram à mente que estariam novamente interessados em suas perspetivas sobre um deles era a arquitetura de aplicações, certo?

Arquitectura de Aplicação – O que observamos é importante

Tom Gorip: Se estamos a olhar para estes, este relatório, a pensar na nossa arquitetura, nas nossas aplicações, como estamos a aproveitar as nossas ferramentas para serem devidamente configuradas com base na arquitetura da nossa aplicação e também talvez alguma conformidade. Aspectos de, uh, como podemos usar essa informação para começar a pensar novamente, nossos aplicativos de uma maneira diferente.

Para começar, acho que a arquitetura de aplicações. Então, uma espécie de obter um quadro de referência aqui. Há dois pontos de dados neste relatório. Vejam os métodos de solicitação em tipos de mente, e há mais. Podemos definitivamente sentir-nos à vontade para, sabem, vocês viram que os relatórios têm acesso. Pode puxar o que tiver lá dentro.

Mas primeiro, o quê? Porque é que é importante olhar? Este tipo de coisas como métodos de solicitação em tipos mentais. Quero dizer, quando olho para o relatório pela primeira vez, era como nove mais de 98% dos pedidos para receber mensagens. O quê? Bem-vindo à Internet, certo? Por exemplo, porque é importante olhar para esses dados desta forma? O que acham?

Michael Grimshaw: Não, eu diria que algumas das grandes coisas que me vêm à cabeça é que o que você observa importa, o que você está olhando importa. Por isso, podemos falar de arquitetura e construção como novos aplicativos greenfield e toda a arquitetura sobre isso de um lado.

Mas a primeira coisa que eu obteria, e é o poder de relatórios como este e dados e informações como este, obviamente inteligência de ameaças. Eu acredito muito em fazer a sua arquitetura em torno de sua conformidade, suas necessidades de segurança, e realmente os requisitos não-funcionais é, sabem, a lógica de negócios da sua aplicação não é um pequeno conjunto, mas longe são os dias em que você pode se concentrar apenas na lógica de negócios e uma coisa, você tem que estar olhando para várias dimensões, como como você pode ajustar a sua observabilidade, como usar credenciais mais avançadas de infraestrutura e rotação de plataforma.

Posso falar, podemos falar durante dias sobre isso, mas o grande que se resume a isso é ter inteligência acionável para saber o que você está procurando. Então, a partir de um aplicativo, de ferramentas mencionadas, essa é uma das primeiras coisas que eu chamaria, compreendendo onde você estava, você sabe, quais são os vetores. O que os atores estatais estão a aproveitar o que os guiões de script e todos os outros estão a aproveitar é que precisam de vos informar do que estão a ver no que sabem, quer estejam a fazer, trimestralmente, sabem que estão a fazer exames, esperemos que estejam a fazer exames mais do que apenas trimestralmente, obviamente. Dependendo do seu perfil de conformidade, você precisa fazê-los no mínimo trimestralmente, mas espero que você esteja passando para mais um modelo DevSecOps shift Right, onde esteja continuamente digitalizando ou onde esteja continuamente monitorando a segurança da construção e da mobilidade.

Então a primeira coisa que eu chamaria são estes dados. Esta informação é importante de saber. O que você precisa para estar de olho mais de perto, o que você precisa para ajustar a sua pilha de observabilidade para procurar a sua pilha de observabilidade de segurança, e então inversamente no turno, certo? Está a prestar atenção a mais coisas e a mais vulnerabilidades potenciais que podem introduzir no seu código para se certificar de que não o fazem.

Vocês têm de estar de olho no vosso horizonte. Sempre que tivermos uma dessas conversas, vocês ouvirão muitas analogias, mas é como se estivessem a correr se estiverem numa maratona ou se estiverem a fazer corridas de fundo ou algo parecido, mantenham os olhos no horizonte para que depois de terem de mudar taticamente. De uma forma ou de outra por causa de um buraco, você conhece um rio ou algo assim. Não estamos a perder de vista os horizontes em que estamos a correr.

Richard Yew: Quer dizer, do outro modo, como se olhem para isto, certo?

É também quando se trata de arquiteturas de aplicações, sabem, quando olho para os dados, como disse Tom, a maioria dos pedidos pode ser imposta, mas sabem, é internet, certo? Mas eu acho que uma das coisas que você depara, é também quando você olha para os dados, como quantas solicitações, porque ele conta as histórias de tipo, quais são as conversas do conteúdo que estamos recebendo, certo?

Obviamente. Se você está executando muito espaço de aplicação, você sabe, especialmente, digamos que você tem um spa, certo? Como as suas arquiteturas primárias, certo? Vocês vão ver muitos posts. Vocês vão ver muitos métodos diferentes, certo? Se você pegar muito conteúdo gerado pelo usuário, você pode ver muitas postagens e colocar, certo? Portanto, é um bom colapso para ver. E também, dado que isto são dados de segurança, significa que estes dados vêm de um firewall de aplicação web, certo? Ele realmente vê quanto das cargas úteis que inspecionamos que realmente trips muito.

Então, neste caso, muitas vezes eu acerto. Mas também vemos uma quantidade bastante significativa dessas coisas vindo do post porque é aí que os pagamentos são carregados, por isso é muito, e realmente conta uma história sobre a superfície. As áreas de superfície do teu ataque, e diz-te que se olharmos para as distribuições do teu método de pedido, certo, qualquer coisa que receba qualquer ponto final em oposição, certo, vais ter uma área de superfície muito maior porque, sabem, o post é como, eu uso uma analogia e as pessoas dizem-me que é burro, está na casa, como o pedido do correio, é como o teu lixo e os teus sanitários,

Tipos de mímica

Tom Gorip: Adoro o que estás a dizer é que coisas como o método de pedido começam a pintar uma imagem. Conte uma história sobre a sua aplicação, como está a ser usada, como está a ser atacada, onde pode estar vulnerável. Dá-lhe uma boa perspetiva. E isso também leva ao tipo de mímica.

Uma coisa que achei interessante, adoraria que os vossos rapazes pensassem nisto, é o que vimos que isto é um, é uma grande quantidade, 76% desses blocos. Mais uma vez, esta atividade WAF é, era o tipo mime de aplicação json. Portanto, muita prevenção ao redor. O que isso nos diz sobre a Internet como um todo, como os aplicativos estão sendo desenvolvidos e arquitetados?

Richard Yew: Quero dizer, vou começar com isso. Como ele basicamente diz-lhe de onde vêm os junks, certo? Em certo sentido, o json faz sentido porque, como, a maioria do ponto final da API, uh. UH, como repousante, mesmo nem mesmo repousante, como o Grapqql, dá-lhe o nome, certo? Contém como cargas de pagamento de json. HUM, certo. Portanto, isto é par para o curso, na minha opinião, não deve ser nada surpreendente para muitas organizações, certo?

Obviamente também veem como cargas úteis vindas de tipo de conteúdo HTML, uh, veem um monte como do XML, certo? Então, você definitivamente quer uma coisa quando se trata de projetar e mecanismos de segurança, certo? Você não quer apenas olhar para o json, mas você só quer, porque eu vi certos produtos de segurança , eles só podem analisar o exemplo XML.

Que eles não têm capacidade de analisar o json. É como, se você não puder analisar o json, não pode olhar para os payloads. Então, você quer ter certeza de que tem a capacidade de usar o json. Tem de se certificar de que o seu parser está à altura. Quer dizer, adivinhem? Porque a maior parte passou para, para um WAV é gostar de explorar o analisador.

Então eles estão enviando cargas úteis através de um formato de codificação especial ou como eles, eles iriam enviá-lo em um formato como. Mesmo às vezes apenas mudam. Este é um json, mas mudou o formato para multi-parte, seja o que for. E a web parou de analisar porque apenas olhou para cabeçalhos. OH, isto não é json. Portanto, não estou a analisar.

Então, é assim que se obtém a carga útil para deslizar. Portanto, é definitivamente algo que você quer ser capaz de fazer anotações como, uau, json, é o mais popular. Também queremos ver quais são alguns dos mais obscuros. Aqueles e itens ali que quero salientar, mas vou guardá-los para mais tarde.

Michael Grimshaw: Acho que Richard fez um grande ponto é que apenas um X e nenhum analisador não o cobre na era moderna do desenvolvimento web. Não acho surpreendente que as cargas úteis do aplicativo json e json representem uma percentagem tão grande porque no desenvolvimento web moderno, o json está no mundo, sabem, e nem sequer é apenas desenvolvimento web.

Vocês olham, por exemplo, para alguém que deve nuvem. UH, quer esteja a falar, sobre o CloudFormation e a AWS e outros, sabem, deixem-me usar porque a AWS é a maior. Não foi há muito tempo, quatro ou cinco, talvez um pouco mais de anos atrás. Não me lembro da data exata, mas o CloudFormation era inteiramente XML e depois movido para baseado em JSON e isso assumiu totalmente.

Portanto, é infraestrutura de desenvolvimento web, json. Sim, você tem que ser capaz de analisar tanto em json quanto em XML, mas o ponto de Richard também é ainda mais esotérico e o mais importante é que você tem que ser capaz de analisar todos os dados.

Richard Yew: Sim. Falando de valores discrepantes quando olho para os dados, certo, olho sempre para os pontos de dados mais pequenos, como os 1% ou os 0,5% ou algo que se destacou logo no relatório é que temos 0,14. Assim, 0,14% da quantidade de dados semelhante. Outras informações não-caracterizadas, certo? Mas pode parecer estranho, mas quando se fala de milhares de milhões de dados por mês, quero dizer, 0,14% dos mil milhões, é bastante. E alguns desses tipos de conteúdo são como imagens. JavaScript e outros, como você pensaria historicamente que, oh, esses são conteúdos estáticos, como aqueles são altamente cacheáveis. Por que você colocaria o WAV na frente dos seus JPEGs?

Sabem, como por que têm muitas imagens, certo? O que é que fazem isso? Bem, deixem-me dizer-vos isso, certo? Há esta coisa chamada movimento lateral em segurança, certo? É como se esses JPEGs. Por exemplo, a menos que você os coloque no armazenamento, como no limite, à direita, armazenamento na rede, e onde ele é apenas 100 por cento de serviço, qualquer uma dessas solicitações vai de volta aos seus níveis da web, você sabe, como em seus ambientes, se mesmo apenas 0,1 por cento dessas solicitações voltar às suas origens, isso significa que o invasor pode enviar cargas úteis, seja na forma de cabeçalhos, cookie, cookies, etc. Então, se você estiver usando o mesmo backend para o seu, digamos, seu, você sabe, seu HTML e seu jpeg, como o jpeg, certo?

Você pode ser suscetível a movimentos laterais porque eles estão dizendo: Ei, você sabe, tipo, isto é apenas domínio de imagem. Por exemplo, talvez você não precise proteger isso. Muitas pessoas são como, por que eu colocaria um WAF? Desperdiçam o meu dinheiro, sabem, gostam de colocar as proteções numa coisa maioritariamente estática. E, novamente, isto é algo a notar.

Queremos sempre encontrar falhas porque, como defensor, como alguém que é equipa azul, temos de estar sempre certos. O atacante só precisa de estar certo uma vez, certo? Sabem, quem sabe, como as primeiras cargas úteis no primeiro pedido de json que é encaminhado para as origens criou o backdoor. Pode acontecer.

Tom Gorip: Sim. 100 por cento e o que eu adoro é que vocês também estão a ir com isto, é que ele falou primeiro sobre pintar uma imagem ou contar uma história sobre a sua aplicação. Portanto, obter uma boa compreensão da arquitetura do seu aplicativo. E então onde estão a aplicar os vossos controlos?

Porque para o seu ponto em que você pensa que talvez seja o menos vulnerável pode ser essa via de abordagem quando estamos olhando, hum, e outra vez, isso também está dentro do relatório. Mas quando estamos a olhar para as categorias de ataques mitigados, 45% eram regras de controlo de acesso, o que significa prevenção de pedidos postados.

Se o seu aplicativo não aceitar mensagens, como limitar o cenário de ameaças, limite onde os invasores podem fazer cutucadas e prod no seu aplicativo aplicando regras de controle de acesso. Se você não aceitar a aplicação, Jason, bloqueá-la. Certo. Previna-a. Não há razão para permitir que isso aconteça em 1º lugar.

E então você traz um bom ponto do tipo, olhando para o tipo de outliers, as partes menores do aplicativo. Adoro esse processo de pensamento. Então, ao longo dessas linhas, vamos continuar a puxar um pouco esse fio. Portanto, 45% são regras de controle de acesso onde bloqueámos 37%. UH, somos conjuntos de regras geridos.

Então, isso é toda a sua inteligência de ameaças e o seu script entre sites esse tipo de imposto. E então 19% eram regras personalizadas vendo isso e pensando como defesa de camadas. Foi o que eu pensei que, à medida que os pedidos entram, eles estão a passar por estes filtros que precisam de estar a contemplar, certo?

Uma abordagem de Defesa em Camadas

Tom Gorip: Quando você implementa WAF ou controles de segurança em seu aplicativo, você precisa entender sua arquitetura e ajustar suas ferramentas de segurança para corresponder a isso. Para, novamente, limitar o seu cenário de ameaças, mas depois também precisam de camadas, certo?

Michael Grimshaw: Você precisa de camadas. E uma das coisas que eu quero, e quero falar com camadas, mas acho que é disso que estamos a falar aqui é que realmente ilumina a importância do ciclo de feedback entre o vosso desenvolvimento, os vossos programadores de funcionalidades, o vosso SDLC, os vossos arquitetos e a vossa equipa de segurança, porque se a vossa equipa de segurança ou o vosso WAF ou o vosso SOC ou o que estiver a voar cego, sabem, sabem, sabem, sabem, sabem, sabem, json?

Não publicamos? O que é que fazemos? Será essa, essa comunicação, esse ciclo de feedback? Você pode economizar dinheiro até que a FTE desperdiçou tempo, economizar dinheiro em ferramentas, apenas um ciclo de feedback apertado entre os seus desenvolvedores, os seus arquitetos e o seu, e a sua equipa de segurança faz toda a diferença no mundo.

Richard Yew: Quando se trata de camadas, eu sempre digo, não, vou trazer meta palavra-chave, sabem, como defesa em profundidade. Vocês sabem, como, eu realmente acho que precisamos, temos que ter uma mentalidade que, realmente tem ordem para os seus termos. Mas talvez eu esteja errado.

Talvez haja um filtro de água de camada única, sabem, eles estão a usar carbonos de coco como, por exemplo, o que quer que o nomeie. Certo. Mas geralmente, em geral, quando olhamos para valores mobiliários, certo? Nenhuma camada pode ser considerada uma bala mágica. Como, por exemplo, só porque você tem o gerenciamento de bots não significa que você queira esperar que o gerenciamento de bots capture tudo, desde aplicativos, como DDoS até aquisições de contas.

Cada mecanismo funciona em conjunto. E a maneira como você está tentando colocá-lo, como você sabe, como. OK. Eficiente o mais possível. Por exemplo, estamos a tomar 45% de excesso de regras. Gosto de lhe chamar de LCA. Quer dizer, isto é apenas, é LCA, certo? É que a LCA normalmente é executada na nossa primeira camada. E há uma razão por trás disso porque é barato correr.

É apenas um monte de IPs, país, o que quer que seja. UH, ASN, assinaturas JA3, certo? Você corre para trás porque é uma assinatura estática que qualquer coisa que viole essas coisas. Imediatamente se afasta do futuro, como se estejamos segundo sub milisegundos, sabe, certo? São as nossas camadas inteiras, as pistas plurais em sub-milissegundos.

Mas sabem, como querem ser capazes de se livrar de tanta coisa do lixo, certo? E eu costumava ter um amigo a trabalhar na indústria é como se ele me dissesse, certo, isto é o que chamamos de encolhimento do palheiro. Quer que você queira receber um monte de pedidos semelhantes, não é? E você tenta encontrar o ataque.

É tipo, bem, você está tentando encontrar aquela única solicitação de HTTP que está carregando essa carga ruim e que resulta em uma violação. Então, você está procurando uma necessidade de um palheiro. Portanto, ser capaz de rapidamente amarrar o palheiro, remover o máximo possível dessas camadas frontais para que as camadas mais sofisticadas possam processar.

Por dados adicionais, o que seria muito útil novamente, remonta ao facto de não estarmos apenas a executar a defesa do perímetro, certo? É só porque vocês cruzam, vocês desrompem a parede. Não quer dizer que haja, vocês deveriam ter torres de vigia, certo? De facto, todo o conceito de defesa em profundidade é uma estratégia militar que veio dos romanos à medida que expandiam os seus territórios ao ponto de se tornar um império.

Não é possível ser apenas paredes ao redor e ter certeza de que você só depende dos outros perímetros para derrotar o ataque. É por isso que. Temos uma defesa em camadas.

Michael Grimshaw: Absolutamente. E acho que podemos ter mencionado isto, abordámos isto numa discussão anterior, Richard. Eu gosto do exemplo de imunologia aqui é se a sua saúde é dependente de um ambiente estéril, você é um homem morto.

Não se trata de evitar, não se trata de ter um ambiente de isolamento e tudo o que está dentro do seu estéril. Trata-se de construir imunidade. E a única maneira de perceber que é assim que você está livre de patógenos é desenvolver imunidade a eles e uma abordagem em camadas defensivas é necessária para isso.

É como você. Sim, você precisa dos melhores firewalls de rede. Vocês sabem, vocês precisam de um perímetro forte. Mas adivinhem? Isso vai ser violado. Quero dizer, no mundo dos atores estatais e onde o mundo inteiro está, é potencialmente uma ameaça. Efetivamente, você precisa apenas de planear que o seu perímetro vai ser violado.

Então, uma vez que eles fazem isso, então qual é a próxima camada? E a próxima camada depois disso, e a próxima camada depois disso. E então como você está monitorando isso e fingerprinting esses tipos de violações para que você saiba o que eles estão acontecendo. Sim, é imperativo

Arquitectura distribuída

Tom Gorip: Isso é interessante, e por alguma razão, há a pensar em como é que uma arquitetura distribuída se joga nisso? Porque eu posso ver uma espécie de duas extremidades do espetro aqui. Você pode olhar para ele e olhar para o risco, você está adicionando entorse, mas então você também pode. UH, olhem para ele e, uh, trazendo mais valor. Distribuindo as cargas de trabalho em várias regiões ou locais, permitindo mais disponibilidade.

Então, onde é que vocês veem isso a tocar?

Michael Grimshaw: Absolutamente. Vivemos no mundo da arquitetura distribuída. Quando você tem uma pegada global, bem. Sabem, mais de 300 pontos de presença em todo o mundo. Estamos numa era de computação paralela distribuída em massa, e não somos apenas nós. Quero dizer, hum, isto remonta bem mais de 20 anos, mas esta é a essência do desenvolvimento web. Infra-estrutura da Web. Você tem que assumir que está distribuído. Que você esteja correndo massivamente em paralelo e onde, o que move a agulha aqui de uma segurança, de um suporte, e de um suporte de custo é a primeira coisa que eu chamaria para fora é evitar a fuga de flocos de neve, e isso também se relaciona com a conformidade, que vamos chegar aqui em um pouco é que, se você estiver executando massivamente paralelo, distribuído, você precisa que sua infraestrutura seja o mais semelhante possível com essa arquitetura distribuída. Um, um, um, porque quando você está falando com seus auditores, você pode afirmar, você pode atestar.

Michael Grimshaw: Sim, nós só temos que realmente olhar para um deles porque este é um cortador de biscoitos em cada, você sabe, nós temos que olhar, você sabe, e seus auditores vão prová-lo. Eles não vão apenas dar um exemplo e correr com isso. Você pode dar uma olhada em qualquer um dos nossos pontos globais de presença e eles são basicamente exatamente o mesmo cortador de biscoitos um após o outro que ajuda a segurança.

Então, você tem basicamente o mesmo modelo que você está indo como você está, como você está trabalhando em suas camadas e rolando suas camadas um, mas também como você está rastreando, digitalizando e observando. Essa seria uma das grandes coisas de que eu falaria tanto quanto a arquitetura distribuída e a razão pela qual eu estava mencionando que com conformidade é porque se você estiver em um sistema distribuído massivamente, seus auditores não vão querer testar e auditar cada um se eles puderem validar e verificar e você pode afirmar que eles estão corretos. Exatamente a mesma arquitetura, eles são concorrentes uns dos outros.

Tom Gorip: É mais fácil dizer do que fazer, certo? Especialmente ao falar de uma arquitetura distribuída no nosso cenário, certo? Não estamos falando de implantar um monte de instâncias do EC2 que vêm de uma imagem dourada em algum lugar.

Estamos a falar de hardware. Certo. De certa forma. E como é que operacionalizam algo assim?

Michael Grimshaw: Este é um ponto excelente e excelente. E onde isso chega a um, é também uma abordagem multi-camada a isso. Não apenas a segurança que vem de você, de sua aquisição e de sua equipe de gestão do ciclo de vida, você precisa estar alinhado nisso porque um bom exemplo, a razão pela qual me permite obter o Kubernetes é um ótimo exemplo.

É distribuído em paralelo, não distribuído globalmente, mas você não vai executar um cluster do Kubernetes em todo o mundo. Mas o Kubernetes tem um ótimo exemplo disso é que você tem problemas no Kubernetes. Se você tem um monte de servidores que têm drivers diferentes ou diferentes, sabe, nick cards diferentes ou hardware diferente, você basicamente não pode executar o Kubernetes.

É por isso que, como eu disse, trabalhar com a gestão do seu ciclo de vida e com a sua equipa de compras para comoditizar a sua infraestrutura. Essa é a ponta da lança na ponta da lança. Queremos que o seu hardware seja o mais semelhante possível um ao outro. Agora, deixem-me chamar a atenção para um grande risco que experimentámos recentemente durante a Covid é o problema que encontrámos com a logística e o enorme choque para o espaço de distribuição global chegou ao local onde vocês, mesmo que estivessem a utilizar hardware de cortador de biscoitos comoditizados antes da Covid com os atrasos no transporte e transporte e logística.

Michael Grimshaw: De conseguir obter o mesmo tipo de chipsets ou qualquer outra coisa assim e não é só você, são as pessoas que você compra hardware de seus fornecedores, etc. É uma espécie de bola de curveball grande que traz para cima a segunda camada onde você tem que se adaptar e que é sobre quando você chega à imagem e o software real que você está executando nele, em primeiro lugar, como o seu hipervisor ou o seu sistema operacional ou o seu hipervisor?

Essa é a próxima camada de onde, mesmo que não seja completamente uniforme por baixo, queremos chegar lá o mais perto possível. A próxima camada é torná-la tão cortadora de biscoitos e uniforme na sua imagem e na sua camada de hipervisor do sistema operacional. E a partir daí, uma abordagem semelhante com aplicações.

Você quer obter isso o mais padronizado possível de segurança para custos por um monte de razões.

Richard Yew: Sabem, vou dizer-vos como quando se trata de aplicações. Certo, sabem, disputado, eu sei que provavelmente é contrário à crença popular, e isso pode ser um pouco contra-intuitivo porque estamos a pensar em arquitetura bem distribuída.

Por isso, estamos a tirar dos servidores virtuais centralizados, dos ambientes de nuvem, e estamos distribuídos por todo o mundo. E se eu vos disser que ter uma arquitetura distribuída torna a vossa superfície de ataque mais pequena? Parece meio estranho. Parece um pouco, mas, mas pensem assim, certo?

Ao ter distribuído, e é por isso que eu acho que é muito importante quando você está projetando aplicações, especialmente estamos falando de site, certo? Vocês não, projetam e o que eu acho um erro comum, e isso é segurança limítrofe. Então, se eu me desviar um pouco do assunto é que eu acho que há um erro em que eu vi pessoas, clientes, organizações, eles vão projetar os aplicativos com base em uma arquitetura centralizada e depois tentar executá-lo na plataforma distribuída como A, CDN, então você tem que criar muita otimização ainda como, Oh, o que precisa ser enviado, sabem, depois do fato para a lógica, mas é chamado design moderno?

É realmente projetar aplicações com arquiteturas distribuídas em mente. Seria como, por exemplo, você está acostumado a processar muitas lógicas em um local centralizado. Basta usar o CDN para armazenar em cache o seu jpeg e os seus ficheiros estáticos, etc. Mas que tal enviar algumas das lógicas?

Digamos que você apenas tenha um exemplo muito simples, como as suas redirecionamentos, certo? Você como a sua infraestrutura centralizada original vai fazer redirecionamentos para um cliente. E se você tiver dezenas de milhares de redirecionamentos ligados? Certo. HUM, que tal mudar essas lógicas para a borda?

Que tal mudar essas coisas? E ao fazer isso, certo, quando eu digo superfície de ataque, certo, você está, mudando essa lógica para a borda, certo, você está reduzindo as cargas, você está reduzindo a probabilidade de falha em uma central, como, como arquiteturas, por ter descarregado parte disso, sabe, segurança ao ar livre é o que a CIA, certo?

Richard Yew: Estamos a falar da parte da disponibilidade. É muito importante. Então eu diria movendo muitos desses mecanismos, incluindo mecanismos de segurança. Então, se você for capaz de filtrar novamente, encolher o palheiro do ataque na borda externa dos perímetros, certo, você é suscetível, menos vulnerabilidade no seu centralizado, você sabe, uma nuvem ou hardware semelhante, espero que não mais.

Richard Yew: Vocês 2024, sabem, mas hardware, mas basicamente chamamos a infraestrutura de origem e isso é muito importante. Posso dizer que há tantas outras coisas que podemos fazer porque estamos obviamente à beira daquilo que estamos a implementar muitas tecnologias e vou dizer-vos, cara, como fazer apenas a contagem distribuída.

Em cerca de 1 milissegundo e tendo todos os servidores, como, por exemplo, tudo bem, que os dados, é uma dor, sabem, quando estão a tentar sincronizar o número de pedidos que contam por segundos em todas as infraestruturas, uh, dentro de um pop, certo? HUM, mas eu, acho que é algo de que queremos fazer uso.

Richard Yew: Então, então, em vez de ter apenas um cérebro central, como, uh, lógica na sua, na sua arquitetura centralizada. Começou talvez a dividi-lo assim como os humanos, sabem, os cérebros humanos são arquiteturas tecnicamente distribuídas. Você tem o seu cérebro e você tem o seu cérebro de lagarto. E adivinhem? Porque, porque quando tocas algo quente, não vais ter tempo para reagir.

Richard Yew: Se essas coisas têm que passar por um cérebro central. Você tem que se queimar antes de puxar para trás, certo? É por isso que, por assim dizer, começar a pensar sobre o que é um novo design de arquitetura. Talvez, em vez de fazer aprendizado de máquina e treinamento e tudo no centralizado, você faça uma conferência na borda e depois faça um treinamento em locais centralizados.

Mais uma vez, volta a gostar. De certa forma, você está realmente reduzindo um pouco a vulnerabilidade e tornando todo o seu sistema mais robusto de uma perspetiva de segurança.

Michael Grimshaw: Sim. Sim, e esta coisa diz perfeitamente o que estávamos a falar apenas de camadas é porque ao nos afastarmos de uma abordagem centralizada, um, um, ou do que estávamos a falar também com imunologia, afastando-nos de uma abordagem centralizada, um, um.

Você, se, quando for atacado e for desfeito, hum, a quantidade de dados ou, ou, ou a exposição que você tem é tremendamente limitada, então não é um booleano completo, um, estou protegido ou não? Quando tudo está centralizado. Tudo bem. Se eles estiverem dentro e tiverem acesso aos dados, eles terão acesso aos dados, torná-los distribuídos.

OK. Talvez, talvez uma região ou um subconjunto ou um subsistema. Um atacante pode aproveitar um dia zero ou o que quer que seja e entrar, mas não tem todo o seu sistema. E também é uma coisa de resiliência porque não estamos a perder todo o córtex cerebral de uma só vez.

Richard Yew: A propósito, como, o bot da Lindsay simplesmente me verificou e, uh, acho que usei uma analogia má. UH, humano é, acho, acho que nós, não temos cérebros e outros lugares, mas eu deveria ter, eu deveria ter dito que é um polvo. Um polvo tem como cérebros e todos os braços. Sim. Ou seja, essa é uma verdadeira arquitetura distribuída.

Geolocalização – Onde estamos a bloquear a maioria dos ataques?

Tom Gorip: Sim, isso é justo. Isso é bom. Portanto, ficar ao longo das linhas da arquitetura distribuída, talvez puxando em conformidade um pouco aqui. Uma das estatísticas que eu pensava ser. Isto foi muito interessante para mim, pelo menos para ver no papel, eu estava a olhar para geolocalização. Então, onde estamos a bloquear ataques dos cinco países mais importantes?

Tudo bem. Eu obtenho os cinco países que mais me foram: A França, a Alemanha, a Rússia e a Chechénia. O que eu achei super interessante aqui é pelo que vale a pena saber que há muitas APTs que ficam sem a China. Eles não estão na lista. Não na lista, o que eu achei interessante quando pensamos em geolocalização.

Acho que muitas pessoas se voltam para delimitação geográfica. Ei, deixem-me bloquear em países de que eu sei que provavelmente serão atacados, mas 26%. O hater número um era dos EUA. Tipo, o que é que isso vos diz? Também acho que estou a pensar nisso do ponto de vista da conformidade. Como é que o que é geofencing como em, sabem, 2023, 2024, é aqui que estamos agora.

Richard Yew – Quero dizer, minha opinião, certo, eu sei que temos, como, cada cliente, sabe, quando embarcamos, falamos sobre controle de exportação, e temos que, tipo, fazer, tipo, esses controles com, tipo, geofencing, sinto que algumas dessas coisas, alguns desses requisitos para serem revisitados, já que eu sei que pode não ser algo que todos querem ouvir, especialmente se vocês correrem com antecedência, mas se estiverem dando desculpas por uma dor de cabeça, mas se eu estou a tempo, se eu estou a fazer isso, se eu estou a pedir desculpas por uma vez em que eu estou a fazer? E tão fácil de simplesmente girar a VM em todo o lado. Como, lembro-me que, quando estávamos a olhar para a Black Hat no ano passado, estávamos a ver distribuições como o ISP para um ataque DDoS anónimo no Sudão, certo?

Richard Yew: Há como, eles estão usando um provedor de hospedagem. Em todo o lado. Sabemos de onde eles vêm, como eles vêm deste país específico, Europa de Leste, sabem, como é aí que a organização está, certo? Mas, então o ataque vem de qualquer lugar, como hoje em dia. Então é como, pois, você bloqueia um hacker chinês por Joe que esgrima a China? Será que isso funciona mesmo hoje em dia? Certo?

Michael Grimshaw: Não, mas tem toda a razão. E, historicamente, a China é bem conhecida por usar essas VPNs de abordagem muito própria e, e realmente ofuscando a origem de onde está o ataque, hum, obviamente com a Rússia, elas usam lá há tanto de um país adulto, como sabem, quase o estado, quase incentivando atores individuais na Rússia a participar dela.

A estrutura de comando e controlo da China é um pouco menos do que dizer mob ou, ou, um, um, orientado que se vê como a Rússia ou, ou, ou Cheshire e coisas assim foram descentralizadas. Exatamente. Bom, bom chamamento. HUM, mas sim, e Richard, eu acho que você está certo. Precisamos de revisitar isto, mas vão haver clientes e vão haver segmentos de mercado.

E verticais que têm requisitos regulamentares. Então, e um dos grandes com quem não se mexe é o Office of Foreign Asset Control, OFAT. E é aí que a delimitação geográfica e com, como especialmente qualquer um dos serviços financeiros, indústria bancária, um, certificando-se de que, sabem, o seu banco ou os seus serviços financeiros não estão disponíveis para a Coreia do Norte, por exemplo, ou para o Irão e outros lugares nas listas da lista.

A delimitação geográfica ainda é importante, especialmente para os requisitos regulamentares. Precisamos de revisitar esses. E, e nós precisamos, um, de facto, isto recentemente surgiu na Ucrânia onde, um, um, uh, foi chamado isso, que o forte russo, enquanto, [00:39:00] Starlink usa geolocalização. Para evitar que seja usado na Rússia, a Rússia opera soldados russos e operadores estão, estão a utilizá-lo, uh, de outros países em, uh, território ucraniano ocupado.

A lista é longa sobre uso duplo. Materiais de dupla utilização, coisas como essas que podem ser usadas para fins civis e militares e como isso é muitas vezes proveniente de países terceiros e isso é a mesma coisa que é verdade aqui, mas ainda há linhas reguladoras absolutamente duras. Alguns clientes têm que lidar com ou delimitá-los muito.

Richard Yew: Tens razão. É apenas uma corrida às armas. Acho que o ponto é que, enquanto estamos a falar de arquitetura distribuída, falámos sobre como é importante que os nossos clientes usem isso para nos proteger. Mas, tal como o Mike e eu dissemos, ambos os atacantes estão a usar arquiteturas distribuídas.

Richard Yew: Quer dizer, eles são, bem, quero dizer, é meio engraçado, esse foi o ponto principal do DDoS. Certo? Quer dizer, é de onde vem o D.

Tom Gorip: Sim, isso é bom. Sabem, estou desapontado por estar a ficar sem tempo porque acho que podemos gastar provavelmente mais 20 minutos só neste tópico.

Pensamentos e recomendações finais

Tom Gorip: Mas como estamos a correr um tempo, eu gostaria de ouvir, como sabem, a pensar neste relatório, a pensar em alguns dos pontos de dados de que falamos aqui. Da arquitetura de aplicações à conformidade, delimitação geográfica, todo o jogo. Adoro ouvir os vossos pensamentos e recomendações ao público.

Como, o que devemos estar a olhar? Como podem proteger-se melhor?

Michael Grimshaw: Sim, adoro este relatório. Sabem, quero trazê-lo de volta e falar sobre o relatório. Já falamos de muitas coisas, mas uma das coisas que, e talvez isso seja porque estou a passar. O que uma auditoria de PCI neste momento é uma das coisas que eu adoro neste relatório está em duas coisas que vêm à mente, hum, em torno de onde este relatório e essas abordagens ajudam na sua segurança e, especialmente, na verdade, a sua estatura de conformidade está em PCI. Um dos requisitos do PCI é estabelecer um processo para identificar vulnerabilidades de segurança de vulnerabilidade usando fontes externas respeitáveis para obter informações e atribuir uma classificação de risco. Agora, este relatório não dá exatamente um CVEs, mas isso é parte novamente para colocar em camadas a sua abordagem de auditoria é que eu gostaria, sabem, adoro pegar num relatório como este com especificidades de vulnerabilidades do sistema operativo ou mudar para a esquerda como uma base de dados de vulnerabilidade nesse contexto.

Michael Grimshaw: E ser capaz de montar uma imagem inteira para os nossos auditores, por um lado, e depois outra exigência da PCI é garantir que você e eu estamos focados apenas no PCI. O ISO está a uma série de outros regimes. Mas a outra coisa é que é importante ter os seus funcionários treinados e atualizados sobre o cenário de segurança e como evitar isso.

E sim, você faz o treinamento em uma base anual. Vocês sabem, vocês precisam fazer treinamento quando alguém é contratado. OK. Todos os anos depois, mas relatórios como este, isto é absolutamente algo que eu iria passar por todos os meus funcionários e em toda a empresa apenas para aumentar a consciência de segurança, ajuda com a sua conformidade, ajuda com a sua segurança. Sou um grande fã.

Tom Gorip: É um grande conselho. Adoro isso. E você, Richard?

Richard Yew: Eu vou dizer definitivamente como, sabem, às vezes ter a visibilidade é muito importante. E eu diria para tornar as coisas mais fáceis, certo? Seria bom ter este tipo de visibilidade em todos os aplicativos, pelo menos o que estamos falando de aplicativos voltados para o público, porque não vamos olhar para todos os seus endpoints na gestão, como seus laptops e Macs, mas pelo menos podemos ver como o que está acontecendo e porque acredito firmemente que você precisa ter um único painel de visão para basicamente tudo como a internet que está entrando e saindo daqui.

Como estamos a falar de todas as solicitações de HTTP, cada solicitação externa, dentro e fora da rede precisa de ser catalogada e ser ótima. Por exemplo, se todos eles são recolhidos e podem ser reportados sob uma visão consolidada como o que falamos aqui, acho que também vai ajudar a facilitar a sua conformidade, especialmente quando se trata de fornecer provas, etc.

Então. OK. Mais uma vez, a visibilidade é importante, certo? Sabem, se olharem para as três, bem, na verdade cinco fases como uma estrutura de segurança NIST, certo? Quero dizer, que há que no lado esquerdo, há apenas um texto como as predições e então você tem que responder, certo? Mas, sabem, tendo a capacidade de ter visibilidade, a deteção é muito importante.

Não se pode mitigar o que se pode ver.

Tom Gorup: Sim, sim. Eu sempre igualo postura de segurança, visibilidade, exposições e ameaças. Não posso proteger o que não consigo ver. Preciso de compreender onde estão as minhas fraquezas, e preciso de compreender como estou a ser atacado. São os três que realmente se juntam para definir a sua postura de segurança.

E ficou um pouco interessante também sobre como partilhar isto com outras pessoas no negócio. Um dos mergulhos profundos que fazemos no relatório, bem como investigar a passagem de diretórios, foi praticamente o tipo número um de ataque que vemos ainda muito proeminente na Internet hoje.

Agora estamos a proteger contra ela, mas isso não significa que as aplicações não sejam vulneráveis a ela. E garantir que os seus engenheiros ou desenvolvedores entendam como este ataque pode ser usado contra você é uma ótima maneira de garantir que você está construindo código seguro desde o início. E o que eu adoro o que falámos hoje é pensar na arquitetura de aplicações, não apenas na arquitetura de aplicações, mas também no negócio e como funciona.

Então, ao usar isso para informar suas ferramentas de segurança, certo? Então você tem a sua arquitetura de aplicação de que tipos de pedidos eu espero ver? Que tipos de mímica, mas também onde é que a minha empresa é capaz de operar e aplicar esses tipos e colocá-los todos como parte dos controles em suas ferramentas de segurança?

Portanto, acho que é isso que me entusiasma no relatório não é apenas olhar para os dados, mas também dedicar tempo a pensar, como, como posso usar esta informação para pensar sobre o mundo um pouco diferente e talvez usar isso para informar o meu ferramentas de segurança para colocar mais controlos, restrições, impedir que o meu negócio seja derrubado. Sabem, no final do dia, é isso que estamos aqui a fazer é proteger o negócio, permitir que ele lhe dê a liberdade de manobra para ganhar dinheiro para os constituintes e trazer valor para os nossos clientes. Muito bom. Portanto, é tudo o que temos para hoje. Obrigado a todos por se juntarem ao ThreatTank.

Se quiser manter-se atualizado com a mais recente inteligência de ameaças do Edgio, vá para o edg.io. Isso é o edg dot io e assine, você sabe, você vai ter mais Intel à medida que ele sai. Michael, Richard adorava a conversa. Sinto que, novamente, poderíamos ter ido pelo menos mais 45 minutos. Isto foi ótimo.

Tom Gorip: Eu aprecio muito o seu tempo.

Richard Yew: Sim. Sim. Obrigado por nos ter aqui. Obrigado pelo grande envolvimento e discussões.

Michael Grimshaw: Obrigado pela grande informação, Tom. Sim. Apreciem. E sempre divertido conversar com você, Richard. Excelente.

Richard Yew: Da mesma forma, homem. Vemo-nos.

Tom Gorup: Até à próxima.