Riscos e controles da cadeia de suprimentos de software — 2025

1. Apresentação: Olá. Olá, pessoal. Bem-vindo ao meu novo curso, que é a segurança da cadeia de suprimentos e a Master Class. Meu nome é Pamurg Law e vou ser instrutor durante todo o curso, que é, obviamente, sobre segurança da cadeia de suprimentos de software Agora, o propósito deste curso é muito, muito simples. Quero explicar a você os fundamentos da segurança da cadeia de suprimentos de software, consolidar os fundamentos até o nível avançado e você obterá uma compreensão muito abrangente da cadeia de suprimentos de software Quais são seus componentes, quais são as partes interessadas e os vários tipos de riscos e problemas de segurança que podem comprometer a integridade e a segurança do seu software. Então, você entenderá todos os riscos existentes e eu lhe darei o conhecimento necessário para implementar um programa adequado de segurança da cadeia de suprimentos. E muito, muito importante. Eu disse um programa de segurança. Não quis dizer que não disse um produto de segurança porque, infelizmente, muitas vezes as pessoas se confundem. Eles acham que a segurança da cadeia de suprimentos de software envolve a implementação de um software ou a obtenção de certificação, e isso não pode estar mais longe da verdade. A segurança da cadeia de suprimentos de software é, como se pode dizer, um nicho completo dentro da segurança cibernética, do qual você precisa entender os diferentes riscos e como mitigá-los Analisaremos alguns estudos de caso também no setor, como eles aconteceram e como você pode usar o Entendê-los para se proteger ainda mais de se tornar vítima dos mesmos problemas que existem Agora, quem sou eu? Meu nome é Kamchal e sou um líder profissional de segurança cibernética multipremiado líder profissional de segurança cibernética multipremiado Escrevi: Ok, vou me chamar Estou em um setor de cibersegurança há mais de 21 anos Fui palestrante, instrutor. Também sou coach de carreira. Eu ajudo as pessoas a entrarem na cibersegurança Eu tenho um canal no YouTube chamado Cloud Security Guy, no qual falo sobre segurança na nuvem e IA. Também sou autora de best-sellers e criadora de cursos, como mencionei Então, só para garantir que eu sei um pouco sobre o que estou falando, esses são alguns dos meus livros escritos sobre governança de IA e segurança cibernética Eu tenho muitos cursos nesta plataforma. Sobre esse assunto. Também escrevi livros sobre Zero Trust e Comtea, certificações de segurança cibernética muitos outros tópicos Estou lá no Substack. Eu tenho um boletim informativo gratuito lá. Eu também estou lá no LinkedIn Cloud, como meu canal do YouTube se chama Cloud Security Guy, e eu estou lá no Twitter, então fique à vontade para entrar em contato comigo lá. Sempre fico feliz em ouvir as pessoas que fizeram meus cursos. Agora, vamos dar um passo à frente, para trás, desculpe. Vamos falar sobre a cadeia de suprimentos quando falamos sobre a cadeia de suprimentos. Agora você pode não estar ciente, mas a cadeia de suprimentos é fundamental para nossas vidas. E o que é uma cadeia de suprimentos? É uma rede de pessoas e empresas envolvidas na criação um produto e na entrega ao cliente, certo? E quando você compra algo, você sabe, como da Internet ou de um produto, e a maioria das pessoas não sabe. Normalmente, é uma jornada muito longa desde a ideia original até o momento da entrega. E tem muita gente envolvida desde o depósito até a empresa, até o transporte até você conseguir, certo? E há muitas pessoas que você chama de partes interessadas envolvidas lá. E o que você não percebe é que existem muitas, muitas oportunidades, também para que algo aconteça à medida que o produto segue esse caminho, as mercadorias estão avançando, certo? Todos esses são problemas. Problemas de segurança estão presentes em qualquer ponto da cadeia de suprimentos. E a maioria das pessoas não sabe, mas a segurança da cadeia de suprimentos faz parte de nossa existência. Por milhares e milhares de anos, como quando as especiarias eram transportadas de leste a oeste ou quando os navios transportavam mercadorias entre continentes, certo? Ou quando as tropas militares estão transportando alimentos e armas durante as guerras, todas as situações, as pessoas estão preparadas para ataques e defendem seus suprimentos Assim, o item poderia chegar ao destino pretendido. E o mesmo se aplica ao software também. Então imagine construir um carro. Certo? Você não fabricaria as peças do zero, certo? Em vez disso, você obteria os vários componentes, os pneus, o motor os componentes eletrônicos de vários fornecedores diferentes em uma fábrica e depois os montaria. E isso é do mesmo jeito. O mesmo princípio também se aplica ao software. E é aí que entra a cadeia de suprimentos de software. Refere-se à sequência de processos envolvidos no desenvolvimento, implantação e manutenção de aplicativos de software, basicamente tudo o que é necessário para criar um software, desde a implantação do código-fonte até a produção, certo? Nos ambientes atuais, é muito, muito raro que as empresas criem software completamente do zero. Em vez disso, o que eles fazem é confiar em uma variedade de blocos de construção, como bibliotecas de código aberto, ferramentas para desenvolvedores, implantações baseadas em nuvem, você sabe E cada um desses componentes faz parte de uma longa cadeia de suprimentos, desde a infraestrutura de TI até o código-fonte, certo? E a cadeia de suprimentos de software se refere à sequência de processos envolvidos na obtenção desse software. Então, isso pode ser o código-fonte, as bibliotecas de terceiros envolvidas , os sistemas de construção e empacotamento, os canais de distribuição, as infraestruturas de implantação, todos eles, eles surgem aqui E é assim que parece nos vários níveis, certo? Por exemplo, quando escrevem, os desenvolvedores confiarão em vários componentes externos ao desenvolver software. Isso pode ser uma biblioteca de código aberto, uma API de terceiros ou um serviço em nuvem. Eles o usam em seu ambiente e o enviam para um sistema de bits, que cria como um artefato de software e vai para um repositório e, em seguida, é implantado Não se preocupe se você não estiver familiarizado com esses termos. Vamos nos aprofundar em cada um desses softwares Estou apenas tentando fazer você entender que o software geralmente é desenvolvido por várias pessoas que podem fazer parte de várias organizações diferentes. E com o tempo, milhares de pessoas podem ter contribuído para um determinado software. Então, você precisa ter certeza de que entendeu. Onde os problemas de segurança podem surgir, certo? E é aí que entra a segurança da cadeia de suprimentos de software . Isso garante a integridade, a segurança e a confiabilidade dos componentes e processos envolvidos no desenvolvimento, distribuição e manutenção do software. Você quer ter certeza de que seu software não está sendo adulterado comprometido em nenhum ponto do ciclo de vida. E na cadeia de suprimentos, não estamos falando apenas do código, mas também das bibliotecas, ferramentas e serviços de terceiros. Depende da infraestrutura. Portanto, a segurança da cadeia de suprimentos de software engloba tudo. segurança da cadeia de suprimentos de software não é uma certificação que você obtém. Não é um produto que você compra. Ela engloba todos esses processos. Está bem? E por que isso é tão importante? Bem, simplificando, isso pode ser um grande ponto cego. Certo? A maioria das empresas se concentra em proteger seus próprios ambientes, seu próprio código, fazer treinamentos e garantir que tudo esteja E eles se esqueceram completamente das bibliotecas de terceiros, dos componentes de terceiros que estão lá E os atacantes não são estúpidos. Eles também estão cientes disso. Por que eles gostariam de atacar de frente quando sabem que a empresa está se protegendo, quando podem simplesmente entrar sorrateiramente por meio de um componente de terceiros, por uma biblioteca de terceiros, por algum outro tipo de backdoor que a empresa não E, infelizmente, como eu, há uma falta de consciência e controle sobre isso. A maioria das empresas acha que comprará um produto e sua cadeia de suprimentos estará segura, ou farão uma lista de verificação, verificarão seu fornecedor e agora estamos seguros ou elas faturarão Todas essas coisas são importantes. A propósito, não estou dizendo que essas coisas não sejam importantes, mas a segurança da cadeia de suprimentos de software é muito, muito mais do que isso. E há uma falta geral de consciência, é por isso que fiz esse curso aqui. E por que você deveria se importar? Quero dizer, não posso enfatizar isso o suficiente quando, há alguns anos, energia solar estava comprometida, certo? Isso aumentou a conscientização sobre a segurança da cadeia de suprimentos de software. E vou falar em detalhes sobre as vitórias solares, mas, em resumo, elas começaram em outubro de 2019 e permaneceram indetectadas até dezembro de 2020. E até então, 18.000 clientes haviam sido colocados em risco, ok? A Microsoft confirmou que tantas empresas foram contratadas, incluindo até mesmo governos dos EUA, certo E a energia solar vence, eles tiveram que se contentar com, acredito, uma ação judicial de 26.000.000 de dólares com seus investidores devido a todas as perdas financeiras E isso não incluiu os milhões gastos pela energia solar eólica e seus clientes, nem a resposta a incidentes, as investigações de ameaças, tempo de inatividade, as remediações e a perda de receita Assim, você pode entender o quão poderoso foi esse ataque e, da mesma forma , Log for J, se você estiver familiarizado, se você esteve em algum lugar em dezembro de 2021 em segurança cibernética, tenho certeza que sabe quantas pessoas tiveram as férias comprometidas por causa desse laboratório popular, ele foi comprometido e estava presente em milhões e milhões de ambientes, e todos eles tiveram presente em milhões e milhões de ambientes, que correr riscos para garantir que eles não estavam vulneráveis. Portanto, a segurança da cadeia de suprimentos de software não é brincadeira. Isso pode levar a ataques cibernéticos devastadores se você não os proteger adequadamente Então, para quem é esse curso? Obviamente, isso é para profissionais de segurança cibernética que desejam obter uma compreensão adequada usei todo o meu conhecimento que tenho sobre segurança da cadeia de suprimentos de software e o incluí neste Também é para desenvolvedores que desejam entender o contexto mais amplo do código, a segurança dele. Esses profissionais, se você quiser refinar seu conhecimento de risco e incluir também os riscos da cadeia de suprimentos da Suffa E, claro, líderes de segurança como CIOs, CTOs, diretores de segurança da informação qualquer pessoa interessada em entender a segurança da cadeia de suprimentos de software felizes em ter você neste curso E como usar este curso, por favor, você precisa entender e implementar as estratégias que vou delinear e diferenciar sua cadeia de suprimentos de software em relação a essas práticas Não basta fazer este curso e depois esquecê-lo. Por favor, aplique o conhecimento de que estou falando. Sabendo que você não está aplicado, você esquecerá isso e, em seguida, criará um programa adequado de segurança da cadeia de suprimentos de software. Esse será o seu projeto para este curso. Quero que você lidere, use os conceitos que eu ensino e os aplique em sua empresa e preencha uma lacuna. É sobre isso que estamos abordando. Agora, software, estamos prestes a começar agora. Lembre-se de que o software está em toda parte. Trilhões de linhas de código-fonte estão presentes em todos os lugares, e uma única vulnerabilidade de software pode impedir empresas inteiras façam negócios e causar bilhões de dólares em danos Agora, mais do que nunca, você precisa entender a cadeia de suprimentos de software e a segurança. Então, espero que isso lhe dê uma boa compreensão e o motive a realmente aprender sobre esse tópico. Vamos começar. Espero que você esteja tão empolgado quanto eu, e nos vemos na próxima lição. Muito obrigado. 2. Como entender a cadeia de suprimentos: Olá, pessoal. Bem-vindo a esta lição na qual entenderemos a cadeia de suprimentos de software. Antes de começarmos a protegê-lo, você precisa entender como a cadeia de suprimentos de software funciona no mundo atual e, em seguida, abordaremos a parte dos riscos Está bem? Então, é disso que você falará nesta lição, que é a cadeia de suprimentos de software, os conceitos-chave que você precisa ter em mente e os diferentes tipos de ambientes que existem. E isso é como um curso básico que definirá a linha de base para todo o Portanto, se você não sabe o que é a cadeia de suprimentos de software, certifique-se de ler esta lição e não acreditará na quantidade de profissionais de segurança que vi cometendo esse erro. O que eles fazem é assumir imediatamente o risco sem primeiro entender ou apreciar o que é a cadeia de suprimentos de software, quais são os diferentes ambientes e como eles funcionam Então, já falamos sobre essa definição antes, uma revisão muito rápida. Cadeia de suprimentos de software, como falamos, a sequência de processos envolvidos na implantação, desenvolvimento e manutenção de aplicativos de software. Basicamente, tudo o que você precisa para criar um artefato de software, desde o desenvolvimento do código-fonte até a implantação da produção, que vem dentro da cadeia de suprimentos de software Falamos anteriormente sobre como é muito raro que as empresas criem ein do zero. Eles contam com blocos de construção , como bibliotecas de código aberto, ferramentas para desenvolvedores e serviços SAS. Todos eles se unem para fazer esse pacote de software, certo? E em todos eles, há um potencial de riscos de segurança. Então, como é um ambiente típico de desenvolvimento de software hoje em dia? Um ambiente de software, desculpe. Então é assim que parece. Vamos analisar a passo o que for preciso. E antes que você pule até mim e comece gritar que meu ambiente não é assim, eu sei que cada ambiente é diferente, mas esse é o mais comum, como esses são os atributos que estarão presentes em praticamente todos os ambientes existentes Então, primeiro de tudo, vamos começar com o ambiente de desenvolvimento. É aqui que a mágica acontece, certo? Os desenvolvedores usam esse ambiente para escrever e testar código. Eles criam novos recursos e experimentam ideias. É como o espaço de trabalho deles, certo? Permitindo que eles escrevam código e dêem vida às suas visões E o ambiente de desenvolvimento geralmente é equipado com várias ferramentas e estruturas, que não estão presentes em outras máquinas de negócios Então, isso é como um ambiente especial. Eles geralmente têm mais privilégios. Então, o que eles fazem? Eles usam seu ambiente de desenvolvimento integrado, suas estações de trabalho, que têm seu software de codificação. Para escrever código, que é enviado para um repositório de código. Um repositório de código pode ser como um servidor compartilhado que contém o código partir daí, a plataforma de construção pega seu código e se transforma em um artefato Agora, os desenvolvedores podem estar usando dependências em seu código ou, quando ele está sendo construído, ele pode extrair dependências Dependências são, como eu disse, esses blocos de construção, certo? Você não vai escrever tudo do zero, certo? Se você estiver escrevendo código em Python, você usará várias Então, todas essas dependências, a plataforma de construção usará para criar seu software, e é assim que o ambiente de desenvolvimento funciona. Então eu escrevo código. Ele entra em um repositório de código, onde o ambiente de construção, gerado, compila esse Ele extrai todas as dependências necessárias. Pode estar dentro do ambiente , pode ser um relatório público , armazenado na Internet. Mas essa é a aparência típica do ambiente de desenvolvimento. Então, depois disso, o que vem , vem o ambiente de teste. Então, depois que o código é escrito, hora de avaliar sua robustez e funcionalidade, certo O ambiente de teste é como um local controlado onde você executa vários tipos de testes, como testes unitários, testes integração, testes de sistema e garantia de qualidade. Você está avaliando meticulosamente esse código, certo? Contra casos de teste predefinidos para descobrir se há algum problema Agora, isso pode ser totalmente automatizado em muitos ambientes. Eles têm DevOps e DFSycoVs. Portanto, você pode ter testes totalmente automatizados. Ou você pode ter uma pessoa sentada lá fazendo o teste e você não vai acreditar que ainda acontecem. Você tem muitas equipes de controle de qualidade e testes que estão executando esses testes automatizados, mas há uma pessoa examinando isso. Portanto, existem várias maneiras de fazer isso. Mas geralmente você tem um ambiente de teste e um ambiente de UAT em que o código é testado para garantir que esteja livre de bots Está bem? O que acontece depois disso? Então, depois disso, você tem algo chamado de pré-produção ou ambiente de teste Então, isso é como uma lacuna entre as fases de teste e produção. Isso geralmente é uma réplica do ambiente de produção. Ele permite que as equipes validem se o software é um comportamento Está funcionando corretamente em condições do mundo real, certo? Como eu disse, é muito próximo ao ambiente de produção. Então, isso permite que eles façam um teste de estresse e analisem várias formas como o software realmente funcionará, sabe? Como o ambiente de teste do UAT, é como um ambiente de teste. Não representa o mundo real. Então, o ambiente de pré-produção e de preparação, isso é muito, muito próximo de como o ambiente de produção funcionará E muitas pessoas usam preprod e staging Há diferenças sutis. Mas geralmente, em geral, eles usam de forma bastante intercambiável, falando honestamente, dentro do que E quais são os benefícios de usar esses ambientes? Como eu disse, teste de carga, teste de desempenho, teste estresse, o que você não pode fazer em ambientes UAT, certo? E eles oferecem várias vantagens porque mostram como o cliente real analisará o software, e ele detectará erros no desempenho, e você diminuirá a velocidade antes o software chegue ao cliente final. Ele permite que você ajuste o desempenho identificando quaisquer gargalos que possam estar presentes e oferece uma boa maneira de avaliar se o desempenho do usuário, a satisfação do usuário e como ele estará presente, porque agora você está tendo uma boa ideia de como o cliente verá esse software, e esse é o benefício de adicionar a pré-produção e a encenação. E, como eu disse, isso é muito, muito próximo ao ambiente de produção, então você pode ter dados reais aqui, dados reais de produção sendo armazenados aqui. E, por fim, é o ambiente de produção. Portanto, esse é o destino final do seu software, é um ambiente ao vivo em que os usuários finais interagirão com seu aplicativo ou sistema. O software é implantado aqui e deve ser meticulosamente testado e refinado nos ambientes anteriores para garantir que os clientes tenham uma Agora, eu nunca ouvi falar de nenhum software que não tenha bug nesse ambiente de produção não importa quantos testes você faça. Mas, seguindo as etapas , você terá uma ideia muito boa e a chance de remover quaisquer bugs que possam estar lá. Então, é assim que um ambiente de software típico se parecerá. Como eu disse, antes que você enlouqueça e me acuse de perder áreas críticas Como eu disse, sei que cada ambiente é diferente, mas esse é o ambiente mais próximo . Geralmente, essas são as formas mais comuns pelas quais ambientes de desenvolvimento de software são estruturados. Então eu espero que você tenha uma boa ideia. Agora vamos dar uma olhada em alguns conceitos que uma olhada existem, que são Dev SecOps, pipelines CICD, artefatos, repositórios de artefatos, repositórios de pacotes e infraestrutura como COD , repositórios de pacotes e infraestrutura . Você pode estar familiarizado com isso, mas eu deliberadamente coloquei isso aqui apenas para relembrar, porque todas essas áreas entrarão em jogo quando falarmos sobre os riscos de segurança da cadeia de suprimentos de software que existem Então, eu coloquei isso como uma revisão em dinheiro. Se você acha que é muito bom em todos esses conceitos, fique à vontade para pular esta lição Mas eu recomendaria fazer isso como uma revisão rápida, então nos vemos na próxima lição. Obrigada. 3. Riscos da cadeia de suprimentos — 1: Olá, pessoal. Bem-vindo. Bem-vindo à próxima lição. E é aqui que realmente começamos a abordar a essência do curso, que agora vamos falar sobre o risco de segurança, certo? A cadeia de suprimentos de software, risco de segurança. Então, na lição anterior, falei com você sobre como os ambientes de desenvolvimento de software geralmente são configurados, certo? Tento abordar o ambiente de desenvolvimento de software mais comum e como ele funciona, quais são os diferentes conceitos e como o software se move por eles. Agora, o que faremos nesta lição falar sobre os riscos de segurança, que são os riscos é falar sobre os riscos de segurança, que são os riscos de segurança na cadeia de suprimentos de sofás, como eles acontecem e faremos uma análise dos incidentes reais Alguns dos mais populares como eventos solares, Cord Cov Quando terminei este curso, provavelmente algum outro ataque à cadeia de suprimentos pode ter acontecido. Mas vou abordar aqueles que abrangem diferentes cenários. E que pode mostrar o impacto real. Portanto, não é apenas teórico dizer que essas coisas podem acontecer. Eu vou te mostrar realmente como isso aconteceu e quais foram os impactos e o que você pode fazer para realmente se proteger, certo, evitar que essas coisas aconteçam. Então, se você se lembra, este é o diagrama que vimos antes, certo? Tínhamos o ambiente do desenvolvedor com o ID, enviando o código para o repositório, a plataforma Bull entraria em ação, inseria todas as dependências e o branco, e o enviaria para o ambiente de teste e, em seguida, a preparação para a produção Isso pode ser totalmente manual ou pode ser um pipeline CICD, branco, enviando seu código Desde os diferentes ambientes até ser empurrado para o ambiente de produção, e foi sobre isso que conversamos. Então, vamos agora pensar nos riscos em alto nível. Agora, vamos começar pelo desenvolvedor. Agora, os desenvolvedores na maioria dos ambientes e o que você chama de desenvolvedores, eles geralmente têm privilégios bastante poderosos Eles têm a capacidade de manter seus próprios ambientes de desenvolvedor porque precisam dessa flexibilidade para criar novos aplicativos e produtos. Pela minha experiência, às vezes podem criar máquinas virtuais como, você sabe, sistemas operacionais dual boat, Linux e Windows. E esses ambientes, muitas vezes, às vezes são invisíveis para as organizações de TI. É por isso que eles os chamam de Shadow IT, certo? E os desenvolvedores acreditam que precisam dessa flexibilidade, certo? Eles precisam da capacidade de criar uma máquina virtual, instalar aplicativos e gerenciar seus ambientes. Eles não querem que seus laptops ou desktops sejam bloqueados e querem acesso administrativo ou de usuários avançados aos seus sistemas porque, e querem acesso administrativo ou de usuários avançados aos se você interromper essa capacidade, eles não terão a capacidade de solucionar problemas para criar ambientes ou terão que passar por dezenas de aprovações para Se você já trabalhou com cibersegurança, tenho certeza que já deve ter visto isso, certo? Então, começamos que essa é a primeira coisa que você precisa pensar sobre os privilégios muito poderosos que os desenvolvedores têm e a que isso levará, veremos Então, é claro, vem em código seguro. E vamos ver se o código que eles estão escrevendo for inseguro Eles o enviarão para um repositório de código e , em seguida, ele será propagado por todos os ambientes, e esse código tem sérias falhas de segurança E se você for um provedor de serviços, como a Solar Winds, esse código inseguro será propagado em todos os lugares, certo Milhares e milhares de pessoas porque você mesmo não verificou, certo? E o código é empurrado para algo parecido com o que você chama de repositório de código, certo? Agora, no repositório de código, você também pode ter vários compromissos aqui, certo? O repositório de origem, o repositório de código, talvez a interface administrativa não seja segura E o atacante pode usar a interface administrativa ou comprometer o servidor subjacente para atacar diretamente o código-fonte e obter acesso a ele, e começar a modificar o Ou eles podem colocar algum malware lá, que se propaga em todos os lugares Então, pense no repositório de código que está lá. Obviamente, você tem a plataforma construída e ela está totalmente integrada aos seus repositórios de artefatos e aos seus repositórios de pacotes E, muitas vezes, o que eles fazem é começar a construir coisas e propagá-las em seus ambientes, certo? Assim, o atacante pode atacar as entradas dessa plataforma de construção, como qual versão usar, e redirecioná-las para algum código malicioso, que a plataforma de construção com a plataforma E veremos isso no ataque dos ventos solares. Assim, eles podem atacar qualquer parte da plataforma construída, incluindo seus serviços ou a infraestrutura subjacente, e podem alterar a forma como ela é cobrada, certo? E isso pode levar adiante. Eles podem comprometer o repositório de artefatos como o pacote sobre o qual falamos, e podem carregar ou publicar artefatos alterados porque você não protegeu E, por fim, as dependências, se você olhar para o topo e essa é uma das coisas mais comuns E, infelizmente, as pessoas acham que essa é a única coisa sobre cadeia de suprimentos de software, mas suas dependências, porque você está usando uma variedade de bibliotecas comerciais e de código aberto de terceiros, existem, e é assim que a maioria dos ambientes é configurada, certo? Então, o que acontecerá é que você terá vários E se um invasor comprometer essa biblioteca. Eles tentam introduzir um comportamento malicioso comprometendo essa biblioteca, e essa dependência se propagará por todo o se propagará por todo Seu código, temos um componente inseguro, como falamos sobre Log for J, certo? Ela será propagada para o seu ambiente e, mais tarde, quando uma vulnerabilidade for descoberta, o invasor poderá usá-la para acessar quando uma vulnerabilidade for descoberta, seu ambiente Então, esse é apenas o ambiente do desenvolvedor, certo? E depois, passando para outros ambientes como o ambiente de teste do UAT, quando você está fazendo o teste, às vezes as empresas nem se preocupam em fazer testes de segurança Eles não têm ideia se o código é seguro. Se o COO está introduzindo alguma vulnerabilidade ou não, algo Eles confiam apenas no desenvolvedor. Você não vai acreditar no quão comum isso ainda é, infelizmente. Então, esse teste de segurança não existe. Muitas empresas que eu vi fazem testes de segurança, mas nada acontece depois disso. Então eles fazem um teste de segurança e, ok, acabaram de publicar um relatório. Essas são as vulnerabilidades de segurança. Ninguém está analisando essas vulnerabilidades, certo? Então, no teste de segurança, você não faz testes de segurança apenas por uma questão de segurança , certo? Você faz testes de segurança para que as vulnerabilidades sejam corrigidas Então, esse é outro problema. O teste de segurança não está lá. Então, é claro, você passa para os ambientes pré-orgulhosos e de encenação. E falamos sobre isso ser uma réplica da produção. Isso não é tão seguro quanto a produção. É uma réplica Então, alguém pode comprometê-lo e obter acesso aos dados porque você tem dados de clientes. Talvez você não os tenha mascarado ou anonimizado, para que as pessoas possam ter acesso a esses dados e comprometê-los E, por fim, é claro, o ambiente de produção. O ambiente de produção, eu o mantive fora do escopo deste curso porque, é claro, essa é a segurança cibernética tradicional Você terá patches e todas essas outras coisas. Mas isso também pode ficar comprometido, certo? Porque eu quero que você pense nisso do ponto de vista geral. Esses são todos os ataques que podem acontecer, certo? E, por fim, é claro, se você observar as setas que conectam esses ambientes, esta, o pipeline CICD, se você estiver usando, se estiver usando um pipeline CSED, falamos sobre como a integração contínua testará rapidamente, enviará o código e fará o teste e, em seguida, a implantação contínua ou enviará o código para o outro se estiver usando um pipeline CSED, falamos sobre como a integração contínua testará rapidamente, enviará o código e fará o teste e, em seguida, a implantação contínua ou enviará o código para o se você observar as setas que conectam esses ambientes, esta, o pipeline CICD, se você estiver usando, se estiver usando um pipeline CSED, falamos sobre como a integração contínua testará rapidamente, enviará o código e fará o teste e, em seguida, a implantação contínua ou enviará o código para o outro. ambientes, certo? E se alguém conseguir comprometer o pipeline do CICD? Esse pipeline tem acesso a todos os ambientes, certo? Assim, eles podem realmente controlar qual código está sendo enviado, que tipo de testes estão acontecendo Isso é outra coisa que você deve ter em mente. É outra coisa muito, muito perigosa que pode acontecer. Então esse é o panorama geral. Esse é o tipo de ataque eu quero que você pense quando estiver pensando na segurança da cadeia de suprimentos, certo? E essa é minha opinião? Então você pode estar pensando, e esta é apenas sua opinião subjetiva Então não, eu o baseei em uma referência do setor. Então isso é Salsa. Dizem que eles o pronunciam salsa, o que eu gosto, mas níveis de cadeia de suprimentos para artefatos de software Essa é uma referência do setor. Vou colocar o link neste curso. Portanto, é uma estrutura de segurança. É como uma lista de verificação das melhores práticas para evitar que a segurança da cadeia de suprimentos de seu software seja comprometida, certo E geralmente é usado em todo o setor. É um independente muito, muito bom , independente de tecnologia, independente de fornecedores E é como um conjunto de diretrizes. Você pode adotá-los lentamente e eles são estabelecidos pelo consenso do setor. E eles estão configurados. Então, qualquer pessoa que esteja criando software, use-os, certo? Qualquer pessoa que esteja produzindo, consumindo ou fornecendo software, como plataformas de construção ou qualquer outra coisa, isso pode ser usado para, por exemplo, obter mais confiança na segurança da cadeia de suprimentos de software. É como a colaboração cruzada do setor. Falaremos mais sobre isso mais tarde. Mas é como se fosse um fornecedor completamente neutro, o que você chama de estrutura para garantir um plano para proteger seu software Ele fornece um vocabulário comum para falar sobre segurança da cadeia de suprimentos de software E foi sobre isso que eu construí esse diagrama. Então é isso que queremos mostrar. E isso é uma referência do setor. Então, vou colocar o link lá. Você pode ver, então não sou só eu, você está pensando que eu estou apenas falando da minha própria opinião. Isso é baseado em um benchmark do setor sobre o qual falei, e eu definitivamente recomendaria que, mais tarde, quando criássemos um programa de segurança da cadeia de suprimentos de software dê uma olhada nele, ok? Então, agora vamos falar sobre o principal risco de segurança. Eu não vou falar sobre isso nesta lição, porque eu já lhe dei algumas coisas para falar. Continuaremos na próxima lição. Mas vamos falar sobre o principal risco de segurança. Todos os riscos sobre os quais falamos no diagrama, vamos nos aprofundar em cada um deles e pensar como isso funciona e quais são as implicações desses ataques acontecerem. Entender isso é muito importante porque, caso contrário, você não poderá proteger algo se não entender como isso acontece, certo? Então, agora vamos nos aprofundar em cada um desses riscos e vou mostrar o impacto dessas coisas acontecendo. Ok, muito obrigado. Te vejo na próxima aula. 4. Riscos da cadeia de suprimentos — 2: Olá, pessoal. Bem-vindo a esta lição. E agora vamos falar sobre os principais riscos de segurança sobre os quais falamos no diagrama. E vamos caminhar um por um, para que você tenha uma ideia melhor desses riscos de segurança. E mais tarde, quando começarmos a protegê-los, você terá uma ideia muito melhor E também veremos alguns estudos de caso sobre ventos solares e Kokov sobre como esses riscos podem realmente acontecer e realmente Vou dar um passo a passo para dar a você uma melhor avaliação desses ataques Então, vamos começar com o número um , que é o código inseguro Agora, código inseguro não é, quero dizer, falando honestamente, isso é algo que está no setor há décadas, e há muita consciência agora e há muita consciência Quero dizer, em comparação com os outros ataques, eu diria que código inseguro não é tão sério Sei que a maioria das empresas começou a adotar medidas, mas esse é o ponto de partida. De todos os riscos de segurança da cadeia de suprimentos de software Honestamente, como eu disse, a raiz de todo mal, seja ele primário ou de terceiros, você precisa garantir que seu código esteja seguro E o erro que vejo muitas empresas cometendo elas protegem seu código primário, que é seu próprio código, mas não olham para terceiros, e você tem que tratar todos os códigos da mesma forma. Você precisa se certificar de que tem a garantia de que esse código foi protegido. E você pode perguntar: como posso proteger o código de terceiros? Eu não tenho acesso a ele? Bem, existem maneiras de fazer isso. Você pode perguntar ao fornecedor Você pode avaliar os processos de gerenciamento de risco do fornecedor, certo? Portanto, existem maneiras de verificar isso e vamos examiná-lo com mais detalhes. Onde falamos sobre a criação do programa de gerenciamento de riscos de segurança do fornecedor Mas o código inseguro significa que, se você não estiver protegendo seu código, todos os outros controles não importarão, pois é aí que reside a maioria dos riscos de segurança Então, esses são apenas exemplos. Eu costumava examiná-los e, se você conhece um pouco de codificação, é algo como um ataque de injeção em que você não está limpando o código, apenas aceitando código em seu ambiente, e praticamente qualquer pessoa pode simplesmente ignorar esse código e praticamente qualquer pessoa pode simplesmente para acessar seus bancos de dados subjacentes, seu sistema operacional subjacente você conhece um pouco de codificação, é algo como um ataque de injeção em que você não está limpando o código, apenas aceitando código em seu ambiente, e praticamente qualquer pessoa pode simplesmente ignorar esse código para acessar seus bancos de dados subjacentes, seu sistema operacional subjacente. É chamado de ataque de injeção. E você não vai acreditar, mesmo em 2024, vejo pessoas ainda cometendo esse erro. Então , é incrível. Eu estava estudando programação em 2002. Então, já faz quase 22 anos, e esse problema ainda existe, que achei muito engraçado é que esse erro ainda exista apesar de todos os avanços que fizemos . Isso é outra coisa. É como um ataque de bomba ZIP caso você não esteja familiarizado com isso, é como um arquivo que você não está validando um arquivo ZIP ou um arquivo compactado, você está apenas extraindo-o sem fazer nenhuma Assim, você pode realmente causar uma negação de serviço ao atacante Você pode esgotar o espaço ou a memória do sistema alvo ao tentar extraí-lo, E, honestamente, o formato ZIP é o mais usado, mas você pode muito bem usá-lo É como compactar um arquivo grande que consiste em um único caractere, certo? E você pode criar um arquivo de um MB que será descompactado em uma GV E, na verdade , vai bagunçar o sistema operacional porque você não está fazendo nenhuma validação Então, esse é outro ataque , devido ao seu código inseguro E isso é, quero dizer, qualquer um sabe disso. Essa é a coisa mais antiga e comum, que são segredos codificados Como se as pessoas fossem preguiçosas. Eles não querem fazer uma validação segura e ninguém está vendo o código. Então, eles realmente inserem os segredos codificados e eles são enviados para um repositório público de código exemplo, supondo que você esteja usando um ceifeiro de código público, alguém o acessa e pronto, ele tem acesso ao seu ambiente porque você insere o ID do usuário e a senha em um Muitas empresas que eu conheço têm políticas de senha muito rígidas, mas não analisam o código. Que está aí, então eles nem estão escaneando o código. Portanto, isso pode, na verdade, fazer com que IDs de usuário, senhas chaves de acesso codificadas sejam inseridas em um código e enviadas para o relatório do código Qualquer pessoa que tenha acesso a esse código agora pode ignorar e comprometer seu ambiente Então, isso é só para mostrar o quão perigosos esses ataques são. Então, isso era como um código inseguro. Vamos passar para o próximo, que são componentes de terceiros inseguros E é aí que entra o maior foco quando as pessoas falam sobre segurança da cadeia de suprimentos, basicamente dependências de terceiros vulneráveis ou maliciosas dependências de terceiros Você sabe, falamos sobre isso anteriormente: softwares modernos dependem de bibliotecas ou adios de terceiros E se essas dependências contiverem vulnerabilidades ou talvez códigos maliciosos, elas podem introduzir riscos em todo o seu ambiente, certo E o software de terceiros, pense que o software de terceiros é apenas um software primário escrito por outra pessoa. Assim como a nuvem é apenas um servidor executado por outra pessoa. Dependências de software de terceiros, você pode pensar nisso. Essas são suas dependências, mas escritas por outra pessoa. Todos os riscos de que falamos sobre codificação também são transferidos para cá E essas vulnerabilidades podem entrar em seu ambiente. Se o atacante conseguir comprometê-lo. Essa dependência, essa dependência agora será usada para comprometer seu ambiente, certo E essas podem ser vulnerabilidades conhecidas. Portanto, não é como se estivesse oculta porque essa vulnerabilidade conhecida há muito tempo, mas você não consegue corrigi-la porque ela quebrará seu aplicativo ou porque o fornecedor não lançou uma correção Então você tem que pensar sobre isso. Ok, o que eu faço agora? Ou isso pode ser zero dias, como o bloqueio inicial para J. Você se lembra de Log para J, certo? Isso pode ser zero dias. Ninguém sabia disso. De repente, ele chega e não há solução para isso. E rapidamente, os atacantes podem começar a manipulá-lo, começar a tentar comprometer ambientes E é como se existissem vulnerabilidades imediatas que permanecessem inativas em uma base de código por meses, anos E quando finalmente são descobertas e anunciadas pessoas em todo o mundo, elas estão brigando Gostaria de descobrir se eles estão usando esse software ou não, certo, para descobrir se eles usam essa dependência e como se proteger de serem explorados Os atacantes também estão lutando. A propósito, eles estão tentando determinar quem está usando esse software vulnerável e estão tentando criar exploits para aproveitar e comprometer o ambiente Então, é como se fosse uma corrida louca para as pessoas descobrirem, certo? E é assim que geralmente parece. Então você tem um atacante, ele compromete esse ambiente. Eles comprometem um laboratório terceirizado e esse laboratório terceirizado está se espalhando Está sendo propagado para milhares e milhares de empresas, certo, como Lock for and take the solar wins Alguém comprometeu o ambiente dos ventos solares e esse código que usamos para espalhar o meio ambiente Então, esse é outro exemplo de como isso aconteceu. E geralmente é assim que os componentes inseguros de terceiros funcionam, certo? Você tem que pensar sobre isso a partir dessa perspectiva. Então, essas eram a codificação de primeiro nível e as dependências de terceiros Vou dividir esta lição em várias partes porque quero que você absorva o que falamos antes de eu passar para a próxima. Na próxima, falarei sobre comprometer o repositório de código onde você está armazenando o Lembre-se de que quando o desenvolvedor costumava enviar código, ele ia para um repositório de código Então, vamos falar sobre o repositório de código e o que pode acontecer. Obrigado e nos vemos na próxima lição. 5. Riscos da cadeia de suprimentos — 3: Olá, pessoal. Bem-vindo. Bem-vindo a esta lição. E agora vamos falar sobre o comprometimento do repositório de código Então, como você pode ver, se você se lembra do diagrama, estamos nos movendo lentamente pela cadeia de suprimentos de software. E já falamos sobre repositórios de código antes. Básico, pense nisso como uma biblioteca centralizada ou um repositório centralizado onde seus desenvolvedores podem colaborar no Então eu escrevo um código e o envio para um relatório de código. Outro desenvolvedor também está escrevendo código. Eles estão pressionando para o mesmo relatório. E o código, você já ouviu falar do Github em todo o mundo. Portanto, garante que todo o código esteja sincronizado. E o que pode acontecer, os atacantes podem ter acesso a esse repositório Talvez o software não seja seguro, ou talvez eles comprometam o usuário. Eles enviaram um link malicioso, e ele disse que inseriu seu ID de usuário e senha e eles conseguiram obtê-los. Agora eles podem manipular o código-fonte na fundação Ou até mesmo muitas pessoas não estão cientes. O repositório em si pode ser usado para oferecer ataques aos clientes E às vezes as pessoas não estão cientes disso. Portanto, há a segurança do próprio repositório, garantindo que o repositório não seja comprometido e que o próprio repositório possa ser usado como E vamos dar um exemplo. Então, caso você não esteja ciente disso, acho que isso aconteceu em 2020, o malware octopus scanner Então, na verdade, eles são atacantes. O que eles fizeram foi ter um conjunto de repositórios hospedados no Github e, sem querer, eram Sem querer, eles estavam sendo usados para veicular malware. E, na verdade, a equipe de segurança do Github pesquisou e descobriu que o que aconteceu foi que esses repositórios não estavam protegidos e estavam sendo usados para distribuir malware em todos os setores E os donos dos repositórios estavam completamente inconscientes Eles estavam se comprometendo como um código malicioso nos repositórios Quando eles estão fazendo isso extraindo o código, na verdade estavam extraindo malware e fornecem um alto nível, como você chama? O que ele faz bem, basicamente, comprometeu o próprio repositório E você pode imaginar o quão perigoso isso é, certo? Porque por quê? Porque o malware está sendo puxado para a estação de trabalho do desenvolvedor E a partir daí, ele é inserido na versão, e agora você está dando a esse malware a capacidade de se mover pelo seu ambiente. E como as principais pessoas comprometidas são os desenvolvedores, e se você se lembra do que falamos, os desenvolvedores tradicionalmente têm mais acesso do que as pessoas normais, certo? Eles têm privilégios elevados, usuários avançados. Portanto, isso permitirá que eles potencialmente tenham acesso aos ambientes de produção. Você poderia potencialmente obter acesso ao banco de dados, senhas e outros ativos essenciais, certo? Há um enorme potencial de escalonamento de acesso para o invasor que está fazendo um escalonamento de privilégios, que é um objetivo central da maioria dos comprometimentos de dados Quando o atacante entra em um ambiente, a primeira coisa que ele quer fazer é se tornar o administrador, certo? E isso é só para mostrar o que pode acontecer. As pessoas pensam que, Oh, o depósito de códigos pode se tornar público Essa é a pior coisa que pode acontecer. Não, se você não protegeu seu repositório de código, o relatório de código em si pode ficar comprometido e ser usado para veicular malware E falaremos sobre todos os controles de segurança mais tarde. Primeiro, quero que você entenda os riscos. E isso está muito ligado ao ambiente do desenvolvedor. Já falamos sobre isso antes, certo? É um desenvolvedor que eles precisam acessar porque querem poder usar sandboxes Eles querem a capacidade de girar máquinas virtuais, instalar aplicativos e, pelo menos, ter acesso elevado. Eles não querem aquele PC corporativo no qual não podem fazer nada porque precisam da capacidade de executar código. Então, eles têm ferramentas poderosas, eles têm IDs com plug-ins. Esses plug-ins podem ser comprometidos, certo? Então, todas essas coisas em que você precisa pensar. E, claro, PreProdeEnvironments. No ambiente de pré-produção, ele terá dados do cliente. Então, se um malware estiver lá, comprometendo a máquina do desenvolvedor e, lentamente, sendo empurrado para o ambiente, o atacante poderá alcançar até chegar a um ambiente em que o malware possa lhe dizer: Olha, eu tenho acesso aos dados do cliente Você poderá extrair esses dados. Então, é assim que você pode ver como várias coisas se juntam, o PC do desenvolvedor não está seguro, a varredura de origem está sendo comprometida seu ambiente de pré-produto contém dados de produção completamente abertos Tudo isso se junta para realmente comprometer seu ambiente. Então, isso foi mais do ponto de vista do desenvolvedor. Agora vamos falar sobre ataques durante a fase de construção. Já falamos sobre um servidor de compilação antes, certo? É uma parte crítica do CICD porque basicamente eles automatizam o processo de compilação de código, execução de testes e preparação de aplicativos para implantação É como se o servidor de compilação estivesse fazendo tudo, certo? E os ataques durante a fase de construção são muito perigosos porque, se atacante conseguir obter acesso ou controle não autorizado sobre o servidor de compilação, eles podem realmente causar estragos em seu ambiente Por quê? Como as plataformas criadas geralmente são integradas aos seus repositórios de artefatos, onde está seu código ou seus repositórios de pacotes, E eles podem modificar sua construção. Então, eles podem realmente atacar essas plataformas de cobrança. Eles têm muitos parâmetros, certo? Então, eles podem realmente mudar isso. Eles podem usá-lo para direcionar para algum lugar que esteja comprometido. Ou eles podem realmente usar a própria plataforma de cobrança para enviar seu próprio código malicioso, como o que aconteceu com os ventos solares, sobre o qual falaremos em breve. Ou eles podem realmente usá-lo para comprometer os artefatos, certo? Portanto, a plataforma construída é uma parte muito, muito importante do seu ambiente. E um dos melhores exemplos do que acontece são as vitórias solares. Depois desta lição, veremos algumas lições mais tarde, faremos o estudo de caso do que acontece quando uma plataforma construída é comprometida O impacto absoluto do melhor exemplo disso são as vitórias solares O outro muito ligado a isso é o comprometimento do gasoduto CICD Falamos sobre o gasoduto CICD. Por quê? Isso envia automaticamente o código, implanta e o testa E esses oleodutos são alvos muito, muito atraentes para os atacantes Por quê? Porque eles oferecem um caminho direto para o ambiente de produção de software sistema e os dados do usuário. Então, quero dizer, como isso pode ser comprometido? Há várias maneiras. Você pode ter credenciais inseguras. Talvez você não tenha configurado os controles de acesso corretamente. Você pode ter ferramentas vulneráveis que ficam comprometidas, certo? E lembre-se de que o CSCDPipeline é o processo automatizado usado para integrar, testar E isso pode levar a graves violações de segurança. E isso pode fazer com que, na verdade outros clientes também se comprometam, sobre o qual falaremos em um estudo de caso chamado Cod COV Eu vou te mostrar o que acontece. Na verdade, se o pipeline do CICD for comprometido, o impacto Então, esses são os dois. Então, um é o servidor de compilação, vamos fazer um estudo de caso e este. Vamos fazer um estudo de Kas. Em breve, mostrarei o que acontece quando o servidor de compilação ou o pipeline do CICD são comprometidos Mas agora, eu quero que você pense sobre o impacto do que pode acontecer. Portanto, isso cobre essa seção específica. Agora vamos falar sobre o depósito de pacotes, mas, como eu disse, não quero nem, tipo, sobrecarregá-lo com muitas Na próxima lição, falaremos sobre o pacote chorado e os ataques específicos que podem atacá-lo e alguns ataques exclusivos, como ataques de dependência e confusão Como eles acontecem e qual é o impacto desses ataques. Então, muito obrigado, e nos vemos na próxima. 6. Riscos da cadeia de suprimentos — 4: Olá, pessoal. Bem-vindo. Bem-vindo a esta lição. E agora vamos nos concentrar no repouso do pacote. Se você se lembra do seu software que está empacotado em um pacote, certo? Todo o código e tudo o que ele tem dependências agrupados em um pacote, que você pode implantar nos ambientes do cliente e nos seus ambientes de produção Agora, o repositório de pacotes é onde esses pacotes são mantidos, e o próprio relatório do pacote pode ser comprometido Então, talvez você não tenha protegido o repositório de pacotes, certo? Nós lhe demos acesso aberto. Então você o configurou incorretamente. Talvez você esteja conectado à Internet, talvez tenha permitido acesso anônimo. Você está usando senhas padrão e concedendo privilégios de upload a usuários que podem ser E o que pode acontecer é que um atacante possa obter acesso a esse repositório de pacotes e envenená-lo Portanto, o repositório de pacotes é violado ou manipulado por agentes maliciosos Então, isso pode afetar a integridade e a segurança de toda a cadeia de suprimentos, certo, a cadeia de suprimentos de software, porque eles podem enviar pacotes maliciosos, certo? Lembre-se de que esse é um local centralizado onde os pacotes de software estão sendo armazenados Então, o que pode acontecer? As pessoas podem enviar malware. Assim, a injeção de malware e o código malicioso podem ser adicionados aos pacotes no repositório Então, quando as pessoas o baixam e integram esses pacotes comprometidos, o malware se torna parte do aplicativo ou, uh, do roubo de credenciais Talvez os invasores possam roubar credenciais de pacotes e usá-las para inserir outros códigos não autorizados Você pode até mesmo substituir pacotes legítimos. Então você tem um nome de pacote. Você pode substituí-lo por seu próprio pacote malicioso e, posteriormente, ele será enviado para milhares e milhares de pessoas E, por fim, ataques de confusão de dependência. Esse é um tipo especial de ataque em que o que os atacantes fazem é publicar pacotes, cujos nomes são semelhantes aos pacotes privados internos usados pela empresa E se o pacote público tiver um número de versão maior, os gerenciadores de pacotes poderão buscá-lo os gerenciadores de pacotes poderão em vez do interno, e eu mostrarei como isso acontece É um ataque muito único, mas extremamente perigoso. Mas isso é exatamente o que eu queria te mostrar. E isso não é uma piada. Quero dizer, o repositório de pacotes, só para dar um exemplo. Este foi um repositório de pacotes que foi comprometido no ano passado. atacante conseguiu acessar Acho que o atacante conseguiu acessar quatro contas inativas e sequestrou mais de uma dúzia de pacotes com mais de 500 milhões E, basicamente, eles substituíram, eu acho a descrição do pacote por sua própria mensagem, e isso foi autorizado a comprometer, basicamente, modificar os pacotes, e ela foi empurrada cada vez mais. Assim, os desenvolvedores que baixassem os pacotes obteriam o pacote malicioso. E só para mostrar o quão perigoso isso é, pessoal, se você não estiver usando algo como autenticação multifatorial, se estiver apenas abrindo suas senhas compartilhadas, é assim que isso aconteceu E, você sabe, isso só mostra o quão perigoso é que pessoas, que estão completamente abertas, que não têm controle de acesso, possam realmente pegar malware. As pessoas pensam em malware. Eles pensam em algo que entra na Internet ou por e-mail, certo? Eles não percebem que sua cadeia de suprimentos de software, que é seu pacote, suas plataformas construídas também podem ser usadas para inserir códigos maliciosos em seu ambiente e no ambiente de seu cliente, que pode causar um grande problema de reputação à sua empresa Então, lembre-se de todas essas coisas, por favor. E agora, então, o que eu queria falar antes, confusão de dependência, se você se lembra Então, esses são como um tipo especial de ataque. Eles exploram como os gerenciadores de pacotes estão baixando e instalando pacotes Então, o que um atacante faz é publicar um pacote malicioso um repositório público de pacotes com o mesmo nome de um pacote popular, que está sendo E o que acontece é que quando você solicita esse pacote, se você não configurou seu repositório de pacotes, o que ele vai fazer é ir primeiro à Internet e verificar se existe um número de versão maior Então, supondo que você esteja usando versão um em seu repositório privado, o atacante colocará o mesmo nome e colocará a Portanto, o repositório de pacotes, se você não o configurou corretamente, ele baixará esse pacote malicioso É por isso que é chamada de confusão de dependência, certo? Estamos explorando a forma como essas coisas funcionam. Lembre-se, temos repositórios públicos e repositórios privados, certo? Desculpe. Portanto, repositórios privados são hospedados internamente, mas você pode ter repositórios públicos como Node Packet Manager e tudo Assim, os atacantes públicos podem descobrir rapidamente quais são os pacotes comuns e mais populares e podem enviar rapidamente muitos e muitos pacotes maliciosos com o mesmo nome E isso é muito, muito perigoso porque, se você não o configurou corretamente, os invasores podem criar um pacote malicioso com o mesmo nome um pacote legítimo e enviá-lo para esses repositórios de pacotes populares Então, quando um desenvolvedor solicita uma dependência legítima, o gerenciador de pacotes busca esse pacote malicioso E essa é uma ótima maneira de enviar malware. Então é assim que vai parecer, certo? Você tem um repositório público de pacotes. O atacante vai lá Ele diz: Ok, esses são os pacotes mais comuns. Vou lançar minha própria versão com o mesmo nome, mas vou colocar um número de versão maior do que o atual. Versão três, versão quatro, versão cinco, certo? E o que acontece? Então, o desenvolvedor vai até lá. Ele diz, eu quero o pacote XYZ para o registro privado. Eles não configuraram esse registro privado para usar apenas os privados. Portanto, por padrão, o comportamento vai primeiro para o repositório público Ele vai dizer e vai buscar o pacote errado Não vai buscar o interno. Vai dizer: Ei, eu tenho a versão um na Internet, há a versão dois. Então, vai dar o que você chama de mais recente. Mas esse foi malicioso. Este foi empurrado pelo atacante. Portanto, se for bem-sucedido, a confusão e o ataque de uma dependência podem ter consequências seriamente confusas Ele pode infectar todos os clientes que instalam o pacote malicioso e, em seguida, eles podem ser atacados porque foram comprometidos por malware ou ransomware, e pode ser mitigado garantindo que os desenvolvedores revisem e verifiquem seus pacotes e mantenham suas dependências atualizadas, mas com dependências privadas mas com Portanto, é um tipo de ataque muito único com o qual muitas pessoas não estão familiarizadas. E isso é muito perigoso na forma como funciona. Então, isso encerra esse particular, o que você chama de área de risco de segurança da cadeia de suprimentos Na próxima lição, falarei sobre um estudo de caso. Lembre-se de que falamos sobre o comprometimento da plataforma de construção e o pipeline do CICD. Vamos falar sobre as veias solares e as do código CV. Então, nesta lição, que foi bastante longa, falamos sobre os tipos de software, os riscos da cadeia de suprimentos, os diferentes pontos de entrada dos ataques e o impacto que pode acontecer. Então, com o impacto, vou dar mais contexto, analisando os ataques reais que aconteceram e as consequências muito perigosas que aconteceram por causa desses ataques. Então, muito obrigado. Reserve um tempo para, tipo, ler esta lição novamente, se precisar. Para que você tenha uma boa base, nos vemos na próxima lição. Obrigado. 7. SolarWinds: Olá, pessoal. Bem-vindo. Bem-vindo a esta lição, que trata de entender o ataque de ventos solitários. Tenho certeza que você deve ter ouvido falar sobre o ataque à cadeia de suprimentos de ventos solares. É um dos ataques mais devastadores que já aconteceram, pelo menos em 21 anos trabalhando em segurança cibernética, o impacto e a quantidade de empresas comprometidas Solar wins é facilmente um dos maiores ataques cibernéticos que já aconteceram. É muito possível que você esteja fazendo esse meu curso, principalmente por causa do ataque cibernético do vento solar, vou ser honesto, sim. Então essa é a razão pela qual eu queria falar sobre ventos solares. Você não pode falar sobre segurança da cadeia de suprimentos sem falar sobre o ataque cibernético solar, eólico e estudos de caso, e, você sabe, realmente dar um passo atrás e analisar algumas dessas questões realmente ajudará a contextualizar os riscos de segurança da cadeia de suprimentos de que eu estava falando, porque então você pode dar uma olhada na perspectiva de um incidente real que na perspectiva de um incidente real aconteceu e só para ter uma ideia melhor de como essas coisas são perigosas, certo? Então, vamos seguir em frente. Então, quando falamos sobre vitórias solares, é, como eu disse, um dos ataques mais devastadores da cadeia de suprimentos de todos os tempos É como reconhecer, você sabe, todos os grandes incidentes de segurança cibernética e realmente mostra as vulnerabilidades que existem na cadeia de suprimentos do sofá e as consequências, como o impacto As vitórias solares tiveram um impacto global. Ele está espalhado por governos e organizações em todo o mundo, simplesmente por causa do quão comum é o software de energia eólica solar, certo? E, na verdade, muitas OSCs, milhares e milhares de empresas, elas reavaliaram a segurança da cadeia de suprimentos e sua confiança em fornecedores terceirizados em todos os setores E a energia solar vence, se você não estiver familiarizado, é uma empresa de software de gerenciamento de rede amplamente usada e que foi alvo ataque altamente sofisticado à cadeia de suprimentos. Basicamente, os atacantes conseguiram se infiltrar no processo de desenvolvimento e distribuição do software solar eólico processo de desenvolvimento e distribuição do e inserir códigos maliciosos em suas Portanto, não foi apenas um ataque direto às vitórias solares, mas um ataque indireto às milhares e milhares de empresas. Em que eles confiam. Então, a atualização maliciosa foi disfarçada como uma atualização legítima de software para o Solar Wins, foi distribuída para milhares de clientes do Solar Wins e entrou sorrateiramente nas redes de tantos clientes do Solar Win, certo nas redes de tantos clientes do Solar Win E é realmente um lembrete de como é importante proteger a cadeia de suprimentos de software e de como você realmente precisa continuar avaliando, continuar fazendo essas avaliações de risco Então isso é o que parecia certo. Como eu disse, o solar ganha ofertas como e gerenciamento de desempenho de ID sistema de monitoramento e gerenciamento de desempenho de ID chamado Orion, e é usado por clientes em todo o mundo E a Orion geralmente tem acesso aos registros e dados de desempenho do sistema dos clientes E é por isso que provavelmente os atacantes o atacaram, porque foi por isso que ele se tornou vítima do ataque à cadeia de suprimentos Então, o que eles fizeram foi usar malware personalizado projetado para o ciclo de construção dos ventos solares. E eles conseguiram substituir os arquivos. Algumas pessoas dizem que são milissegundos e basicamente conseguiram substituir os arquivos por suas próprias atualizações maliciosas E houve um ataque muito, muito sofisticado , do jeito que eles fizeram, certo? Chamava-se The Malway, chamava-se Sunspot, e permitia que os hackers basicamente monitorassem O ambiente de desenvolvimento dos ventos solares. E sempre que pagavam suas contas, eles as substituíam por sua própria atualização maliciosa Então, basicamente, era uma porta dos fundos. E esse backdoor, quando as atualizações eram enviadas para a atualização maliciosa, agora eles tinham acesso a milhares e milhares de clientes porque conseguiam se infiltrar em outros clientes porque haviam colocado sua própria atualização maliciosa na atualização solar wins Então, as vitórias solares os ajudaram a distribuir esse malware, certo? E você pode entender por que Slewns era um alvo tão promissor para esse tipo de ataque à cadeia de suprimentos, certo? Por que eles possivelmente seriam assim? Bem, porque honestamente, como eu disse, muitas empresas multinacionais e agências governamentais usam o software Oon Tudo o que os hackers precisavam era instalar essa atualização maliciosa, e a Solewns a distribuiria, certo E como as empresas confiam nelas, elas as instalariam Então era, tipo, muito bonito do jeito que não bonito por causa do dano que aconteceu, mas muito bonito da forma como foi projetado. Você podia ver o quão inteligentes esses caras eram, certo? E o que aconteceu depois disso? Uma empresa de segurança, acredito que foi a Frey. Eles detectaram esse malware que estava se espalhando para os clientes e conseguiram identificar o pacote de atualização do sunburst Eles identificaram em K que esse pacote de solvinas foi comprometido, certo E uma vez detectados, eles imediatamente emitiram essa atualização, e vários clientes puderam detectar o mesmo comportamento acontecendo em seu enami E então eles perceberam o quão ruim era o spread, certo? Ele infectou milhares e milhares de clientes por meio deles. E a Solns lançou correções rápidas para eliminar esse backdoor Mas, você sabe, quero dizer, acho que cerca de 18.000 clientes da Solar Vines aplicaram a atualização Sunburst, que então permitiu que os atacantes acessassem remotamente os clientes da Solar Vines aplicaram a atualização Sunburst, que então permitiu que os atacantes acessassem remotamente os dados de seus clientes. E, você sabe, nós tivemos, eu acho que o Departamento de Saúde, Tesouro e Estado dos EUA, todos eles estavam infectados, grandes nomes, você sabe, como grandes empresas de tecnologia, todos eles foram afetados pelo malware E o ponto principal disso é que a forma como eles conseguiram divulgá-lo mostrou o ponto cego da confiança nas atualizações de software, e isso realmente fez com que não apenas a Solar Vines, mas outras empresas analisassem o processo de reconstrução Se você é uma empresa que está distribuindo software para outras empresas, certo? E você está emitindo atualizações automaticamente. Você precisa realmente pensar sobre o que aconteceria se houvesse um malware dentro disso? Como faço para ter certeza de que isso não aconteça comigo? E esse é o objetivo principal de analisar esse estudo de caso. E foi isso que aconteceu depois disso. Então, muitas empresas analisaram suas contas de software, tipo, como faço para ter certeza de que não tenho alguém entrando sorrateiramente E foi aí que começou a surgir o conceito de compilações reproduzíveis, que discutiremos que discutiremos Mas eu só queria te mostrar o impacto. Como no governo Biden, eles emitiram uma ordem executiva para melhorar a segurança cibernética do país Você pode ver a data de 12 de maio de 2021 e eles tinham um requisito específico sobre segurança da cadeia de suprimentos de software. Eles disseram que mencionaram o fato de que esse tipo de software não tem transparência. Não sabemos se o malware está chegando, e realmente precisamos implementar controles para garantir que a segurança da cadeia de suprimentos de software esteja protegida, certo? E o mais chocante foi que a decisão da Landmark, a Securities and Exchange Commission, SEC, na verdade acusou o CSO de vitórias solares de fraudes e falhas de controle interno relacionadas às práticas segurança cibernética da empresa Eles disseram que compraram acusações de que você havia distorcido o quão segura era a energia solar Então, na verdade, eles os compraram. Eles disseram que ele enganou os investidores sobre as práticas de segurança cibernética da empresa Ele não divulgou os riscos e o controle inadequado. Então, basicamente, ele exagerou o quão seguros eles estavam e não revelou todos os riscos E isso foi como uma mudança significativa na forma como as pessoas veem a segurança cibernética Agora, as OSCs percebem que são realmente responsáveis, você sabe, não apenas por multas, mas na verdade E avaliará que as OSCs realmente precisaram dar um passo atrás. E é por isso que a segurança da cadeia de suprimentos de software se tornou tão proeminente hoje em dia. E espero poder fazer você entender quão importante era a vitória solar. Agora, como se proteger? Essa é uma pergunta de $1.000.000, certo? Como você garante que sua empresa não se torne a próxima, digamos, vitória solar? Agora, infelizmente, muitas boas práticas convencionais de boas práticas convencionais de segurança não conseguem combater esse tipo de ataque. Por exemplo, o que as pessoas dizem que apenas versões assinadas instaladas, você sabe, atualizações de software assinadas digitalmente que vêm da energia solar vence Isso não vai ajudar porque o software é sinalizado. É proveniente de uma empresa legítima. Não é como se um atacante estivesse entrando sorrateiramente. Está vindo de uma empresa confiável, certo? Atualize seu software para a versão mais recente, como as pessoas dirão, certo? Porque o software atualizado era o que era malicioso. E isso fazia parte do processo de construção válido. Então foi aí que o problema começou a surgir. Você nem pode dizer, revise o código-fonte porque eles estavam comprometendo o processo de construção, certo? Então, algumas das principais coisas que você pode fazer é, junto com suas boas práticas de segurança, como monitoramento e fortalecimento, garantir que você tenha controles que monitorem o comportamento. As organizações realmente precisam fortalecer seu processo de construção contra esse tipo de ataque, certo garantir que você tenha controles que monitorem o comportamento. As organizações realmente precisam fortalecer seu processo de construção contra esse tipo de ataque, As organizações realmente precisam fortalecer seu processo de construção contra esse tipo de ataque E eles precisam garantir que o ambiente de construção não seja comprometido. Eles garantiram que falaremos mais sobre isso quando falarmos sobre a proteção da cadeia de suprimentos de software Mas o ambiente de construção precisa ser protegido. Você precisa garantir que as pessoas não possam simplesmente comprometer o ambiente e inserir suas próprias atualizações maliciosas, e você precisa estar monitorando. E as duas coisas mais importantes que você pode fazer são verificar compilações reproduzíveis e listas de materiais de software Vou entrar em detalhes sobre suas listas de materiais de software, mas a contramedida mais forte você pode ter é chamada de construção reproduzível, que é uma construção que sempre produz as mesmas saídas para que os resultados da construção possam os resultados da construção Então, basicamente, compilação reproduzível verificada é onde alguém independente pode produzir uma compilação a partir do código-fonte e verificar se os resultados da compilação vêm do mesmo código-fonte que você está reivindicando Quase, eu diria que 99% dos softwares atuais não são assim. Mas no caso dos ventos solares, o que teria acontecido? Por exemplo, como seria uma compilação reproduzível verificada? Apenas pelo nome que você pode ver, você pode verificá-lo e reproduzi-lo Então, se você tiver acesso ao código-fonte e à compilação. O que as faturas reproduzíveis verificadas fazem? Eles basicamente oferecem uma contramedida muito, muito forte contra ataques como solares em que os binários não correspondem ao código-fonte Por quê? Porque um atacante inseriu um código malicioso em um binário, certo? Porque no caso das veias solares, elas atacam o binário, não o código-fonte. Portanto, uma das vantagens das compilações reproduzíveis é que, quando essas duas construções acontecem, você pode construí-las de forma independente, e ambas produzirão o mesmo artefato pouco a pouco E isso lhe dará a confiança que nenhum malware foi injetado nisso E essa é toda a motivação por trás desse conceito. E o que teria acontecido com as moedas solares se as vitórias solares tivessem implementado contas reproduzíveis, seria necessário que elas gerassem um bom binário partir da fonte e o comparassem com o binário distribuído E não combinaria, certo? Portanto, essa discrepância introduzida teria sido introduzida pela inserção do código malicioso e teria sido detectada porque, e teria sido detectada quando eles estão distribuindo o binário, ele não corresponderia à compilação reproduzível verificada . E isso poderia ter alertado os desenvolvedores sobre a presença de alterações não autorizadas que, ei, o processo de construção foi comprometido Há algo extra adicionado ao binário, que não existia antes. É 100% infalível? Absolutamente não. Porque lembre-se, os atacantes já estavam dentro do ambiente, certo Portanto, você também precisa de outros controles de segurança. Mas esse tipo de construção verificada e reproduzível oferece um tipo de controle muito, muito forte contra ela Vou colocar o link também para todo o site que pretende esse tipo de controle Mas lembre-se de que, se você estiver distribuindo atualizações para milhares de clientes e precisar desse tipo de verificação, a esteira reproduzível verificada é um controle muito, muito forte contra Então, espero que isso tenha sido útil para você. Demos um passo atrás e observamos com atenção o ataque dos ventos solares. Agora, vamos dar uma olhada em outro ataque e ver como isso aconteceu e foi um tipo diferente de ataque dos ventos solares. Mas só para dar mais contexto sobre como esses ataques acontecem, obrigado, e nos vemos na próxima lição. 8. Codecov: É mais Olá, pessoal. Bem-vindo a esta lição. E agora continuando com o anterior, onde demos uma olhada nos ventos solares. Agora vamos para outro recente, que é o Dov Attack Agora, os ventos solares, se você se lembra, comprometem o processo de construção, certo? Os atacantes conseguiram comprometer o processo de criação e injetar Com este, é mais sobre o pipeline do CICD. Se você não está familiarizado com Codkov, espero que eu esteja pronunciando o nome, se eles não ficarem com raiva Mas sim, é uma ferramenta de cobertura de código. O que isso significa? Basicamente, a verificação de quanto do seu aplicativo está sendo testado, sabe? exemplo, quando você está criando aplicativos modernos quando usamos o CICE, usamos testes automatizados, certo? Nós conversamos sobre isso antes. E queremos ter certeza de que cada linha de código foi testada, certo, e cada FOG, e isso requer uma estrutura de teste bastante madura É aqui que entra o Cod Cov e pode ajudar você a saber quais linhas de código não estão sendo abordadas em seu ambiente de CI E é assim que eles se comprometem, eles comprometem este, o que lhes permitiu comprometer outros ambientes também. Agora, se você se lembra do vento solar, solar wins era mais direcionado e voltado para a espionagem contra agências governamentais e grandes corporações, certo Tinha um motivo geopolítico claro, como um ataque de um estado-nação Essa é mais parecida com uma ampla violação de segurança que afetou indiscriminadamente uma grande variedade de empresas Eles não se importavam com quem estava sendo comprometido. E eles estavam focados em roubar informações dos ambientes de desenvolvimento da Soffe Oh, é disso que estamos falando agora. O ataque do Code Cv, foi descoberto em abril de 2021, se bem me lembro. Sim, era como uma enorme praia de segurança. E, como eu disse, essa é uma ferramenta de cobertura de código muito popular usada por desenvolvedores de software para avaliar a eficácia de seus testes. E ele se integra a vários sistemas de controle virgens. Ele gera relatórios para que você saiba o quão bem os testes de software estão cobrindo sua base de código, certo? Então, basicamente, os atacantes obtiveram acesso não autorizado aos sistemas Code CoF Como eles exploraram nossa vulnerabilidade. Acho que na criação da imagem do Docker, não precisamos saber os detalhes do Docker Mas, basicamente, eles modificaram o script do carregador do Bash. Vou ver detalhes disso. O que lhes permitiu fazer isso permitiu que eles exportassem secretamente informações confidenciais dos clientes da Cod C, certo A partir daí, especificamente dos ambientes de CI, ambientes de integração contínua. E quais são essas informações, credenciais, ID de usuário, senhas, chaves de token e outros dados que eles poderiam usar para conceder acesso adicional e não autorizado Acho que não foi detectado por vários meses, 31 de janeiro de 2021 até abril de 2021 E qualquer pessoa que baixou o script comprometido do carregador do Bash, basicamente, expôs suas informações sem saber Acho que afetou cerca de 29.000 clientes, grandes nomes do setor, sabe? E, novamente, como sempre, todo mundo acordou com ataques na cadeia de suprimentos Desculpe, e todo mundo acordou com ataques na cadeia de suprimentos e, de repente, percebeu quanto essas coisas são críticas E Kotov notificou os usuários afetados e eles revogaram e emitiram as chaves e tudo mais, e eles concordaram em ter seu Mas se você der uma olhada, é assim que basicamente parecia, certo? Então, vamos nos concentrar em, se você se lembra do ambiente de CI, um ambiente de integração contínua. Podemos fazer muita automação poderosa aqui para testar nosso aplicativo, certo? E você também confia em muitas coisas externas, certo? Bancos de dados, sistemas de pagamento, infraestrutura em nuvem. Quando você está fazendo o teste, todos esses componentes precisam ser acessados a partir do pipeline para que eles possam criar e testar o aplicativo. Então, basicamente, seu pipeline de CI precisa ter acesso a quais segredos e credenciais para que eles possam obter acesso E, normalmente, espero que, se você estiver criando um ambiente de CI, use a infraestrutura de teste , não o byte de produção, mas, com base na minha própria experiência, é muito comum que as credenciais de produção sejam usadas porque as pessoas querem ter certeza de que estão fazendo o teste corretamente e que o teste está cobrindo o máximo possível Então, infelizmente, muitas vezes essa informação pode acontecer. Portanto, é muito provável que o ambiente de CI tenha acesso a informações muito confidenciais. Então, atacando Kotkov, foi isso que eles fizeram, certo? Eles infectaram o malware e comprometeram a ferramenta de teste Eles têm acesso a todas as credenciais. Dentro do ambiente de CI para todos os clientes da Cdf. E, basicamente, se você se lembra, eles comprometeram um script Bash, que é apenas um conjunto de instruções sobre o que você escreveria se já tivesse feito terminal ou Bash, mas escrito de forma Eles adicionaram uma única linha de código, que deveria enviar todas as variáveis de ambiente do CI para o servidor remoto do atacante Você entende que eles estão basicamente extraindo esses dados silenciosamente. E agora você pode entender se eles tivessem cerca de 23.000 clientes, qualquer pessoa que estivesse usando a versão comprometida do Cod Cov entre 31 de janeiro e 1º de abril teria sido afetada E grandes corporações foram afetadas e, na verdade, divulgaram basicamente documentos para seus clientes sobre como se recuperar desse ataque. E o que eles fazem, o que eles fizeram depois de terem comprometido isso Então, eles não os atacaram diretamente. Eles poderiam ter conduzido vários ataques a partir daí, certo? Mas o que eles fizeram foi realmente comprometer repositórios do código-fonte porque obtiveram as credenciais A fonte. E eles conseguiram acessar então seus repositórios de código-fonte E eles conseguiram descobrir porque esses repositórios podem ter, na verdade, credenciais de produção Então você pode ver como esse ataque está ocorrendo em cascata, certo? Primeiro, eles comprometeram Kotkov. Eles obtiveram as credenciais dos repositórios de código-fonte dos clientes Eles comprometeram esses repositórios. Eles tiveram acesso à produção. E eles se levantaram e até perceberam que haviam notado a atividade suspeita em outros repositórios privados Eles estavam sendo clonados para alguns usuários não autorizados, e isso mostra como era simples, KotkVuu comprometido Use credenciais roubadas do Git, acesse repositórios privados, use essas credenciais roubadas e, em seguida, você poderá começar a escaneá-los em busca e, em seguida de informações confidenciais. Só para mostrar como esse ataque foi maravilhosamente simples e como eles conseguiram comprometer tantos clientes usando isso Novamente, como mencionei , teve um impacto global. grande quantidade de clientes estavam trocando seus segredos, seus depósitos de código-fonte e os atacantes conseguiram acessar depósitos não autorizados e, infelizmente, continham código-fonte e credenciais internas Uma grande quantidade de clientes estavam trocando seus segredos, seus depósitos de código-fonte e os atacantes conseguiram acessar depósitos não autorizados e, infelizmente, continham código-fonte e credenciais internas . Novamente, agora você tem uma ideia melhor do que pode ser feito. Obviamente, é diferente dos ventos solares, onde o ambiente de construção foi comprometido. Mas aqui, novamente, você precisa melhorar a segurança do meio ambiente. Não consigo me estressar o suficiente, você precisa garantir que seu ambiente esteja Mantenha seus repositórios de código-fonte limpos. Não coloque credenciais lá em seu repouso. Se alguém conseguir comprometê-los, ele pode usá-lo como um ponto de partida para o seu ambiente, certo? Coloque controles de filtragem e vazamento de dados. Como você sabe se alguém está vazando dados silenciosamente Você pode até mesmo fortalecer seus repositórios de código-fonte por meio de autenticação multifatorial e Então, se você sabe que as solicitações vêm apenas de uma área específica, você pode realmente colocar restrições de IP, certo? Portanto, mesmo que tenham as credenciais, não poderão acessá-las Fortalecimento da segurança dos dutos do CICD, garantindo que eles tenham apenas o acesso Você não quer dar a eles credenciais de administrador em todo o ambiente, certo? E, claro, evitando credenciais codificadas. Então, esse foi, novamente, outro estudo importante, outro ambiente que foi comprometido devido a um ataque à cadeia de suprimentos, e espero que você tenha visto uma imagem diferente agora Eu escolhi este deliberadamente porque é diferente de como os solares foram comprometidos Agora você tem uma boa ideia e espero que tenha preparado o terreno para entender como podemos protegê-la Você tem uma boa ideia dos riscos e, no contexto dos ataques reais, vê como esses riscos se materializam Então, agora podemos passar para a próxima lição, que é sobre realmente proteger a cadeia de suprimentos de software Agora podemos passar para a parte boa, que é, na verdade, proteger e mitigar esses riscos Então, muito obrigado, e nos vemos na próxima lição. 9. Crowdstrike: Olá, pessoal. Bem-vindo. Bem-vindo a esta nova lição que acabei de enviar sobre a interrupção do CrowdStrike Então, a menos que eu queira dizer, se você não está usando TI ou não está usando nenhum sistema, você já deve ter ouvido falar sobre a interrupção do CrowdStrike, que aconteceu este ano Cloud Strike é uma empresa de soluções de segurança muito, muito popular. Quer dizer, eles oferecem seus produtos exclusivamente para empresas e grandes organizações. Eles são muito, muito famosos no mundo da segurança cibernética. Infelizmente, eles se tornam como um nome familiar. Agora todo mundo os conhece por causa desse incidente. E, basicamente, embora isso não seja como um incidente de cibersegurança, ninguém o comprometeu, mas teve um impacto enorme na cadeia de suprimentos E isso é muito importante. Eu não poderia falar sobre a cadeia de suprimentos de software ou os riscos de segurança da cadeia de suprimentos sem discutir sobre o Cloud Strike. Agora, se você não conhece o CloudStrike, eles basicamente têm um componente chamado CrowdStrike. É como um sensor. Ele usa IA para proteger os ambientes dos clientes, você sabe, identificando e protegendo contra as ameaças mais recentes. E, em poucas palavras, basicamente em 2024, eles introduziram uma nova atualização, certo, que basicamente o novo sensor não conseguiu suportar e travou E, dada a proximidade do sensor CrowdStrike do sistema operacional Windows, isso resultou na falha de todos os sistemas e uma grande interrupção global que afetou quase todos os setores que afetou quase Milhões e milhões de endpoints foram afetados, certo? E isso foi apelidado a maior interrupção de identificação de todos os tempos ou uma das maiores , acho que é a maior simplesmente por causa da natureza e da forma como aconteceu Eu já falei com você sobre a rodseg, é uma empresa de soluções de segurança muito, muito popular Milhões de empresas o usaram e é uma boa empresa. Infelizmente, o nome ficou meio que arrastado pela lama por causa desse incidente Mas, sem dúvida, é uma empresa muito boa, uma empresa de segurança muito, muito, muito madura. Mas, infelizmente, a atualização de software com defeito. Eu conduzi até aquela tela azul da morte. É como um loop em máquinas Windows fazendo com que elas falhem repetidamente. E apesar de multidões estarem implantando a solução, o impacto em todo o mundo foi enorme E, como eu disse, literalmente, aeroportos, portos, vamos dar um exemplo, que tipo de coisas acontecem. Os aeroportos foram afetados. Se você estava viajando em algum momento , você tem minhas condolências Você verá imagens de, tipo, você sabe, em todos os lugares, aeroportos congestionados, milhares de voos atrasados, portos de embarque sendo afetados, supermercados, hospitais, eu moro no Reino Unido e o NHS, enviando uma declaração dizendo que eles não atender clientes no momento pacientes por causa do impacto: empresas de identificação, escritórios governamentais, etc . ligado. Quero dizer, em todo o mundo, grandes fechamentos, atrasos estavam acontecendo, milhares de voos parecidos E, basicamente, mostra a natureza interconectada da cadeia de suprimentos de software E mesmo sendo a parte impressionante, isso não é como um ataque. Foi apenas um erro, mas mostrou o impacto que pode acontecer, e isso é apenas um exemplo. Quero dizer, tenho certeza que você teria visto, certo? Mas isso mostra o quão perigosas são as dependências em todo o mundo em relação a esse tipo de software, certo? Então, o mundo, como eu disse, hospitais, empresas australianas, disseram que tinham uma fatura de danos de cerca de 1 bilhão, certo? E bancos, mídia, NHS. Então, o impacto em todo o mundo foi incrível. Mas é muito, muito importante separar o fato da hipérbole E eu não gosto disso da forma como muitas vezes foi formulado. E como as pessoas começaram a dizer que foi um ataque cibernético. Isso teve um impacto cibernético na disponibilidade, é claro, e não foi como um ataque de um criminoso. E eles emitiram um relatório de causa raiz, que você pode ver. E eles mencionaram como isso aconteceu. Basicamente, o censor. Era como esperar, eu acho, cerca de 20 campos de entrada, mas tinha a atualização mais recente em 21 campos de entrada, e a incompatibilidade de contagem foi o que causou uma falha global E como o intérprete esperava 20 valores e, quando começou a acessar o 21º, produziu um anúncio de memória fora dos limites Você sabe, essas coisas. E como está tão bem integrado ao código do Windows, quando travou, derrubou todo o sistema operacional, e a tela azul estava piscando em todo o mundo, em supermercados, aeroportos, em todos os lugares que você possa imaginar, basicamente estava piscando , resumindo: faltavam testes adequados para atualizações de sensores Isso contornou seus novos processos. O teste não foi um impedimento. E muitas pessoas começaram a dizer que isso agora poderia ser explorado E eu recomendaria a leitura das postagens do blog da CrowdStrike nas quais eles abordaram e refutaram as alegações sobre o sensor de segurança Falcons Embora fosse uma falha de memória fora dos limites, foi determinado que ele não poderia ser explorado para escalonamento anterior E eles forneceram uma análise detalhada da causa raiz que mesmo esse bug não permite a execução de nenhum programa, e mencionaram os outros controles que tinham, como fixação de certificados, validação de soma de verificação, controle de acesso e detecção antiadulteração , antiadulteração E eles mostraram que vou vincular o relatório aqui, o blog aqui, e eu definitivamente recomendo que você o leia, porque se você for analisar essas situações, certifique-se de que está analisando corretamente e não está inserindo coisas que não existiam naquela época. E a CoudStak afirmou o compromisso com a segurança e mencionou que seu programa de recompensa por bugs e mencionou que seu programa de recompensa por bugs também foi aprimorado. Mas as lições a serem aprendidas com esse incidente são muito, muito importantes. Então, só para ficar muito claro, atacante, mesmo que isso não tenha sido um ataque, mas os atacantes aprenderão Eles viram o quão prejudicial esse ataque foi o impacto Portanto, você pode, sem dúvida, imaginar que os atacantes se interessaram por esse ataque e pensarão em como podem causar um impacto ainda maior na próxima vez e ganhar algum dinheiro Se você é um fornecedor de soluções. É como no CrowdStrike, você fornece algum agente, algum software para a empresa É bom analisar seus processos de teste. Pense nesse tipo de resiliência. O que acontece se seu endpoint estiver muito próximo ao kernel do Windows e algo acontecer, Faça uma implantação em fases. Não faça uma abordagem de big bang. Não acredito que estou tendo que dizer isso, mas isso parece certo. Não é necessário fazer uma grande implantação, faça-a em fases e faça auditorias independentes de todo o processo CrowdStrike, acho que eles se envolvem com duas empresas diferentes para fazer uma avaliação completa de suas práticas de desenvolvimento de software, testando apenas para garantir que não tenham pontos cegos E do ponto de vista do cliente, se você usa um software como o RoudStrik, em primeiro lugar, eu recomendaria remover a dependência excessiva de eu recomendaria remover dependência excessiva Se você tem um fornecedor que está fazendo tudo e algo acontece com esse fornecedor, você terá um grande problema, Pense nesse cenário e adicione-o ao seu manual de recuperação de desastres Mas eu tenho que ser muito claro. Esse tipo de cenário muito poucas pessoas podem prever. Foi como um incidente do Cisne Negro, certo? Como algo que acontece uma vez a cada duas, três décadas. Mas eu recomendaria pensar em coisas como backups na nuvem ou ter um desktop virtual, que é uma imagem completamente separada dos seus desktops normais, certo? Portanto, se algo acontecer, se houver um caso importante, você poderá se recuperar para o desktop em nuvem. E isso é algo totalmente isolado de sua rede normal Não tem os mesmos agentes. Tem agentes diferentes. Pode custar mais , mas, em tal incidente, você poderá criar uma imagem completamente separada, na qual sua equipe poderá retomar pelo menos atividades limitadas, porque muitas empresas foram completamente fechadas. Os servidores estavam inativos, mas até mesmo os desktops comuns estão inativos porque o Cloud Stoke estava funcionando em todos os lugares, certo Portanto, pense em ter outra imagem na qual você possa implantar e colocar em execução, que seja separada das imagens normais e que não seja afetada pelos mesmos problemas Então, essas eram as coisas que eu queria falar sobre todo mundo, só para mostrar a vocês, porque o CrowdsTK foi como um grande incidente Ainda está se desenrolando. Muitas notícias estão saindo. Mas pense nesses incidentes, especialmente quando estiver pensando em proteger seu software para aplicar a cadeia Muito obrigado Te vejo na próxima aula. 10. Protegendo a cadeia de suprimentos — 1: Olá, pessoal. Bem-vindo. Bem-vindo a esta lição, que faz parte de uma aula com várias partes, que tratará proteção da cadeia de suprimentos de software Agora, espero que você tenha uma boa ideia do que é a cadeia de suprimentos de software. Você tem uma boa ideia dos riscos que podem acontecer. Você viu ataques reais e como eles foram comprometidos, certo? Então, agora vamos analisar a implementação de controles na cadeia de suprimentos de software. Analisaremos os controles e práticas de segurança, alguns dos erros comuns que as pessoas cometem quando iniciam sua jornada de segurança na cadeia de suprimentos de software. Em seguida, também examinaremos alguns padrões e estruturas, que você pode aproveitar para obter o melhor benefício Ao criar um programa de segurança da cadeia de suprimentos, você não precisa criar do zero w. Você pode aproveitar o que você já tem. Então, se você der uma olhada, isso é o que discutimos anteriormente. Lembra? Esse era o ambiente com os riscos de ter um ambiente de desenvolvedor, que pode ser comprometido Você tem um código inseguro, a plataforma de compilação está comprometida, o repositório do código-fonte, as dependências, você não poderia estar fazendo testes de segurança Você teve uma violação de dados no ambiente de pré-produção e até mesmo seu ambiente de produção pode ficar comprometido Então é aqui que entra a segurança da cadeia de suprimentos de software para basicamente proteger todos esses riscos, certo? E se você se lembra de quando começamos o curso, falamos sobre segurança da cadeia de suprimentos de software, certo? Basicamente, é garantir a integridade, a segurança, a disponibilidade a confiabilidade de todos os componentes e processos envolvidos. Em seu desenvolvimento, distribuição e manutenção de software. Você quer ter certeza de que ninguém mexa com seu software, que ninguém o adultere E muito, muito importante quando falamos sobre uma cadeia de suprimentos, não estamos falando apenas sobre o código-fonte direto, certo? Também estamos falando sobre bibliotecas, ferramentas e serviços de terceiros e sobre a infraestrutura, porque vejo que muitas vezes não é sua infraestrutura que está reduzindo o comprometimento. São os fornecedores ou os fornecedores. Então, como garantir que seu programa de segurança da cadeia de suprimentos cubra tudo? Então é isso que você precisa ter em mente. E quais são , infelizmente, alguns dos erros comuns que as pessoas cometem e que sempre me dão dor de cabeça quando falo com clientes: segurança da cadeia de suprimentos. O que não é? Não é uma ferramenta ou produto. Por favor. Qualquer pessoa que diga que qualquer fornecedor que venha até você e diga: Compre meu produto e você terá segurança da cadeia de suprimentos de software, isso é totalmente falso Isso vai te ajudar. Sem dúvida, isso vai te ajudar, mas não é. É parte da segurança da cadeia de suprimentos de software, não o objetivo final. Está bem? Você não pode simplesmente se tornar sua cadeia de suprimentos de software não segura porque você comprou uma solução por milhões de dólares e a implementou. Não é uma certificação. Qualquer um diz que use essa lista de verificação ou use essa coisa, e agora sua cadeia de suprimentos está protegida Novamente, não é assim que funciona. Também não é uma lista de verificação do fornecedor. Algumas pessoas fazem uma avaliação de risco do fornecedor e acham que agora sua cadeia de suprimentos de software está segura E também não é uma atividade única. É algo que você precisa avaliar continuamente os riscos E o último é o MyF, habilitando o MFA. Novamente, não há nada de errado em habilitar a MFA. É uma parte muito importante da segurança do fornecimento de software. Mas as pessoas acham que , como habilitamos MFA, agora nosso ambiente está seguro Não tenho ideia de como isso acontece, mas por favor, não cometa esse erro, certo? Então, como eu disse, pense na definição que falei com você anteriormente, esta, tenha isso em mente e não se confunda com esses equívocos E quando falamos proteger a cadeia de suprimentos de software, estamos falando sobre vários controles, certo? E é nisso que vou me concentrar nessas aulas. Falaremos sobre práticas de codificação segura, o que você pode fazer, componentes de terceiros, fortalecimento de seu ambiente, segurança do pipeline do CICD, testes e digitalização de segurança reais, a construção de material de software, L BOM, se você não estiver familiarizado, e, é claro, o gerenciamento do fornecedor West Todas essas coisas se juntam para uma segurança eficaz da cadeia de suprimentos de software e, em seguida, veremos como criar um programa real também. Então, vou abordar todos esses itens. Eu não vou te bombardear com informações. Vamos passo a passo construindo seu ambiente, certo? Então, no final, seu ambiente ficará assim. Você terá controles em vários níveis e, em seguida, terá um programa adequado em execução, que garante que todas essas coisas sejam cuidadas e avaliadas os riscos. Então, como eu disse, vamos fazer isso em passos largos. Nos vemos na próxima lição. Começaremos a mergulhar profundamente nesses controles. Muito obrigado e nos vemos na próxima lição. 11. Protegendo a cadeia de suprimentos — 2: Olá, pessoal. Bem-vindo. Bem-vindo de volta à aula. E continuamos nossa lição anterior qual falamos sobre proteger a cadeia de suprimentos e os controles de segurança, podemos implementá-los Então, se você se lembra, mostrei esses controles básicos que incluem práticas de codificação seguras, componentes de terceiros, ambientes de acumulação, pipelines de CICD, testes Todos eles, vamos dar uma olhada um por um. Então, vamos seguir em frente. E se você se lembra, eu mostrei o diagrama também assim: se anteriormente tivéssemos os riscos aparecendo neste diagrama, mas se você colocar os controles, esses controles que você está vendo no diagrama, esses riscos são mitigados Então, vamos começar com o primeiro, que é a codificação segura Se você se lembra, falamos sobre os riscos, certo? E eu disse que o código inseguro é a raiz de todo mal Codificação tão segura, é por isso que precisamos discuti-la primeiro. Codificação segura no contexto da segurança da cadeia de suprimentos refere-se aos desenvolvedores que desenvolvem software de forma que você garanta que nenhuma vulnerabilidade esteja presente no código em nenhum momento Está bem? E isso requer controles, tanto de conscientização quanto de controles técnicos, certo? Porque lembre-se de que existem várias maneiras pelas quais as vulnerabilidades podem ser introduzidas Então, vamos falar sobre treinamento de código seguro e como integrar o feedback de segurança ao próprio ID, que é uma parte crítica que muitas pessoas perdem. Vamos falar sobre como as revisões seguras de código podem acontecer. E, claro, o teste de segurança do código que é submetido ao SAST e ao dust Se você trabalha com segurança cibernética, tenho certeza de que está familiarizado com isso Então, primeiro, vamos começar com o treinamento de código seguro. Segurança A conscientização sobre código inseguro é um começo muito, muito importante Você precisa informar seus desenvolvedores sobre código inseguro e, tipo, os perigos dele, certo Há muitos, muitos bons treinamentos disponíveis. Os dez melhores sistemas operacionais são a referência do setor. Tenho certeza de que, se você trabalha com segurança cibernética, já deve ter ouvido falar disso Então, eduque-os, fale sobre treinamentos como esse, mostre a eles, converse com eles sobre as inseguranças, pode ser, mas muito, muito importante Por favor, não faça com que morra usando o PowerPoint, que é como quando você os entrega como um documento de PowerPoint de 200 páginas Acredite em mim, ninguém vai se lembrar disso. Mostre a eles, na verdade, mostre-lhes trechos de código inseguros e mostre quais são as vulnerabilidades Mostre a eles que, se você corrigir isso no próprio código, quanto tempo e esforço serão economizados, em vez de alguém descobrir isso mais tarde e depois corrigi-lo e a quantidade de tempo desperdiçada, certo? Portanto, há muitos, muitos treinamentos muito bons disponíveis sobre código inseguro, OVA, coisas como injeção de SQL, scripts entre sites, todas scripts entre sites, todas essas coisas. Então, conscientize-os. Mas em um ponto muito, muito importante, e é aqui que as pessoas perdem a oportunidade, comece com a conscientização, mas certifique-se de fazer isso, que é o ponto integrar o feedback de segurança ao ID O ID é o ambiente de desenvolvimento integrado. E com isso, quero dizer, a codificação que eles estão fazendo, eles devem ser capazes de obter feedback de vez em quando Está bem? Você pode dar quantos treinamentos quiser Os desenvolvedores precisam de uma forma de obter feedback em tempo real. Está bem? Quando eles estão desenvolvendo o código, como informá-los de que o código não é seguro, certo? Quais problemas estão presentes? E essa é a maneira mais fácil e fácil de proteger Acredite, você não precisa fazer testes de segurança mais tarde se o desenvolvedor souber imediatamente, se ele fizer uma verificação rápida e ver, olha, esses são os inseguros Talvez meu código que eu escrevi não seja seguro, eu preciso corrigi-lo. Essa é a maneira mais fácil e, se você fizer isso corretamente, verá um grande aumento no seu código de segurança. Está bem? Então, se você pegar um exemplo, se você se lembra que mostrei esse exemplo logo no início, como se fosse um código que não higieniza, a entrada é obtida e, claro, isso pode levar a coisas como injeção de SQL, onde as pessoas podem realmente acessar seus bancos de dados de back-end, seus sistemas operacionais, seus arquivos, se você não Agora, esse é um exemplo de um IDE, como o código do Visual Studio, em que as pessoas digitam corretamente. E essa é uma ferramenta, o que você chama de code-whisperer, que é A. Você pode usar qualquer ferramenta. A propósito, não gosto de mencionar ferramentas específicas Mas se você olhar a captura de tela, então esse era o código, o mesmo código que eu mostrei, se eu colocá-lo aqui e executar uma verificação de segurança, imediatamente, ele me dirá, olha que há uma injeção de SeQL, e ele me dirá a linha Você vê o quão poderoso isso é se você fizer isso corretamente. Então, você pode dizer imediatamente que o desenvolvedor saberá, olha, estou introduzindo uma vulnerabilidade de segurança no código. Preciso corrigir isso antes de enviá-lo ao repositório. E isso levará a um grande aumento na qualidade do seu código de segurança. Novamente, se você se lembra, eu mostrei este o ataque com bomba zip em que as pessoas enviam um arquivo que pode ser potencialmente descompactado em GB de uma grande quantidade de dados e ficar inativo no servidor causa uma negação Então, se você fizer isso, novamente, você verá imediatamente, ele lhe dará um feedback, upload irrestrito de arquivos perigosos, toque que você pode ver na parte inferior e o link do recurso Então, essa é uma maneira muito, muito poderosa. Mostrei o exemplo de código com spur, mas você pode usar muitas ferramentas que integram ao próprio IDE e fornecem feedback em tempo real ao desenvolvedor Sobre o tipo de código que eles estão enviando e por que ele é inseguro Então, por favor, veja isso. Não cometa o erro que 90% das pessoas cometem, que é dar treinamento em código de segurança aos desenvolvedores e esperar que eles encontrem tudo. Não, não vai funcionar assim, dê a eles ferramentas que forneçam feedback em tempo real. Então, depois disso, falamos sobre testes. Agora, se você se lembra, falamos sobre testes, eles passam pelo pipeline do CSED, vão para os testes de qualidade É aqui que você pode apresentar seus diferentes tipos de testes de segurança para o código. O primeiro é o teste estático de valores mobiliários de aplicativos ou SAS. Essa é uma metodologia de teste que analisa seu código-fonte. Ele não executa o programa e geralmente é executado em um estágio inicial durante a própria fase de codificação Ele informará você , então examinará o código-fonte e descobrirá, ei, você está introduzindo alguma vulnerabilidade de segurança Você pode integrar as ferramentas ao pipeline do CICD e ele faz uma análise muito completa da sua base de código Ele examina o código porque ele vai direto ao nível do código O segundo é o DAST, que é uma metodologia de teste de caixa preta, o que significa que o código não tem acesso Ele não está examinando o código-fonte, mas na verdade é executado. Então, durante sua execução, o programa está em execução. Na verdade, simulo ataques externos, como injeção de SQL, e isso é executado posteriormente no pipeline do CICD. Normalmente, quando seu software está em pré-produção ou no ambiente de teste Então, parece as páginas da web e as APIs, e tenta explorá-las Portanto, os dois booster são usados juntos. Não há ninguém tentando dizer que I SASPTO é DAS B SAS e DAS se complementam O DAST identifica as disponibilidades de uma perspectiva diferente e o SAS analisa Então, eles se complementam. Idealmente, você deveria olhar para os dois. E como isso acontece? Então, se você olhar para a esquerda, você tem o ID em que dá treinamento aos desenvolvedores e está colocando feedback no ID. Então, eles estão escrevendo um código seguro. Depois que eles enviam o código, ele entra no pipeline de CI. Ele faz testes, relatórios, construção e o SAST entra Então, parece o código-fonte. Se o código não for seguro, ele volta para o desenvolvedor. Por favor, corrija isso. Se for aprovado, ou seja, se passar o ID, ele passa pelo SAS e vai para o pipeline do CD, onde você tem o produto de teste de revisão Dentro da encenação, você tem os anúncios acontecendo. Esse é um exemplo muito simplista de análise, mas é uma ferramenta muito, muito poderosa Portanto, se você colocar segurança distribuída em todo o seu ciclo de vida, você definitivamente resultará uma maior qualidade de código em seu aplicativo. Então esse foi o SAST e a poeira. Quero abordar o outro exemplo, que é, novamente, um dos exemplos mais cruciais. Acho que é nisso que as pessoas mais pensam quando falam sobre segurança da cadeia de suprimentos de software, que são componentes ou dependências de terceiros Falamos sobre as bibliotecas, certo? As bibliotecas porque ninguém cria aplicativos do zero Você vai depender de bibliotecas, bibliotecas como a Log FoJ, mas ficou comprometido Portanto, todas essas bibliotecas podem introduzir vulnerabilidades, componentes de terceiros e são um grande ponto cego Então, o que você faz aqui? Você usa algo chamado análise de composição de software. Então, o que ele faz é examinar suas dependências. Quais são as dependências? Quais são as bibliotecas de software? Na verdade, elas identificam quaisquer riscos de segurança existentes Assim como o SAST se parece com o código-fonte. Esta se parece com suas bibliotecas de terceiros e diz aos desenvolvedores: Ei, seu componente é vulnerável e pode realmente usá-lo continuamente para descobrir se alguma vulnerabilidade é porque não é estática, certo? Pode ser possível que um componente esteja seguro e amanhã se torne inseguro Portanto, a análise da composição do software SCS monitora completamente e parece o que está acontecendo Então, este é um exemplo da CISA, eles são um site do governo e têm uma publicação muito boa, vou vinculá-la sobre proteger a cadeia de suprimentos de software para desenvolvedores E eles dão essa recomendação. Então, dentro do pipeline, o desenvolvedor talvez ele selecione um componente para download, certo? Não sei, a biblioteca Log four j. Assim, o componente é colocado em um repositório seguro intermediário onde você tem a análise da composição do software Então, ele o digitalizará e informará que, ok, isso é seguro. Não há problemas e ele o moverá para o repositório seguro E a partir daí, o desenvolvedor agora pode fazer login, fazer o check-in e começar a usá-lo dentro do código. Ou, a menos que encontre um problema, ele volta. Portanto, essa é uma maneira muito boa de ver como a composição e análise de software funcionam. E se você olhar novamente no pipeline, ou seja, dentro do ID, você tem código e feedback seguros, e também pode colocar a composição do software e o RSS lá Então, quando o desenvolvedor está acessando uma biblioteca, a composição do software Ss entra em ação e que ela é insegura ou está dentro do pipeline de CI Então, quando o SAST acontece, SAS pode se integrar à análise da composição do software e informar que o código está seguro, mas você está usando uma biblioteca insegura. E por último, o DAST Portanto, ao fazer o DAS, você também pode monitorar as bibliotecas presentes e informar no software em execução quais problemas existem. Então, essa foi apenas uma visão de alto nível da primeira parte, que era o código inseguro e como protegê-lo Então, agora, espero que você tenha uma ideia muito melhor dos controles que você pode implementar para proteger seu código-fonte. Ok, agora na próxima, vamos analisar o fortalecimento do ambiente, como fortalecemos os relatórios de código-fonte, os servidores de faturas, os servidores de pacotes, e vamos analisá-lo em um nível mais alto e ver como ele complementa a segurança do código-fonte do software. Muito obrigado, e eu vou te perguntar na próxima lição. 12. Protegendo a cadeia de suprimentos — 3: Olá. Olá, pessoal. Bem-vindo, bem-vindo. Estamos continuando nossa aula agora. Abordamos a codificação, a codificação branca segura e por que isso é importante e como protegê-la E também falamos sobre dependências de terceiros, certo? Então, vamos continuar nesse caso, e agora vamos falar sobre os ambientes. Se você se lembra, falamos sobre o ambiente do desenvolvedor, o ambiente de pré-produção. E vamos falar sobre os componentes que estão presentes nesta lição. Então, primeiro de tudo, você sabe, fornecer ferramentas práticas, praticamente, garantindo que os desenvolvedores sejam capazes de fazer o que quiserem Esse é um dos maiores desafios, você sabe, em segurança cibernética, porque se você não der aos desenvolvedores o que eles precisam para fazer seu trabalho, os desenvolvedores são muito experientes tecnicamente Eles encontrarão maneiras inseguras de fazer seu trabalho. Então é aqui que a segurança cibernética sempre foi um pouco desafiadora, certo? Vamos dar um exemplo. Empresas e equipes de segurança cibernética normalmente não querem que os funcionários executem códigos em suas estações de trabalho ou laptops, por motivos óbvios No entanto, os desenvolvedores precisam disso. Eles precisam da capacidade de instalar ferramentas essenciais e testar seu software de forma eficaz. É aí que você precisa ser flexível, no ambiente do desenvolvedor. E, como eu disse, os desenvolvedores são muito experientes em tecnologia. Se você não der a eles o que eles querem, é provável que eles encontrem maneiras de contornar os obstáculos que os impedem de trabalhar e isso criará um ambiente inseguro É por isso que você precisa pensar dar aos desenvolvedores a capacidade de fazer o que eles precisam fazer. Portanto, há muitas maneiras de fazer isso. Na verdade, você pode segmentar a rede de desenvolvedores. Então você pode colocá-lo em uma rede separada, certo? Conheço pessoas que colocaram seus ambientes de desenvolvedores completamente na nuvem e os separaram da rede de produção A única coisa que os combina é um repositório. Mas eles têm todos os direitos porque sabem que, mesmo que haja algum problema acontecendo lá, ele está na nuvem, completamente separado da rede de produção Então é aqui que você precisa pensar. Se um atacante o comprometer , o que acontecerá? Então, uma vez que um invasor o compromete, ele pode potencialmente injetar um núcleo malicioso explorar Portanto, existem muitas maneiras variadas de fazer isso. Você pode separar, como eu disse, seu ambiente de negócios e seu ambiente de desenvolvimento, isolar seus desenvolvedores do negócio principal Portanto, certifique-se de que eles não tenham acesso a nenhuma função comercial crítica e pense em maneiras de proteger seu ambiente de desenvolvedor Você está implementando a autenticação multifatorial oferecendo a eles coisas como VDI, que oferece uma sandbox Portanto, isso lhes dá a capacidade de fazer o que querem, mas são restritos. Eles são colocados em uma caixa de areia específica. Então, essas são as coisas em que você realmente precisa pensar quando está fortalecendo seus ambientes, certo Como isolar seus desenvolvedores de seus ambientes de produção. E, claro, você também tem ambientes de pré-produção . Eles têm dados. Certifique-se de torná-lo anônimo. Você o está higienizando da melhor maneira possível. Ao contrário da crença popular, você não precisa de todos os dados lá. Você só precisa do suficiente para simular toda a produção, mas talvez não precise de tudo. Por exemplo, dados de uma vaca ou dados de PII, você pode potencialmente higienizá-los você pode potencialmente higienizá-los Então pense nessas coisas. Você precisa ter monitoramento de segurança. Eu falei sobre anonimização de dados. Então, essas são as maneiras pelas quais você pode fortalecer seu ambiente de desenvolvimento e seu ambiente de produção P. E conversamos sobre endurecimento. Uma das principais coisas a considerar é a segurança de seus repositórios de código-fonte, seu servidor de compilação, seu servidor de pacotes Todas essas coisas vêm à mente, quer você tenha um pipeline de CICD ou DevOps ou apenas Então, vamos passo a passo. Em primeiro lugar, é o seu repositório de código. Se você se lembra, é aqui que você coloca todo o seu código, sim. É aqui que seus desenvolvedores estão colocando o código e reforçando o acesso ao Reaper Você pode pensar em usar coisas como autenticação multifatorial Você está analisando quem tem acesso ao repositório e protege a infraestrutura subjacente Se estiver no local e alguém puder invadir o próprio servidor , você não pode realmente confiar no código, que estará em cima dele, E sempre aplique esse princípio de privilégio de locação. Você não vai acreditar em quantas empresas eu conheço que verificam o acesso de seus aplicativos, mas elas esquecem completamente os IPOs Eles sentem muita falta disso. Então, acesso do usuário aos repositórios, pense em como você se autenticou Existe uma boa política de senhas? Você está aplicando coisas como a autenticação multifatorial? Você está restringindo isso aos endereços IP? Como falamos sobre a questão do Cod Cv, certo? Isso poderia ter acontecido se os IPs tivessem sido destruídos, porque mesmo que tivessem comprometido seu repositório, eles não teriam conseguido acessá-lo E, claro, uma das coisas mais perigosas, continue escaneando. Sempre mantenha suas credenciais e seu código-fonte separados Você sabe se seus desenvolvedores codificaram alguma credencial em seu EPO, separando logicamente suas credenciais separando logicamente E certificando-se de que eles estão sendo digitalizados. Essa é uma das coisas mais básicas. Até hoje, posso garantir que muitas empresas têm credenciais codificadas em seus repositórios e não estão cientes disso Então você tem esse plano? Você tem algum tipo de plano de resposta a incidentes se descobrir, certo? Essas são todas as coisas em que você precisa pensar quando fala sobre seu repositório de código Se o Code Depot estivesse protegido, ataques como o Cod COV poderiam ter sido bloqueados Ok, o próximo é o pipeline de construção, certo? Conversamos sobre isso quando o desenvolvedor compromete algo com o código, o repositório É aí que entra seu pipeline de construção. Isso pode fazer parte do pipeline do CSCD. Você tem que garantir isso de forma mais importante, porque esse é um dos maiores alvos Já vimos isso acontecendo em ventos solares, certo? O que um atacante faz? Ele se infiltra em uma rede de desenvolvimento. Ele escaneia para descobrir onde estão os repositórios de código-fonte, onde estão os sistemas construídos e onde estão as vulnerabilidades. Ele compromete isso. Agora ele é capaz de comprometer o código que está sendo confirmado, e você pode comprometer os binários, certo? Se você quiser proteger a integridade do seu código e dos artefatos de construção, certifique-se de que sua compilação seja reforçada E lembre-se sempre de que os fios de construção são uma das ameaças mais perigosas que podem existir, conforme evidenciado pelo ambiente dos ventos solares Então, o que podemos fazer? Então, primeiro de tudo, seguindo as diretrizes de endurecimento. A maioria das ferramentas de construção existentes tem práticas recomendadas de fortalecimento que você pode seguir Separe seu desenvolvimento, sua rede de engenharia, da rede coopit Nós já conversamos sobre isso. Você está monitorando seu ambiente de construção? Você tem coisas como uma autenticação multifatorial lá Por quê? Você está auditando a quais contas eles têm acesso Porque lembre-se de que o servidor de compilação, se estiver implantando código automaticamente em ambientes diferentes, precisará ser acessado Como você sabe que essas contas não foram comprometidas, certo? Certificando-se de que você está registrando todo o acesso. E também falamos sobre as compilações reproduzíveis verificadas , certo Portanto, construções que você pode criar em ambientes separados, e elas sempre serão as mesmas Isso lhe dá a garantia de que ninguém adulterou uma construção como a E certificando-se basicamente seus segredos e suas credenciais estejam seguros Portanto, essa é uma lista de verificação completa que você pode usar para começar a proteger seus ambientes construídos Então, esses são os servidores de construção. O que mais é o servidor de pacotes? Se você se lembra, então você coloca coisas no código-fonte, elas vão para o servidor de compilação e, a partir daí, vão para o pacote. Agora, o servidor de pacotes é onde seu software é implantado, certo? Seus pacotes de software. E comprometimento do repositório de pacotes Isso pode ser uma ameaça significativa em sua cadeia de suprimentos de software. Falamos sobre isso mais cedo. Se os atacantes conseguirem comprometê-lo, eles podem potencialmente enviar códigos maliciosos para lá, certo Então, novamente, fortalecendo o MFA, usando assinaturas criptográficas. O que é isso? Você deseja garantir a integridade de seus pacotes de software. Dessa forma, se esse pacote for adulterado ou alterado, sua assinatura criptográfica entrará Porque o pacote terá uma pegada digital exclusiva, certo? E podemos verificar se ninguém adulterou. Então, novamente, você pode ter certeza de que está usando canais seguros, certificando-se de que HDDPS, SFTP ou até mesmo VPNs estejam sendo usados para garantir que os pacotes sejam criptografados em transet, verificando a integridade dos pacotes de software antes da distribuição certificando-se de que HDDPS, SFTP ou até mesmo VPNs estejam sendo usados para garantir que os pacotes sejam criptografados em transet, verificando a integridade dos pacotes de software antes da distribuição. Então, você quer comparar a assinatura criptográfica atual do seu pacote com a assinatura original para ter certeza de que ninguém a adulterou, certo? E contra assiná-lo. Esses são alguns dos controles muito, muito importantes. E agora, quero retomar um dos principais riscos sobre os quais falamos. Você se lembra disso, o ataque de confusão de dependência. Era uma grande, muito parecida com uma grande cadeia de suprimentos, que é onde o atacante publica um pacote malicioso em um repositório público de pacotes com o mesmo nome de um pacote com o mesmo nome Então, seu desenvolvedor pode pedir um pacote, e o que acontece é que o pacote primeiro, o que ele faz, ele verifica o relatório público. E aí o atacante colocou o mesmo nome, mas com um número de versão maior Então você pode ter a versão três, ele colocará a versão cinco. E o repositório de pacotes, da forma como está configurado, primeiro acessará a Internet para verificar e baixará o pacote malicioso E dessa forma, o pacote será copiado para sua rede de desenvolvedores e para o Bingo O atacante tem acesso ao seu ambiente de desenvolvimento de software e é capaz de comprometê-lo Então, é apenas uma forma de ataque que explora a forma como os ambientes de desenvolvimento de software e os gerenciadores de pacotes funcionam, você sabe, coisas como o gerenciador de pacotes node , o índice de pacotes Python É assim que funciona. Então, novamente, o que você pode fazer para garantir isso Você pode usar repositórios privados para dependências críticas, basta usar repositórios privados com controles de acesso rígidos para reduzir o risco de acidentalmente Você pode usar o bloqueio de dependências, certificando-se de que sua dependência o pacote que o desenvolvedor está listando, esteja bloqueada uma versão específica que você Isso evita que essas atualizações automáticas comprometam versões mais recentes potencialmente comprometidas Neste diagrama, você pode ver que o atacante comprometeu um repositório público de pacotes E o desenvolvedor pediu um pacote. O pacote não acessará a Internet para verificá-lo. Por quê? Porque você bloqueou a dependência. Você disse que esta é a única versão que eu quero, que você já verificou, que está disponível no local Portanto, ele não acessará a Internet e você poderá contornar completamente esse ataque O invasor não conseguirá comprometer seu ambiente. Então, essas são as coisas que eu quero que você tenha em mente, que é proteger contra ataques de confusão de dependência, certo? Essas são as coisas que você precisa pensar : verificar se os nomes de todos os pacotes usados em seu projeto são conhecidos e confiáveis. E você pode fazer isso verificando a fonte e o mantenedor de cada pacote antes de adicioná-lo às Assinatura do pacote já mencionado. A mesma coisa que você tem uma assinatura digital, certo? Assinando o pacote e usando repositórios de pacotes privados, então considere usar repositórios de pacotes privados onde você hospeda suas dependências internas Isso pode ajudar a reduzir o atacante, como mostrei no diagrama anterior Mesmo que ele introduza um pacote malicioso, que tenha o mesmo nome de sua dependência interna, seu gerenciador de pacotes não irá até lá porque ele permanecerá no local e usará apenas o E, claro, monitorar e escanear seus pacotes, certo? você quer ter certeza de que nenhuma vulnerabilidade Enquanto isso, você quer ter certeza de que nenhuma vulnerabilidade foi introduzida Portanto, isso pode ajudar a capturar pacotes maliciosos e monitorar os downloads dos pacotes. Portanto, ao monitorar os downloads do seu pacote, você pode ajudar a detectar qualquer atividade maliciosa. Portanto, essas são todas as coisas que você pode fazer para se certificar de que está protegido contra ataques de confusão de dependência Então, abordamos agora os ambientes. Agora, quero falar sobre um tópico muito importante que é crucial quando se trata de segurança da cadeia de suprimentos de software, é a construção de material de software, o SBOM Obrigado. E não vou abordar isso porque acho que você já tem coisas suficientes para entender nesta lição. Nos vemos na próxima lição, começaremos este tópico. Muito obrigado e nos vemos na próxima lição. 13. SBOM: Olá, pessoal. Bem-vindo. Bem-vindo a esta lição, que aborda um tópico muito, muito importante na segurança da cadeia de suprimentos de software, que é um software construído a partir de material, o SBOYM Então, o que é um SBM? É muito simples. É basicamente um inventário aninhado. É uma lista de ingredientes. De todos os componentes de software que estão presentes em seu software. E se você pensar na cadeia de suprimentos de software, certo, cada estrutura de ferramenta ou construção é usada para escrever, criar e executar aplicativos, e é aí que entram todas as vulnerabilidades, certo? E você está constantemente reutilizando código, pacotes de software, e fornecedores terceirizados também vendem pacotes comerciais Portanto, a complexidade de criar todos esses aplicativos de software torna muito, muito crucial ter um inventário de todos os componentes usados para criar esse aplicativo, um catálogo, certo? E esse catálogo ajuda as organizações a identificar e detectar rapidamente se elas têm alguma vulnerabilidade de segurança no ambiente Então é aqui que entra o SBM. Tornou-se muito parecido com um padrão na segurança da cadeia de suprimentos de software. E é aqui que você pode realmente perguntar aos fornecedores e obter isso E vamos analisar isso com mais detalhes. Então você pode realmente fazer isso sozinho. Você pode até mesmo fazer isso com a planilha do Excel. Eu não o recomendaria de forma alguma, ou você pode gerá-lo automaticamente. Existem muitos, muitos softwares que escaneiam seu ambiente e, em seguida, eles realmente geram ou compilam materiais É isso que eu recomendo usar um gerado por máquina. E é muito, muito benéfico, por quê? Porque ajuda você a identificar componentes vulneráveis e fornece um conhecimento completo do que você tem, certo? E se houver um incidente de uma biblioteca específica que esteja sendo comprometida Como você saberia se seus aplicativos críticos têm isso ou não? Na verdade, você pode consultar rapidamente seu SBM, se ele estiver em formato de máquina, para descobrir se essa versão específica dessa biblioteca específica está sendo usada, certo? E isso ajuda você a selecionar fornecedores que também estão escrevendo, como se seu fornecedor fosse transparente e dissesse: Ei, aqui está meu SBM com Você sabe que esse é um fornecedor maduro, certo? Eles têm todas essas coisas necessárias. E mesmo depois de acreditar que foram as vitórias da energia solar, os fornecedores da cadeia de suprimentos de software e a segurança da ordem executiva que surgiu, eles também começaram a exigir que você tivesse um SPOM Então, como eu disse, você pode fazer isso manualmente, usando uma planilha do Excel. Eu absolutamente não o recomendaria porque você pode ter centenas a milhares de dependências Normalmente, você pode fazer isso usando ferramentas geradas por máquina, certo, que são totalmente automáticas para você. Então, como eu disse, o que isso faz? É como um inventário completamente exaustivo, certo? Ele detalha cada peça de código aberto, bibliotecas e pacotes de código de terceiros que são utilizados no desenvolvimento de um aplicativo de software e dá uma boa ideia da composição do software, certo? Dessa forma, você sabe o que está lá, o que não existe, qual versão você está usando, quais bibliotecas e pacotes de código estão usando? Como são os componentes de terceiros, qual é o status do PAT Quais são as dependências entre eles? E você pode entender agora que, se eu quisesse saber qual é o status do PAT porque não sei se o software específico é vulnerável ou não a um ataque específico, o SBOM pode ajudá-lo imediatamente a identificá-lo E isso é como um gerado por máquina . É assim que parece. Quer dizer, eu não quero que você leia, mas isso só mostra que você pode ver que mostra qual é o pacote. Certo? Qual é o status? Qual é a versão? Qual é o hashcode? Quem é o fornecedor? Então, todas essas coisas entram em jogo. E como isso ajuda? Então eu já falei sobre isso, mas, você sabe, primeiro de tudo, você tem transparência. Então, ele fornece uma lista completa do que você tem, certo? Esse nível de transparência permite que as empresas saibam exatamente o que há no software , facilitando o gerenciamento e a segurança. gerenciamento de vulnerabilidades com o SBM, você pode identificar rapidamente se há algum componente de software vulnerável a problemas de segurança Assim, você pode identificar problemas de forma proativa. Em conformidade, muitos setores têm requisitos regulatórios que exigem padrões de segurança para software Portanto, se você não tiver o software em casa, talvez esteja usando um software baseado em um fornecedor Você pode usar um SBOM. Você pode pedir ao fornecedor o SBM, certo? E, claro, segurança da cadeia de suprimentos. O objetivo principal disso é melhorar a segurança da cadeia de suprimentos e também ajudar na resposta a incidentes. Digamos que, no caso de uma resposta a um incidente, SBM permite mais rápida e eficiente a incidentes Você pode determinar rapidamente quais componentes podem ser afetados por um ataque. E, novamente, rastreamento de dependências. Então, como eu disse, fica muito complicado rastrear o que você tem e o que não tem. Portanto, um SVM ajuda você a rastrear essas dependências ao longo do tempo. E hoje em dia, na era do GNAI e tudo mais, você pode realmente colocar uma IA em cima desses arquivos consultá-los e obter respostas completamente humanas, certo? Então, todas essas coisas em que você pode pensar. Então, se eu olhar para isso dessa perspectiva. Então, suponha que você tenha uma equipe de cibersegurança, certo? E sua empresa esteja comprando um produto de um E agora, a equipe de cibersegurança quer saber que tipo de software existe É de código aberto? Como é construído, certo? Então você pergunta ao fornecedor, você pode me dar um SBM? Então é isso que o fornecedor responde corretamente. Eles fornecem um SBOM e a pessoa agora pode lê-lo e obter essa garantia Ok, o que está aí? O que não está lá? Agora, nenhum software está imune às vulnerabilidades de segurança, certo? Todo Não há nenhum software que seja totalmente 100% seguro. Então, você pode até mesmo fazer isso com um SBOM. Então, você pode perguntar ao fornecedor há alguma vulnerabilidade nas redes do seu laboratório de software Eles podem fornecer OSB e algo chamado troca explorabilidade de vulnerabilidades. Agora, o que é isso? Essa é uma estrutura projetada para comunicar as vulnerabilidades de segurança do software, especialmente se o software é vulnerável ou não Portanto, as declarações do VX fornecem aos fornecedores uma maneira de se Se há uma vulnerabilidade ou não, você pode dizer exatamente a eles. Então, se eu sou um fornecedor e um cliente me perguntar, posso dar a ele o SBM mais um E eu digo que essa vulnerabilidade não é uma preocupação para nosso produto, e você pode detalhar as condições sob as quais ela pode ser um problema, mas você a mitigou, certo Portanto, faz parte do SBOM e oferece transparência Portanto, esse é, novamente, um padrão que está se tornando cada vez mais popular na cadeia de suprimentos de software. Por que porque você não tem acesso ao código-fonte terceirizado, certo? Mas se você estiver comprando um aplicativo, poderá realmente usar o SPM. Você pode usar o VX para obter essa garantia. E na próxima lição, o que vamos fazer é fazer um estudo de caso real, tipo, como isso aconteceria se um cliente estivesse comprando um software e o que podemos fazer? Então eu acho que isso abrange praticamente todas as coisas sobre as quais falamos, certo? Então, analisamos isso a partir do ambiente do desenvolvedor, codificação segura, fortalecimento, digitalização de componentes, testes, fortalecimento do ambiente e agora analisamos isso da analisamos isso Então, espero que tenha sido útil para você entender o quão vasto é esse mundo, certo? Agora, você tem uma boa ideia do que é a segurança da cadeia de suprimentos de software e dos controles em cada estágio e dos equívocos que as pessoas têm, como se fosse um produto que você compra ou se fosse uma certificação que você obtém Então, agora que você está em um bom estado, agora você pode estar pensando: Ok, existem tantos controles. Como eu realmente implemento? Por onde eu começo, começo com o SBM? Eu começo com o código seguro? Eu começo com dependências? O que eu tenho que fazer? Então, falaremos sobre isso na próxima lição, onde falaremos sobre isso na próxima lição, onde falaremos sobre a criação de uma cadeia de suprimentos de software, um programa de segurança e risco. se você começar a fazer isso em sua empresa, onde começar e onde todos esses componentes diferentes entrarão. Está bem? Então, espero que isso tenha sido útil para você. Te vejo na próxima aula. Obrigada. 14. Conclusão: Olá, olá, pessoal. Bem-vindo. Bem-vindo à lição final. E isso está apenas terminando. Obrigada Obrigado por me ouvir, falar só Deus sabe por quanto tempo. Mas espero que você tenha entendido bem a segurança da cadeia de suprimentos de software. Espero que você tenha uma visão holística agora e não esteja pensando apenas em comprar um produto ou simplesmente ativar a MFA ou algo parecido Espero ter aumentado seu conhecimento sobre novos tipos de ataques. Então lembre-se, é uma jornada contínua. Siga as melhores práticas e tendências do setor que já existem e comece. Eu não posso, por favor, não ser uma daquelas pessoas que simplesmente estudam esta lição e depois a esquecem na próxima semana. Ok, comece, pegue algumas das lições sobre as quais falei e comece a implementá-las em sua empresa. Dê uma olhada nos repositórios construídos, nos repositórios pacotes e comece a implementá-los Mas basicamente terminamos o curso. Espero que tenham gostado de me ouvir Babylon por tantas horas. Muito obrigado por me aturar. Lembre-se de que eu te dei um projeto no início. Você pode pegar isso e dividir sua própria cadeia de suprimentos de software relação ao risco de que falamos e compartilhá-la. E faça uma avaliação simples de onde você está, sua cadeia de suprimentos, quais são os riscos e como você pode mitigá-los, documente-a para ter uma ideia melhor Porque se você não aplicar esse conhecimento, posso garantir que você o esquecerá. Você terá desperdiçado seu tempo e dinheiro se não aplicar o conhecimento sobre o qual falei . Então é mais ou menos isso. Por favor, sinta-se à vontade para entrar em contato comigo. Estou lá no Substack, no LinkedIn e também tenho um pequeno canal no YouTube Eu vinculo tudo nos comentários. Desculpe, dentro da lição, você pode clicar nela e entrar em contato comigo se você achou que foi uma boa lição Se você achou que esse foi o pior curso que você já fez, me avise, por favor, também. Não se preocupe nem um pouco. Fico feliz em receber feedback. Então, muito obrigado. Isso encerra este curso. Espero que você tenha se divertido e vemos no próximo curso que ensino. Muito obrigado e adeus.