Home Blogs DevSecOps: Mude para a esquerda para evitar mudar o Roteiro do Produto para a direita – Edgio
Applications

DevSecOps: Mude para a esquerda para evitar mudar o Roteiro do Produto para a direita – Edgio

About The Author

Outline

Bem-vindo ao quarto episódio de Beyond the Edge, um podcast dedicado a explorar os desafios dinâmicos enfrentados pelas empresas digitais modernas.

Neste episódio, nossa anfitriã, Lauren Bradley, gerente global de campanha, conversa com o diretor de engenharia de plataforma de Michael Grimshaw Edgio, e Richard Yew, diretor sênior de gerenciamento de produtos da plataforma de segurança Edgio, sobre mudar para a esquerda. Especificamente, como a cultura e a tecnologia mudam à medida que a proteção de aplicativos web e API se tornam uma parte nativa e inerente do seu ciclo de vida do DevOps.

"Segurança é como farinha para você assar o bolo, e quando a segurança é feita corretamente, você não pode vê-lo. Todo o ponto de segurança é quando é feito direito, ele deveria ter sido cozido e não é visível."

Uma Introdução ao Podcast Beyond the Edge de Edgio Episódio 4: DevSecOps: Shift Left para evitar mudar seu Roteiro de Produtos para a direita, hospedado por Lauren Bradley, gerente de campanha global da Edgio.

Lauren Bradley: Hey lá, e bem-vindo ao Beyond the Edge, onde nós cavamos nos prós e contras de 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 proteção de aplicativos web e API se tornam uma parte nativa e inerente do seu ciclo de vida DevOps.

Vamos começar com uma estatística chocante do Ponemon Institute. Hoje, é preciso mais, a maioria das empresas, mais de 200 dias para até detetar uma violação. Se você não está detetando uma violação rápida o suficiente, isso vai custar-lhe grande. A IBM descobriu que o custo de bugs corrigidos encontrados durante a fase de teste pode ser 15 vezes mais do que aqueles encontrados durante o projeto.

Então, para simplificar, quanto mais tempo você esperar para pegar um problema, mais ele vai custar. E não estamos apenas falando de dinheiro, retrabalho, tempo e energia podem, em última análise, mudar os roteiros dos produtos. Então, como você pode efetivamente mudar para a esquerda e evitar desperdiçar recursos valiosos e parar o seu progresso?

Juntando-nos hoje, temos Michael Grimshaw, Diretor de Engenharia de Plataformas de Edgio, e Richard Yew, Diretor Sênior de Gestão de Produtos da Plataforma de Segurança Edgio. Bem-vindo, 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 seus pensamentos iniciais sobre esse tema? Mike, vamos começar com você.

Michael Grimshaw: Absolutamente. Em primeiro lugar, deixe-me começar agradecendo, agradecendo-lhe, Lauren, por ter um interesse tão grande. Neste tópico muito importante e, e você está cavando e aumentando as conversas que tivemos e estamos tendo em torno disso, incluindo este ano aqui é, é apenas um valor inestimável e imperativo para o trabalho que estamos fazendo na indústria.

Michael Grimshaw: Esse entendimento precisa ser compartilhado de forma ampla e, e realmente apreciar o interesse. Meu nome é Michael Grimshaw. Sou Diretor de Engenharia de Plataformas 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 pensando em termos da unificação de seus aplicativos e infraestrutura 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 por porque ele move a agulha de uma maneira tão grande, quanto a segurança, quanto a rentabilidade, e muitas das áreas que são tão importantes para a nossa indústria.

E eu posso ir em torno de DevSecOps, mas deixe-me entregá-lo a Richard para sua introdução.

Richard Yew: Muito obrigado, Michael. Sim. Sim. Este é um tema muito importante. É muito próximo e caro no meu coração, porque eu pessoalmente vivi todo o processo de ciclo de vida de desenvolvimento de software, bem como traduzi-los para o negócio.

Agora, falando do que eu faço… Obviamente, como Lauren mencionou, eu executo nossas organizações de gerenciamento 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 entregar valor aos nossos clientes. E, você sabe, tudo o que obviamente incluiria como otimizar nossa prática de desenvolvimento, nossa segurança, CI CD Practice. para garantir que somos realmente capazes de entregar produtos seguros.

Direita. Isso realmente fornece valor aos nossos clientes, os entrega no prazo, nos orçamentos e garante que proporcionamos uma ótima experiência aos nossos clientes. Então, minha lente nisso é realmente olhar para todo o DevSecOps, você sabe, de uma perspetiva das pessoas – o processo em oposição à tecnologia e como podemos realmente implementar as melhores práticas, para, a indústria

O que é DevSecOps?

Michael Grimshaw: Até o seu ponto, Richard, deixe-me apenas me deixar roubar a bola lá se você não se importa.

E só acho que vamos padronizar o que queremos dizer com DevSecOps e mudar para a esquerda, certo? Havia o Gartner, aqui estão as coisas para algumas pessoas escutarem neste DevSecOps, e os termos mudam para a esquerda, mudam para a direita, etc. podem parecer relativamente novos. Isso não é novo, você sabe, não é como, oh, a coisa mais quente que acabou de acontecer há um ano.

Não, isso tem sido assar na indústria por um bom tempo. E, na verdade, o 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 no setor, apenas estendendo-se para incluir a segurança no infosec no ciclo de feedback e no ciclo de vida do seu desenvolvimento de software.

E assim, como eu disse, o Gartner estava escrevendo, escrevendo sobre isso, em 2017, e já havia sido, um processo e um movimento na indústria. Por um bom tempo antes disso. Então, estes não são conceitos novos. É, apenas uma extensão do que temos trabalhado há anos. E efetivamente o que é DevSecOps, é preciso o modelo semelhante, de DevOps, pois você tem um lado de desenvolvimento e realmente um lado de operação.

E no crux, ele está construindo em todas as suas necessidades de segurança o mais rápido possível, quero dizer, desde o início do design, construir o, você sabe, todo o processo para onde seus desenvolvedores no navio à esquerda está no lado do desenvolvimento, me desculpem, a mudança para a direita está mais no lado da observabilidade das operações. Vamos nos concentrar no lado esquerdo da mudança aqui hoje, mas é basicamente assar em seus testes de suas varreduras, e sua validação, tão cedo quanto à 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 a sete anos mais, é coisas como ter segurança, digitalizar e digitalizar seu, você sabe, 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 eu tenho dado é construir e verificar a segurança nos IDEs que seus desenvolvedores usam. É apenas um exemplo, e há muitos deles.

Para que, à medida que eles estão escrevendo seu código, eles recebem feedback imediato. OH, eu apenas deixei a porta aberta para, você sabe, preenchimento 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 eles não tenham um cliente reclamando sobre o cliente ou usuário final sendo desaprovado, você sabe, um mês depois, não, ele é tratado ali mesmo.

Mais barato, mais rápido, mais fácil no início. Richard, você ia dizer alguma coisa.

Por que mudar 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, você sabe, bem, todo mundo sabe um monte de custos operacionais, você sabe, 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 colocando muito esforço e falando sobre o porquê, você sabe, tenho certeza que vamos entrar no “como” mais tarde, mas queremos chegar em casa sobre a razão pela qual isso é tão importante porque, você sabe, 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 liberar 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 montagem de ameaças. Obviamente, não estamos dizendo que você sabe, a fase inicial do esforço de desenvolvimento iria capturar completamente todas as vulnerabilidades de segurança.

É por isso que precisamos implementar a defesa em profundidade. Mas é muito importante que você saiba, ao olhar para as oito fases, você sabe, em geral, dos ciclos de dívida, ciclos de vida de, você sabe, plano, código, construa, teste, todo o caminho para gostar de monitorar e operar. Direita. Você olha para eles quanto mais à direita você for, você sabe, como quando você encontrar uma vulnerabilidade de segurança, quanto mais caro ele vai levar, você sabe.

Para suas organizações realmente corrigir o problema. Então, estamos falando da diferença entre, você sabe, encontrar uma vulnerabilidade em uma varredura que acontece depois que você já lançou um monte de códigos para as produções versus dizer, você sabe, como fazer uma tarefa dinâmica de segurança de aplicativos no ambiente de teste para realmente detectá-la 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 patch virtual antes de liberar uma redução de código para mitigar isso. Mas, novamente, é muito importante entender que a segurança precisa ser incorporada desde a primeira etapa 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 equipes de DevOps e segurança

Lauren Bradley: Sim, e esses são realmente bons pontos, vocês. Quero dizer, do ponto de vista do usuário, o que, fora dos custos, monetariamente, isso pode significar para um DevOps ou uma equipe de segurança experimentar no dia-a-dia se eles não estão implementando isso desde o início?

E eu também quero falar sobre como implementamos de forma eficaz no ciclo de vida do DevOps.

Michael Grimshaw: Grande pergunta. Ótima pergunta. E, deixe-me ser realmente contundente na minha resposta inicial. É todos na indústria, cada CEO, CTO, CFO – todos, engenheiros, usuários – 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ê apenas vira o interrutor e todo o seu trabalho é de repente feito seguro. Isso é o que todo mundo quer, mas isso não é realidade. Ou seja, você sabe, as pessoas nos perguntam. Eu quero perguntar a eles, como está o tempo em terra de fantasia? Eu ouço que é bom. Este tipo de ano é, e se você abordar sua segurança, seu infosec, bem como seu desenvolvimento, pois isso é apenas um parafuso-on. Você sabe, “oh, eu vou comprar algumas ferramentas que eu vou parafusar depois que temos 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, você sabe, 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 ferramental de segurança e você está pronto para ir.

Isso afeta tudo, desde o seu custo até a velocidade do desenvolvedor e o custo lá para seus clientes. E, um ótimo exemplo disso é minha suspeita, quase todos que estão ouvindo este podcast em algum momento de sua carreira estiveram em uma situação em que um novo recurso ou um novo serviço ou algo assim, ou até mesmo apenas um patch e atualização foi implantado. Tudo parece bom. Tudo está funcionando 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 ser desagradados”, ou “acabamos de ter um incidente de segurança”, ou algo assim. E a razão é porque, ok, você implantou, mas talvez as varreduras não tenham terminado a execução, ou você não fez varreduras, ou você não as teve devidamente sintonizadas, e você acabou de introduzir uma enorme vulnerabilidade de segurança.

Talvez isso afete você, mas mais importante, isso afeta seus clientes. DevSecOps é sobre assar 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 maneira grande. Mas também se trata de remover a responsabilidade por sua empresa e por seus clientes.

Incorporando a segurança no DevOps – é como fazer um bolo!

Richard Yew: Com certeza. Você sabe, falando sobre, você sabe, falando sobre o cozimento, você sabe, como Mike usou tal termo totalidade coerente. Assim é tão verdadeiro. Isto é muito poderoso, esta é uma palavra muito poderosa para mostrar por que é tão importante ter isso cozido no lugar, você sabe, como eu sou conhecido dentro de Edgio para ser o cara da analogia.

Eu gosto de jogar um monte de analogia ao redor e eu sou, você sabe, eu ouvi isso grande. 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 é evangelismo. 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, você sabe, como líderes de segurança, não é apenas como, é como as pessoas muitas vezes pensam em segurança, como adicionar camadas adicionais de processo em seu fluxo de trabalho, mas você sabe, 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, você sabe, implementações de segurança adicionais que você precisa fazer para garantir a segurança da organização. Então, uma das analogias que eu ouvi que foi ótimo é que você sabe, a segurança não deve ser tratada como uma cereja no bolo, você sabe, como você faz do bolo e apenas colocar todos os picings como um último passo, você sabe, isso geralmente é o que as pessoas fazem quando não têm um fluxo de trabalho de segurança, ICD, e eles apenas implementam firewalls e, você sabe, proteção de API, qualquer que seja a última fase da fase de produção. O que deve ser, a segurança, é como farinha, você sabe, ele, deveria ter sido algo desde o início.

Segurança é como farinha para você assar o bolo. E então, quando a segurança é feita corretamente, você não pode vê-lo. E todo o ponto de segurança é quando é feito direito, ele deve ter sido cozido e não é visível. Não deve ser algo que crie desafios. Não deve ser algo que atrasa a organização.

Como analogias que, você sabe, eu costumava ajudar a mostrar ao negócio por que isso é importante é que ter um forte processo de segurança, culturas de tecnologia de segurança, é como ter freios fortes. Em um carro de corrida, você sabe por que cada supercarro lá fora tem grandes, você sabe, realmente grandes, freios extravagantes porque permite que eles corram mais rápido.

Permite-lhes travar com força. Ele permite que eles vão mais rápido e se tornam mais difíceis, certo? Ele permite que eles ganhem a corrida. Então, ter freios fortes é tão importante quanto ter um motor forte, certo? É assim que devemos olhar para a segurança em um filosófico. Você sabe, obviamente, nós falamos muito sobre altos níveis, certo? Então, obviamente, queremos, você sabe, como ir mais fundo nisso. O gist de like, 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 proporciona-lhe controlo. Há a corrente ou a estrada que temos à frente está cheia de curvas, curvas de curvas e tudo isso, e há, com certeza, há caminhos retos onde você pisou e você não toca nos freios, mas para navegar tudo, isso, aquele freio, eu acho, amor, eu amo ambas as analogias, Richard, porque essa analogia de travagem, dá-lhe o controle, dá-lhe o controle de grão mais fino quando você está enfrentando travagens, desafios, e, e coisas inesperadas.

Richard Yew: Grande apelo. A propósito eu quero esclarecer, eu não vim com essa analogia que é desse cara chamado Dr. Eric Koh. Ele tem, e ele dirige um ótimo podcast. Então, eu recomendo que todos vão assistir isso. Mas sim, acho tão apropriado ao explicar o conceito para o 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 de velocidades

Lauren Bradley: Richard, você fala sobre como você, você mencionou, você sabe, se, se é, DevSecOps está feito, certo? Você não vê isso. E, obviamente, uma dessas visibilidades gritantes é o custo. Também são equipas isoladas. Também parece que há uma desconexão entre equipes quando existem esses problemas que surgem e por que eles não foram apanhados antes?

Que processos, que comunicação não estava ocorrendo para resolver esses problemas de forma rápida ou eficaz? Então, minha pergunta para você é, você sabe, em sua experiência, qual… Você sabe, há, provavelmente há uma falta de transparência. Há uma tomada de decisão lenta, há potencial para desperdiçar recursos.

Quando você tem equipes silenciadas, quais problemas tendem a ser os mais problemáticos quando as equipes operam em silos em sua opinião?

Richard Yew: Sim, eu vou pegar este. Eu acho que uma coisa que, você sabe, eu pessoalmente experimentei em minha vida passada, certo, é que você sabe, e é quando, sabe, quando falamos de produtos semelhantes, sabe, como tipo de planeamento, é importante que, por vezes, tenha uma equipa de segurança que não está incluída na I&D, como na organização CTO.

Às vezes, em muitas organizações, observamos silos entre as equipes de segurança e a organização CTO, e você descobrirá que muitos processos foram feitos após o fato. Então, por exemplo, encontramos uma situação em que lançamos muitos produtos, liberamos muitos códigos porque não há um tipo forte de colaboração de comunicação entre as equipes de segurança e as equipes de engenharia.

O que você acabou com é que, você sabe, uma organização deve estar em conformidade. Às vezes, os exemplos específicos são que você tem equipes que vêm fazendo as varreduras como uma ou duas vezes por ano. Qual é o resultado dessas digitalizações? Bem, eu vou ser dito: “Ei Richard, nós temos que desacelerar no próximo trimestre porque acabamos de encontrar como uma centena de bugs de segurança grandes e pequenos diferentes, você sabe, como talvez, talvez como 20, como dos 20 primeiros são gravidade um e dois e acima, enquanto o resto, você sabe, é sobre, você tem que se concentrar em corrigir essas coisas.”

E há um SLA dentro da organização para você corrigir, você sabe, o que acabou acontecendo é que, ao fazer isso, você basicamente pegou meu roteiro e você apenas os jogou fora para o próximo trimestre. Portanto, não mudando para a esquerda, não fazendo realmente esse processo no lugar, apenas fazendo essas coisas apenas no lado direito, estamos essencialmente empurrando nosso roteiro, que é, você sabe, resultados geradores de receita, potencialmente que poderiam ajudar a expandir nossos negócios. Nós vamos ter potencialmente movê-lo para a direita para que possamos realmente, você sabe, gastar um quarto está tentando, 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 trocados, certo? Porque você não se desviou para a sua prática.

E algumas dessas coisas poderiam ter sido melhoradas com melhores colaborações, especialmente entre equipes de segurança de aplicativos dentro de uma organização e ainda e equipe de desenvolvimento. É por isso que vemos que muitas organizações estão começando a ter esse novo conceito. Você sabe, vocês ouviram falar sobre 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 aplicativos BP. Então, você vai começar a ouvir esses termos como O APP 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, digamos, você sabe, implementando análise de composição de software, implementando ID seguro, implementando todas as tarefas de caixa preta e branca, você sabe, durante o processo para garantir que, você sabe, possamos capturar alguns desses problemas antes, você sabe, logo no início do ciclo de vida do desenvolvimento.

Michael Grimshaw: E eu amo tudo. Ótima pergunta, Lauren. E eu amo tudo o que você acabou de dizer, Richard. Porque há um custo associado a isso. Você sabe, se as pessoas, se alguém está em um produto onde eles ouvem, esperam, você sabe, se eu mudar para a esquerda, eu não tenho que mudar meu roteiro para a direita.

Isso é música para os ouvidos deles. Mas, talvez para 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 amassar seu departamento de vendas. Você impactou seus clientes porque você tem, especialmente quando se trata de segurança, muitos clientes. Eu sei do lado da plataforma, quando falo com meus fornecedores, quero saber qual é o roteiro porque, ok, talvez eu tenha que ir aos meus auditores e eu preciso obter controle de compensação até que você libere algo em seu roteiro. Bem, se você acabou de me dizer, ok, o que eu estava esperando para ser entregue em um quarto vai ser de três quartos. Vou começar a olhar para outros fornecedores. Por quê? Porque tenho obrigações para com os meus auditores que tenho de cumprir.

E eu também amo, Richard, você trouxe auditores e realmente o processo de conformidade. Esse é outro exemplo aqui ao seu ponto, Lauren, sobre onde a silitizaçã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ê realmente não se integrou, você ainda está operando uma mentalidade de asilo, você provavelmente terá alguém que está em conformidade ou em segurança falando com seus auditores, eles vão ter que traduzir isso através de uma ou duas camadas para o lado da engenharia que, esperamos, vai implementar tudo o que pretende, e então isso é apenas para implementá-lo. E então todas as evidências 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, você sabe, esse velho jogo de rumor da escola primária é um tipo de função semelhante em que se você tiver equipes integradas que estão trabalhando com os auditores que imediatamente sabem como traduzir isso para a tecnologia específica e você tem digitalização e você pode transformá-lo imediatamente e colocá-lo no seu conjunto de regras e analise e valide isso em tempo real, bem como quando você está se reunindo com os auditores. Você tem todas as suas provas juntas bem lá. Isso é um divisor de águas radical. Ele permite que você entregue as coisas mais rapidamente aos seus clientes em vez de como Richard disse, continue mudando seu mapa de estrada agora mesmo.

Lauren Bradley: Sim. Então, para ser mais tangível nisso, quero dizer, como os CIOs e os líderes do AppSec podem quantificar suas métricas para entender as implicações de custo ou mesmo apenas o sucesso geral?

Como você implementa o processo DevSecOps?

Richard Yew: O que, você sabe, é engraçado porque falamos muito sobre o porquê, você sabe o quê, mas vamos mergulhar mais fundo no como, porque eu sei disso, é para isso que muita gente faz. Não estamos aqui para lhe dar declarações fofas e de alto nível. O que esperamos fornecer é um pouco de valor para quando se trata de exatamente como implementar isso.

Então, talvez possamos destacar o mapa DevSecOps que temos, e então podemos como se fosse apenas passar por como podemos otimizar as etapas. Tudo bem. Então, como você pode ver os testes de segurança tradicionais, você sabe, como funciona de forma linear, certo? É, é como se quando estamos falando de cachoeira, como o seu plano, você tem, beleza, um teste,

Muitos testes de segurança foram feitos durante a fase de monitoramento 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. Como, quando você apenas Google DevSecOps hoje, como Mike disse anteriormente, esse conceito já existe, você sabe, há 7 anos, certo? Você sabe que algumas organizações podem não chamá-lo desse ciclo. Algumas organizações apenas chamam de AppSec, certo? Então, certas organizações vão chamá-las de um pipeline de segurança. Então, esta é uma representação aproximada do que um pipeline de segurança representa. Certo? Então, desde o início, você tem na fase de planejamento, 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. Então, como você codifica, como você vai para uma segunda fase, sua fase de codificação, certo? Você quer se certificar de que você tem o gancho. Você quer ter certeza de que você tem um IDE seguro, que sempre está realmente em tempo real, enquanto os desenvolvedores que escrevem o código realmente capturaram alguns dos problemas em tempo real. Obviamente, isso não é uma bala de prata, certo? Mas é uma camada adicional e estamos falando de camadas adicionais nos ciclos de defesa profunda. Agora, à medida que avançamos mais e mais para baixo no processo, certo? Uma vez que você se comprometeu com o código, certo? Você quer ter certeza de que tem um processo – que é capaz de fornecer, uh, uma varredura estática de todo o seu código para garantir que eles verifiquem a dependência automática, a cadeia de suprimentos, a 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 eles têm?

Porque, você sabe, eu não garoto, eu apenas li uma estatística há uma semana ou duas – 25% dos downloads do Apache Log4j ainda está fora da versão mais antiga que ainda contém uma vulnerabilidade. Me desconcerte que ainda é uma estatística, você sabe, agora que estamos quase dois anos. Eu não sei, foi dois anos ou três anos a partir de quando 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ê saiba exatamente qual versão do software você está executando.

É importante. Então, então nos movemos para testar, certo? Você quer se certificar de que tem testes internos, você tem seus testes dinâmicos, você sabe, implementados para garantir isso. Podemos testar o aplicativo que está em execução e ver se há algum tipo de vulnerabilidade que pode ser explorada.

Você sabe que isso geralmente é feito através de fuzing. Agora, o que não é mostrado aqui em um ciclo DevSecOps tradicional? Porque tudo isso parece bastante prática padrão da indústria, certo? À medida que avançamos para implementar, monitorar, responder. Historicamente, você colocaria firewall de aplicativos web, gerenciador de bots, títulos de API, todas as soluções de proteção de API de aplicativos web na fase de resposta e monitoramento, certo? É quando você monitora seu tráfego de produção, garante que não há exploração.

Mas o que é algo a considerar é realmente mover algumas dessas proteções de API de aplicativos web que você tem no lugar. Mude-os para a esquerda também. Coloque-os neste caso, na foto, é um passo em frente. Coloque-os na fase de teste enquanto você está fazendo seu teste de segurança de aplicativo dinâmico, certo? Por que você não testá-los através do seu mecanismo de segurança de produção? Então, você sabe, na verdade quanto de uma vulnerabilidade existe entre o código, quantas dessas vulnerabilidades podem ser mitigadas, porque o importante é que estamos sempre tentando encontrar maneiras de melhorar esse ciclo de vida atual do aplicativo, fazendo um desenvolvimento funcionar mais rápido. Uma prática geral quando você encontra uma vulnerabilidade de segurança durante esse teste é que você basicamente pára o trem. Você volta, certo? Você corrige o código, você re-liberá-los. Você passa pelos oito passos novamente. Mas e se eu lhe dissesse que talvez haja uma maneira de você dizer: “Ei, não vamos parar o trem?”

Vamos manter o trem indo. Vamos liberar isso, tendo uma espécie de teste adicional com soluções de segurança na frente do passo quatro, que permitirá que você saiba com antecedência o que praticamente corrigir na produção para que você não precise parar o seu trem. Você mantém seu trem indo. Você mantém sua velocidade.

Você libera o código com o patch virtual em vigor para mitigar a vulnerabilidade e, em seguida, você os corrige no próximo ciclo, espero, o que acontecerá muito rapidamente. Essa é também uma dessas maneiras, as maneiras inovadoras que queremos, você sabe, educar e trabalhar com nossos clientes para tentar melhorar o fluxo de trabalho de segurança CICD existente.

Michael Grimshaw: Eu amo isso, Richard. Eu te amo chamando o fato de puxar, puxando isso para a esquerda. Então, apenas para o seu ponto é se o seu plano de jogo é, oh, vamos colocar isso em produção e então vamos nos preocupar com isso. Você terá problemas e terá algo que pode mitigar que pode cobrir seu backside, tanto por meio de seu processo de desenvolvimento, implantação e operações. Eu amo o que você chamou lá fora. E uma analogia, e uma analogia semelhante, eu diria, seria como Chaos Monkey. 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 planejar, projetar e projetar para isso bem antes que ele atinja a produção. Caso contrário, você estará na miséria.

Quantificando métricas para entender as implicações de custo e o sucesso

Richard Yew: Sim, e Lauren, eu gosto de responder perguntas anteriores, como podemos medir o sucesso agora que apenas 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. Direita. Então, você sabe, existem 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 que, quanto da cobertura de aplicativos você tem, e que tipo de métricas podem ser úteis.

Então, por exemplo, você tem mais de 90/95% de todos os seus aplicativos ou aplicativos voltados para a Internet em suas organizações cobertos pelo mesmo processo? Você tem o mesmo processo padronizado cobrindo? Direita. Que tudo, incluindo composição de software, análise, SAS, teste, teste, teste, você sabe, como aplicação web, proteções de API.

Você tem essas coisas no lugar para manter a cobertura de rastreamento? Com que frequência você libera e com que frequência você tem que rolar para trás? Em que fase, devido à vulnerabilidade de segurança que você deteta e com que frequência você tem que reverter na fase de produção, em comparação com a frequência com que você tem que reverter durante o, você sabe, fase de commit de código onde você está fazendo análise estática porque obviamente rolando para trás das produções.

Vai ser muito mais caro do que corrigir o código após um pouco de análise estática de código. Direita. 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, eu acredito com isso com o processo certo com o processo de mudança para a esquerda direita, você pode reduzir drasticamente no meio tempo para detetar, para muito mais curto. Então, tente começar a reunir métricas para detetar quanto tempo leva de uma divulgação de vulnerabilidade para você detetar aqueles edifícios dentro de suas organizações.

E também implementar entretanto para responder, certo? MTTR entretanto para resolver enquanto isso para resoluções, certo? A média da indústria é de 70 dias, então é de 70 dias após a vulnerabilidade ser encontrada, certo? Explorada Ainda leva uma organização média de 70 dias para resolver isso. Mas com esse rastreamento inicial, com que rapidez você pode resolver? Assim que você encontrar uma versão vulnerável de logs para J usando seu código em sua análise de composição de software, com que rapidez você pode corrigi-los 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, eu 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 de seus processos DevSecOps. Então, eu vi todos os tipos. E eu vi organizações de clientes que têm semanas ou até meses de tempo para resolver problemas críticos como log4j. Então, é muito importante manter essas métricas em mente enquanto você tenta melhorar o processo como um todo.

Michael Grimshaw: E há alguns outros KPIs que eu quero jogar aqui é que, como no lado da plataforma, quando você está lidando com 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, você sabe, a torneira é tanto quanto o dinheiro VC e muito disso realmente secando, mas o nome do jogo e o ambiente crescente da taxa de juros é uma batida acima muito rentável.

E há um aspeto aqui. Adoro este técnico. Claramente, você sabe, diretor de engenharia de plataforma. Eu amo 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 para seu CFO, bem como seu CTO tornou-se imperativo.

E assim o KPI é em torno de um custo e receita é, este é outro, este é um aspeto importante enorme aqui também. E, e eu só quero chamar algumas das coisas como esta é, por exemplo, do lado da receita. Se você está sentado com uma discussão de linha vermelha, se você tem um cliente que está olhando para comprar sua compra, mas 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 seu risco aqui. E se você vir até ele com a mentalidade da velha escola. OH, sim, nós desenvolvemos as coisas e então nós, nós deixamos, nós certificamo-nos que nosso infosec as examina e tudo isso. Eu estive em muitas discussões de linha vermelha e discussões de contrato, e isso simplesmente não voa mais.

O nível de questionários e questionários do departamento de risco do seu cliente e do departamento jurídico passou a um nível de detalhe nos últimos cinco anos, muito menos 10 anos. Além disso, ser capaz de ter uma solução totalmente integrada shift-left para ter aplicativos da Web e proteção de API – tudo isso. Quando você está falando com os advogados de outras pessoas, isso move a agulha de uma maneira grande. O que isso significa? Isso significa que permite que você feche negócios mais rapidamente. E uma das coisas se você não está praticando o SHIFT Left ou você está apenas pensando que é infosec como um complemento, eu encorajo você a voltar e olhar para suas proporções de fechamento e onde eles se separaram e especificamente olhar 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 a receita e eles podem economizar uma enorme quantidade de dinheiro.

No início do podcast, cobrimos muitas economias de custo em relação aos custos internos, mas há receita em implicações beta aqui que eu acho importante para chamar, porque é aí que tantos olhos estão neste mundo crescente de taxas de juros.

Finalização

Richard Yew: Esse é um excelente ponto. Estou feliz que nós meio que trocamos chapéus um pouco, você sabe, como colocar meus chapéus SDLC e você colocar em seu, seu chapéu de negócio. Isso é ótimo. Espero que todas essas coisas que compartilhamos proporcionem um pouco de valor ao nosso público.

Lauren Bradley: Muito obrigado a ambos. Acho que é uma ótima nota para terminar. Cobrimos a importância de mudar para a esquerda e como preparar efetivamente aplicativos da Web e proteção de API para o ciclo de vida do DevOps. E, claro, como medir efetivamente o sucesso. Há menos falsos positivos? Qual é a sua média resolução de tempo? Com que rapidez você está enviando software? E você está ganhando mais receita?

Todas essas métricas são vitais para o sucesso de um negócio. Então, eu 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 em Beyond the Edge. Vamos ver você no próximo episódio.