Bem-vindo ao quarto episódio de Além do Limite, um podcast dedicado a explorar os desafios dinâmicos enfrentados pelas empresas digitais modernas.
Neste episódio, a nossa anfitriã, Lauren Bradley, gerente global de campanha, conversa com o diretor de engenharia de plataformas de Michael Grigshaw Edgio, e Richard Yew, diretor sénior de gestão de produtos da plataforma de segurança Edgio, sobre mudar para a esquerda. Especificamente, como a cultura e a tecnologia mudam à medida que as aplicações web e a proteção de API se tornam uma parte nativa e inerente do seu ciclo de vida do DevOps.
"A segurança é como farinha para você fazer o bolo, e quando a segurança é feita corretamente, não se pode vê-lo. O ponto de segurança é quando está feito bem, ele deve ter sido cozido e não é visível."
Uma Introdução ao Podcast de Edgio, para além do limite Episódio 4: DevSecOps: Mude para a esquerda para evitar mudar o seu Roteiro de Produto para a direita, hospedado por Lauren Bradley, gerente de campanha global da Edgio.
Lauren Bradley: Ei lá, e bem-vindo ao Além do Limite, onde nos aprofundamos nos detalhes dos negócios digitais modernos. Eu sou Lauren Bradley, sua co-piloto para este episódio, e hoje vamos explorar o tópico de mudar para a esquerda, especificamente como a cultura e a tecnologia mudam à medida que a aplicação web e a proteção de API se tornam uma parte nativa e inerente do seu ciclo de vida do DevOps.
Vamos começar com uma estatística chocante do Ponemon Institute. Hoje, a maioria das empresas leva mais de 200 dias para detetar uma violação. Se você não estiver detetando uma violação suficientemente rápida, isso vai custar-lhe muito. A IBM descobriu que o custo dos erros corrigidos encontrados durante a fase de teste pode ser 15 vezes mais do que os encontrados durante o projeto.
Por isso, para simplificar, quanto mais tempo esperarmos para resolver um problema, mais custará. E não estamos apenas a falar de dinheiro, de retrabalho, de tempo e de energia pode, em última análise, mudar os roteiros dos produtos. Então, como é que podes efetivamente mudar para a esquerda e evitar desperdiçar recursos valiosos e impedir o teu progresso?
Juntando-nos hoje, temos Michael Grimshaw, Diretor de Engenharia de Plataforma de Edgio, e Richard Yew, Diretor Sénior de Gestão de Produto para a Plataforma de Segurança Edgio. Bem-vindos, Michael e Richard. É ótimo ter você.
Michael Grimshaw: Obrigado, Lauren. Ótimo estar aqui. Obrigado.
Lauren Bradley: Vocês podem me contar um pouco sobre vocês mesmos e sobre os seus pensamentos iniciais sobre este tema? Mike, vamos começar com você.
Michael Grimshaw: Absolutamente. Em primeiro lugar, deixem-me começar por agradecer, a Lauren, por terem tido tanto interesse. Neste tópico muito importante e, e vocês estão a investigar e a falar e as conversas que tivemos e estamos a ter em torno disto, incluindo este ano aqui é, é apenas um valor inestimável e imperativo para o trabalho que estamos a fazer na indústria.
Michael Grimshaw: Este entendimento precisa de ser partilhado de forma ampla e, e realmente apreciar o interesse. Chamo-me Michael Grimshaw. Sou o Diretor de Engenharia de Plataforma aqui na Edgio. Para aqueles de vocês que não estão familiarizados com, ou, super familiarizados com a plataforma em termos de indústria, está realmente a pensar em termos da unificação das suas aplicações e infraestruturas em unidades coerentes.
E eu venho para a plataforma com um fundo de segurança pesado, e esta é uma área que eu sou bastante apaixonada porque move a agulha de uma forma tão grande, quanto a segurança, quanto a rentabilidade, e tantas áreas que são tão importantes para a nossa indústria.
E eu posso ir em torno do DevSecOps, mas deixe-me entregá-lo ao Richard para a sua introdução.
Richard Yew: Muito obrigado, Michael. Sim. Sim. Este é um tópico muito importante. É muito próximo e querido no meu coração porque eu, pessoalmente, vivi todo o processo de ciclo de vida do desenvolvimento de software, bem como traduzi-los para o negócio.
Agora, falando do que eu faço… Obviamente, como Lauren mencionou, eu administro nossas organizações de gestão de produtos de segurança no Edgio. Assim, o meu dia-a-dia envolve trabalhar com a equipa de I&D, a equipa de engenharia para garantir que estamos a dar valor aos nossos clientes. E, sabem, tudo o que obviamente incluiria, como otimizar a nossa prática de desenvolvimento, a nossa segurança, a prática de CI CD. para garantir que somos capazes de entregar produtos seguros.
Certo. Isso realmente fornece valor aos nossos clientes, entrega-os dentro do prazo, com orçamentos, e garante que proporcionamos uma ótima experiência aos nossos clientes. Portanto, a minha lente nisto é olhar para todo o DevSecOps, sabem, numa perspetiva das pessoas – o processo em oposição à tecnologia e como podemos implementar as melhores práticas, para a indústria
O que é o DevSecOps?
Michael Grimshaw: Até ao ponto, Richard, deixe-me apenas roubar a bola lá se não se importa.
E só acho que vamos padronizar o que queremos dizer com DevSecOps e mudar para a esquerda, certo? Houve o Gartner, aqui estão as coisas para algumas pessoas que escutam neste DevSecOps, e os termos mudam para a esquerda, mudam para a direita, etc. podem parecer relativamente novos. Isto não é novo, sabem, não é como, oh, a coisa mais quente que acabou de acontecer há um ano.
Não, isso tem sido feito na indústria há algum tempo. E de facto, a Gartner teve um relatório de 2017 sobre o ciclo de vida do DevSecOps. Era apenas uma extensão do DevOps, a tendência do DevOps na indústria, estendendo-se apenas para incluir a segurança na infosec no ciclo de feedback e no seu ciclo de vida de desenvolvimento de software.
E assim, como eu disse, o Gartner estava escrevendo, escrevendo sobre isso, em 2017, e já tinha sido, um processo e um movimento na indústria. Por um bom tempo antes disso. Portanto, estes não são conceitos novos. É apenas uma extensão do que temos trabalhado há anos. E efetivamente o que é DevSecOps, é que é preciso o modelo semelhante, de DevOps, em que você tem um lado de desenvolvimento e realmente um lado de operação.
E no ponto crucial, está a construir em todas as suas necessidades de segurança o mais rapidamente possível, quer dizer, desde o início do design, construir o, sabem, todo o processo até onde os seus desenvolvedores no navio à esquerda estão do lado do desenvolvimento, desculpem-me, mudar para a direita é mais do lado da observação das operações. Vamos focar-nos no lado esquerdo aqui hoje, mas basicamente está a fazer testes às suas digitalizações, e na sua validação, já à esquerda. E o mais cedo possível no ciclo de vida de desenvolvimento no seu SDLC. Então, por exemplo, uma das coisas sobre as quais ele fala, e novamente, isso remonta há mais de sete anos, é coisas como ter segurança, digitalizar e digitalizar suas bibliotecas de terceiros de código aberto, repositórios, base de código, bem como o código que você escreve, o design, a arquitetura, os nove metros inteiros, e fazer isso desde o início. E um dos exemplos que tenho dado é a criação e verificação de segurança dos IDEs que os seus desenvolvedores usam. É apenas um exemplo, e há muitos deles.
Para que, à medida que estão a escrever o seu código, obtenham um feedback imediato. OH, eu apenas deixei a porta aberta para, sabem, enchimento de credenciais ou injeção de sequelas, e eles ficam como um erro de sintaxe, eles recebem um erro de segurança logo há a escrita do código. Então, eles podem corrigir isso imediatamente, para que não tenham um cliente reclamando sobre o cliente ou o usuário final sendo desfeito, sabem, um mês depois, não, é tratado ali mesmo.
Mais barato, mais rápido, mais fácil no início. Richard, você ia dizer alguma coisa.
Porque é que a mudança para a esquerda é tão importante quando se trata de custo?
Richard Yew: Ah, sim. Sim. Como eu acho que o custo é realmente muito importante para falar, sabem, bem, todos sabem muitos custos operacionais, qualquer organização, é como o desenvolvimento, certo? O processo de I&D.
Então, quando se trata de custo, é por isso que mudar para a esquerda é mais importante, certo? Porque estamos a fazer muito esforço e a falar sobre o porquê, sabem, tenho a certeza de que vamos entrar no “como” mais tarde, mas queremos chegar a casa sobre a razão pela qual isto é tão importante porque, sabem, temos dados.
Sim. Isso, de acordo com nossa pesquisa, mostra que você sabe, se você está corrigindo uma vulnerabilidade de segurança que foi encontrada depois de lançar seu código e produções custam 15 vezes mais do que você sabe quando é encontrada em uma fase de design quando você está fazendo a ameaça de montagem. Obviamente, não estamos a dizer que sabem, a fase inicial do esforço de desenvolvimento apanharia completamente todas as vulnerabilidades de segurança.
É por isso que precisamos de implementar a defesa em profundidade. Mas é muito importante que saibam, ao olharem para as oito fases, vocês sabem, em geral, dos ciclos de dívida, dos ciclos de vida de, sabem, planificar, programar, construir, testar, até gostar de monitorizar e operar. Certo. Você olha para eles quanto mais à direita for, sabe, como quando encontrar uma vulnerabilidade de segurança, mais caro vai levar, sabe.
Para as suas organizações resolirem o problema. Então, estamos falando da diferença entre encontrar uma vulnerabilidade em uma digitalização que acontece depois de você já ter lançado um monte de códigos para as produções versus dizer, sabem, como fazer uma tarefa dinâmica de segurança de aplicativos no ambiente de teste para detectá-lo logo antes de enviar esse código para as produções, certo?
Richard Yew: Você pode ser capaz de corrigir esses problemas, ou implementar algum tipo de correção virtual antes de lançar uma redução de código para mitigar isso. Mas, novamente, é muito importante entender que a segurança precisa ser incorporada desde o primeiro passo do processo, mesmo antes de começar a escrever o código antes de colocar qualquer coisa no seu IDE e começar a pensar em fazer modelagem de ameaças. Ei, que parte do projeto poderia potencialmente ser suscetível à exploração?
Implicações do dia-a-dia para as equipas de DevOps e segurança
Lauren Bradley: Sim, e esses são realmente bons pontos, vocês. Quer dizer, do ponto de vista do utilizador, o que, fora dos custos, monetariamente, isso pode significar para um DevOps ou uma equipa de segurança experimentar no seu dia-a-dia se não estiverem a implementar isto desde o início?
E também quero falar sobre como implementámos de forma eficaz no ciclo de vida do DevOps.
Michael Grimshaw: Grande pergunta. Grande pergunta. E, deixem-me ser muito contundente na minha resposta inicial. É toda a gente na indústria, cada CEO, diretor de tecnologia, CFO – todos, engenheiros, utilizadores – o que todos queremos é apenas uma bala mágica que podemos fazer, o que fazemos no dia-a-dia.
E então temos uma bala mágica de segurança que você simplesmente vira o botão e todo o seu trabalho é de repente feito seguro. É isso que todos querem, mas isso não é realidade. Isto é, sabem, as pessoas perguntam-nos. Quero perguntar-lhes, como está o tempo em terra de fantasia? Eu ouço que é bom. Este tipo de ano é, e se abordarmos a sua segurança, a sua infosec, bem como o seu desenvolvimento, pois isto é apenas um parafuso. “OH, vou comprar algumas ferramentas que vou usar depois de termos tudo desenvolvido, construído e implantado, e vai continuar e tornar tudo seguro”, você está comprando um peso de papel muito caro, para ser honesto com você.
E é por isso que, sabem, foi mencionado, é sobre pessoas, processos e ferramentas. É por isso que a totalidade coerente desta abordagem é tão importante. É você, estamos longe anos, décadas, se alguma vez foi possível. Para ser honesto com você, aprendemos muitas lições com a ideia de você apenas projetar algo e colocar um conjunto de ferramentas de segurança e você está pronto.
Isso impacta tudo, desde o seu custo até a velocidade do seu desenvolvedor e o custo lá para os seus clientes. E, um ótimo exemplo disso é a minha suspeita, quase todos os que estão ouvindo este podcast em algum momento da sua carreira estiveram em uma situação em que um novo recurso ou um novo serviço ou algo assim, ou mesmo apenas um patch e atualização foi implantado. Tudo parece bom. Tudo está a correr bem. E então de repente você recebe uma chamada de um de seus clientes ou infosecs recebe uma chamada de um dos clientes. “Acabamos de ficar sem conta”, ou “Acabamos de ter um incidente de segurança”, ou algo assim. E a razão é porque, ok, você implantou-o, mas talvez as varreduras não tenham terminado de ser executadas, ou você não as fez corretamente sintonizadas, e você acabou de introduzir uma enorme vulnerabilidade de segurança.
Talvez o afete, mas mais importante, afeta os seus clientes. DevSecOps é sobre fazer tudo isso juntos em um processo coerente e evitar isso. Trata-se de corte de custos. Absolutamente. Trata-se de melhorar as margens? OH, de uma forma grande. Mas também se trata de eliminar a responsabilidade da sua empresa e dos seus clientes.
Incorporar a Segurança no DevOps – é como fazer um bolo!
Richard Yew: Sem dúvida. Vocês sabem, falando sobre, sabem, falando sobre o cozimento, sabem, como Mike usou um termo tão coerente na totalidade. Assim é tão verdadeiro. Isto é muito poderoso, esta é uma palavra muito poderosa para mostrar porque é importante ter isso feito no lugar, como eu sou conhecido no Edgio por ser o sujeito da analogia.
Gosto de fazer uma série de analogia e estou, sabem, a ouvir isto muito bem. Analogias Eu acho que serviriam como uma base forte para empurrar para as culturas certas dentro de qualquer organização como todos sabemos, como pessoas de segurança, uma grande parte do nosso trabalho é evangelização. Não se trata apenas de implementar as tecnologias certas e criar um processo, mas também de fazer muito marketing interno.
Dizer que as pessoas são importantes em termos de segurança para o negócio, certo? Porque, como líderes de segurança, não é como se as pessoas muitas vezes pensarem em segurança, como adicionar camadas adicionais de processo ao seu fluxo de trabalho, mas sabem, a maneira certa de pensar sobre isso é que como a segurança pode acelerar o negócio?
Como a segurança pode realmente trazer mais receita, porque esta é uma boa maneira de justificar muita segurança, sabe, implementações de segurança adicionais que você tem que fazer para garantir a segurança da organização. Então, uma das analogias que ouvi dizer que foi ótimo é que sabem, a segurança não deve ser tratada como uma cereja no bolo, sabem, como você faz do bolo e apenas colocar todos os picings como um último passo, sabem, isso é geralmente o que as pessoas fazem quando não têm segurança, fluxo de trabalho do ICD, e eles apenas implementam firewalls e, sabem, proteção API, seja qual for a última fase de produção. O que deveria ser, a segurança, é como farinha, sabem, devia ter sido algo desde o início.
A segurança é como farinha para você fazer o bolo. E então, quando a segurança é feita corretamente, você não pode vê-la. E todo o ponto de segurança é quando está bem feito, deveria ter sido cozido e não é visível. Não deve ser algo que crie desafios. Não deve ser algo que abrande a organização.
Como analogias que, sabem, eu costumava ajudar a mostrar ao negócio porque isso é importante é que ter um forte processo de segurança, culturas de tecnologia de segurança, é como ter fortes travões. Num carro de corrida, sabemos porque é que cada supercarro tem travões grandes, sabem, muito grandes, sofisticados, porque permite que eles corram mais depressa.
Permite-lhes travar com força. Permite-lhes ir mais rápido e virar mais forte, certo? Permite-lhes ganhar a corrida. Então, ter travões fortes é tão importante como ter um motor forte, certo? É assim que devemos olhar para a segurança numa filosofia. Sabem, obviamente, falamos muito de níveis elevados, certo? Então, obviamente, queremos, como se fosse aprofundar nisso. A essência do tipo, ok, então tudo isso está bem, mas como exatamente vamos implementar isso?
Michael Grimshaw: Sim. Acho que é um grande apelo a travar. Uma travagem potente dá-lhe controlo. Há que a corrente ou a estrada que temos à frente está cheia de curvas, curvas apertadas, e tudo isso, e há, claro, há retas em que você dá chão e você não toca nos freios, mas para navegar tudo, isso, esse freio, eu acho, amor, eu amo ambas as analogias, Richard, porque essa analogia de travagem, dá-lhe controle, dá-lhe controle, ele está enfrentando desafios inesperados e de grãos, inesperados, e de grãos mais finos.
Richard Yew: Um grande apelo. A propósito, quero esclarecer, não cheguei à analogia que é deste tipo chamado Dr. Eric Koh. Ele tem, e ele dirige um excelente podcast. Por isso, recomendo que todos vejam isso. Mas sim, acho que é tão apropriado explicar o conceito ao negócio, especialmente com aqueles que são novos para este tipo de conceito.
Equipas problemáticas e silenciadas e mapas de estrada de mudança
Lauren Bradley: Richard, você fala sobre como você, você mencionou, sabe, se, se isso acontecer, DevSecOps está feito, certo? Vocês não veem isso. E obviamente, uma dessas visibilidades gritantes é o custo. Também são equipas isoladas. Também parece que há uma desconexão entre as equipas quando existem estes problemas que surgem e porque não foram apanhados antes?
Que processos, que comunicação não estava a acontecer para resolver estes problemas de forma rápida ou eficaz? Então, a minha pergunta para vocês é, sabem, na sua experiência, qual de… Sabem, há, provavelmente há uma falta de transparência. Há uma tomada de decisão lenta, há potencial para desperdiçar recursos.
Quando se tem equipas em silos, que problemas tendem a ser os mais problemáticos quando as equipas operam em silos na sua opinião?
Richard Yew: Sim, vou pegar neste. Acho que uma coisa que, sabem, eu experienciei pessoalmente na minha vida passada, certo, é que sabem, e é quando, sabem, quando falamos de produtos semelhantes, sabem, como tipo de planeamento, é importante que, por vezes, temos uma equipa de segurança que não está inserida na I&D, como na organização de CTO.
Às vezes, em muitas organizações, observamos silos entre as equipas de segurança e a organização de tecnologia de informação e descobrimos que muitos processos foram feitos depois do facto. Então, por exemplo, encontramos uma situação em que liberamos muitos produtos, liberamos muitos códigos porque não há um tipo forte de colaboração de comunicação entre as equipas de segurança e as equipas de engenharia.
O que acabámos com é que, sabem, uma organização deve estar em conformidade. Às vezes, os exemplos específicos são que temos equipas a fazer exames uma ou duas vezes por ano. Qual é o resultado dessas digitalizações? Bem, eu vou ser dito: “Olá Richard, temos que abrandar no próximo trimestre porque acabamos de encontrar como uma centena de pequenos e grandes erros de segurança diferentes, como talvez, talvez como 20, como dos 20 primeiros são a gravidade um e dois e acima, enquanto o resto, sabem, é sobre, você tem que se concentrar em corrigir essas coisas.”
E há um SLA dentro da organização para que vocês resolvam, sabem, o que acabou por acontecer é que, ao fazer isso, vocês basicamente pegaram no meu roteiro e simplesmente os deitaram para o próximo trimestre. Por isso, não mudando para a esquerda, não fazendo realmente este processo, apenas fazendo essas coisas apenas do lado direito, estamos essencialmente a impulsionar o nosso roteiro, que é, sabem, resultados geradores de receitas, potencialmente que podem ajudar a expandir o nosso negócio. Nós vamos ter potencialmente movê-lo para a direita para que possamos, na verdade, gastar um quarto é tentar, após o fato, mitigar esses problemas.
É por isso que eu digo, bem, é tremendamente caro para a organização e para o negócio imaginar ter, tendo que mudar os itens do roteiro por um quarto. Então, todos os seus horários de lançamento de seus novos produtos, recursos e funcionalidades têm que ser mudados, certo? Porque não se desviou para a sua prática.
E algumas dessas coisas poderiam ter sido melhoradas com melhores colaborações especialmente entre equipas de segurança de aplicações dentro de uma organização e ainda assim e equipa de desenvolvimento. É por isso que vemos que muitas organizações estão a começar a ter este novo conceito. Vocês sabem, vocês ouviram falar de RH BP, sabem, parceiros de negócios de RH que estão incorporados em diferentes unidades de negócios.
Há agora um conceito de Segurança de Aplicação BP. Então, você vai começar a ouvir estes termos como O APLICATIVO SEC BP que, que pode se tornar prática onde você tem pessoas trabalhando. Quase como um gerente semi-incorporado da equipe de engenharia para garantir que eles fornecem a orientação, ferramentas e processos certos em cada etapa do fluxo de trabalho de desenvolvimento, por exemplo, da implementação de análise de composição de software, implementação de ID seguro, implementação de todas as tarefas de caixa preta e branca, você sabe, durante o processo para garantir que, você sabe, somos capazes de capturar alguns desses problemas antes, você sabe, logo no início do ciclo de vida do desenvolvimento.
Michael Grimshaw: E eu adoro tudo. Excelente pergunta, Lauren. E eu amo tudo o que você acabou de dizer, Richard. Porque há um custo associado a isso. Sabem, se as pessoas, se alguém está num produto onde ouvem, esperam, sabem, se eu mudar para a esquerda, não tenho de mudar o meu roteiro para a direita.
Isso é música para os ouvidos deles. Mas, talvez para os CFOs, ou mesmo operações, ou outras áreas do negócio, você pode estar dizendo: OK, bem, qual é o impactos disso? O impactos é enorme. Você acabou de bater o seu departamento de vendas. Você impactou seus clientes porque tem, especialmente no que toca à segurança, muitos clientes. Sei que, do lado da plataforma, quando falo com os meus vendedores, quero saber qual é o roteiro, porque, ok, talvez eu tenha que ir aos meus auditores e preciso de obter controlo de compensação até que você libere algo no seu roteiro. Bem, se me disseste, ok, o que eu estava à espera de ser entregue num quarto será de três quartos. Vou começar a olhar para outros vendedores. Porquê? Porque tenho obrigações para com os meus auditores que tenho de cumprir.
E eu também adoro, Richard, vocês trouxeram auditores e realmente o processo de conformidade. Esse é outro exemplo aqui para o vosso ponto, Lauren, sobre onde a siloização pode explodir radicalmente as coisas.
Se você está no meio de um PCI, SOC, ISO, FedRAMP, qualquer um desses vários frameworks de conformidade, e você ainda não se integrou, você ainda está operando uma mentalidade de asilo, você provavelmente vai ter alguém que está em conformidade ou informação s falando com seus auditores, eles vão ter que traduzir isso através de uma ou duas camadas para o lado da engenharia que espero que vai implementar tudo o que é apenas. E então todas as provas e a digitalização e tudo o que você precisa para fornecer de volta aos seus outros, boa sorte.
Se isso realmente se traduz, todos nós jogamos o velho jogo de rumores da escola primária é um tipo semelhante de função em que se você tem equipas integradas que estão trabalhando com os auditores que sabem imediatamente como traduzir isso para a tecnologia específica e você tem digitalização e você pode transformá-lo imediatamente e colocá-lo em seu conjunto de regras e digitalizar e validar em tempo real, bem como quando você está se reunindo com os auditores. Vocês têm todas as provas juntas ali mesmo. Isso é uma mudança radical no jogo. Permite que você entregue as coisas mais rapidamente aos seus clientes em vez de como Richard disse, continue mudando o seu mapa de estrada agora mesmo.
Lauren Bradley: Sim. Então, para ser mais tangível nisso, quero dizer, como é que os CISOs e os líderes da APPS podem quantificar as suas métricas para compreender as implicações de custos ou mesmo apenas o sucesso geral?
Como implementar o processo DevSecOps?
Richard Yew: O que, sabem, é engraçado porque falamos muito sobre o porquê, vocês sabem o quê, mas vamos mergulhar mais fundo no como, porque eu sei isso, é para isso que grande parte da nossa audiência serve. Não estamos aqui para vos dar declarações fofas e de alto nível. O que esperamos fornecer é um pouco de valor para quando se trata de como implementar isso.
Então, talvez possamos destacar o gráfico do DevSecOps que temos, e então podemos como se fosse apenas analisar como podemos otimizar os passos. Tudo bem. Então, como podem ver os testes de segurança tradicionais, sabem, como se fossem corridas de forma linear, certo? É como quando estamos a falar de cascata, como o vosso plano, vocês têm, beleza, um teste, certo?
Muitos testes de segurança foram feitos durante a fase de monitorização do operador. Então, está do lado direito. Então, agora que o novo conceito é, se avançarmos nas próximas fotos, certo? É que você pode encontrar 100 variedades diferentes deste gráfico. Tipo, quando você apenas Google DevSecOps hoje, como Mike disse anteriormente, este conceito existe, sabem, há 7 anos, certo? Vocês sabem que algumas organizações podem não chamar esse ciclo. Algumas organizações chamam-lhe AppSec, certo? Por isso, certas organizações vão chamar-lhes um canal de segurança. Portanto, esta é uma representação aproximada do que um gasoduto de segurança representa. Certo? Então, desde o início, você tem na fase de planeamento, certo?
Você tem a análise de ameaças de modelagem de ameaças. Você tenta garantir que você tenha feito toda essa modelagem enquanto está projetando soluções. Assim como, enquanto você codifica, como você vai para uma segunda fase, a sua fase de codificação, certo? Você quer ter certeza de que você tem o viciado. Você quer ter certeza de que você tem um IDE seguro, que está sempre em tempo real, enquanto os desenvolvedores que escrevem o código capturaram alguns dos problemas em tempo real. Obviamente, isso não é uma bala de prata, certo? Mas é uma camada adicional e estamos a falar de camadas adicionais nos ciclos de defesa profunda. Agora, à medida que avançamos cada vez mais no processo, certo? Depois de se comprometer com o código, certo? Você quer ter certeza de que tem um processo – quem é capaz de fornecer, uh, uma digitalização estática de todo o seu código para garantir que eles verificam a dependência automática, a cadeia de suprimentos, vulnerabilidade, etc, juntamente com a análise de compensação de software para criar uma visualização de software de materiais que mostram que tipo de versão do software você está usando? Quantos anos têm?
Porque, sabem, não sei, li apenas uma estatística há uma ou duas semanas – 25% dos downloads do Apache Log4j ainda está fora da versão mais antiga que ainda contém uma vulnerabilidade. Perplexo-me que ainda é uma estatística, sabem, agora que estamos quase dois anos. Não sei, foi dois ou três anos a partir do momento em que a primeira vulnerabilidade de dias zero do Apache Log4j foi anunciada no início de dezembro? Era 2021? Então, é realmente algo que precisamos nos concentrar em fazer melhor e ter esse tipo de conversa/análise de software em vigor para garantir que você sabe exatamente qual versão do software você está executando.
É importante. Então, vamos em direção aos testes, certo? Você quer ter certeza de que tem testes internos, você tem seus testes dinâmicos, você sabe, implementados para garantir isso. Podemos testar a aplicação que está em execução e ver se existe algum tipo de vulnerabilidade que possa ser explorada.
Vocês sabem que isso geralmente é feito através de fuzing. Agora, o que não é mostrado aqui em um ciclo DevSecOps tradicional? Porque tudo isto parece uma prática bastante padrão da indústria, certo? À medida que avançamos para a direita para implantar, monitorar, responder. Historicamente, colocaria firewall de aplicações web, gestor de bots, títulos de API, todas as suas soluções de proteção de API de aplicações web na fase de resposta e monitorização, certo? É quando monitorizamos o tráfego de produção, garantimos que não há exploração.
Mas o que é algo a considerar é mover algumas das proteções da API de aplicativos web que você tem em vigor. Mude-os para a esquerda também. Colocá-los neste caso, na imagem, é um passo em frente. Coloque-os na fase de teste enquanto você está fazendo o seu teste de segurança dinâmico de aplicativos, certo? Por que não os testa através do seu mecanismo de segurança de produção? Então, sabem, na verdade quanto de uma vulnerabilidade existe entre o código, quantas dessas vulnerabilidades podem ser mitigadas, porque o importante é que estamos sempre a tentar encontrar maneiras de melhorar os ciclos de vida atuais do ciclo de vida do aplicativo fazendo um desenvolvimento funcionar mais rápido. Uma prática geral quando se encontra uma vulnerabilidade de segurança durante esse teste é que basicamente se pára o comboio. Você volta, certo? Corrigimos o código, liberamo-los novamente. Você passa pelos oito passos novamente. Mas e se eu vos dissesse que talvez haja uma maneira de dizerem: “Ei, não vamos parar o comboio?”
Vamos continuar o comboio. Vamos lançá-lo, tendo uma espécie de teste adicional com soluções de segurança na frente do quarto passo que lhe permitirá saber com antecedência o que fazer praticamente patches na produção para que não tenha que parar o seu treino. Você continua o seu comboio. Vocês mantêm a sua velocidade.
Liberamos o código com o patch virtual em vigor para mitigar a vulnerabilidade, e depois corrigimos-os no próximo ciclo, espero, o que acontecerá muito rapidamente. Esta é também uma dessas formas, as formas inovadoras que queremos, sabem, educar e trabalhar com os nossos clientes para tentar melhorar o fluxo de trabalho de segurança CICD existente.
Michael Grimshaw: Eu adoro isso, Richard. Eu amo você chamando o fato de puxar, puxar isso para a esquerda. Então, apenas para o seu ponto é se o seu plano de jogo é, oh, vamos colocar isto em produção e então vamos nos preocupar com isso. Você vai ter problemas e ter algo que pode mitigar que pode cobrir a sua parte traseira, tanto através do seu processo de desenvolvimento, implantação e operações. Eu adoro o que vocês chamaram por aí. E uma analogia, e uma analogia semelhante, eu diria, seria como o Macaco do Caos. Aqui está a coisa. Se você tem Chaos Monkey trabalhando em produção, e a única vez que você está lidando com Chaos Monkey é quando ele está em produção, você vai ter um desenvolvimento horrível e experiência operacional.
Você tem que planear, projetar, e projetar para isso bem antes que ele atinja a produção. Caso contrário, você vai estar na miséria.
Quantificar Métricas para compreender as implicações de custos e o sucesso
Richard Yew: Sim, e Lauren, gosto de responder a perguntas anteriores, como medimos o sucesso agora que olhamos para todo o ciclo de vida do DevSecOps e como podemos otimizá-lo. Qual é a melhor prática, certo?
Muito rapidamente. Então conseguimos acompanhar o sucesso. Então, obviamente, você precisa ser capaz de quantificar o sucesso. Certo. Então, sabem, há algumas das métricas que podem ajudar se você é um líder de segurança e está tentando medir o sucesso dos programas de segurança de aplicativos, uma das coisas que você pode ver, também é o quê, quanto da cobertura de aplicativos você tem, certo?
Então, por exemplo, você tem mais de 90/95% de todas as suas aplicações ou aplicações voltadas para a internet em todas as suas organizações cobertas pelo mesmo processo? Tem o mesmo processo padronizado de cobertura? Certo. Que tudo, incluindo composição de software, análise, SAS, teste, teste, teste, você sabe, como aplicação web, proteções de API.
Vocês têm essas coisas em vigor para manter a cobertura de rastreamento? Com que frequência libertam e com que frequência têm de recuar? Em que fase, por causa da vulnerabilidade de segurança que detetamos e com que frequência é necessário recuar na fase de produção, em vez da frequência com que é necessário recuar durante a fase de confirmação de código, na qual se está a fazer análises estáticas, porque obviamente se está a reverter as produções.
Vai ser muito mais caro do que corrigir o código depois de um pouco de análise estática de código. Certo. As outras duas estatísticas lá, você definitivamente quer medir como, como Lauren aludiu anteriormente. O tempo médio da indústria para detetar o que chamamos de MTTD é de 200 dias. Então, acredito que com isto com o processo certo com o processo de mudança para a esquerda, você pode reduzir drasticamente entretanto para detetar, para muito mais curto. Então, tente começar a juntar métricas para detetar quanto tempo demora de uma divulgação de vulnerabilidade para detetar aqueles edifícios dentro das suas organizações.
E também implementar entretanto a resposta, certo? MTTR entretanto para resolver entretanto as resoluções, certo? A média da indústria é de 70 dias, portanto, 70 dias depois de a vulnerabilidade ser encontrada, certo? Explorada Ainda leva uma organização média de 70 dias para resolver isso. Mas com este rastreamento inicial, com que rapidez é que se consegue resolver? Assim que você encontrar uma versão vulnerável de logs para J usando seu código na análise de composição de software, com que rapidez você pode fazer o patch virtual com um firewall, ou com que rapidez você pode ir e atualizar suas bibliotecas para usar um software diferente, certo? Então, medindo isso em uma organização muito madura, falei com algumas organizações que realmente têm o que estamos falando de quatro horas de tempo médio para resolver o tempo para o evento log4j.
Isso é extremamente impressionante. E isso fala da maturidade dos seus processos DevSecOps. Então, eu já vi todos os tipos. E eu vi organizações de clientes que têm semanas ou mesmo meses de tempo para resolver problemas críticos como log4j. Portanto, é muito importante manter essas métricas em mente enquanto tentamos melhorar o processo como um todo.
Michael Grimshaw: E há alguns outros KPIs que quero ser apresentados aqui é que, como no lado da plataforma, quando se trata de infraestrutura ou, em muitos casos, qualquer coisa de engenharia, custo sempre foi um elemento importante aqui. Mas nos últimos anos, com taxas de juros crescentes, sabe, a torneira está tão longe quanto o dinheiro de capital de risco e muito disso realmente se seca, mas o nome do jogo e o ambiente de taxas de juros crescentes é uma batida muito lucrativa.
E há um aspeto aqui. Adoro esta técnica. Claramente, sabem, diretor de engenharia de plataformas. Eu adoro o lado técnico, mas especialmente nos últimos anos, uma grande parte de se você está trabalhando em plataforma, como eu disse, infraestrutura e coisas assim, o aspeto financeiro, e em esclarecer e fornecer feedback ao seu CFO, bem como ao seu diretor de tecnologia, tornou-se imperativo.
E assim o KPI é em torno de um custo e a receita é, este é outro, este é um aspeto importante enorme aqui também. E eu só quero chamar a atenção para algumas das coisas como esta, por exemplo, no lado da receita. Se você está sentado com uma discussão de linha vermelha, se você tem um cliente que está olhando para comprar a sua compra, mas o seu produto, você vai passar por uma linha vermelha de segurança porque a segurança está na mente de todos e seus clientes vão querer ter certeza de que eles estão protegidos.
Eles vão querer minimizar o risco deles aqui. E se vierem até ele com a mentalidade da velha escola. OH, sim, desenvolvemos coisas e depois, deixamos, certificamo-nos de que a nossa infosec as analisa e tudo isso. Tenho estado em muitas discussões sobre a linha vermelha e discussões sobre contratos, e isso simplesmente não voa mais.
O nível de questionários e questionários do departamento de risco do cliente e do departamento jurídico passou a um nível totalmente diferente de detalhe nos últimos cinco anos, muito menos 10 anos. E, ser capaz de ter uma solução totalmente integrada de shift-left para ter aplicações web e proteção de API – tudo isso. Quando estamos a falar com os advogados de outras pessoas, isto move a agulha de uma forma grande. O que é que isso significa? Isso significa que permite que você feche negócios mais rapidamente. E uma das coisas, se você não está a praticar a mudança para a esquerda ou está apenas a pensar que é a infosec como um complemento, eu encorajo você a voltar e olhar para os seus índices de fechamento e onde eles se separaram e especificamente para as discussões da linha vermelha de segurança porque esses tipos de produtos são frequentemente vistos como um centro de custos. Eles não são, eles podem desbloquear receitas e podem poupar uma enorme quantidade de dinheiro.
No início do podcast, cobrimos muitas das economias de custo em relação aos custos internos, mas há receitas em implicações beta aqui que eu acho importante chamar a atenção porque é aí que tantos olhos estão neste mundo crescente de taxas de juros.
Embrulhar
Richard Yew: Esse é um ponto excelente. Fico feliz por termos trocado um pouco de chapéus, como colocar os meus chapéus SDLC e por ter colocado o seu chapéu de negócio. Isto é ótimo. Espero que todas estas coisas que partilhámos proporcionem um pouco de valor ao nosso público.
Lauren Bradley: Muito obrigado a ambos. Acho que é uma ótima nota para acabar. Cobrimos a importância de mudar para a esquerda e como fazer efetivamente aplicações web e proteção de API no ciclo de vida do DevOps. E, claro, como medir eficazmente o sucesso. Há menos falsos positivos? Qual é a sua média resolução de tempo? Com que rapidez estão a enviar software? E você está ganhando mais receita?
Todas essas métricas são vitais para o sucesso de um negócio. Por isso, agradeço a ambos, Michael e Richard, por se juntarem a mim hoje. Foi realmente um prazer e obrigado ao nosso público também por se juntar a nós no Além do Limite. Vamos ver vocês no próximo episódio.
